PFC 2446 Acero PDF

Proyecto Fin de Carrera
Ingeniería de Telecomunicación
Diseño e implantación de un servidor RADIUS

basándose en servidores Kerberos
Autor: José Mª Acero Vázquez

Tutor: Germán Madinabeitia Luque
Equation Chapter 1 Section 1
Departamento de Ingeniería Telemática

Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2018
Proyecto Fin de Carrera
Ingeniería de Telecomunicación
Diseño e implantación de un servidor RADIUS

basándose en servidores Kerberos
Autor:
José Mª Acero Vázquez
Tutor:
Germán Madinabeitia Luque
Profesor colaborador
Departamento de Ingeniería Telemática

Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2018
iii
Proyecto Fin de Carrera: Diseño e implantación de un servidor RADIUS basándose en servidores Kerberos
Autor: José Mª Acero Vázquez
Tutor: Germán Madinabeitia Luque
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2018
El Secretario del Tribunal
v
A mi familia, sin su apoyo no
hubiese podido llegar hasta aquí
A mis maestros por hacer
realidad mi formación, y en
especial a Germán, por su
paciencia y ayuda en la
elaboración de este PFC
vii
Agradecimientos
Quiero agradecer a todas las personas que me han ayudado de un modo u otro a la elaboración de este
proyecto y también a que pueda llevarse a cabo. Agradezco a mi madre y hermanos su insistencia en que lo
terminase, a mi mujer insistiendo también y haciéndome ver cada día lo importante de llevarlo a buen puerto y
por supuesto a mi hija, cuya sonrisa me animaba cada día a continuar.
También quiero agradecer a la Escuela de Ingenieros de Sevilla en su inmensa labor de educarnos para el
futuro, haciendo mención especial a Germán, cuya paciencia y ayuda agradezco enormemente.
Y no me quiero olvidar de todo el personal de la subdirección de sistemas de información del Servicio
Extremeño de Salud, y en especial a mis compañeros de CDATEX que me han apoyado y ayudado en todo
momento.
A todos: ¡GRACIAS!
José Mª Acero Vázquez

Miajadas, Cáceres 2018
ix
Resumen
Vivimos en un mundo donde la autenticación de usuarios juega un papel muy importante debido a la alta
conectividad de la que disponemos y al elevado número de servicios a los que accedemos. Por ello es
importante contar con sistemas que permitan una autenticación sencilla y fiable y que se pueda adaptar a todas
las casuísticas posibles.
Este es el objetivo de este proyecto fin de carrera, responder a una necesidad que surge en un momento dado y
hacerlo cumpliendo todos los requisitos necesarios y de la forma más sencilla y eficiente posible.
Veremos cómo implantar desde cero un sistema de autenticación basado en RADIUS y Kerberos, cómo
configurarlo y finalmente cómo ejecutarlo en un entorno real.
xi
Abstract
We live in a world where user authentication plays a very important role due to the high connectivity that we
have and the high number of services we access. It is therefore important to have systems that allow simple
and reliable authentication and that can be adapted to all possible cases.
This is the objective of this final year project, to respond to a need that arises in a given moment and to do it
fulfilling all the requirements and in the most simple and efficient way possible.
We will see how to implement an authentication system based on RADIUS and Kerberos from scratch, how to
setup and execute it in a real environment.
xiii
Índice
Agradecimientos ...........................................................................................................................................ix
Resumen .......................................................................................................................................................xi
Abstract....................................................................................................................................................... xiii
Índice .......................................................................................................................................................... xiv
Índice de Tablas.......................................................................................................................................... xvii
Índice de Figuras ....................................................................................................................................... xviii
1 Introducción........................................................................................................................................... 1
2 Descripción del protocolo RADIUS ......................................................................................................... 3
2.1. Introducción...................................................................................................................................................... 3
2.1.1 Autenticación ............................................................................................................................................. 4
2.1.2 Autorización ............................................................................................................................................... 4
2.1.3 Registro ....................................................................................................................................................... 4
2.2 Propiedades del servidor RADIUS..................................................................................................................... 4
2.3 Funcionamiento del servidor RADIUS .............................................................................................................. 4
2.3.1 Formato de mensaje.................................................................................................................................. 5
2.3.2 Tipos de paquetes RADIUS ........................................................................................................................ 6
2.3.3 Clave compartida (shared-secret) ............................................................................................................ 7
2.3.4 Parejas atributo-valor ................................................................................................................................ 7
2.3.5 Diccionarios ................................................................................................................................................ 9
2.4 Métodos de autenticación................................................................................................................................ 9
2.4.1 PAP .............................................................................................................................................................. 9
2.4.2 CHAP ......................................................................................................................................................... 10
2.4.3 Extensible Authentication Protocol (EAP) .............................................................................................. 10
2.4.4 Kerberos ................................................................................................................................................... 11
2.4.5 LDAP .......................................................................................................................................................... 11
2.5 Realms.............................................................................................................................................................. 11
2.6 Hints ................................................................................................................................................................. 12
2.7 Alta disponibilidad........................................................................................................................................... 12
3 Kerberos .............................................................................................................................................. 13
3.1 Introducción ..................................................................................................................................................... 13
3.2 Descripción del protocolo Kerberos ............................................................................................................... 14
3.2.1 Pre-authentication. Ticket Granting Ticket ............................................................................................14
3.2.2 Uso de servicios. Ticket Granting Service ...............................................................................................15
4 Directorio Activo de Microsoft ............................................................................................................. 18
4.1 Introducción .....................................................................................................................................................18
4.2 Algunas definiciones........................................................................................................................................19
4.3 Cómo funciona.................................................................................................................................................20
5 Funcionamiento del sistema auto vlan y autenticación de red 802.1x ................................................. 22
5.1 Switch 3Com ....................................................................................................................................................22
5.2 Switch Cisco......................................................................................................................................................23
5.3 802.1X ..............................................................................................................................................................23
6 Necesidades del SES............................................................................................................................. 25
6.1Tipos de conexiones .........................................................................................................................................25
6.1.1 Conexiones desde la red GPRS/UMTS ....................................................................................................25
6.1.2 Conexiones desde los switches y otro equipamiento de red ...............................................................25
6.1.3 Autenticación de red usando 802.1X......................................................................................................26
6.1.4 Conexiones desde equipamiento inalámbrico ......................................................................................26
6.2 Tipos de usuarios .............................................................................................................................................28
6.2.1 Usuarios directorio activo........................................................................................................................28
6.2.2 Usuarios ocasionales ................................................................................................................................28
6.2.3 Usuarios de switches ...............................................................................................................................28
6.3 Otros requisitos................................................................................................................................................28
7 Solución adoptada: Freeradius y Kerberos........................................................................................... 29
7.1 Elementos de la solución .................................................................................................................................29
7.1.1 RADIUS ......................................................................................................................................................29
7.1.2 Kerberos ....................................................................................................................................................30
7.2 Interoperabilidad de la solución .....................................................................................................................30
7.3 Ventajas/inconvenientes ................................................................................................................................30
7.4 Instalación ........................................................................................................................................................31
7.4.1 Freeradius .................................................................................................................................................31
7.4.2 Kerberos ....................................................................................................................................................32
7.5 Configuración...................................................................................................................................................32
7.5.1 Freeradius .................................................................................................................................................32
7.5.2 Kerberos ....................................................................................................................................................37
7.5.3 Integración Freeradius/Kerberos ............................................................................................................38
7.5.4 Integración Kerberos/Directorio Activo .................................................................................................39
7.6 Ejecución y comprobación del funcionamiento de los servidores ................................................................40
7.6.1 Freeradius .................................................................................................................................................40
7.6.2 Kerberos ....................................................................................................................................................41
7.6.3 Comprobación integración Freeradius/Kerberos ..................................................................................42
7.6.4 Comprobación integración Kerberos/Directorio Activo .......................................................................42
7.7 Alta disponibilidad ...........................................................................................................................................43
8 Seguridad............................................................................................................................................. 45
8.1 RADIUS .............................................................................................................................................................45
8.2 Kerberos ...........................................................................................................................................................46
9 Configuración y comprobación del resto de equipos ........................................................................... 49
9.1Configuración de un switch .............................................................................................................................49
9.1.1 3Com 4400................................................................................................................................................49
9.2 Cisco 2960 ....................................................................................................................................................52
9.2 Configuración controladora inalámbrica.......................................................................................................54
9.3 Configuración clientes 802.1X ........................................................................................................................56
9.4 Configuración conexión inalámbrica..............................................................................................................57
xv
9.5 Comprobación acceso administración switches ........................................................................................... 59
9.5.1 3Com......................................................................................................................................................... 59
9.5.2 Cisco .......................................................................................................................................................... 59
9.6 Comprobación autenticación 802.1X ............................................................................................................ 60
9.6.1 3Com......................................................................................................................................................... 60
9.6.2 Cisco .......................................................................................................................................................... 62
9.7 Comprobación acceso inalámbrico ................................................................................................................ 62
BIBLIOGRAFÍA ............................................................................................................................................. 67
Anexo. Ficheros de configuración................................................................................................................ 68
A.1 Freeradius ........................................................................................................................................................ 68
A.1.1 clients.conf ............................................................................................................................................... 68
A.1.2 users ......................................................................................................................................................... 75
A.1.3 ./mods-enabled/eap ............................................................................................................................... 80
A.1.4 radiusd.conf ........................................................................................................................................... 102
A.1.5 ./sites-enabled/default ......................................................................................................................... 120
A.2 Kerberos......................................................................................................................................................... 142
A.2.1 /etc/krb5.conf ........................................................................................................................................ 142
A.2.2 /etc/krb5kdc/kdc.conf .......................................................................................................................... 143
ÍNDICE DE TABLAS
Tabla 2–1. Tipos de atributos 9
xvii
ÍNDICE DE FIGURAS
Figura 2-1. Formato de mensaje RADIUS 5

Figura 2-2. Formato de parejas atributo-valor 7
Figura 2-3. Formato de atributos específicos del fabricante 8
Figura 2-4. Autenticación EAP 11
Figura 3-1. Mecanismo de autenticación Kerberos. Fuente: web.mit.edu 15
Figura 3-2. Mecanismo de obtención TGS Kerberos. Fuente: web.mit.edu 16
Figura 4-1. Esquema Directorio Activo 20
Figura 5-1. Esquema funcionamiento 802.1X 23
Figura 5-2. Esquema funcionamiento RADA 24
Figura 6-1. Esquema funcionamiento WPA 27
Figura 9-1. Configuración wlan 54
Figura 9-2. Configuración servidor RADIUS 54
Figura 9-3. Configuración seguridad 55
Figura 9-4. Configuración servidor AAA 55
Figura 9-5. Configuración general 55
Figura 9-6. Configuración 802.1X 56
Figura 9-7. Configuración 802.1X 56
Figura 9-8. Configuración inalámbrica 57
Figura 9-9. Configuración inalámbrica II 58
Figura 9-10. Configuración inalámbrica III 58
xix
1 INTRODUCCIÓN
E
ste proyecto ha sido realizado para el Servicio Extremeño de Salud (en adelante SES), el organismo
público autónomo encargado de gestionar el sistema de salud público extremeño.
La idea de la instalación de un servidor RADIUS surgió a la hora de querer implantar un servicio de datos
móvil. Para ello era necesario que los usuarios que usaban el servicio se autenticasen previamente a la entrada
en la red, puesto que así lo requería el operador de telefonía móvil. Éste daba la posibilidad de hacer ellos
mismos la autenticación o bien delegarla en nosotros. Por comodidad y rapidez en la gestión de los usuarios de
este servicio se optó por la segunda opción. Ello significaba que el servidor RADIUS del SES debía de
comunicarse con el del operador. Además se decidió que tenía que comunicarse también con el directorio
corporativo que ya estaba implantado, para no tener que dar de alta en varios sitios a los usuarios.
En este punto el SES fue consciente de otras posibilidades que se abrían al incluir en su red un servidor de
autenticación, y de esta forma empezaron a surgir nuevas aplicaciones para el servidor, incluso antes de que
éste se montase. Fue necesario un estudio previo sobre todos los servidores disponibles para garantizar una
elección correcta, que cubriese las necesidades actuales y tuviese en cuenta también el futuro, puesto que las
redes del SES están en continua evolución para adaptarse a las nuevas tecnologías y a la creciente demanda de
los usuarios del sistema.
La red del SES está compuesta por una gran variedad de centros de toda índole, atendiendo tanto a su tamaño
como a su funcionalidad. Estos centros son hospitales, centros de salud, consultorios, gerencias de área, otros
edificios administrativos y otros centros de sanidad variados (centros de planificación familiar, de
drogodependencia, salud mental, sociosanitarios, etc). Todos estos centros forman una compleja Intranet con
un punto especial localizado en los Servicios Centrales del SES en Mérida. Este nodo de la red contiene el
grueso de los servidores, los enlaces externos, la salida a internet, etc. En total estamos hablando de una red
con unos 15.000 usuarios repartidos por toda la geografía de Extremadura, desde sus principales ciudades
hasta sus más recónditos pueblos.
Las nuevas funcionalidades requeridas empezaron a tomar forma: autenticación centralizada para el acceso a
los switches, routers y otro equipamiento de red, autenticación para los usuarios de las redes inalámbricas y
uso de la funcionalidad de autoVLAN que poseen los switches. La primera nos iba a permitir gestionar de una
forma única el acceso a todos los switches del SES (incluyendo los de los hospitales, centros de salud, etc).
Hasta ese momento la gestión era local a cada switch, y no era por usuario, sino que existía el mismo usuario
en todos los switches. En cuanto a la segunda funcionalidad, el SES se estaba planteando el uso de redes
inalámbricas en algunas de sus sedes, pero todavía no se había abordado el tema por no tener claro el problema
de la seguridad. Puesto que el alcance de estas redes sobrepasa las fronteras físicas de los edificios se hace
necesario establecer mecanismos de autenticación de acceso a la red, así como mecanismos de cifrado para
impedir que datos tan sensibles como los datos médicos vayan 'libremente' por el aire. Por ello se optó por
montar una infraestructura de red inalámbrica basada en control de acceso usando el protocolo 802.1X y el
protocolo de cifrado WPA2. El tercer uso aplicado, autoVLAN, es una funcionalidad que poseen los switches
para que, dependiendo de las credenciales proporcionadas por el usuario, asigne una u otra vlan, comenzando
1
2 Introducción
ya la seguridad en el nivel físico directamente, puesto que podemos tener los usuarios en vlans separadas, de
forma que no se vean entre ellos, ni siquiera a nivel 2.
Además de la autenticación de los usuarios el servidor RADIUS también permite el registro de todas las
conexiones, facilitando una auditoría posterior. Con este fin se pueden instalar en el servidor una serie de
herramientas que nos permiten obtener estadísticas de uso de los recursos, para poder comprobar su correcto
funcionamiento.
Otra posibilidad que se abrió al estudiar la propuesta fue el tema de usar Kerberos. Kerberos es un sistema
creado en el MIT (Massachusetts Institute of Technology) por el cual los usuarios, una vez identificados,
pueden acceder a distintos recursos de la red sin necesidad de volverse a autenticar de nuevo, usando un
sistema de tickets. Para ello hay que cambiar los sistemas que se quieran "kerberizar" y así poder ofrecer esta
posibilidad.
Hay que indicar que el proyecto ha sido desarrollado íntegramente en el entorno del SES. Debido a ello hay
datos que no se facilitan, tales como contraseñas, direcciones IP, etc, puesto que son datos reales muy sensibles
y que la política de seguridad del SES (y los propios contratos de trabajo de acuerdo a la LOPD) no permite
difundir.
2 DESCRIPCIÓN DEL PROTOCOLO RADIUS
E
N este capítulo vamos a explicar detalladamente en qué consiste y como es la implementación del
protocolo RADIUS.
2.1. Introducción
La amplia difusión y desarrollo de las actuales redes de telecomunicación hacen más necesario que nunca
controlar el acceso que tienen los usuarios a los distintos recursos a su disposición, puesto que el catálogo es
muy amplio y no todo el mundo necesita los mismos accesos y privilegios.
RADIUS (Remote Authentication Dial-In User Service) es un protocolo ampliamente utilizado que permite la
autenticación, autorización y el registro (accounting) de los usuarios remotos que acceden a través de un
servidor de red o servidor de acceso (conocido en la terminología anglosajona como NAS, Network Access
Server).
Originariamente fue desarrollado para el acceso remoto mediante llamada telefónica (dial-up access), pero
ahora está soportado por servidores de VPN (Virtual Private Network), puntos de acceso inalámbricos,
switches con autenticación, servidores de acceso ADSL y otros tipos de servidores de acceso. En sus inicios
fue desarrollado por la empresa Livingston Enterprises (concretamente por Steve Willins, cuyo nombre aún
hoy aparece en la RFC) en respuesta a una solicitud del servidor de acceso a internet Merit Networks. Más
tarde, Livingston se convirtió en Lucent Tecnologies y a partir de ahí trabajaron junto con Merit Networks
para formalizar el protocolo y someterlo a la aprobación de la industria. Actualmente Lucent ofrece un
servidor RADIUS gratuito, aunque no es el que utilizaremos.
RADIUS está especificado en la RFC 2865 (Remote authentication Dial-In User Service, IETF Draft
Standard) y la RFC 2866 (RADIUS Accounting, informational).
Aunque el desarrollo de RADIUS fue anterior, su funcionamiento tiene mucho paralelismo con lo que se
conoce como AAA. AAA son las siglas de Authentication, Authorization and Accounting (esto es,
autenticación, autorización y registro). Este sistema se encarga de dar respuesta a las siguientes tres preguntas:
 ¿Quién eres?
 ¿Qué servicios tienes permitidos?
 ¿Qué haces con esos servicios?
Ahora vamos a ver cómo podemos responder a estas tres preguntas.
3
4 Descripción del protocolo RADIUS
2.1.1 Autenticación
La autenticación es el proceso de verificar la identidad de una persona o máquina. Es la respuesta a la pregunta
¿quién eres? La forma más común de realizar esto es la conocida combinación de usuario y contraseña. Hoy
día hay otros métodos de autenticación más seguros (no hay que distribuir la contraseña, por ejemplo) como
pueden ser los certificados digitales y los mecanismos de infraestructura de llave pública (PKI). Más adelante
entraremos en detalle sobre los mecanismos de autenticación que usaremos.
La autenticación persigue conseguir una relación de confianza entre los dos extremos, una vez que se ha
comprobado que el usuario es válido.
2.1.2 Autorización
Por autorización podemos entender el conjunto de reglas que nos permiten decidir qué puede hacer un usuario
previamente autenticado en un sistema. Es la respuesta a la pregunta “¿Qué servicios tienes permitidos?”.
Estas reglas serán establecidas por el administrador del sistema atendiendo al perfil que tenga el usuario que
pide la autorización, dejándole usar solo los recursos que tenga asignados. Por supuesto estas reglas deben
estar incluidas en la política de seguridad de la organización.
2.1.3 Registro
Una vez que el usuario se ha autenticado en el sistema y que tiene los recursos que le han sido asignados de
acuerdo a su perfil, es interesante saber qué hace con esos recursos. Esto es el registro. Estos datos son
guardados y pueden ser utilizados posteriormente para una auditoría, una predicción sobre el uso futuro de la
infraestructura, un seguimiento del funcionamiento normal de la red, etc. RADIUS no especifica cómo se
tienen que almacenar los datos, tan solo regula los mensajes que se pasan entre el cliente y el servidor. De este
modo al implementar el servidor tenemos libertad para guardar los datos de diversos modos, por ejemplo en
archivos de texto, en una base de datos, en archivos binarios, etc.
2.2 Propiedades del servidor RADIUS

La RFC que define las especificaciones del protocolo RADIUS dicta que:
 Está basado en UDP, por lo que es no orientado a conexión.
 Usa un modelo de seguridad paso-a-paso.
 Es “sin estado”.
 Soporta autenticación PAP y CHAP vía PPP.
 Usa algoritmos MD5 para proteger las contraseñas.
 Soporta el modelo AAA.
2.3 Funcionamiento del servidor RADIUS

El funcionamiento de un servidor RADIUS se basa en el paso de mensajes desde y hacia el servidor. Estos
mensajes se pasan usando el protocolo UDP (User Datagram Protocol), en detrimento del protocolo TCP. El
puerto usado es el 1812 para los mensajes de autenticación y el 1813 para los mensajes de registro. Algunos
servidores también funcionan en los puertos 1645 y 1646, aunque generalmente esto es configurable. Esta
decisión en cuanto al uso del protocolo UDP se debe al funcionamiento en sí del protocolo, en el cual el
tiempo de espera depende sobre todo de la paciencia del usuario delante de la pantalla de login. Es más
conveniente usar un protocolo que si no recibe una respuesta instantánea envíe la petición a otro servidor a
tener que dejar un usuario esperando dos minutos debido a las retransmisiones de tcp. Solo un mensaje
RADIUS va incluido en la 'carga' (payload) del protocolo UDP.
Diseño e implantación de un servidor RADIUS basándose en servidores Kerberos 5
2.3.1 Formato de mensaje

Hemos dicho anteriormente que RADIUS se basa en el paso de mensajes, ahora vamos a ver cuál es el
formato de esos mensajes. Siguen el siguiente formato:
Figura 2-1. Formato de mensaje RADIUS
Tal y como vemos en este esquema la cabecera la componen un octeto con el campo código, otro con el
campo identifier, 2 octetos para el campo length y 8 o 16 octetos para el campo authenticator. La carga del
paquete la constituyen parejas atributo-valor, con una longitud variable
Pasamos a ver cada uno de los campos:
2.3.1.1 Code
El campo “code” es de un octeto de longitud e indica el tipo de mensaje RADIUS que se envía en ese paquete.
Los códigos válidos son:
 Access-Request
 Access-Accept
 Access-Reject
 Accounting-Request
 Accounting-Response
 Access-Challenge
 Status-Server
 Status-Client
 Reserved
Más adelante entenderemos el significado de todos estos campos
2.3.1.2 Identifier
El campo “identifier” es de un octeto de longitud y se usa para el enlazado de las peticiones iniciales y su
posterior respuesta. Es un identificador único del mensaje, que permite detectar mensajes duplicados (posibles
por el uso del protocolo UDP) junto con el puerto UDP origen y el tiempo transcurrido entre mensajes
2.3.1.3 Length
El campo “length” indica la longitud total en octetos del mensaje incluyendo cabecera y carga. Este campo se
verifica cuando el servidor recibe un paquete como medida para comprobar la integridad de los datos.
Sus valores válidos oscilan entre 20 y 4096.
Si llega un mensaje con una longitud mayor que la indicada en este campo, el servidor solo tomará la longitud
indicada en length, ignorando el resto. Si lo que llega es un paquete con una longitud menor que la indicada en
length, el paquete será descartado, sin avisar de ninguna forma este hecho.
2.3.1.4 Authenticator
El campo authenticator se usa para asegurar la integridad de los datos de carga (payload). Hay 2 tipos de
valores: los valores de petición (request) y los valores de respuesta (response). Los “request authenticators” se
usan con los mensajes Access-Request y Accounting-Request. En este caso la longitud es de 16 octetos y se
genera de una forma aleatoria para prevenir ataques. El otro tipo, el “response authenticator”, se usa en los
mensajes Access-Accept, Access-Reject y Access-Challenge. El valor de dicho authenticator se calcula usando
un hash MD5 generado a partir de los campos code, identifier, length y request-authenticator, la carga del
paquete y la 'clave compartida' (shared secret, más adelante se explicará el significado de este término).
2.3.2 Tipos de paquetes RADIUS

Pasamos a ver en detalle los distintos tipos de mensajes que maneja el protocolo RADIUS.
2.3.2.1 Access-Request
Este paquete lo envía el cliente cuando requiere los servicios de la red. El cliente envía el paquete de petición
al servidor RADIUS con una lista de los servicios requeridos. Este paquete tiene el campo 'code' igual a 1.
La carga de este mensaje puede incluir (aunque no es obligatorio, como veremos más adelante) el atributo con
el nombre de usuario que solicita el acceso. Un atributo exigido en este mensaje es la dirección IP o el nombre
del equipo de red que está haciendo la petición. También tiene que contener la contraseña del usuario, una
contraseña CHAP o un identificador de estado, pero no ambas cosas. Si la contraseña del usuario viaja por la
red lo hará en un hash MD5, no lo hace en claro, para evitar que se pueda averiguar la contraseña simplemente
capturando los paquetes.
2.3.2.2 Access-Accept
Este mensaje se envía por el servidor RADIUS al cliente para indicarle que el acceso ha sido aceptado. Si
todos los atributos enviados en el Access-Request se aceptan el servidor pondrá el campo 'code' igual a 2 y en
el campo identifier pone el valor que tenía ese mismo campo en el Access-Request. Cuando el cliente recibe el
Access-Accept lo coteja usando el campo 'identifier', descartando el paquete en caso de no coincidir.
La información incluida en la carga de este mensaje variará dependiendo de la configuración del servidor y del
cliente que haya solicitado el acceso, puesto que ofrece información acerca de los parámetros con los cuales se
acepta la conexión, y éstos dependen del mecanismo de autorización, como ya vimos anteriormente. Por
ejemplo, este mensaje podría llevar la dirección IP que se le asigna al equipo solicitante, su máscara de red,
puerta de enlace, vlan a la que pertenece el usuario, etc.
2.3.2.3 Access-Reject
Este mensaje lo envía el servidor cuando deniega el acceso solicitado por el cliente. Según la RFC que lo
regula, el servidor debe enviar siempre una respuesta al cliente, ya sea aceptando o denegando su solicitud. La
denegación puede ser debida a varios motivos: contraseña incorrecta, usuario no autorizado, etc, todo
dependerá de la configuración del servidor.
La carga de este mensaje se limita a una pareja atributo-valor que son el Reply-Message y el Proxy-State. No
puede llevar ningún otro atributo. En el Reply-Message se puede especificar el motivo por el cual se deniega el
acceso, aunque esto no está regulado, dando libertad al fabricante para poder colocar los mensajes oportunos.
2.3.2.4 Access-Challenge
Este paquete se envía desde el servidor cuando desea más información del usuario, bien sea porque recibe
información confusa o porque ésta es incompleta. Cuando el cliente recibe este mensaje responde con un
nuevo mensaje Access-Request con la información solicitada. Este intercambio de mensajes durará hasta que
el servidor tenga toda la información que necesite y ya no solicite más Access-Challenge sino que envíe un
Access-Accept o Access-Reject.
2.3.2.5 Accounting-Request
Mensaje enviado por el cliente al servidor que indica que quiere hacer un registro de la conexión. A excepción
de los atributos User-Password, CHAP-Password, Reply-Request y State, la carga de este mensaje puede
contener cualquier otro atributo de los que están permitidos en los mensajes Access-Accept o Access-Request.
2.3.2.6 Accounting-Response
Mensaje enviado por el servidor al cliente indicando que puede llevar a cabo el proceso de registro. Si esto no
fuera posible el servidor sencillamente no respondería al cliente. Al igual que pasa con el Access-Accept, el
campo identifier es igual en los paquetes de petición y respuesta, por lo que el cliente sabe qué peticiones se
han llevado o no a cabo.
Los atributos permitidos en este tipo de mensajes son el Proxy-State y cualquiera de los vendor-specific (más
adelante hablaremos sobre ellos).
2.3.3 Clave compartida (shared-secret)

La clave compartida es una contraseña conocida por el cliente y el servidor que se usa en las operaciones que
requieren cifrado de datos durante el paso de mensajes. La clave debe tener una longitud mayor de 0, pero se
recomienda que tenga una longitud de al menos 16 octetos. Esta clave nunca viaja por la red, solo se usa en
ambos extremos.
La clave compartida se define para una pareja cliente-servidor (recordando que cliente es el equipo que se
comunica con el servidor RADIUS, por ejemplo un punto de acceso wireless o una batería de modems, no
tiene por qué ser el usuario final), por lo que se puede especificar un clave compartida distinta para cada
cliente, aumentando con ello la seguridad.
2.3.4 Parejas atributo-valor

Las parejas atributo-valor que se pasan en los mensajes RADIUS son una parte esencial de estos paquetes. Por
motivos de seguridad, la RFC RADIUS restringe que ciertos atributos puedan ser usados en ciertos paquetes,
por ejemplo el atributo User-Password no está permitido en un mensaje de respuesta del servidor al cliente.
Los atributos RADIUS están definidos en las RFCs 2865, 2866, 2867, 2868, 2869 y 3162.
2.3.4.1 Formato
Las parejas atributo-valor tienen el siguiente formato:
Figura 2-2. Formato de parejas atributo-valor
Y los siguientes son los significados de cada campo

2.3.4.1.1 Number
Indica el tipo de atributo que lleva. No se pasa el nombre del atributo, solo el número (ya veremos más
adelante como podemos relacionar uno con otro con el uso de diccionarios). El número varía entre 1 y 255,
aunque hay un valor especial (el 26) que permite actuar como pasarela para los atributos específicos de los
fabricantes, de modo que el número de atributos a priori no está limitado.
2.3.4.1.2 Attribute Length
Este campo especifica la longitud del atributo, que puede ser de 3 octetos o mayor.
2.3.4.1.3 Value
Contiene el valor del atributo en sí. Este campo se requiere para cada atributo presente en la lista, incluso
aunque su valor sea NULL. La longitud depende de la naturaleza del atributo (por eso es necesario el campo
anterior).
2.3.4.2 Tipos de atributos
La RFC especifica el formato de datos de ciertos atributos. Por ejemplo, una dirección IP no puede ser un
número aleatorio, sino un conjunto de 4 números. Para cumplir con esto, cada valor correspondiente tiene
asignado un tipo, que simplemente indica qué tipo de valor es: hay 6 tipos diferentes:
 Integer (INT) Valores enteros, se toman tal como son.
 Enumerated (ENUM) Consiste también de un valor entero, pero el valor está basado en un rango de
valores configurable por el usuario, con un significado “definido”.
 IP Address (IPADDR) Es un tipo de datos de 32 bit específico para transmitir direcciones IP. Una
versión reciente del protocolo RADIUS incluye soporte para direcciones Ipv6.
 Character String (STRING) Estas cadenas de caracteres están pensadas para que sean cadenas en el
formato UTF-8. El dato se pasa como un array de caracteres.
 Date (DATE) Es un tipo de 32 bit que representa el número de segundos transcurridos desde el 1 de
Enero de 1970
 Binary (BINARY) Puede tomar el valor “0” o “1”
2.3.4.3 Atributos específicos del fabricante
El protocolo RADIUS ofrece mucha flexibilidad a los fabricantes para poder incluir sus propios atributos
específicos. Como ya hemos dicho antes, hay un atributo específico para este fin, el atributo vendor-specific,
de valor 26.
En la siguiente figura se indica cómo encaja el atributo específico del fabricante dentro del atributo estándar
RADIUS:
Figura 2-3. Formato de atributos específicos del fabricante

2.3.4.3.1 Vendor ID
Este campo son 4 octetos que representan al fabricante. Estos códigos son estándares y se definen en la RFC
como “Números asignados”. Así, cada fabricante/vendedor/desarrollador tiene un único número llamado
Network Management Private Enterprise Code o NMPEC.
2.3.4.3.2 Vendor Type
Es de un octeto de longitud e indica la funcionalidad del atributo, tal y como lo hacía el atribute number en las
parejas atributo-valor estándar. Este valor se mueve en el rango 1-255 y su significado lo define el fabricante.
2.3.4.3.3 Length
Este campo también tiene un octeto de longitud e indica la longitud total del atributo específico del fabricante,
con una longitud mínima de 7. Tiene un comportamiento idéntico al campo length de los atributos estándar.
2.3.4.3.4 Value
El valor en sí del atributo. Estos valores llevan características especiales y capacidades no estándares que cada
fabricante implementa. Su longitud viene determinada por el parámetro anterior.
2.3.5 Diccionarios
Como hemos dicho antes, en los atributos no aparece por ningún lado el nombre de éste, sino tan solo el
código que lo representa. Para los ordenadores esto puede estar bien, pero no para los humanos. Para evitar
este inconveniente se usan los diccionarios en los que se establece una relación entre el nombre del atributo y
su código de atributo. También se usan diccionarios para los atributos específicos de fabricante.
El protocolo ofrece flexibilidad a la hora de definir los diccionarios, lo único exigido es su formato y que el
servidor pueda acceder a ellos, pero se pueden almacenar en ficheros de texto, ficheros binarios, bases de
datos, etc, dependiendo de la implementación del servidor RADIUS en concreto.
Una forma posible sería usando una tabla como la siguiente, el la que se indica el número de atributo, su
nombre y su tipo:
Tabla 2–1. Tipos de atributos
# ATTRIBUTE-NAME TYPE
1 User-Name STRING
2 User-Password STRING
3 CHAP-Password STRING
…
8 Framed IP-Addres IPADDR
2.4 Métodos de autenticación

RADIUS soporta distintos protocolos para la autenticación de los usuarios. Los dos más usados son el
Password Authentication Protocol (PAP) y el CHAP (Challenge-Handshake Authentication Protocol). Otros
que también se usan son MS-CHAP (Microsoft Challenge Handshake Authentication Protocol), MS-CHAP
v2 y EAP (EAP-TLS, EAP-TTLS, EAP-MD5, EAP-PEAP, etc). También ofrece la posibilidad de usar otros
protocolos desarrollados por terceros, como por ejemplo los mecanismos de autenticación de usuario de
windows NT, Windows 2000, Linux, etc. Por lo tanto en principio podremos usar cualquier protocolo que esté
soportado por el servidor RADIUS que elijamos, puesto que no todos tienen las mismas características. Pero
gracias al uso de los atributos específicos de fabricante podemos implementar casi cualquier cosa
2.4.1 PAP
Vamos a explicar el funcionamiento de este tipo de autenticación. El cliente lee el identificador y la clave
compartida del mensaje de petición y lo envía encapsulado dentro de una secuencia hash MD5. La contraseña
original (en claro) del usuario se pasa a través de un proceso XOR. El resultado de estos dos procesos se pone
en el campo value del atributo User-Password. El servidor RADIUS hace el proceso inverso al recibir el
mensaje. Cuando la autenticación falla puede deberse a que es incorrecta bien la clave del usuario o bien la
clave compartida.
Cuando usamos PAP con RADIUS, en los paquetes de petición la única condición es que tiene que incluir el
atributo User-Password, ni siquiera el atributo User-Name es necesario en este caso.
2.4.2 CHAP
Al contrario que en el caso de PAP, en CHAP se usa el principio de que la contraseña no debe ser enviada en
claro en ningún paquete a través de la red. CHAP cifra el identificador de usuario y contraseña. La máquina
del usuario hace entonces el procedimiento de login, habiendo obtenido una llave (key, en este caso la clave
compartida) desde el cliente RADIUS de al menos 16 octetos de longitud. El cliente hace un hash de esa llave
y devuelve un identificador CHAP, una respuesta CHAP y el nombre de usuario al cliente RADIUS. El cliente
RADIUS, una vez que ha recibido toda la información anterior, pone el identificador chap en el campo
correspondiente dentro del atributo chap-password y envía una respuesta. El valor “desafío” (challenge)
obtenido se pone en el atributo chap-challenge o en el campo authenticator de la cabecera. Para autenticar al
usuario, el servidor RADIUS usa el valor chap-challenge, el identificador chap y la contraseña del usuario (que
tiene almacenada u obtiene de algún modo) y hace otro hash MD5. Este último resultado debe ser igual al
atributo CHAP-Password enviado por el usuario para que se permita el acceso del usuario, rechazándolo en
caso contrario. Hay que hacer notar que el servidor debe tener acceso a la contraseña en claro del usuario para
que este método pueda funcionar (no es un problema del protocolo RADIUS, sino del CHAP), por lo que
habrá que protegerlas adecuadamente (permisos de los ficheros implicados, políticas de seguridad, etc).
2.4.3 Extensible Authentication Protocol (EAP)

EAP fue originariamente creado como una extensión al protocolo PPP (Point to Point Protocol) para permitir
el desarrollo de mecanismos de autenticación de acceso a la red arbitrarios.
EAP está soportado en las recientes versiones de RADIUS, y en este proyecto es uno de los protocolos de
autenticación empleado, por lo que vamos a ver cómo funciona.
EAP soporta mecanismos de autenticación de clave pública/clave privada, tarjetas inteligentes (smarts cards),
contraseñas de un solo uso (one-time passwords) y Kerberos. Para soportar estas nuevas funcionalidades
RADIUS incluye dos nuevos atributos que son el EAP-Message y el Message-Authenticator.
Con los protocolos de autenticación PPP (Point to Point Protocol) como son PAP, CHAP, MS-CHAP y MS-
CHAPv2, el mecanismo de autenticación se elige durante la fase de establecimiento del enlace. Durante la fase
de la autenticación de la conexión, el protocolo elegido se usa para validar la conexión. Sin embargo, con EAP
el mecanismo de autenticación no se elige durante el establecimiento del enlace PPP. En lugar de eso, cuando
se crea el enlace, cada extremo de la conexión PPP usa un esquema específico de autenticación EAP,
conocido como 'tipo EAP'. Ejemplos de tipo EAP son EAP-CHAP, EAP-MSCHAP, EAP-PEAP, EAP-TLS
(TLS: transport level security) y EAP-TTLS.
El servidor RADIUS encapsula los paquetes EAP dentro de paquetes estándar RADIUS, usando el atributo
EAP-Message. Esto permite al servidor RADIUS “hablar” con otro servidor de autenticación usando un
protocolo estándar ya definido y sin necesidad de modificaciones en el propio protocolo RADIUS. Así se
pueden crear nuevos módulos de autenticación tanto en el cliente de acceso como en el servidor de
autenticación. Instalando las bibliotecas EAP necesarias en los dos extremos otro nuevo tipo de EAP puede ser
fácilmente soportado, sin tener que modificar el protocolo RADIUS ni los equipos intermedios que
únicamente tienen que transportar los mensajes EAP.
EAP va también asociado al protocolo de capa de enlace 802.1X. El protocolo IEEE 802.1X, un estándar
IEEE para la autenticación de red, define como EAP se soporta por los equipos 802, incluyendo puntos de
acceso 802.11b/g/n (WiFi) y switches ethernet.
Una transacción EAP ocurre del siguiente modo:
1. El cliente y el servidor de acceso a la red (en nuestro caso, puesto que vamos a usar EAP para el
acceso wireless el servidor de acceso será la controladora inalámbrica) negocian el uso de EAP a
través del protocolo de enlace correspondiente (en nuestro caso, 802.11b/g/n).
2. El servidor de acceso (controladora inalámbrica) envía un mensaje EAP-Request/Identity al cliente
para comprobar su identidad.
3. El cliente responde con un mensaje EAP-Response/Identity
4. El servidor de acceso recibe esta respuesta y se la reenvía al servidor RADIUS dentro de un mensaje
Access-Request, incluyendo la información recibida del cliente en el atributo EAP-Message.
5. El servidor RADIUS responde con un mensaje Access-Challenge que contiene un atributo EAP-
Message.
6. El servidor de acceso desencapsula este mensaje y se lo reenvía al cliente (por ejemplo, le pide el
usuario y la contraseña).
Estos pasos se repiten las veces que sea necesario hasta obtener del servidor RADIUS el correspondiente
Access-Accept o Access-Reject (recordemos que está obligado a responder, según la RFC).
Recalcar que el servidor de acceso a la red se comporta como una 'pasarela' entre el cliente final (usuario) y el
servidor RADIUS, sin realizar ningún tipo de proceso sobre los mensajes EAP, puesto que esta tarea la
realizan el cliente y el servidor RADIUS. Por lo tanto los tipos EAP no tienen por qué estar instalados en el
servidor de acceso, tan solo es necesario que éste soporte EAP como protocolo de autenticación y el paso de
mensajes EAP a un servidor RADIUS, pero no tiene que analizar ni modificar en modo alguno dichos
mensajes.
A continuación mostramos un diagrama con un ejemplo de autenticación EAP:
Figura 2-4. Autenticación EAP
2.4.4 Kerberos
Por supuesto RADIUS soporta el uso de un servidor Kerberos para delegar en él la autenticación de los
usuarios.
2.4.5 LDAP
RADIUS también soporta el uso de un servidor LDAP (Lightweigth Directory Access Protocol) para realizar
la autenticación de los usuarios. En este caso el servidor actuará como pasarela entre las peticiones del usuario
y las encaminará hacia el LDAP
2.5 Realms
Los 'realms' son identificadores que se ponen antes o después (prefijo o sufijo) del nombre de usuario,
separados de éste por un carácter prefijado como puede ser ‘@’,’ \’, o ‘/’, con la finalidad de que el servidor
RADIUS identifique qué servidor usará para la autenticación.
Mediante estos identificadores podemos realizar una función de proxy, dotando al sistema de una alta
escalabilidad. Por ejemplo, tres servidores de acceso a internet que operen en el centro, en el sur y en el norte
forman una alianza de forma que cada uno tiene su propio servidor RADIUS, pero puede ofrecer servicio a los
usuarios de las otras redes (que se identificarán usando @operador) llevando las peticiones de estos usuarios al
RADIUS correspondiente, haciendo una especie de 'roaming'. También lo podemos usar si tenemos distintos
dominios en nuestra organización y queremos que cada uno tenga un mecanismo de autenticación distinto.
2.6 Hints
El uso de hints nos permite realizar modificaciones a las peticiones que nos llegan, usando unas determinadas
reglas. Así cuando un paquete llega al servidor se comprueban esas reglas y si el paquete las cumple (por
ejemplo, un nombre de usuario, un determinado sufijo, etc) añadirle o eliminarle los atributos que estén
especificados en la regla. Esto se puede usar para asegurar la compatibilidad entre distintos servidores o entre
distintos clientes que no traten igual la información.
2.7 Alta disponibilidad

En los sistemas actuales la alta disponibilidad es algo muy importante para garantizar la continuidad del
servicio. Para conseguir alta disponibilidad se usan máquinas de respaldo (activo-activo o bien activo-backup),
redundancia geográfica, generadores eléctricos autónomos, etc. En el caso de un servidor RADIUS la alta
disponibilidad es también muy importante, ya que si el usuario no puede entrar en la red, poco importa los
servicios que en ella se ofrezcan. Por esto hay que garantizar que el servicio siempre funcione de acuerdo a sus
criterios de criticidad.
Los clientes RADIUS suelen tener la posibilidad de incluir un servidor primario y otro secundario, de modo
que si el primero cae (o no responde en el tiempo adecuado) se consulte en el segundo. Esto ya es una manera
de garantizar la alta disponibilidad.
Otro modo de tener un servicio RADIUS en alta disponibilidad es usando máquinas en cluster, de forma que
siempre haya al menos una funcionado. Podemos tener incluso máquinas funcionando en paralelo, usando
diversos métodos.
Más adelante, cuando veamos la solución adoptada para el SES estudiaremos cómo se ha resuelto el tema de la
alta disponibilidad.
3 KERBEROS
E
N este capítulo vamos a describir en detalle el sistema Kerberos, que será el sistema que realmente
autentique los usuarios en nuestro sistema.
3.1 Introducción
Kerberos es un protocolo de autenticación de redes creado por el MIT (Massachusetts Institute of Tecnology)
que permite que varios equipos de una red puedan demostrar mutuamente su identidad de manera segura. Fue
desarrollado en la década de l980 inicialmente como ‘Project Athena’. Debe su nombre a Cerbero, el perro de
tres cabezas guardián de la puerta del reino de Hades, de la mitología griega.
La identificación es mutua, de forma que tanto cliente como servidor, es decir tanto el solicitante del servicio
como el que lo ofrece, pueden asegurarse de la identidad del otro, no como ocurre en otros sistemas en los que
solo se identifica el cliente.
Kerberos se basa en criptografía de clave simétrica (los mecanismos de clave asimétrica o clave
pública/privada que se usan en la actualidad todavía no habían entrado en escena cuando se desarrolló
Kerberos inicialmente), y necesita un tercer nodo en el que confían todas las partes. Dicho tercer nodo debe
estar muy bien protegido por ser un elemento primordial en la infraestructura de Kerberos.
Antes de empezar a explicar el protocolo vamos a ver una serie de definiciones necesarias para entender el
sistema Kerberos:
 Realm: Define el dominio de autenticación o reino del que se hará cargo el servidor Kerberos. Se
suele utilizar el dominio DNS de la organización y se suele poner en mayúsculas.
 Principal: son las entidades que usan el sistema, por lo tanto pueden ser tanto máquinas como
personas:
 Usuario: usuario@REALM
 Maquina: fqdn@REALM
 Servicio: servicio/fqdn@REALM
 Ticket: Se utiliza para identificar a los principales. Los facilita el servidor Kerberos de la organización
(el autentication server de forma más precisa)
 KDC: Key Distribution Center, es la parte principal del sistema Kerberos, que distribuye los tickets
para los diferentes servicios. Se compone a su vez de autentication server (AS), ticket granting server
(TGS) y una base de datos.
 Kerberos Server: se utiliza para modificar los principales.
 Ticket granting ticket (TGT): ticket especial que se usa para poder obtener tickets adicionales para el
mismo realm. Este ticket no autoriza el acceso a ningún servicio, se utiliza para autenticar al cliente en
sí.
13
14
Kerberos
Para que Kerberos funcione correctamente es necesaria la configuración previa de un servicio DNS (Domain
Name System o servidor de nombres de dominio) y de un servicio de tiempo NTP (Network Time Protocol).
Ambos servicios ya están funcionando en el SES, por lo que obviaremos su instalación y configuración.
Kerberos funciona usando un sistema de tickets, de modo que cuando un usuario entra al sistema, Kerberos le
facilita un ticket con un período de validez determinado y es ese ticket el que permite identificar
inequívocamente al usuario en los sistemas que estén adheridos al sistema Kerberos, evitando así al usuario
tener que introducir su contraseña una y otra vez al acceder a distintos servicios. Esto también puede
conseguirse mediante un sistema “single sign on”, pero éste tiene la desventaja que la información de
usuario/contraseña viaja continuamente por la red. En Kerberos esto no ocurre.
Hemos visto que RADIUS y Kerberos usan información de usuarios. En el SES la información de los usuarios
está almacenada en un directorio corporativo de Microsoft, Active Directory o Directorio Activo. Creaermos
un sistema Kerberos partiendo de cero configurando un nuevo reino y a su vez, este servidor se comunicará
con el directorio activo para los dominios ya existentes. RADIUS recibirá la petición de autenticación, se la
pasará a Kerberos y éste la resolverá o si es necesario la redigirá al directorio corporativo.
Usando Kerberos podemos tener las siguientes ventajas:
 Poder usar “single sign on”, es decir tener que teclear una sola vez nuestra contraseña, en lugar de
tenerla que poner una y otra vez para acceder a distintos servicios.
 Asociado a lo anterior los desarrolladores de aplicaciones no se tienen que preocupar de la parte
de la autenticación y el control de los usuarios, ya que de esa parte se encargará Kerberos.
 La lista de servicios que ya están “kerberizados” es muy extensa por lo que podemos usarlos sin
problemas y además hay muchas guías y protocolos estándares (GSS-API, SSPI, SASL, etc) para
desarrollar una aplicación teniendo Kerberos en mente.
 Debido a su gran extensión y aceptación podemos usarlo en entornos mixtos, donde mixto
significa exactamente “cualquier” cosa, desde amplia variedad de sistemas operativos, elementos
de red, aplicaciones, entornos virtualizados, etc, con lo cual sea cual sea el entorno que usemos
Kerberos encajará perfectamente, ya que es fácilmente adaptable y configurable.
 La contraseña nunca viaja por la red, de ningún modo, por lo que aunque la red sea insegura
(todas lo son) nuestra contraseña estará a salvo.
 Si un usuario cambia su contraseña, el cambio hay que realizarlo (nosotros o el usuario) solo en
un sitio, no en cada servidor al que se accede.
 La autenticación de los usuarios está centralizada en un solo punto.
 Si queremos desautorizar a un usuario que ya se ha autenticado previamente lo podemos hacer.
No solo se autentica el usuario sino que también se autentica el servidor, y así el cliente sabe que el servidor
que le está atendiendo es quien dice ser, evitando con ello muchos de los ataques que se producen en las redes,
tanto desde dentro como desde fuera.
3.2 Descripción del protocolo Kerberos

La autenticación en Kerberos se da en dos etapas, y vamos a ver cuáles son.
3.2.1 Pre-authentication. Ticket Granting Ticket

En la versión 4 del protocolo el servidor estaba expuesto a ataques de fuerza bruta debido a que un atacante
podía pedir TGTs de forma recursiva usando diferentes principales, y así obtenía los tickets y posteriormente,
ya offline, podía usar la fuerza bruta para intentar averiguar la password del usuario.
Para evitar esto en la versión 5 se incluyen los métodos de pre-autenticación, que especifican que un cliente
debe identificarse frente al KDC antes de pedir un ticket granting ticket (TGT).
Y ahora se distinguen dos pasos:
1. Authentication Service Request (AS_Request). Es el primer mensaje que se envía al KDC e incluye
(en texto claro) el nombre del principal del cliente, el principal del ticket granting server, una marca de
tiempo o timestamp y el tiempo de validez solicitado (normalmente 8 o 10 horas). En este paso si la
pre-autenticación es obligatoria el KDC no envía todavía el TGT, si no que envía un mensaje de pre-
autenticación al cliente. Para esto normalmente se envía un timestamp cifrado con la clave del cliente,
y este a su vez responde nuevo con otro AS_Request incluyendo el timestamp cifrado, con lo que se
consigue la pre-autenticación y ahora sí se envía el TGT, usando el AS_Reply.
2. Authentication Service Reply (AS_Reply). El Authentication Server genera una clave de sesión
aleatoria y hace dos copias, una para el cliente que se suma a la AS_Reply y la segunda copia
permanece en el KDC, para cuando el cliente solicite acceso a los diferentes servicios en el futuro. El
TGT enviado al cliente se almacena en la caché de credenciales. El TGT está cifrado con la clave del
cliente, por lo que solo dicho cliente podrá descifrarlo. El mensaje de respuesta tiene dos partes, una
cifrada con la clave del usuario que incluye la copia de la clave de sesión para el usuario, el tiempo de
vida del ticket y el nombre del principal, y otra parte cifrada primero con la clave del servidor y
posteriormente con la clave del cliente que incluye la copia de la clave de sesión del servidor, un
timestamp del servidor, el tiempo de vida del ticket, el principal del cliente y la IP del cliente.
Como parte del TGT está cifrado con la clave del servidor, aunque realmente se almacena en el cliente, éste no
puede ver su contenido, al no conocer la clave para descifrarlo.
Podemos resumir el mecanismo de autenticación con esta imagen:
Figura 3-1. Mecanismo de autenticación Kerberos. Fuente: web.mit.edu
3.2.2 Uso de servicios. Ticket Granting Service
Una vez el usuario se ha autenticado y tiene el Ticket Granting Ticket (TGT), es hora de usar un servicio de
los que tenga permitidos, para ello requiere otro ticket que es el llamado Ticket Granting Service (TGS), que
generan los correpondientes TGS_Request y TGS_Reply, ambos cifrados por seguridad. El proceso tiene
lugar en tres pasos:
16
Kerberos
1. TGS_Request. Este mensaje consta de varias partes: el propio TGS_request que incluye el principal
del servicio que el cliente quiere usar, el TGT obtenido anteriormente y un autenticador que incluye la
clave generada por el KDC anteriormente y una marca de tiempo. Con este autenticador el KDC
puede comprobar que la petición viene de un cliente autenticado previamente, porque incluye la clave
de sesión que él mismo le generó.
2. TGS_Reply. Ahora el KDC genera unas nuevas claves (keys). El mensaje de respuesta nuevamente se
cifra con la clave generada en el proceso de autenticación, garantizando así que solo el cliente que lo
solicita puede ver el TGS. Al igual que en el proceso anterior hay una parte cifrada con la clave del
usuario que incluye una nueva clave de sesión, el tiempo de vida y el nombre del principal del
servicio. Y por otra parte, el TGS en sí mismo está cifrado primero con la clave generada en el primer
paso de autenticación y después con la clave actual de sesión recién generada e incluye la copia de la
nueva clave asociada al servicio, el tiempo de vida, un timestamp del KDC, el principal del cliente y
la IP del cliente.
3. Petición al servicio. Una vez que el cliente tiene el TGS, lo usará para contactar con el servicio y así
garantizarle que es quién dice ser y de esta forma el servicio sabrá que es un cliente válido y
previamente autorizado. Los pasos a seguir en esta fase dependen del servicio solicitado, por lo que no
entraremos en más detalles.
Podemos resumir el mecanismo de obtención del TGS con esta imagen:
Figura 3-2. Mecanismo de obtención TGS Kerberos. Fuente: web.mit.edu
Para que el servidor Kerberos autentique a un usuario, éste tiene que estar en su base de datos (que como
veremos más adelante, se puede enlazar con bases de datos ya existentes como por ejemplo un LDAP o un
Directorio Activo de Microsoft). En la base de datos de Kerberos está el ‘principal’, que viene a ser como el
“nombre de usuario/máquina” y también su contraseña.
El servicio de red frente al que se autentica el usuario también debe estar en la base de datos principal (master
database) de Kerberos. El principal de un servicio tiene el siguiente formato: servicio/instancia@realm_name.
El carácter ‘/’ separa el primary (servicio por ejemplo web, correo, etc) de la instancia (máquina o servidor que
ejecuta el servicio), y el carácter ‘@’ lo separa del nombre del realm.
Por cada servicio hay también un service key, solo conocido por el servicio y el sistema Kerberos. Dicho
service key también se almacena en la base de datos principal en el lado de Kerberos. En el lado del servidor
se almacena en los llamados keytab. Esta service key viene a ser como la contraseña del servicio por el lado
del servidor por lo que hay que almacenarla de forma segura dentro del servidor. Será la llave que se use para
cifrar la información que deba ser solo visible por el servidor.
Resumiendo lo que hemos visto en este capítulo: cuando un usuario inicia sesión en un dominio protegido por
Kerberos, el cliente manda la petición al servidor, que busca el principal del cliente en su base de datos. Si
dicho principal existe, el servidor devuelve un ticket-granting ticket (TGT), y la clave asociada, cifrada con la
contraseña del usuario para que solo este pueda verla. Entonces el cliente descifra el ticket con su contraseña y
la almacena en el almacén de tickets para poderla usar también posteriormente, mientras sea válida. Si ahora el
cliente quiere acceder a uno de los servicios del dominio, por ejemplo el correo, mira en su almacén de tickets
si tiene un ticket disponible para ello y que no esté caducado. Si no lo tiene, usa el ticket-granting ticket para
pedir al servidor Kerberos un ticket para dicho servicio. El servidor Kerberos comprueba si tiene configurado
ese servicio (comprobando si tiene un principal para ese servicio) y si es así nos da el ticket oportuno. Dicho
ticket vuelve al cliente que lo solicitó y éste lo envía al proveedor del servicio, que lo descifrará usando su
keytab, y si es válido admitirá la petición del cliente y la conexión quedará establecida.
4 DIRECTORIO ACTIVO DE MICROSOFT
E
n este capítulo vamos a describir brevemente en qué consiste y cómo funciona el sistema Directorio
Activo de Microsoft, puesto que es el sistema de directorio corporativo centralizado usado en el SES en
la actualidad.
4.1 Introducción
En una definición amplia un directorio no es más que una lista de objetos. Una guía telefónica es un buen
ejemplo de directorio, donde para cada uno de sus elementos se guarda el nombre, dirección y número de
telefóno.
Una red está formada por múltiples elementos: ordenadores, servidores, impresoras, usuarios, etc. Incluso en
una red pequeña es necesario tener control sobre todos estos elementos porque si no la tarea de administrarlos
se puede volver difícil y sobre todo muy tediosa.
Imaginemos una red de tan solo 10 ordenadores totalmente independientes unos de otros, y 10 usuarios. Si
cada uno de los usuarios quisiera iniciar sesión en cada uno de los ordenadores sería necesario establecer 100
cuentas de usuario en total, que además no tendrían nada que ver una con la otra, no tendrían ningún tipo de
sincronismo, por lo que los cambios hechos en un ordenador no se reflejarían en los 9 restantes. Por supuesto
gestionar todo eso sería un auténtico caos. Es un ejemplo un poco extremo pero hasta hace poco no distaba
mucho de la realidad.
Para resolver este tipo de problemas necesitamos una estructura de directorio corporativo centralizado y
Directorio Activo de Microsoft es una de las soluciones más utilizadas en la actualidad, debido a la gran
extensión de los servidores y sistemas operativos que lo soportan y también a su facilidad de uso. Pero hay
muchos más sistemas de similares características tanto de código abierto como propietarios. Algunos de los
más conocidos son Samba, Mandriva, Novell eDirectory, Sun Java Directory Server y OpenDS.
Directorio Activo es una base de datos central que incluye información sobre todos los elementos asociados a
la infraestructura de red: usuarios, grupos, carpetas, impresoras, políticas, servidores, etc.
Además de almacenar toda la información sobre los elementos también dispone de un conjunto de servicios o
facilidades que relacionan dichos elementos entre si, como que un usuario pueda iniciar sesión en una
máquina, que tenga permiso para usar una impresora, que sus ficheros se guarden en una carpeta de grupo, etc.
Todos esos servicios, facilidades y las herramientas para gestionarlos también forma parte del Directorio
Activo, puesto que sin ellos no se podría realizar la gestión.
Directorio Activo es una herramienta muy potente para llevar a cabo la gestión de una infraestructura de
equipos, porque permite tener todos los elementos bajo control y establecer reglas y políticas que facilitan la
tarea de los administradores de sistemas. Sin dicha herramienta algo tan sencillo como que un usuario se
18
conecte a una impresora determinada podría ocasionar más de un dolor de cabeza y sin embargo usando la
herramienta se convierte en una tarea muy sencilla.
Directorio Activo también permite jerarquía de usuarios en su funcionamiento, de modo que podemos tener
distintos grupos de usuario con distintos perfiles de forma que cada uno tenga acceso solo y exclusivamente a
lo que necesite para desarrollar su trabajo. La granularidad es tal que no solo podemos limitar el acceso a un
objeto en particular, sino que también se puede restringir el acceso a cada una de sus propiedades o atributos.
El servicio de directorio no solo facilita la tarea a los administradores, sino también a los usuarios. Por ejemplo
un usuario puede buscar un recurso sin saber nada acerca de los detalles del recurso, lo que le simplifica su
trabajo diario.
4.2 Algunas definiciones

Antes de continuar, para entender el funcionamiento de Directorio Activo tenemos que tener claros algunos
conceptos que se se usan en este sistema:
 Objeto: cualquier elemento que pertenece al directorio, ya sea lógico (carpeta, grupo, dominio, árbol,
bosque) o físico (ordenador, impresora, servidor, etc). En general se subdividen en tres grupos:
usuarios (usuarios, grupos, departamentos, etc), recursos (carpeta compartida, impresora, etc) y
servicios (correo electrónico, acceso a internet, acceso a ficheros, configuración de programas, etc).
Por supuesto hay objetos que pueden contener a su vez otros objetos, como por ejemplo un grupo de
usuarios o el conjunto de impresoras. Dependiendo de la clase a la que pertenezca, cada objeto tendrá
una serie de características específicas, por ejemplo nombre, dirección IP, propietario, etc. Cada
objeto queda identificado a través de de un identificador único global (GUID, Global Unique
Identifier), dicho número es único y no cambia nunca en la base de datos del directorio, se crea
cuando se genera el objeto.
 Unidad Organizativa (OU por sus siglas en ingés Organizational Unit): es un tipo especial de objeto
que se usa para organizar el directorio en unidades administrables. En estas OUs podemos delegar
control administrativo. Es decir, una OU nos permite agrupar objetos para poder usarlos en su
conjunto posteriormente, por ejemplo los usuarios de un departamento, todo lo que haya en un
edificio, las impresoras de una planta, etc. Se pueden crear tantas OU como necesitemos, pero hay que
seguir un orden para que la estructura lógica represente lo que nosotros deseamos y lo haga de forma
coherente.
 Dominio: una colección de objetos que forma un subconjunto administrativo. Se le pone el nombre
usando el sistema de nombres DNS, por lo tanto es imprescindible que haya al menos un servidor
DNS funcionando en la red. En un dominio se permite aplicar políticas de grupo, pero dichas políticas
se aplican a dicho dominio, no se extienden ni hacia abajo (subdominios) ni hacia arriba.
 Árbol: conjunto de dominios que comparten un espacio de nombres común (DNS) y están
organizados según una jerarquía específica. Los distintos dominios se enlazan con relaciones de
confianza transitivas y bidireccionales. Por ejemplo si tuviéramos el dominio empresa.net y un
subdominio de la sección de ventas llamado ventas.empresa.net, la union de ambos formaría un árbol
de dominios.
 Bosque: conjunto de varios árboles que no comparten espacio común de nombres. Pueden tener
diversas relaciones de confianza entre ellos. Igual que los árboles tienen dominios con algo en común
entre ellos, en los bosques se pueden agrupar distintos árboles sin ninguna relación aparente, incluso
de organismos o empresas diferentes. Es la jerarquía superior dentro de Directorio Activo. Cada
bosque contine al menos un dominio, que será el dominio raíz del bosque. Cuando creamos el primer
dominio en nuestro sistema, éste se convierte en la raíz de un nuevo árbol y también en la raíz de un
nuevo bosque. El dominio raíz de un bosque contiene el esquema del bosque, que se comparte con el
resto de dominios.
 Relación de confianza: es el método de comunicación entre dominios, árboles y bosques. Las
relaciones de confianza permiten a los usuarios de un dominio autenticarse en otro. Las hay
20
Directorio Activo de Microsoft
unidireccionales y bidireccionales. Pueden ser transitivas (A confía B, B confía en C, por lo tanto A

confía en C) o no. También hay tipos especiales de relaciones de confianza: confianza explícita,
confianza de acceso directo, confianza entre dominios, confianza de bosque, confianza externa, etc.
 Controlador de dominio (DC): es un servidor o conjunto de ellos cuya función es la de controlar y
mantener el Directorio Activo funcionando. Hay al menos uno por cada dominio, pero lo más usual es
que haya al menos dos, para garantizar la alta disponibilidad del sistema. También es responsable de
de la autenticación de objetos dentro de su ámbito de control.
 Sitio: es un grupo de ordenadores conectados en una misma ubicación. La ubicación puede ser la
misma físicamente o estar conectada con el ancho de banda adecuado, es decir podemos tener un sitio
con equipos en dos edificios, por ejemplo. Estas agrupaciones se usan para reducir el ancho de banda
entre distintos controladores de dominio, puesto que si tenemos diferentes DC en distintas ubicaciones
tenemos que tener en cuenta el ancho de banda que se usa entre las distintas sedes, al ser un recurso
limitado.
 Partición: cada controlador de dominio puede poseer varias particiones, dependiendo de su extensión:
partición de dominio para el dominio que tiene asingado dicho DC, partición de configuración que
contiene la topología de un bosque con todos los DCs que tenga dicho bosque y partición esquema
para definir objetos de forma única en todo un bosque (puesto que la creación de un objeto es local en
cada dominio). Con la partición esquema podemos definir objetos que sean globales en el bosque, y
así no tener que configurarlos en cada uno de los dominios pertenecientes.
En la siguiente figura podemos ver cómo distintas OU pueden formar un dominio, y cómo varios de estos
dominios se pueden unir formando un árbol.
Figura 4-1. Esquema Directorio Activo
4.3 Cómo funciona

En realidad Directorio Activo es la agrupación de varios elementos que se comunican entre sí: una base de
datos LDAP, servidor de nombres DNS, servidor DHCP, también puede operar como servidor de hora NTP y
por supuesto un sistema de autenticación basado en Kerberos. Y aglutinando todo esto está el corazón del
software Directorio Activo que permite la integración de todos estos elementos, usando la consola MMC
(Microsoft Management Console).
Los objetos son independientes de su ubicación física, por lo que podemos tener por ejemplo los usuarios de
una OU repartidos entre varios edificios, y en un mismo edificio tener varias OUs, lo que da mucha
flexibilidad a la hora de establecer reglas, relaciones y políticas.
Una ventaja de usar Directorio Activo es que tanto usuarios como administradores pueden encontrar objetos
de una forma sencilla, sin tener que conocer detalles sobre el objeto en cuestión. Por ejemplo un usuario podrá
acceder a una carpeta compartida a la que tenga acceso, pero no tiene por qué saber en qué servidor está
alojada dicha carpeta ni cuáles son los detalles de su implementación.
Directorio Activo se instala en uno o más servidores de la red que actuarán como controladores de dominio. Es
una función especial que tienen los servidores con el sistema operativo de Microsoft. Para convertirlo en
controlador de dominio el administrador del sistema tiene que “promocionar” el servidor que quiere convertir.
Es una acción que se realiza de manera sencilla a través de un asistente o también se puede hacer a través de la
línea de comandos de Windows. Si alguna vez queremos que un servidor deje de ser controlador de dominio
(por ejemplo porque hemos adquirido uno con mejores características y lo queremos sustituir) hay que hacer el
proceso inverso que en terminología de Directorio Activo se llama “degradar”. Se recomienda que los
servidores que hacen de controlador de dominio no realicen además otras tareas o funciones como por ejemplo
ser un servidor web, de ficheros, etc, ya que eso podría afectar al rendimiento del sistema.
Por supuesto los controladores también se encargan de la autenticación de usuarios de su dominio, y gracias a
las relaciones de confianza un usuario de un dominio puede iniciar sesión en otro dominio que no sea el suyo.
Así el controlador de dominio se convierte en el KDC (Key Distribution Center) de su sistema Kerberos.
A los dominios se les pueden aplicar políticas de grupo que pueden incluir diversas reglas como acceso a
recursos (correo, internet, ficheros), instalación de software de forma desatendida y centralizada,
actualizaciones, cambios en los programas instalados, cambios en la configuración de los equipos, cambios
visuales, etc, ofreciendo mucha flexibilidad y control a los administradores de sistemas, siempre y cuando el
directorio esté bien definido (sobre todo su esquema lógico) y configurado.
Cuando tenemos más de un controlador de dominio la información se replica entre ellos y todos tienen la
misma importancia en la organización, son iguales entre sí. Cada controlador de dominio (DC) almacena una
copia duplicada de la base de datos del directorio y la sincronización entre ellos es automática.
Otra de las ventajas de Directorio Activo es que aisla la estructura organizativa lógica de la estructura física
real que tengamos implantada, de forma que podemos conseguir dos objetivos:
 Cambiar la estructura lógica de una red sin tener que preocuparnos de su parte física.
 Al contrario: cambiar toda la estructura física sin que ello nos obligue a cambiar la estructura lógica.
Además de lo que ya hemos visto, Directorio activo también ofrece al administrador de sistemas diversas
herramientas para facilitar su labor:
 Servicios de certificado, de modo que podemos implementar una infraestructura de clave pública o
PKI.
 Servicios de federación, para que los usuarios del Directorio Activo puedan usar un servicio de single
sign-on para acceder a distintos servicios, por ejemplo servidores web, de correo, etc.
5 FUNCIONAMIENTO DEL SISTEMA AUTO VLAN Y
AUTENTICACIÓN DE RED 802.1X
E
L sistema auto vlan de los switches nos permite asignar a los equipos que se conectan una vlan u otra
atendiendo a ciertos parámetros. Este sistema permite empezar a tratar la seguridad ya en el nivel físico
de la red. Para ello el switch tiene que soportarlo y los switches que tiene el SES (serie 4400 de 3Com y
Cisco 2960) lo soportan.
Una vez que se ha comprobado la identidad del equipo que se intenta conectar a la red se le puede conectar a la
vlan que le pertenece, no conectarlo en ninguna, o incluso desactivar (temporal o definitivamente) el puerto al
que se ha conectado el equipo, eliminando con ello la posibilidad de nuevos intentos a través de ese puerto.
La comprobación de la identidad se puede llevar a cabo de varias formas:
 con usuario y contraseña ofrecido por el usuario usando el protocolo de autenticación 802.1X.
 a través de su dirección MAC.
También se puede usar una combinación de los dos métodos anteriores.
Todo esto está incluido dentro de la llamada seguridad de puerto de los switches 3Com y Cisco que dispone el
SES, aunque por supuesto otros fabricantes también lo implementan.
5.1 Switch 3Com

Un puerto de un switch 3com 4400 puede estar configurado en los siguientes modos:
 Sin seguridad: el puerto funcionará normalmente, sin tener en cuenta nada relativo a la seguridad.
 Aprendizaje continuo: el switch va aprendiendo las direcciones MAC que se van conectando hasta
que se alcanza el número máximo de direcciones MAC permitidas. Cuando se alcanza el número
máximo permitido, se sustituye la siguiente que se vea por la primera aprendida.
 Aprendizaje automático: igual que el anterior pero al llegar al número máximo permitido, al
siguiente equipo no se le permite la conexión.
 Sin aprendizaje: solo se permite la conexión de usuarios especificados, identificados por su MAC.
 Login en red: se usa el protocolo de autenticación 802.1X. Cuando un cliente se autentica
correctamente, el puerto se habilita.
 Login seguro de red: una combinación de los dos últimos, el usuario tiene que autenticarse y
además ser un equipo válido.
 Modo RADA (siglas de Basic RADIUS Authenticated Device Access). Usa un servidor RADIUS
para la autenticación del usuario basándose en su MAC. Este modo es útil cuando no se dispone de
cliente 802.1X o no se quiere utilizar (un equipo sin la configuración 802.1X necesaria, una
impresora, etc).
22
 Modo RADA seguro. Igual que el anterior, pero además requiere que el cliente también se
autentique usando 802.1X.
 Modo Mixto: usa el modo RADA o el login de red para ofrecer acceso al cliente.
5.2 Switch Cisco

En un switch Cisco partimos de una configuración distinta debido a sus opciones de VoIP: si un puerto está
configurado para poder llevar voz sobre IP, éste funcionará, pero solo para el tráfico de voz sobre IP, incluso
aunque el usuario no se autentique, para permitir que el teléfono siempre esté operativo. Una vez visto esto, las
opciones que tenemos son las siguientes, usando autenticación bien por MAC (port security) o bien 802.1X:
 Port-security con single-host: se permite una MAC por puerto. Si el puerto cae y levanta de nuevo se
lleva de nuevo a cabo el proceso de autenticación. Si en el puerto aparece más de una MAC, el puerto
se desactiva
 Port-securty con multiples hosts: se permiten varias MAC en un mismo puerto siempre que estén
autenticadas todas; si una falla, el puerto se deshabilita. Se puede establecer un número máximo de
equipos conectados.
 Forced-authorized: el puerto siempre estará habilitado y no se llevará a cabo ninguna comprobación
 Forced-unauthorized: el puerto siempre estará sin autenticar, ignorando los intentos del cliente.
 Auto: el puerto se inicia como no autorizado cuando cambia de estado de down a up en el link, e
intenta la autenticación usando 802.1X, al igual que vimos antes en los 3Com.
5.3 802.1X
El login de red 802.1X permite controlar el acceso de usuarios habilitando o deshabilitando el puerto. Cuando
un equipo intenta acceder a la red (desde el momento en que la tarjeta de red activa el nivel de enlace) se
pregunta su identidad (para ello el equipo ha tenido que ser previamente configurado con 802.1X). Esta
identidad se envía a un servidor RADIUS para su comprobación.
En este modo de funcionamiento el switch solo permite la conexión de un equipo a cada puerto, detectando si
hay un hub o switch entre su puerto y el cliente, desactivando el puerto en ese caso.
En esta figura se muestra un esquema del funcionamiento:
Figura 5-1. Esquema funcionamiento 802.1X
Para el login de red el switch usa el protocolo EAP (Extensible Authentication Protocol).
24
Funcionamiento del sistema auto vlan y autenticación de red 802.1x
En el modo de funcionamiento RADA, en lugar de usar 802.1X se usa una lista de direcciones MAC
permitidas en el servidor RADIUS, siguiendo un esquema similar al visto anteriormente:
Figura 5-2. Esquema funcionamiento RADA

En ambos modos de funcionamiento y para ambos fabricantes (3com y Cisco) la respuesta del servidor
RADIUS incluye información suficiente para indicar al switch la vlan que tiene que asignar al usuario. Los
atributos que van en los mensajes RADIUS para este servicio son:
 Framed protocol = PPP
 Service-Type = Framed
 Tunnel-Type = VLAN
 Tunnel-Medium-Type = 802
 Tunnel-Private-Group-Id= < Identificador de VLAN o vlan_id>
El último atributo es el que especifica la VLAN. Tiene la forma de un número seguido de “u” o “t” (o ninguno
de los dos) para indicar si el puerto se asigna a la vlan 'sin etiquetar' (Untagged) o 'etiquetado' (Tagged). El
número es el identificativo de la vlan en el switch.
En los switches Cisco además tenemos la posibilidad de incluir una vlan de invitados, de forma que si el
switch no recibe respuesta a sus peticiones de autenticación 802.1x a través de los mensajes del protocolo EAP
asigna el puerto a esa vlan, donde podremos tener por ejemplo un portal de ayuda que guíe al usuario para
poder arreglar su situación, descargarse un cliente 802.1X, ponerse en contacto con el soporte técnico, etc.
6 NECESIDADES DEL SES
E
N este capítulo vamos a ver las necesidades que nuestro sistema va a tener que cumplir. Estos requisitos
están impuestos por la organización y hay que cumplirlos y tenerlos en cuenta en el diseño de la
solución.
6.1Tipos de conexiones
6.1.1 Conexiones desde la red GPRS/UMTS
El SES dispone de dispositivos móviles para ofrecer acceso a su red desde cualquier punto. Cuando estos
equipos tienen que entrar en la red del SES, lanzan una petición a un APN del proveedor de servicios móviles.
Una vez que se comprueba que esa SIM tiene permitido el acceso a la red se le pasan las credenciales a un
servidor RADIUS propio del operador, que hace de proxy hasta nuestro servidor. Cuando a éste le llega la
petición comprobará primero que el origen de la petición es válido y que la clave compartida (shared secret) es
válida. Una vez hecho esto deberá comprobar en el directorio corporativo si las credenciales del usuario son
válidas. Dependiendo del grupo al que pertenece el usuario (definido por @ seguido del nombre de grupo) le
asignará los parámetros de red que le correspondan, concretamente la dirección IP, la máscara de red asociada
a esta dirección, su puerta de enlace y los servidores DNS.
Así, el dispositivo móvil pasa a ser un dispositivo de red más en el SES, con un direccionamiento propio, que
accederá al resto de redes usando su enrutamiento y sus políticas de firewall.
Por lo tanto el RADIUS que usemos tiene que tener soporte para acceder a un directorio activo, soporte de
pools de direcciones y también soporte de grupos (realms).
6.1.2 Conexiones desde los switches y otro equipamiento de red

El servidor RADIUS también se usa para ofrecer una gestión de usuarios centralizada para el acceso a los
distintos routers, switches, firewalls y otro equipamiento de red del SES. De este modo se consiguen tres
objetivos:
 Cada usuario tiene su usuario y contraseña, no uno genérico para todos. Esto nos permite también
tener el control para saber qué usuarios han accedido a cada equipo, para auditorías posteriores.
 El cambio de usuario y contraseña solo hay que hacerlo en un servidor centralizado, no hay que ir
equipo por equipo cambiando los usuarios.
 La configuración inicial de los equipos es mucho más rápida, al no tener que definir los usuarios
manualmente en cada uno, simplemente basta dar de alta el switch en la lista de equipos
autorizados para acceder al servidor RADIUS.
 Podemos asignar distintos niveles de acceso a distintos usuarios de forma centralizada y cómoda.
Pero también nos enfrentamos a un problema en este caso: si no hay conexión con el servidor RADIUS no se
25
26
Necesidades del SES
podría entrar en el switch. Para evitar esto los equipos tienen la opción de que pasados 3 intentos de conexión
fallidos al RADIUS usan la lista de usuarios locales que tengan definidos, pero solo en ese caso extremo, y así
siempre tendremos acceso al switch, aunque para este caso extremo en los switches se configurará un único
usuario.
El funcionamiento en este caso es el siguiente: el equipo (switch) lanza la petición al servidor RADIUS,
pasándole las credenciales del usuario. El servidor RADIUS comprueba estas credenciales y si son correctas
le manda el Access-Accept al equipo y también el grado de acceso permitido (administrador, operador, etc)
dependiendo del perfil del usuario.
Con esta solución, además de agilizar el acceso a los equipos podemos mantener fácilmente un registro de las
conexiones que han tenido.
6.1.3 Autenticación de red usando 802.1X

El otro uso que se le dará al RADIUS en su uso con los switches es para la realización de auto vlan con
autenticación de red 802.1X, de forma que dependiendo del usuario que se conecte o la MAC del equipo que
hace la petición, automáticamente se le asigna una vlan u otra. Las MACs que están guardadas se tratan como
si fueran usuarios, añadiendo otro grado de seguridad más, empezando en este caso por el nivel físico.
En este caso vemos que el RADIUS elegido tiene que tener soporte para “entender” los atributos vendor-
specific de 3Com y Cisco, y también tiene que tener soporte para EAP como vimos en el capítulo anterior.
6.1.4 Conexiones desde equipamiento inalámbrico

El SES dispone de una controladora inalámbrica marca Cisco integrada en la electrónica de red central(switch
Cisco 6513) para ofrecer acceso inalámbrico. Este equipo permite la conexión de puntos de acceso
inalámbricos sin inteligencia que son manejados por la controladora. Con este equipo se simplifica muchísimo
la gestión de la red inalámbrica de un edificio o campus, independientemente del número de puntos de acceso
requeridos para ofrecer la cobertura necesaria. Mediante dicho equipo se tiene una visión y una gestión
centralizada de toda la red inalámbrica, no teniendo que configurar cada punto de acceso por separado,
permitiendo además el “roaming” de un punto de acceso a otro, de forma que el usuario siempre tendrá la
mejor cobertura disponible, aunque se mueva entre distintos puntos de acceso (por ejemplo un usuario que se
mueva dentro de un edificio irá pasando por distintos puntos de acceso, conectándose a aquel que le ofrezca
mayor cobertura, siempre y cuando la señal baje del umbral mínimo configurado).
Debido a los requisitos de seguridad exigidos por el SES en cuanto a las conexiones inalámbricas, se ha optado
por el empleo de la tecnología EAP-PEAP (mschapv2) y WPA2 (AES). Estas tecnologías consisten en una
autenticación de usuario basada en RADIUS (EAP-PEAP) y un posterior cifrado de la información transmitida
usando la tecnología WPA2 (Wireless Protected Access). En cuanto a la autenticación se ha usado EAP-PEAP
porque ofrece muy buena seguridad sin necesidad de usar certificados en el cliente, ya que esto último
complicaría mucho la tarea de los administradores y sobre todo de los usuarios, por lo que preferimos
evitarlos.
Dadas las características de los equipos del SES se hacía inviable el uso de certificados en el cliente, aunque sí
es necesaria la instalación de certificados en el servidor RADIUS, por exigencias del protocolo EAP, por lo
que montamos una CA (Certificate Authority, o Autoridad de Certificación) para poder expedir nosotros
mismos los certificados usando SSL.
Para que un PC se pueda conectar a esta red inalámbrica es necesario que disponga de un cliente de acceso que
soporte los protocolos WPA y EAP-PEAP. Los sistemas operativos actuales soportan ambos sin problemas, y
por política de seguridad el equipamiento antiguo que ya no es actualizable no se permite en el SES.
Así, cuando un cliente inicia el intento de conexión, es la controladora la quien envía sus credenciales al
servidor RADIUS. En este caso, y debido a ser EAP, solo se envía el nombre de usuario. El RADIUS
responde con un paquete de “desafío” (challenge), que la controladora le reenvía al cliente, estableciéndose
una negociación hasta que el servidor RADIUS manda el Access-Accept (o el Access-Reject en caso de no ser
un usuario válido).
Por lo tanto, para esta función el RADIUS debe proveer soporte EAP-PEAP.
6.1.4.1 WPA
Aunque no forma parte en sí del objetivo del proyecto vamos a explicar un poco el funcionamiento de WPA:
Wireless Protected Access.
Hasta hace no mucho, la única manera de proteger una red wireless (nos referimos al nivel de enlace, puesto
que en niveles superiores siempre podemos poner otro grado más de protección, como por ejemplo un túnel
IPSEC) era mediante lo que se conoce como WEP (Wired Equivalent Privacy, privacidad equivalente al
cable). Pero este protocolo se reveló inseguro, puesto que si un atacante capturaba paquetes de la red durante
un tiempo (una hora podría ser suficiente) era relativamente fácil averiguar la clave WEP usada en la red.
Además, el que haya muchos paquetes en la red y el uso de claves WEP de poca longitud todavía hace más
fácil el trabajo a los atacantes.
Para solucionar estos problemas, se creó por parte del consorcio WiFI Alliance (asociación sin ánimo de lucro
formada por más de 200 empresas que tienen como objetivo el estandarizar todo lo relacionado con las
comunicaciones inalámbricas) el WPA, que ofrece nuevos mecanismos de cifrado, así como otros mecanismos
de autenticación que generalmente van asociados a este protocolo. Recordemos que la autenticación garantiza
la identidad del usuario, mientras que el cifrado se encarga de 'ocultar' el tráfico que pasa por un enlace.
Un posible esquema de uso para WPA es el siguiente:
Figura 6-1. Esquema funcionamiento WPA

Hay que destacar que WPA se habla entre el cliente final (usuario) y el Access Point correspondiente, pero que
la comunicación entre el access point y el RADIUS no va cifrada con WPA, es decir WPA solo existe “en el
aire”.
WPA se basa en WEP para su funcionamiento, pero se diferencia en que cuando se inicia una sesión, se usa
TKIP (Temporal Key Integrity Protocol) o AES (Advanced encription standard) para obtener la clave WEP de
esa sesión. Además, esa clave WEP se cambia regularmente, evitando uno de los problemas que tenía el
protocolo WEP. Cuando se produce este cambio de clave, también se re-autentica el cliente.
La información facilitada por el servidor RADIUS se utiliza para obtener esa cambiante clave WEP. Aunque
también es posible usar WPA sin tener que utilizar RADIUS: es el llamado WPA-PSK (Pre-Shared Key), en el
que se usa una 'semilla' conocida (Pre-shared key) para ir generando esas claves. Esta solución sigue siendo
mejor que WEP porque esta clave no se usa directamente para cifrar, por lo que no viaja por la red ni se puede
obtener mediante análisis del tráfico.
Por último, indicar que hay una versión de WPA que en lugar de usar TKIP, usa CCMP (Counter Mode with
CBC-MAC Protocol). CCMP usa cifrado AES (Advanced Encription Standard). AES es más seguro que
TKIP. Si bien hemos dicho antes que WPA-TKIP es una mejora sobre el WEP, AES no tiene nada que ver con
él, son protocolos independientes.
28
Necesidades del SES
6.2 Tipos de usuarios

6.2.1 Usuarios directorio activo
Son usuarios pertenecientes al SES que tienen todos sus datos en el directorio corporativo. El directorio
corporativo es un Directorio Activo de Microsoft, configurado con varios servidores actuando como
controladores de dominio.
6.2.2 Usuarios ocasionales

Usuarios invitados que no pueden ser incluidos en el Directorio Activo por falta de tiempo o datos necesarios.
Aquí también se incluyen los usuarios de prueba usados por el personal del SES. Estos usuarios se crearán en
el servidor de forma local debido a su inmediatez y comodidad.
6.2.3 Usuarios de switches

Estos usuarios no pueden coincidir con los que se usarán para el resto de aplicaciones (aunque pertenezcan a la
misma persona), debido a los atributos que es necesario mandar en los mensajes RADIUS para distinguir
distintos niveles de acceso, etc. Por esta razón se crearán usuarios en el servidor RADIUS (para esto no se
usará Kerberos) expresamente para esta tarea.
6.3 Otros requisitos

Dada la criticidad de los sistemas de información del SES, la alta disponibilidad es algo imprescindible para
garantizar siempre la continuidad. En el caso del proyecto que nos ocupa, tanto el servidor RADIUS, como el
de Kerberos también tienen que estar redundados ya que si un usuario no puede entrar en la red, poco importa
los servicios que en ella se ofrezcan. Por esto hay que garantizar que el servicio siempre funcione.
Los clientes RADIUS y Kerberos suelen tener la posibilidad de incluir un servidor primario y otro secundario,
de modo que si el primero cae (o no responde en el tiempo adecuado) se consulte en el segundo. Esto ya es una
manera de garantizar la alta disponibilidad.
Otro modo de tener un servicio RADIUS en alta disponibilidad es usando máquinas en cluster, de forma que
siempre haya al menos una funcionando. Podemos tener incluso máquinas funcionando en paralelo, usando
diversos métodos.
Otra manera de garantizar la alta disponibilidad es usando balanceadores de carga para los servicios que
estamos ofreciendo, de modo que en ellos se crea un servidor virtual (virtual server) y un pool de servidores, y
es el propio balanceador el que garantiza la alta disponibilidad y el balanceo de carga.
7 SOLUCIÓN ADOPTADA: FREERADIUS Y
KERBEROS
P
ara implantar la solución se han seleccionado los sistemas que veremos a continuación, todos ellos
ejecutándose en un servidor testing de Debian, concretamente la versión Debian Buster 7.2.0-19. Se ha
elegido como S.O. Debian por su continua actualización a últimas versiones disponibles así como su
facilidad para instalar y configurar nuevos paquetes.
7.1 Elementos de la solución

7.1.1 RADIUS
Se ha seleccionado el servidor Freeradius, concretamente la última versión disponible que es la 3.0.16.
Freeradius ya no se incluye en la distribución Debian, pero como cualquier otro software se puede instalar
descargándose el paquete .tar.gz de la página www.freeradius.org e instalándolo en el servidor, lo que además
nos permite si lo deseamos ser más específicos en los parámetros de compilación, aunque en este proyecto no
lo utilizaremos ya que es suficiente con la parametrización inicial.
Sus principales características son las siguientes:
 Freeradius es uno de los servidores RADIUS más completos y modulares que existen en la
actualidad, estando entre los 5 más utilizados. Se puede utilizar tanto para pequeños sistemas
con unos pocos usuarios hasta para grandes sistemas de autenticación distribuidos. Es rápido,
flexible y muy configurable.
 Está incluido dentro del 'Freeradius Server Project', algo más que solo un servidor RADIUS.
Existe más software incluido en este proyecto, como puede ser un módulo de autenticación
PAM, un módulo de autenticación para el servidor web Apache, etc.
 Su base es muy similar al servidor RADIUS de Livingston. Muchos de sus ficheros de
configuración son similares y su uso será muy familiar para cualquiera que haya manejado
una variante del servidor RADIUS de Livingston.
 Amplio soporte de ficheros de diccionarios con atributos específicos de fabricante. Incluye
soporte para LDAP, bases de datos MySQL, PostgreSQL, Oracle, etc. También soporta
múltiples protocolos de autenticación como EAP, con EAP-MD5, EAP-SIM, EAP-TLS,
EAP-TTLS, EAP-PEAP, y Cisco LEAP.
 Tiene también soporte para actuar de proxy RADIUS, incluyendo opciones de redundancia
ante caídas y de balanceo de carga, por lo que es muy escalable.
 Puede también tener más de una entrada por defecto, siendo capaz de hacer “falling through”
hacia la siguiente.
29
30
Solución adoptada: Freeradius y Kerberos
 Soporte para poder limitar el número de usuarios simultáneos.

 Soporte para grupos (huntgroups).
 Posibilidad de uso de sentencias #INCLUDE en los ficheros de configuración.
 Ha sido escrito por un grupo de desarrolladores con décadas de experiencia en
implementaciones de software para RADIUS, ingeniería de software y desarrollo de paquetes
UNIX. El resultado es la sinergia entre muchos nombres de implementaciones RADIUS
basadas en software libre, incluyendo varios desarrolladores del proyecto Debian
GNU/Linux.
7.1.2 Kerberos
En este caso teníamos claro que la solución iba a ser la oficial de Kerberos, que no es otra que la
implementación de Kerberos hecha por el MIT, concretamente los paquetes de la versión 5 del sistema
Kerberos para la distribución Debian (versión 1.16-2).
Existen otras versiones de Kerberos como pueden ser:
 Heimdal Kerberos, versión desarrollada en Suecia y que es la más parecida y compatible con
la versión del MIT.
 Active Directory, el conocido directorio activo de Microsoft, no es una implementación de
Kerberos como tal, pero sí está basado en su funcionamiento.
 TrustBroker: es una versión comercial, desarrollada por la empresa Cybersafe.
 Shishi: una versión GNU de la implementación versión 5 de Kerberos.
Aunque hemos visto que hay otras versiones, la del MIT es la más completa, la que más tiempo lleva
desarrollándose, sobre la que hay más documentación y está implementada en más soluciones a nivel global,
tanto en sistemas operativos (Linux, Unix, Windows, etc) como en servicios adaptados para poder usar la
infraestructura.
7.2 Interoperabilidad de la solución

Por simplicidad y rapidez, se han instalado las dos soluciones en la misma máquina, con lo cual nos evitamos
tener que habilitar comunicaciones entre distintas máquinas, gestiones de usuarios, permisos, etc. En otro
entorno más extenso quizás sea más conveniente dedicar un servidor para cada propósito y en el SES no se
descarta hacerlo así en un futuro próximo, conforme se vayan añadiendo más usuarios al sistema. Esta tarea
será sencilla puesto que tan solo hay que copiar las configuraciones de cada uno de los entornos a los nuevos
servidores elegidos y establecer las comunicaciones necesarias entre ellos.
Esto nos da una idea de lo escalable que es el sistema, siempre que se requiera se pueden hacer los cambios
pertinentes para llevarlo a cabo
7.3 Ventajas/inconvenientes
Como hemos visto en la introducción, Freeradius y Kerberos soportan todo lo necesario para cumplir los
requisitos del SES. Vamos a ver las ventajas frente a soluciones comerciales. Algunas de las ventajas
expuestas no son exclusividad de los componentes elegidos, sino que son aplicables al software libre en
general.
Ventajas:
 No tienen costes de adquisición ni de licencias.
 Son productos muy escalables.
 Tiene múltiples funcionalidades

 Están en continuo desarrollo, ofreciendo nuevas funcionalidades cada poco tiempo y actualizaciones
para corregir fallos previos.
 Disponibilidad del código fuente.
Inconvenientes
 Inexistencia de soporte por parte de una empresa.
 No certificado por ningún fabricante (aunque hay empresas que ofrecen soluciones comerciales
válidas certificadas por su departamento de ingeniería, como es el caso del operador de telefonía
móvil que da servicio al SES.
 Configuración tediosa y difícil a base de ficheros de texto.
7.4 Instalación
7.4.1 Freeradius
Freeradius ya no está disponible en la lista de paquetes de Debian por lo que no hay disponibles archivos
binarios y tenemos que descargar el código fuente y compilarlo e instalarlo nosotros mismos.
Podemos usar la instalación por defecto o elegir los parámetros de compilación; esta opción es algo más
complicada, pero a cambio tendremos una versión compilada con las opciones preferidas por nosotros. Las
opciones que tenemos para la compilación son las siguientes:
--enable-shared[=PKGS] build shared libraries [default=yes]
--enable-static[=PKGS] build static libraries [default=yes]
--enable-fast-install[=PKGS] optimize for fast installation
[default=yes]
--with-logdir=DIR Directory for logfiles [LOCALSTATEDIR/log]
--with-radacctdir=PATH Directory for detail files [LOGDIR/radacct]
--with-raddbdir=DIR Directory for config files [SYSCONFDIR/raddb]
--with-threads Use threads, if available. (default=yes)
--with-snmp Compile in SNMP support. (default=yes)
--disable-ltdl-install Do not install libltdl
--with-experimental-modules Use experimental and unstable modules.
(default=no)
--enable-developer urns on super-duper-extra-compile-warnings when
using gcc
Como los parámetros por defecto son suficientes para nosotros, simplemente ejecutamos:
tar xvfz freeradius-VERSION.tar.gz
cd freeradius-VERSION
./configure
make
make install
32
Los tres últimos comandos llevarán bastante tiempo ya que en ellos se comprueba que el equipo tenga todo lo
necesario y se lleva a cabo la compilación.
Y eso ya nos crea los ejecutables y todos los ficheros necesarios para el funcionamiento del servidor. Para
poder ejecutar esos comandos nuestro sistema deberá poseer un compilador de C y el gestor de dependencias
‘make’. Si como es nuestro caso tenemos un sistema “limpio” (tan solo instalamos el sistema base de debian,
sin nada más) debemos instalarlo con los comandos:
apt-get install gcc make
El sistema de paquetes automáticamente nos instalará todo lo necesario para que funcione.
7.4.2 Kerberos
Para instalar Kerberos lo podemos hacer de forma similar a Freeradius descargándonos su código fuente y
compilándolo nosotros, o bien elegir el sistema de paquetes de Debian, que es la opción más rápida y sencilla,
ya que no existe compilación. Para la instalación del servidor son necesarios los siguientes paquetes: krb5-
kdc, krb5-admin-server, por lo que simplemente ejecutando
apt-get install krb5-kdc krb5-admin-server
ya tenemos en nuestro sistema todo lo que necesitamos.
7.5 Configuración
Primeramente vamos a ver como se configuraría cada servicio por separado y posteriormente veremos los
pasos a seguir para conseguir la integración entre ellos, que serán dos: Freeradius usa Kerberos para la
autenticación y éste a su vez lee la información de los usuarios del Directorio Activo.
7.5.1 Freeradius
Toda la configuración de Freeradius se hace en base a ficheros de texto, si bien hay alternativas que ofrecen
una gestión a través de una interfaz web, usando PHP en el desarrollo, pero esta posibilidad no está todavía lo
suficientemente rodada y carece de muchas de las funcionalidades posibles. Vamos a ver únicamente los
ficheros utilizados en este proyecto, aunque Freeradius tiene más ficheros que los aquí listados.
Como en otros ficheros de configuración de Unix y Linux un '#' al principio de una línea indica que esa línea
es un comentario y no se tiene en cuenta al leer el fichero. Usaremos estos comentarios en los ficheros para
explicar qué significa exactamente cada parámetro. Los ficheros originales también son bastante
autoexplicativos e incluyen comentarios para ayudar en la configuración.
La ruta por defecto de los ficheros de configuración es /usr/local/etc/raddb.
Indicar también que aunque Freeradius posee un montón de características y soporta múltiples protocolos
haremos las modificaciones necesarias en sus ficheros de configuración para que solo demos soporte a lo que
realmente utilizamos. Para ello “comentaremos” con ‘#’ las líneas que no nos interesen en lugar de borrarlo
por si en un futuro lo volviésemos a activar. Esto nos permitirá una ejecución y una depuración mucho más
rápida.
7.5.1.1 Fichero clients.conf
Este fichero contiene los equipos (no clientes “humanos”, sino máquinas, es decir los servidores de acceso a la
red, como pueda ser un switch o la controladora inalámbrica) autorizados para acceder al servidor RADIUS,
con su correspondiente IP, una clave compartida y una descripción. Por supuesto la clave compartida también
hay que configurarla en cada uno de los servidores de acceso a la red.
Por lo tanto en este fichero tendremos que añadir todos los equipos que tengan que hablar con el servidor
RADIUS, es decir todos los switches, controladora inalámbrica, etc.
El formato para añadir un nuevo equipo es el siguiente:

client pc_jose {
ipaddr = 10.165.18.175
secret = testing123
}
En este caso he dado de alta mi propio PC, que utilizo para lanzar pruebas.
7.5.1.2 Fichero users
En el servidor RADIUS original, al usuario que no estaba en el fichero users ni tenía una cuenta local en la
máquina del servidor (lo segundo y único que se miraba) se le denegaba el acceso. Solo había una entrada por
defecto permitida si no se encontraba el usuario en el fichero. En Freeradius existe la posibilidad de tener más
de una entrada por defecto, que el servidor va comprobando “saltando” de una a otra en su orden de aparición,
parando el proceso en caso de encontrar alguna coincidencia. Usando la opción Fall-Through=yes, le decimos
al servidor que continúe comprobando el resto del fichero, incluso habiendo encontrado ya una coincidencia,
permitiendo un control mucho mayor para establecer la coincidencia. El fichero users de Freeradius soporta
incluso espacios en blanco en el nombre de usuario.
En este fichero se almacenan varios datos del usuario como pueden ser su nombre de usuario, contraseña, tipo
de servicio, IP, etc. Para cada tipo de usuario hay distinta información que podemos añadir.
Nosotros usaremos este fichero para añadir manualmente los usuarios que no estén en el Directorio Activo,
como son los invitados y los usuarios que creemos para los switches y equipos de red y por otro lado
indicaremos también en este fichero que la autenticación del resto de usuarios (el 99,99% de ellos) se haga a
través de Kerberos como veremos más adelante en la integración de RADIUS y Kerberos.
7.5.1.3.1 Ejemplo general
Un ejemplo de usuario en este fichero sería:
steve Cleartext-Password := "testing"
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 172.16.3.33,
Framed-IP-Netmask = 255.255.255.0,
Framed-Routing = Broadcast-Listen,
Framed-Filter-Id = "std.ppp",
Framed-MTU = 1500,
Framed-Compression = Van-Jacobsen-TCP-IP
7.5.1.3.2 Usuario con solo autenticacion

Si simplemente queremos una autenticación sencilla nos basta con un usuario y la primera línea:
usuario Cleartext-Password := "contraseña"
7.5.1.3.3 Usuario red movil

Para los usuarios móviles, tenemos otro tipo de usuarios, que se definen así:
34
Movil1 Auth-Type = Local, User-Password == "passmovil1", Calling-Station-

Id=="34123456789"
Ascend-Client-Assign-DNS = 1,
Ascend-Client-Primary-DNS = 192.168.1.100
Ascend-Client-Secondary-DNS = 192.168.1.101,
Framed-IP-Netmask = 255.255.255.0
Donde el calling-station-id nos indica el número de la línea móvil usada. Y en este caso lo que hacemos es que
si ese usuario se conecta con esa línea móvil, además de permitirle el acceso, le enviaremos la información de
red correspondiente, es decir su IP, máscara de red y servidores DNS.
7.5.1.3.4 Usuario gestion switch

Si el usuario lo vamos a usar para gestionar un switch hay que indicarle el nivel de acceso, en el siguiente caso
se corresponde a un switch 3com, y usamos uno de los atributos específicos de fabricante:
admin_jose Auth-Type = Local, User-Password == "password"
3Com-User-Access-Level = 3Com-Administrator
7.5.1.3.5 Usuario 802.1X

En el caso de usar RADIUS para autenticación 802.1X con auto vlan hace falta también incluir la información
correspondiente, como por ejemplo el puerto donde este usuario se ha autenticado le asignaremos la vlan 5 sin
etiquetar (u de untagged):
jose.acero User-Password == "password"
Tunnel-Type = VLAN,
Tunnel-Medium-Type = 6,
Tunnel-Private-Group-Id = "5u"
7.5.1.3.6 Resto de usuarios

Una vez que ya tengamos especificadas todas las formas que puede tener un usuario para que el RADIUS lo
valide, añadimos esta línea al final del fichero:
DEFAULT Auth-Type := Reject
Y de esta forma cualquier usuario que no cumpla con ninguno de los parámetros que se especifican a lo largo
del fichero será rechazado, sin hacer ninguna otra comprobación.
7.5.1.3 Fichero ./mods-enabled/eap
En este fichero encontramos toda la configuración relacionada con el protocolo EAP (Extensible
Authentication Protocol). En versiones anteriores de Freeradius, esta configuración estaba incluida dentro del
fichero general radiusd.conf, pero por razones de modularidad se ha decidido ubicarlo en un fichero distinto.
Incluye toda la información necesaria para poder utilizar este protocolo desde qué tipo de autenticación EAP
usar hasta dónde se encuentran los certificados para poder garantizar la autenticidad de los mensajes EAP.
7.5.1.4 Fichero radiusd.conf
Este es sin duda el fichero más importante del servidor, ya que en él está la configuración básica y se hace la
llamada a otros ficheros. También en el fichero radiusd.conf se hace referencia a otros ficheros del sistema
operativo, del directorio de instalación del programa, etc.
Como ya hemos dicho antes, Freeradius es modular y a través de su API y de este fichero, el servidor pasa las
distintas opciones y comandos a los distintos módulos. Para entender mejor el funcionamiento del fichero
debemos saber que en Freeradius se usan los siguientes operadores:
Atributo=Valor especifica el valor de un atributo, pero solo si no hay otro 'item' del mismo atributo.
Atributo:=Valor especifica el valor de un atributo, sobreescribiendo el valor antiguo si lo tuviese
Atributo==Valor comprueba que exista el atributo y lo compara con el especificado
Atributo += Valor añade ese atributo a la lista de items
Atributo!=Valor comprueba que el atributo exista y no tenga el valor especificado.
Atributo>Valor comprueba que haya un atributo en la lista con un valor mayor al especificado
Atributo < Valor igual que el anterior, pero siendo menor el valor
Atributo <= Valor igual o menor
Atributo=~expresión comprueba que la petición contenga un atributo que cumpla la expresión.
Atributo!~expresión comprueba que la petición contenga un atributo que no cumpla la expresión.
Atributo=*valor comprueba que la petición tenga ese atributo, independientemente del valor que tenga.
Atributo!*valor comprueba que la petición no tenga ese atributo, independientemente del valor del mismo.
Mostramos a continuación las partes más relevantes del fichero, donde se definen los directorios a usar y
donde se hace la referencia al resto de ficheros de configuración:
prefix = /usr/local
exec_prefix = ${prefix}
sysconfdir = ${prefix}/etc
localstatedir = ${prefix}/var
sbindir = ${exec_prefix}/sbin
logdir = ${localstatedir}/log/radius
raddbdir = ${sysconfdir}/raddb
radacctdir = ${logdir}/radacct
confdir = ${raddbdir}
modconfdir = ${confdir}/mods-config
certdir = ${confdir}/certs
cadir = ${confdir}/certs
run_dir = ${localstatedir}/run/${name}
db_dir = ${raddbdir}
$INCLUDE proxy.conf
$INCLUDE clients.conf
modules {
$INCLUDE mods-enabled/
36
}
policy {
$INCLUDE policy.d/
}
$INCLUDE sites-enabled/
7.5.1.5 Fichero ./sites-enabled/default
Al igual que el fichero eap.conf, éste también estaba incluído en radiusd.conf, pero dada su importancia se hizo
un fichero adicional. En este fichero tenemos distintas secciones que se encargan de la pre-autorización, la
autenticación, el registro y otras acciones adicionales que se pueden ejecutar después de la autenticación, etc.
Vemos las secciones más importantes del fichero:
server default {
listen {
type = auth
ipaddr = *
port = 1812
} }
authorize {
filter_username
mschap
eap {
ok = return
}
Files
Pap
}
authenticate {
Auth-Type PAP {
pap
}
Auth-Type Kerberos {
krb5
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
eap
}
accounting {
detail
post-auth {} # en esta sección se ejecutarían acciones después de
autenticar
pre-proxy {} # en esta sección se ejecutarían acciones antes de reenviar
la petición a otro RADIUS
post-proxy {}
7.5.2 Kerberos
La instalación en Debian consta de instalar básicamente dos paquetes: el krb5-kdc, que es el KDC en sí, y el
krb5-admin-server que se encargará del resto. Cuando ejecutamos los comandos de instalación el sistema nos
advierte que para crear el reino de Kerberos tendremos que ejecutar el siguiente comando:
krb5_newrealm
Que nos pide una password y los nombres de reino (nombres DNS) que queremos usar y su resultado es que
ya tenemos los ficheros básicos para Kerberos creados.
También tenemos que crear el directorio donde se va a almacenar la base de datos:
mkdir -p /usr/local/var/krb5kdc/
y crearla
kdb5_util -s create
7.5.2.1 Fichero /etc/krb5.conf
En este fichero se definen los realms así como otros parámetros relativos a la configuración del servidor. En
este caso el reino Kerberos será JOSE.RTS.
[libdefaults]
default_realm = JOSE.RTS
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
[realms]
JOSE.RTS = {
kdc = kdc01.jose.rts
admin_server = kdc01.jose.rts
}
[domain_realm]
.jose.rts = JOSE.RTS
jose.rts = JOSE.RTS
7.5.2.2 Fichero /etc/krb5kdc/kdc.conf
En este fichero se especifica los parámetros relativos al KDC (Key Distribution Center)
38
[kdcdefaults]
kdc_ports = 750,88
[realms]
JOSE.RTS = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
#supported_enctypes = aes256-cts:normal aes128-cts:normal
default_principal_flags = +preauth
}
7.5.2.3 Fichero /etc/krb5kdc/kadm5.acl
Este fichero no viene creado por defecto, lo tenemos que crear nosotros y es una lista de control de acceso
(ACL por sus siglas en inglés) que nos permitirá restringir quién puede administar el KDC.
En nuestro caso por simplicidad simplemente tiene la siguiente línea:
*/admin@JOSE.RTS *
que permite que cualquier usuario que se conecte como administrador pueda modificar la base de datos.
7.5.3 Integración Freeradius/Kerberos

Una vez que tenemos instalados y correctamente funcionando tanto el servidor Freeradius como el servidor
Kerberos vamos a realizar la integración entre ellos. De esta forma no tendremos que dar de alta los usuarios
en Freeradius, sino que cuando este reciba una petición se la reenviará a Kerberos que será el encargado de
hacer la autenticación, que es lo que perseguimos.
Para ello lo primero de todo en Kerberos tenemos que crear los principales para el servidor RADIUS, y
también crearemos un usuario de prueba que nos permita comprobar que todo ha sido un éxito.
kadmin.local
kadmin.local: ank -randkey radius/radius.jose.rts@JOSE.RTS
kadmin.local: ank -randkey host/radius.jose.rts@JOSE.RTS
A continuación creamos el keytab para ambos principales:
kadmin.local: ktadd -k /tmp/krb5.keytab
host/radius.jose.rts@JOSE.RTS
kadmin.local: ktadd -k /tmp/krb5.keytab
radius/radius.jose.rts@JOSE.RTS
Como ambos servidores están en la misma máquina copiamos este fichero krb5.keytab a la carpeta de
configuración de Freeradius /usr/local/etc/raddb, y le damos los permisos necesarios para que el demonio
radiusd (y nadie más) pueda abrirlo. Si el servidor Freeradius estuviese en otra máquina habría que copiar
dicho fichero a la máquina, usando scp por ejemplo.
Y por último creamos un usuario de prueba, aunque valdría cualquiera que tuviésemos ya creado, por
supuesto:
kadmin.local: add_principal krbtesting
nos pedirá una contaseña para dicho usuario y con eso hemos finalizado la parte del servidor Kerberos.
En cuanto al servidor Freeradius tenemos que añadir la autenticación Kerberos en el fichero
/usr/local/etc/raddb/sites-enabled/default, añadiendo lo siguiente en la parte de authentication justo después del
módulo PAM:
krb5
}
También tenemos que editar el fichero /usr/local/etc/raddb/mods-enabled/krb5, para indicarle cual es nuestro
servidor Kerberos y dónde está la keytab que generamos anteriormente, para ello le añadimos lo siguiente:
keytab = /usr/local/etc/raddb
service_principal = radius/radius.jose.rts
Por último tenemos que editar el fichero users y añadir antes de la última línea que impide el paso a todos los
usuarios la siguiente línea:
DEFAULT AUTH-Type = kerberos
Si la pusiéramos al principio del fichero autenticaría todos los usuarios contra Kerberos, pero entonces todos
los usuarios que tuviésemos configurados en el fichero users no servirían para nada y no es lo que queremos.
7.5.4 Integración Kerberos/Directorio Activo

Para que el Kerberos se autentique contra el Directorio Activo tenemos que editar nuevamente el fichero
/etc/krb5.conf, añadiendo el dominio corporativo del SES en las dos secciones correspondientes:
DOMINIOSES.RTS = {
kdc = dc.dominioses.rts
admin_server = dc.dominioses.rts
}
[domain_realm]
.dominioses.rts = DOMINIOSES.RTS
dominioses.rts = DOMINIOSES.RTS
Donde dc.dominioses.rts es el servidor del controlador de dominio.

Como no tenemos ningún principal para el DOMINIOSES.RTS tenemos que crear uno para que ambos KDC
se pueda comunicar entre sí, ya que si no, cuando le llegase al KDC JOSE.RTS una petición para autenticarse
contra DOMINIOSES.RTS no sabría qué hacer con ello. Esto es lo que en Kerberos se conoce como Cross
Realm Authentication y para ello tenemos que establecer dos nuevos principales, si queremos que la
comunicación sea bidireccional en cada uno de los KDCs. Como hemos dicho habrá dos principales, uno hace
que JOSE.RTS confíe en los principales de DOMINIOSES.RTS: krbtgt/JOSE.RTS@DOMINIOSES.RTS, al
que asociaremos por supuesto una contraseña que deberá ser muy fuerte ya que se utilizará para interconectar
los dos reinos. Y otro que haga lo opuesto, que DOMINIOSES.RTS confíe en los principales de JOSE.RTS y
que será el principal krbtgt/DOMINIOSES.RTS@JOSE.RTS y al que asignaremos otra contaseña distinta a la
anterior. Esto lo podemos hacer con los siguientes comandos:
root@radius:~# kadmin.local
Authenticating as principal root/admin@JOSE.RTS with password.
40
kadmin.local: ank -kvno 1 -e des3-hmac-sha1:normal -e aes256-cts:normal

+requires_preauth krbtgt/JOSE.RTS@DOMINIOSES.RTS
WARNING: no policy specified for krbtgt/JOSE.RTS@DOMINIOSES.RTS;
defaulting to no policy
Enter password for principal "krbtgt/JOSE.RTS@DOMINIOSES.RTS":
Re-enter password for principal "krbtgt/JOSE.RTS@DOMINIOSES.RTS":
Principal "krbtgt/JOSE.RTS@DOMINIOSES.RTS" created.
kadmin.local: ank -kvno 1 -e des3-hmac-sha1:normal -e aes256-cts:normal
+requires_preauth krbtgt/DOMINIOSES.RTS@JOSE.RTS
WARNING: no policy specified for krbtgt/DOMINIOSES.RTS@JOSE.RTS;
defaulting to no policy
Enter password for principal "krbtgt/DOMINIOSES.RTS@JOSE.RTS":
Re-enter password for principal "krbtgt/DOMINIOSES.RTS@JOSE.RTS":
Principal "krbtgt/DOMINIOSES.RTS@JOSE.RTS" created.
Y ahora hay que crear los mismos dos principales en el otro KDC y añadir también nuestro dominio, pero
como eso ya es el directorio activo lo hacen mis compañeros de la sección de Sistemas.
7.6 Ejecución y comprobación del funcionamiento de los servidores

En esta sección vamos a ver cómo comprobar que el servicio que hemos montado funciona correctamente.
Para ello disponemos de más herramientas además de con los propios equipos a los que estamos ofreciendo el
servicio. El método más rápido (que no el más sencillo) puede ser mirar la salida de debug y los logs del
servidor. Hay también herramientas (para Linux y Windows) que permiten la comprobación de ciertos
parámetros del servidor, aunque siempre con más limitaciones que la propia consola donde está instalado el
servicio. Además usaremos esta información para pasársela al sistema de monitorización y control del SES,
donde un grupo de operadores vigila continuamente (24 horas al día, 7 días a la semana) el estado de la red y
los servidores, dada la alta criticidad del sistema.
Todos los sistemas están configurados para que se arranquen en el inicio del sistema, por si el servidor se
reinicia por cualquier motivo.
7.6.1 Freeradius
Para arrancar el servidor simplemente ejecutaremos el comando:
radiusd
y si no hay ningún error el servidor empezará a ejecutarse en background.
Otra opción para ejecutarlo (parándolo previamente porque no puede haber varias instancias simultáneamente)
es añadir al comando la opción –X, que lo ejecuta en modo debug y así podemos ver lo que le llega y lo que
envía, lo cual viene muy bien para hacer las pruebas y comprobar que todo funciona como debe, tras mostrar
mucha más información se quedaría tal que así:
Listening on auth address * port 1812 bound to server default
Listening on acct address * port 1813 bound to server default
Listening on auth address :: port 1812 bound to server default
Listening on acct address :: port 1813 bound to server default
Listening on auth address 127.0.0.1 port 18120 bound to server
inner-tunnel
Listening on proxy address * port 41837
Listening on proxy address :: port 55833
Ready to process requests
Para asegurarnos que los usuarios funcionan correctamente podemos usar la herramienta radtest, que hace
peticiones de autenticación al servidor RADIUS
radtest radius1 radius123 localhost 0 testing123
Sent Access-Request Id 78 from 0.0.0.0:38744 to
127.0.0.1:1812 length 77
User-Name = "radius1"
User-Password = "radius123"
NAS-IP-Address = 10.165.60.6
NAS-Port = 0
Message-Authenticator = 0x00
Cleartext-Password = "radius123"
Received Access-Accept Id 78 from 127.0.0.1:1812 to 0.0.0.0:0
length 26
Service-Type = Framed-User
Podemos comprobar que hemos recibido un Access-Accept y que además nos ha asignado el Service-Type
Framed-User, tal y como está configurado en el fichero users.
7.6.2 Kerberos
En Kerberos como ya hemos visto tenemos que ejecutar dos servicios independientes, el KDC y el admin
center:
krb5kdc
kadmind
Ahora ya podríamos conectarnos al sistema de administración y por ejemplo crear usuarios:
kadmin.local
Authenticating as principal jose/admin@JOSE.RTS with password.
kadmin.local: ank nuevo_usuario
WARNING: no policy specified for nuevo_usuario@JOSE.RTS; defaulting to
no policy
Enter password for principal "nuevo_usuario@JOSE.RTS":
Re-enter password for principal "nuevo_usuario@JOSE.RTS":
Principal "nuevo_usuario@JOSE.RTS" created.
Con el comando kinit podemos comprobar un usuario y ver su TGT con el comando klist
root@radius:~# kinit nuevo_usuario
Password for nuevo_usuario@JOSE.RTS:
root@radius:~# klist
Ticket cache: FILE:/tmp/krb5cc_1000_Q10TLB
42
Default principal: nuevo_usuario@JOSE.RTS
Valid starting Expires Service principal

24/05/18 19:20:03 25/05/18 05:20:03
krbtgt/JOSE.RTS@JOSE.RTS
renew until 25/05/18 19:20:01
Por supuesto estos comandos los podemos ejecutar también en una máquina remota (en esa máquina no es
necesario instalar el paquete del kdc) y el resultado sería el mismo, pero el ticket viajaría por la red.
7.6.3 Comprobación integración Freeradius/Kerberos

Para probar que la integración que hicimos anteriormente funciona podemos usar el comando radtest visto
antes con el usuario de prueba que se creó en Kerberos
root@radius:~# radtest krbtesting password localhost 0 testing123
Sent Access-Request Id 15 from 0.0.0.0:37616 to 127.0.0.1:1812
length 80
User-Name = "krbtesting"
User-Password = "password"
NAS-IP-Address = 10.165.60.6
NAS-Port = 0
Message-Authenticator = 0x00
Cleartext-Password = "password"
Received Access-Accept Id 15 from 127.0.0.1:1812 to 0.0.0.0:0
length 20
Tal y como esperábamos hemos recibido un paquete Access-Accept, por lo que comprobamos que la
integración funciona correctamente.
7.6.4 Comprobación integración Kerberos/Directorio Activo

Con el commando kinit podemos comprobar que nos podemos autenticar con el dominio del SES:
root@radius:~# kinit josemaria.acero@DOMINIOSES.RTS
Password for josemaria.acero@DOMINIOSES.RTS:
root@radius:~#
Y comprobamos que poniendo la contraseña correspondiente al directorio
activo podemos entrar y con el klist comprobar que tenemos el ticket
correspondiente.
Ticket cache: FILE:/tmp/krb5cc_1000_vBXjCu
Default principal: josemaria.acero@DOMINIOSES.RTS
Valid starting Expires Service principal

30/05/18 09:04:39 30/05/18 19:04:39
krbtgt/DOMINIOSES.RTS@DOMINIOSES.RTS
renew until 31/05/18 09:04:36
7.7 Alta disponibilidad

El SES dispone de una pareja de balanceadores BIG-IP de F5, y por simplicidad esta será la solución de alta
disponibilidad que usaremos. Para ello creamos dos ‘virtual servers’ y dos ‘pools’ para RADIUS y Kerberos
respectivamente. El virtual server será el encargado de recibir las conexiones, usando una IP virtual para ello y
el virtual server envía las peticiones a los dos servidores que añadiremos al pool, que tendrán idéntica
configuración, simplmente cambiando la dirección IP y el nombre del sevidor.
8 SEGURIDAD
E
N este capítulo vamos a ver como incrementar la seguridad de los servidores RADIUS y Kerberos, tanto
de las conexiones que se realizan para accederlos como de los propios servidores y clientes.
Uno de los grandes inconvenientes de los dos sistemas proviene de una de sus mayores ventajas: su gran
expansión. El descubrimiento de un fallo de seguridad en el servidor puede afectar a millones de usuarios en
todo el mundo. Pero por supuesto también habrá mucha gente tratando de resolverlo y obtener un parche de
seguridad lo antes posible, por lo que su gran expansión es ante todo su mayor virtud.
Trataremos cada uno de los sistemas por separado.
8.1 RADIUS
Hay fallos de seguridad que son inherentes al protocolo RADIUS y otros pueden ser debidos a un mal uso del
mismo. Veremos como mitigar los primeros y cómo hacer para no cometer los segundos.
Uno de los problemas es la clave compartida. Se podría atacar esta clave teniendo un sniffer (escaneador de
redes, uno de los más conocidos es el software Wireshark) que viese peticiones Access-Request válidas y sus
correspondientes respuestas. Una vez obtenidos estos dos paquetes, se podrían hacer cálculos con MD5 usando
el código, el identificador, la longitud, el “request authenticator” y los atributos. Por supuesto esto es
computacionalmente muy complicado y se puede evitar fácilmente usando claves compartidas de gran
longitud, y que no sean solo de caracteres alfanuméricos. Si solo se pueden usar caracteres de teclado, la
longitud mínima debe ser de al menos 22 caracteres y consistiendo de letras mayúsculas, minúsculas, números
y caracteres de puntuación. Si se puede configurar la clave compartida como una secuencia de dígitos
hexadecimales (no todos los servidores ni todos los clientes soportan esta opción), se deberá usar al menos una
clave de 32 dígitos hexadecimales.
El campo Request-authenticator y la clave compartida son usadas para obtener la llave con la que se cifra el
atributo User-Password y otros atributos. Si un atacante coloca un sniffer en la red y captura tráfico entre el
cliente y el servidor RADIUS, puede crear un diccionario con los request-authenticators y la correspondiente
clave para cifrar los atributos sensibles. Si el valor del request-authenticator se repite mucho porque varios
servidores de acceso distintos tienen la misma clave compartida, hacemos más fácil la tarea de averiguar la
clave compartida. Por ello otra acción que se puede tomar es definir una clave compartida distinta para cada
pareja cliente-servidor RADIUS.
Tampoco hay autenticación de los paquetes Access-Request en la RFC del protocolo. Por lo tanto usando
técnicas de spoofing (falsear la dirección IP origen de un paquete) podíamos generar falsas peticiones Access-
Request y obtener así información del servidor. Esto se puede evitar usando técnicas de anti-spoofing, que en
el SES están implementadas en el firewall. Otro modo de evitar este inconveniente es exigir el campo
Message-Authenticator en todos los mensajes Access-Request (normalmente este campo solo es requerido en
45
46
Seguridad
los mensajes para tener autenticación EAP). Recordemos que este campo es el hash MD5 del paquete Access-
Request completo usando como llave la clave compartida. Por lo tanto tenemos que asegurar que los
servidores de acceso a la red envíen los paquetes Access-Request con el correspondiente campo Message-
Authenticator y que el servidor RADIUS descarte todos aquellos paquetes que no cumplan esta condición o en
los que falle la verificación de este campo. Este descarte se hace silenciosamente, sin advertir de ello al
solicitante, puesto que no es lo mismo que un Access-Reject.
Otro de los fallos del protocolo es que los mensajes en sí no están cifrados, con lo que alguien que tenga
acceso físico a la red podría colocar un sniffer y ver los paquetes. Este riesgo se ve bastante minimizado en el
entorno del centro de proceso de datos (CPD) puesto que tiene acceso restringido, pero para clientes que estén
en otros departamentos o incluso en otros edificios sí puede suponer un problema. Para ofrecer una mayor
seguridad en este aspecto podríamos usar un túnel IPSEC entre los clientes y el servidor RADIUS, cifrando así
el contenido de todo el tráfico que circule entre los equipos. La RFC 3162 describe el uso de IPSEC con
detalle. En este proyecto, esta solución no se ha implementado, por su complejidad y su coste.
8.2 Kerberos
El protocolo Kerberos es ya de partida bastante seguro puesto que se desarrolló pensando precisamente en ello.
Su seguridad no fue algo que surgió espontáneamente, estaba en su ADN. Además ha ido evolucionando a lo
largo de muchísimos años, haciéndose cada vez más seguro. Todos sus mensajes van cifrados por lo que es
inmune a ataques con analizadores de red.
Una de las medidas de seguridad que se ha añadido es la que ya comentamos en cuando a la pre-autenticación,
por lo que es imprescindimble que esta característica esté habilitada siempre.
Otro aspecto a tener en cuenta es usar siempre la última versión del protocolo, es decir la versión 5. El servidor
también soporta la anterior versión, la 4, pero tenemos que prohibir su uso, puesto que es más inseguro.
Debido a su importancia y a que es el almacen de claves, es servidor KDC tiene que estar fuertemente
protegido, con su sistema operativo configurado convenientemente a nivel de permisos y accesos, así como
detrás de un firewall con la máxima protección posible, ya que si un atacante tuviese acceso podría emitir
tickets no válidos, borrar la base de datos, etc.
Uno de los problemas inherentes del protocolo Kerberos es la duración del ticket. No se debe especificar un
tiempo demasiado largo porque eso puede ocasionar problemas si se llega a interceptar ese ticket. Pero
tampoco demasiado corto porque en ese caso estamos obligando al usuario a que se autentique de nuevo, lo
que además va un poco en contra de la filosofía inicial de hacer que el usuario solo se autentique una vez. Por
lo tanto hay que llegar a un compromiso. Como norma general el tiempo de validez del ticket se suele
establecer en función de la jornada de trabajo, pero en determinados usos, por ejemplo si la máquina es de uso
público y para conexiones de corta duración, ese tiempo se puede bajar lo que queramos para tener más
garantías.
Otro de los problemas del uso de Kerberos en una organización no es un problema del protocolo en sí, sino de
su implementación. Si tenemos un servicio que no podemos o no queremos “kerberizar” eso supone que ese
servicio pueda tener una autenticación distinta, y por lo tanto corremos el riesgo de que sea débil. Esto nos
puede ocasionar una brecha de seguridad en ese punto. Por lo tanto no podemos obviar nunca el tema de la
seguridad, ya que es como una cadena que es tan débil o tan fuerte como lo sean sus eslabones.
Un inconveniente asociado a lo anterior es que si un usuario tiene que tener usar varias claves para diferentes
sistemas es posible que use la misma para todos, por lo que de nada nos vale que un sistema proteja
fuertemente las contraseñas si otro no lo hace y es atacado y quedan expuestas todas las claves, las del sistema
atacado y las de Kerberos por ser las mismas.
Para prevenir este tipo de problemas podemos cambiar el tipo de autenticación frente al usuario en el proceso
inicial de autenticación (recordemos que es ese el único momento en que el usuario tiene que poner su clave).
Inicialmente Kerberos se desarrolló con mecanismos de clave simétrica, que tienen el inconveniente que
ambas claves (las del usuario y las del servidor) tienen que ser almacenadas de algún modo en el servidor.
Aunque este almacenamiento sea seguro, obliga a un alta inicial del usuario en el sistema, y en ese
establecimiento inicial también se puede ver vulnerada la clave del usuario.

Pero existen extensiones del protocolo Kerberos que soportan mecanismos de clave asimétrica, como por
ejemplo los sistemas de clave pública (PKI o Public Key Infraestructure). Con este tipo de sistemas el usuario
presenta su certificado al servidor y esa es la autenticación usada, porque tanto el servidor como el usuario
pertenecen al sistema PKI y los certificados emitidos por ésta aseguran la confianza entre ambos. Además con
este tipo de sistemas logramos otro objetivo: el usuario no puede usar claves débiles debido a que directamente
no usa claves, sino tan solo su certificado. Es posible también proteger el propio certificado mediante una
clave, para asegurar que no caiga en malas manos.
En un sistema de clave pública también se puede sustituir el certificado por otro tipo de autenticación como
por ejemplo los ya muy extendidos tokens de un solo uso, smart cards, autenticación biométrica, etc.
Otra ventaja que nos ofrecen los sistemas de clave pública es que ya no hace falta un alta previa del usuario en
el sistema, tan solo que éste disponga de una credencial admitida, simplificando así el mantenimiento del
servidor sin mermar su seguridad.
Por supuesto no todo iba a ser ventajas: la implementación y mantenimiento de una infraestructura PKI es
compleja y costosa.
También debemos tener cuidado con la seguridad del sistema DNS ya que es una pieza clave del sistema. Si
un atacante logra hacerse con el DNS puede efectuar un ataque de denegación de servicio, ya que los clientes
podrían no encontar el propio servidor Kerberos y sus servicios asociados. El cambio de un nombre DNS a
otra IP que no sea la del servidor Kerberos en principio no afecta a la seguridad de éste, ya que una vez
contactado el servidor se lleva a cabo la autenticación para verificar y eso un sistema intruso fallaría, puesto
que el sistema de autenticación de Kerberos es mutuo como ya vimos anteriormente.
Por último también señalar que otro componente clave para el sistema Kerberos es el servidor de tiempo NTP,
si éste falla y los clientes no tienen la hora sincronizada, no podrán obtener sus tickets y por lo tanto fallará el
sistema. Así que también debemos tener mecanismos que nos aseguren que el servidor NTP funcione
correctamente.
9 CONFIGURACIÓN Y COMPROBACIÓN DEL
RESTO DE EQUIPOS
A
demás del sistema de autenticación en sí que hemos ido instalando y configurando también forman
parte de la solución los elementos que se conectan a dicho sistema. En este capítulo veremos cómo
configurar los distintos clientes del sistema, ya que sin esta configuración no podremos aprovechar
nada de lo que hemos realizado. Los equipos que tenemos que configurar son: switches, clientes 802.1X,
controladora inalámbrica y clientes inalámbricos.
9.1Configuración de un switch
Tenemos que configurar el switch para que la autenticación de los usuarios se haga mediante RADIUS.
Vamos a ver cómo hacerlo en un antiguo switch 3com 4400 y un más moderno Cisco 2960. En cada uno de
los switches hay que realizar dos tareas
 Configurar el switch para que el acceso a la gestión del mismo sea por RADIUS.
 Configurar el protocol 802.1X para que los equipos conectados al switch se autentiquen.
9.1.1 3Com 4400
9.1.1 Acceso
El switch tiene gestión vía web, a través de puerto de consola serie y también a través de telnet/SSH.
Usaremos este último por su comodidad y rapidez.
Cuando nos conectamos al switch por primera vez nos aparece la siguiente pantalla:
Login: admin
Password:
Menu options: --------------3Com SuperStack 3 Switch 4400----
bridge - Administer bridge-wide parameters
feature - Administer system features
gettingStarted - Basic device configuration
logout - Logout of the Command Line Interface
physicalInterface - Administer physical interfaces
protocol - Administer protocols
49
50
Configuración y comprobación del resto de equipos
security - Administer security

system - Administer system-level functions
trafficManagement - Administer traffic management
Type ? for help
------------------------------------SW_Pruebas (1)-----------
Select menu option:
Dentro de security->RADIUS encontramos las distintas opciones que necesitamos:
Select menu option (security): RADIUS
Menu options: --------------3Com SuperStack 3 Switch 4400----
accounting - Administer RADIUS accounting
authentication - Administer RADIUS authentication
pollTime - Set the RADIUS failure poll time
retries - Modify RADIUS retry parameters
setup - RADIUS configuration wizard
sharedSecret - Modify RADIUS security key
summary - Display summary information
Type "quit" to return to the previous menu or ? for help
------------------------------------SW_Pruebas (1)-----------
Lo primero ejecutamos con setup el configuration wizard, que nos pide la información sobre el servidor o
servidores:
Select menu option (security/radius): setup
Enter primary authentication server IP address [0.0.0.0]: 10.165.60.6
Enter primary authentication server UDP port number (?)[1812]:
Enter secondary authentication server IP address [0.0.0.0]:
Enter secondary authentication server UDP port number (?)[1812]:
Enter shared secret (?):
Enter primary accounting server IP address [0.0.0.0]: 10.165.60.6
Enter primary accounting server UDP port number (?)[1813]:
Enter secondary accounting server IP address [0.0.0.0]:
Enter secondary accounting server UDP port number (?)[1813]:
Select action on accounting failure (ignore,reject)[ignore]:
Select menu option (security/radius):
Dicha información la podemos comprobar también si queremos con el comando summary. Una vez
configurado el servidor RADIUS volvemos al menú anterior con quit, y en este menú nos aparece:
Select menu option (security/radius): quit
Menu options: --------------3Com SuperStack 3 Switch 4400----------
device - Administer device security
network - Administer network security

radius - Administer RADIUS security
Si escogemos la opción device

Menu options: --------------3Com SuperStack 3 Switch 4400----------
access - Administer access rights
authentication - Administer authentication mode
ssh - Administer SecureShell
trustedIpHost - Administer Trusted IP Host
user - Administer users
En este menú si elegimos authentication podemos elegir entre local (usuarios locales en el switch,
como está actualmente) o RADIUS, que hará que a partir de entonces la autenticación de acceso a la
administración del switch se lleve a cabo a través del servidor RADIUS, por lo tanto es la opción que
escogemos.
Select menu option (security/device/authentication): system
Select authentication mode (local,RADIUS)[local]:
9.1.2 802.1X
Volvemos de nuevo al menú anterior y escogemos esta vez la opción network, dentro de este menú solo hay
una opción que es access, por lo que usamos esa:
Menu options: --------------3Com SuperStack 3 Switch 4400---------------
access - Administer network access security
------------------------------------SW_Pruebas (1)----------------------
Select menu option (security/network): access
Menu options: --------------3Com SuperStack 3 Switch 4400---------------
detail - Display port users
localAuth - Administer local authentication database
portPrivacy - Configure port privacy
portSecurity - Configure port security
secureAddresses - Administer MAC addresses
summary - Display port security settings
systemMode - Enable/disable network security
systemSummary - Display summary information
Para habilitar los distintos modos de funcionamiento que vimos anteriormente tenemos que ejecutar el
comando portSecurity:
52
Select menu option (security/network/access): portsec

Select user ports (unit:port...,?): 1:1
Enter mode of operation (?)[noSecurity]: ?
One of the following items may be selected at this prompt:
autoLearn,continuallyLearn,learningOff,nbxNetworkLogin,noSecurity,r
ada,
radaAndNetworkLogin,radaElseNetworkLogin,radaOrNetworkLogin,
secureNetworkLogin,standardNetworkLogin
Enter mode of operation (?)[noSecurity]:
Y una vez escogido el modo que queramos hay que habilitar la seguridad en la red con el comando
systemMode
Select menu option (security/network/access): systemMode
Enter system mode (enable,disable)[disable]:
Y con esto terminamos con las opciones de seguridad para un switch 3com. Vía web todo es similar solo que
lo hacemos con un navegador y va más lento y puede haber problemas con navegadores actuales, por lo que se
recomienda usar el modo texto.
9.2 Cisco 2960
9.2.1 Acceso
Los switches Cisco modelo 2960 también tienen administración vía web, pero es muy básica y no incluye
ninguna de las opciones de seguridad. Tampoco las incluye el software de gestión de Cisco llamado Cisco
Network Assistant (CNA), por lo que al igual que hicimos con 3com usaremos telnet/SSH para conectarnos al
equipo.
En los equipos Cisco no hay pantallas de configuración como en 3com, sino que ejecutan un potente sistema
operativo llamado IOS con multitud de comandos y opciones por lo que ofrecen muchas más funcionalidades,
aunque evidentemente su gestión es algo más compleja.
Para entrar a la configuración ejecutamos el comando:
SW_CISCO_PRUEBAS#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW_CISCO_PRUEBAS(config)#
Lo primero que hay que hacer para empezar activar la seguridad es configurar un nuevo modelo AAA:
SW_CISCO_PRUEBAS(config)#aaa new-model
Lo siguiente será añadir el servidor RADIUS:
SW_CISCO_PRUEBAS(config)#radius server radius_jose

SW_CISCO_PRUEBAS(config-radius-server)#?
RADIUS server sub-mode commands:
address Specify the radius server address
automate-tester Configure server automated testing.
backoff Retry backoff pattern(Default is retransmits
with constant delay)
exit Exit from RADIUS server configuration mode
key Per-server encryption key
no Negate a command or set its defaults
non-standard Attributes to be parsed that violate RADIUS
standard
pac Protected Access Credential key
retransmit Number of retries to active server (overrides
default)
timeout Time to wait (in seconds) for this radius server
to reply (overrides default)
Con la anterior instrucción simplemente le hemos dado el nombre. Ahora especificamos el resto de
parámetros:
SW_CISCO_PRUEBAS(config-radius-server)#address ipv4 10.165.60.6
auth-port 1812 acct-port 1813
Y aún nos falta por incluir la shared secret
SW_CISCO_PRUEBAS(config-radius-server)#key testing123
Para ir al menú anterior tenemos que teclear exit, ahora para configurar la autenticación de la administración
del switch a través de RADIUS tenemos que ejecutar los siguientes comandos:
Cisco(config)# aaa authentication login default group radius local
Cisco(config)#line vty 0 15
Cisco(config-line)#login authentication radius_jose
Con la primera línea habilitamos que se pueda usar el servidor RADIUS para autenticar los usuarios y al final
ponemos local para que si el servidor RADIUS no está disponible podamos acceder al switch usando un
usuario local. Las line vty del 0 al 15 son las interfaces virtuales que posee el switch para las conexiones
remotas. Con esto le estamos diciendo que en estas conexiones autentique el usuario con el servidor RADIUS.
9.2.2 802.1X
Y para hacer que el switch autentique los usuarios que se conectan por 802.1X tenemos que hacer lo siguiente
SW_CISCO_PRUEBAS(config)#aaa authentication dot1x default group radius
SW_CISCO_PRUEBAS(config)#dot1x system-auth-control
SW_CISCO_PRUEBAS(config)#interface fastEthernet 0/1
SW_CISCO_PRUEBAS(config-if)#dot1x port-control auto
SW_CISCO_PRUEBAS(config-if)#end
54
Con estos comandos especificamos que la autenticación 802.1X se lleve a cabo a través del servidor RADIUS,
lo habilitamos en el switch, y especificamos qué interfaces estarán en este modo (por supuesto se pueden poner
todas) y por último aplicamos el modo de funcionamiento, en este caso modo auto.
9.2 Configuración controladora inalámbrica

Para la controladora inalámbrica sí tenemos una interfaz de gestión gráfica vía web que hace la configuración
más sencilla.
Lo primero que hacemos es crear la red inalámbrica:
Figura 9-1. Configuración wlan
Posteriormente añadimos el servidor RADIUS:
Figura 9-2. Configuración servidor RADIUS
A continuación editamos las propiedades de seguridad de la red que hemos creado, primero en la pestaña
Layer2:
Figura 9-3. Configuración seguridad
Y posteriormente elegimos el servidor RADIUS creado en la pestaña AAA Servers:
Figura 9-4. Configuración servidor AAA
Por último en la pestaña general también le tenemos que especificar la interfaz, que ya la teníamos
previamente creada e incluye la configuración de red y DHCP:
Figura 9-5. Configuración general
Habilitamos el broadcast SSID para que los usuarios puedan ver la red.
56
9.3 Configuración clientes 802.1X

Para que un equipo que se conecta a la red pueda negociar la autenticación 802.1X con el switch es necesario
que disponga de un cliente 802.1X instalado. Por suerte para nosotros, los sistemas operativos actuales lo
tienen implementado por defecto y tan solo tenemos que configurarlo, dentro de las propiedades de la tarjeta
de red correspondiente:
Figura 9-6. Configuración 802.1X

Ahí vemos que se usa el protocol EAP Protegido. Si pulsamos en “Configuración”
Figura 9-7. Configuración 802.1X

Podemos ver las distintas opciones que tenemos. También desmarcamos la casilla “Validar un certificado del
servidor” ya que no es necesaria en nuestro caso. Y comprobamos que la autenticación que se usa es EAP-
MSCHAP v2.
De esta forma, cuando el pc se conecte al switch éste iniciará el proceso de negociación y el equipo le
solicitará las credenciales al usuario o le enviará las usadas en el inicio de sesión.
9.4 Configuración conexión inalámbrica

El SES dispone de ordenadores portátiles y dispositivos móviles que se pueden conectar a la red de forma
inalámbrica. Los tipos de dispositivos de los que dispone son ordenadores con sistema operativo Windows en
las versiones 7, 8 y 10 de dicho sistema y dispositivos móviles con sistema operativo Android e iOS, en
diferentes versiones.
Para configurar un cliente para acceso inalámbrico simplemente elegimos la red que hemos creado:
Figura 9-8. Configuración inalámbrica
Y una vez que le damos a conectar nos pedirá usuario y contraseña:

58
Figura 9-9. Configuración inalámbrica II
Si el cliente no tiene instalado el certificado SSL del servidor es possible que nos salga un aviso de seguridad
puesto que el certificado que estamos usando es autofirmado, no está firmado por una entidad certificadora de
confianza.
Figura 9-10. Configuración inalámbrica III

9.5 Comprobación acceso administración switches

9.5.1 3Com
Cuando nos conectamos al switch por telnet, éste nos pide usuario y contraseña:
Login: usuario3com
Password:
En el caso de los switches 3com es necesario añadir manualmente los usuarios que se tengan que autenticar al
fichero users del servidor RADIUS, puesto que es requisito necesario en estos switches que el RADIUS
indique en su respuesta Access-Accept el nivel de acceso, que se especifica con el atributo de fabricante
3Com-User-Access-Level, como ya vimos anteriormente.
Así, al servidor le llega la siguiente petición:
(1) Received Access-Request Id 10 from 10.165.18.27:2048 to
10.165.60.6:1812 length 108
(1) User-Name = "usuario3com"
(1) User-Password = "1234"
(1) NAS-Port-Type = Virtual
(1) NAS-IP-Address = 10.165.18.27
(1) Service-Type = Administrative-User
(1) Framed-MTU = 1024
(1) Calling-Station-Id = "10.165.18.175"
(1) Message-Authenticator = 0x0139272f18f9a3e8cf0aa8e714848fe7
Y ésta es su respuesta:
(1) pap: User authenticated successfully
(1) [pap] = ok
(1) } # Auth-Type PAP = ok
(1) Sent Access-Accept Id 10 from 10.165.60.6:1812 to 10.165.18.27:2048
length 0
(1) 3Com-User-Access-Level = 3Com-Administrator
(1) Finished request
Donde comprobamos que además de enviar el Acces-Accept le envía también el 3Com-User-Access-Level

requerido por el switch.
9.5.2 Cisco
Al intentar conectarnos al switch, éste nos pide usuario y contraseña:
User Access Verification

Username: radius1
Password:
60
Y se la envía al servidor RADIUS, por lo que en el servidor vemos lo siguiente:

10.165.60.6:1812 length 80
(0) NAS-IP-Address = 10.165.18.27
(0) NAS-Port = 1
(0) NAS-Port-Type = Virtual
(0) User-Name = "radius1"
(0) Calling-Station-Id = "10.165.18.175"
(0) User-Password = "radius123"
En este caso vemos cómo encuentra al usuario en el fichero users:

(0) files: users: Matched entry radius1 at line 87
(0) [files] = ok
(0) [pap] = updated
(0) } # authorize = updated
(0) Found Auth-Type = PAP
(0) # Executing group from file /usr/local/etc/raddb/sites-
enabled/default
(0) Auth-Type PAP {
(0) pap: Login attempt with password
(0) pap: Comparing with "known good" Cleartext-Password
(0) pap: User authenticated successfully
(0) [pap] = ok
(0) } # Auth-Type PAP = ok
length 0
(0) Service-Type = Framed-User
Y así ya hemos iniciado sesión en el switch.
9.6 Comprobación autenticación 802.1X

9.6.1 3Com
Cuando conectamos un equipo a un puerto configurado con autenticación de red 802.1X, el switch le pide la
identificación al usuario y en el sevidor RADIUS vemos lo siguiente:
10.165.60.6:1812 length 110
(2) NAS-Port = 101

(2) NAS-Port-Type = Ethernet
(2) NAS-IP-Address = 10.165.18.27
(2) Calling-Station-Id = "70-5A-B6-95-BC-0B"
(2) EAP-Message = 0x0200000c0172616469757331
(2) Message-Authenticator = 0xa440d9d1ecca94da511dfbbaab99d3d8
Y su respuesta:
length 0
(12) MS-MPPE-Recv-Key =
0x4f84853b538cf72ec007a16810c33408281008e0c93779cc93fe3c08e05b5664
(12) MS-MPPE-Send-Key =
0xa14855b2218e088fac0b5ba86095908c8ab5b186416bbe630e17084da23a5e07
(12) EAP-Message = 0x030a0004
(12) Message-Authenticator = 0x00000000000000000000000000000000
Como en este switch también se ha configurado el accounting (registro), vemos también la solicitud de
accounting que realiza el switch al servidor:
(14) Received Accounting-Request Id 22 from 10.165.18.27:2048 to
10.165.60.6:1813 length 90
(14) NAS-IP-Address = 10.165.18.27
(14) NAS-Port = 101
(14) Acct-Status-Type = Start
(14) Acct-Session-Id = "1.0.30d136"
(14) Not sending reply to client.
Esta petición no llega al cliente conectado puesto que es algo que se establece sólamente entre el switch y el
servidor RADIUS. Y la respuesta a esta petición de accounting es:
(12) } # accounting = ok
(12) Sent Accounting-Response Id 38 from 10.165.60.6:1813 to
10.165.18.27:2048 length 0
Confirmando al switch que el registro se ha llevado a cabo.
62
9.6.2 Cisco
Una vez que tenemos configurado la autenticación en el switch cuando conectamos un equipo, el switch envía
el Access-Request al servidor RADIUS y éste le responde con el Access-Accept si es un usuario válido.

10.165.60.6:1812 length 129
(24) Called-Station-Id = "00-24-50-F1-E5-82"
(24) EAP-Message = 0x0202000c0172616469757331
(24) Message-Authenticator = 0xc2c217623e038528f080217933a170b1
(24) NAS-Port = 50001
(24) NAS-IP-Address = 10.165.18.27
Y también vemos la respuesta del servidor, en este caso aceptada:

length 0
0x4e2d455b9903ce7fe9e656ffb469082f3edade252ac1343e58d6512d9eff2ec5
0x7aa0e82447f455a3ea180df185481c6a2d5ec2b52ff427cdf3e1aa308a0ee299
(34) EAP-Message = 0x030c0004
9.7 Comprobación acceso inalámbrico

Cuando un cliente se intenta conectar a la red inalámbrica, la controladora le envía la petición de acceso al
RADIUS:

10.165.60.6:1812 length 181
(6) Calling-Station-Id = "10-b1-f8-af-15-08"
(6) Called-Station-Id = "00-24-14-e8-a8-40:wlan-802"
(6) NAS-Port = 29
(6) NAS-IP-Address = 10.165.18.216

(6) NAS-Identifier = "Controller-4"
(6) Airespace-Wlan-Id = 2
(6) NAS-Port-Type = Wireless-802.11
(6) Tunnel-Type:0 = VLAN
(6) Tunnel-Medium-Type:0 = IEEE-802
(6) Tunnel-Private-Group-Id:0 = "101"
(6) EAP-Message = 0x0201000c0172616469757331
(6) Message-Authenticator = 0xa6d5412ea0743ab4c10c51581e5047e8
RADIUS responde iniciando el “challenge” para iniciar el proceso de autenticación:

(7) Sent Access-Challenge Id 249 from 10.165.60.6:1812 to
10.165.18.216:32768 length 0
(7) EAP-Message = 0x010300061920
(7) State = 0xd5576227d4547b4071e54e5924bc02a3
Entonces la controladora hace la petición de usuario y contraseña al cliente final y vuelve a mandar un access-
request al RADIUS:
10.165.60.6:1812 length 362
(8) Calling-Station-Id = "10-b1-f8-af-15-08"
(8) Called-Station-Id = "00-24-14-e8-a8-40:wlan-802"
(8) NAS-Port = 29
(8) NAS-IP-Address = 10.165.18.216
(8) NAS-Identifier = "Controller-4"
(8) Airespace-Wlan-Id = 2
(8) NAS-Port-Type = Wireless-802.11
(8) Tunnel-Type:0 = VLAN
(8) Tunnel-Medium-Type:0 = IEEE-802
(8) Tunnel-Private-Group-Id:0 = "101"
(8) EAP-Message =
0x020300af1980000000a516030100a00100009c0303ae86225477b9cf0963f17dbb23114
e9aaa50ee13659dcae08b2ff8b0c9a861a000003ec02cc030009fc02bc02f009ecca9cca8
64
c00ac024c014c0280039006bc009c023c013c02700330067c007c011009d009c0035003d0
02f003c00050004000a01
(8) State = 0xd5576227d4547b4071e54e5924bc02a3
(8) Message-Authenticator = 0x42f8762a0977157ea331f3eb1c8f445a
Ahora continúa el traspaso de mensajes necesario para el establecimiento que no incluyo por su longitud, y al
final del proceso el RADIUS envía el Access-Accept a la controladora y ésta ya puede ofrecer la conexión al
usuario:
length 0
0x4d850ea9a648ced559b2b91592a5ac642e8ffc601cc616d289deb8144d928f39
0x30726a6b4b8660bcc879e6abef269a2b17dfed541e0fb392e2f42f836e63318b
(16) EAP-Message = 0x030b0004
66
BIBLIOGRAFÍA
Para la elaboración de este proyecto se han utilizado tanto libros como búsqueda de información online.
Libros:
Implementation Guide Switch 4400. 3Com
Radius for Unix Administrators. Lucent Technologies.
Radius Administrator's Guide. Livingston Enterprises.
Radius. Jonathan Hassell. O'Reilly.
Radius Protocol Security and best practices. Microsoft.
Y las fuentes de infromación online han sido:
http://www.freeradius.org
http://web.mit.edu/kerberos
http://www.kerberos.org
http://www.cisco.com
http://www.microsoft.com
http://www.ietf.org
http://www.open1x.org
http://www.linuxjournal.com
http://sourceforge.net
http://www.openssl.org
67
ANEXO. FICHEROS DE CONFIGURACIÓN
A.1 Freeradius
En esta sección mostraremos los archivos de configuración completos del software Freeradius. Los ficheros
están ubicados en la ruta /usr/local/etc/raddb
A.1.1 clients.conf
# -*- text -*-

##
## clients.conf -- client configuration directives
##
## $Id: 76b300d3c55f1c5c052289b76bf28ac3a370bbb2 $
#######################################################################
#
# Define RADIUS clients (usually a NAS, Access Point, etc.).
#
# Defines a RADIUS client.
#
# '127.0.0.1' is another name for 'localhost'. It is enabled by default,
# to allow testing of the server after an initial installation. If you
# are not going to be permitting RADIUS queries from localhost, we suggest
# that you delete, or comment out, this entry.
#
#
#
# Each client has a "short name" that is used to distinguish it from
# other clients.
#
# In version 1.x, the string after the word "client" was the IP
# address of the client. In 2.0, the IP address is configured via
# the "ipaddr" or "ipv6addr" fields. For compatibility, the 1.x
# format is still accepted.
#
client localhost {
68
# Only *one* of ipaddr, ipv4addr, ipv6addr may be specified for

# a client.
#
# ipaddr will accept IPv4 or IPv6 addresses with optional CIDR
# notation '/<mask>' to specify ranges.
#
# ipaddr will accept domain names e.g. example.org resolving
# them via DNS.
#
# If both A and AAAA records are found, A records will be
# used in preference to AAAA.
ipaddr = 127.0.0.1
# Same as ipaddr but allows v4 addresses only. Requires A

# record for domain names.
# ipv4addr = * # any. 127.0.0.1 == localhost
# Same as ipaddr but allows v6 addresses only. Requires AAAA

# record for domain names.
# ipv6addr = :: # any. ::1 == localhost
#
# A note on DNS: We STRONGLY recommend using IP addresses
# rather than host names. Using host names means that the
# server will do DNS lookups when it starts, making it
# dependent on DNS. i.e. If anything goes wrong with DNS,
# the server won't start!
#
# The server also looks up the IP address from DNS once, and
# only once, when it starts. If the DNS record is later
# updated, the server WILL NOT see that update.
#
#
# The transport protocol.
#
# If unspecified, defaults to "udp", which is the traditional
# RADIUS transport. It may also be "tcp", in which case the
# server will accept connections from this client ONLY over TCP.
#
proto = *
#
# The shared secret use to "encrypt" and "sign" packets between
70
Anexo. Ficheros de configuración
# the NAS and FreeRADIUS. You MUST change this secret from the
# default, otherwise it's not a secret any more!
#
# The secret can be any string, up to 8k characters in length.
#
# Control codes can be entered vi octal encoding,
# e.g. "\101\102" == "AB"
# Quotation marks can be entered by escaping them,
# e.g. "foo\"bar"
#
# A note on security: The security of the RADIUS protocol
# depends COMPLETELY on this secret! We recommend using a
# shared secret that is composed of:
#
# upper case letters
# lower case letters
# numbers
#
# And is at LEAST 8 characters long, preferably 16 characters in
# length. The secret MUST be random, and should not be words,
# phrase, or anything else that is recognisable.
#
# The default secret below is only for testing, and should
# not be used in any real environment.
#
secret = testing123
#
# Old-style clients do not send a Message-Authenticator
# in an Access-Request. RFC 5080 suggests that all clients
# SHOULD include it in an Access-Request. The configuration
# item below allows the server to require it. If a client
# is required to include a Message-Authenticator and it does
# not, then the packet will be silently discarded.
#
# allowed values: yes, no
require_message_authenticator = no
#
# The short name is used as an alias for the fully qualified
# domain name, or the IP address.
#
# It is accepted for compatibility with 1.x, but it is no
# longer necessary in >= 2.0

#
# shortname = localhost
#
# the following three fields are optional, but may be used by
# checkrad.pl for simultaneous use checks
#
#
# The nas_type tells 'checkrad.pl' which NAS-specific method to
# use to query the NAS for simultaneous use.
#
# Permitted NAS types are:
#
# cisco
# computone
# livingston
# juniper
# max40xx
# multitech
# netserver
# pathras
# patton
# portslave
# tc
# usrhiper
# other # for all other types
#
nas_type = other # localhost isn't usually a NAS...
#
# The following two configurations are for future use.
# The 'naspasswd' file is currently used to store the NAS
# login name and password, which is used by checkrad.pl
# when querying the NAS for simultaneous use.
#
# login = !root
# password = someadminpas
#
# As of 2.0, clients can also be tied to a virtual server.
# This is done by setting the "virtual_server" configuration
72
# item, as in the example below.

#
# virtual_server = home1
#
# A pointer to the "home_server_pool" OR a "home_server"
# section that contains the CoA configuration for this
# client. For an example of a coa home server or pool,
# see raddb/sites-available/originate-coa
# coa_server = coa
#
# Response window for proxied packets. If non-zero,
# then the lower of (home, client) response_window
# will be used.
#
# i.e. it can be used to lower the response_window
# packets from one client to a home server. It cannot
# be used to raise the response_window.
#
# response_window = 10.0
#
# Connection limiting for clients using "proto = tcp".
#
# This section is ignored for clients sending UDP traffic
#
limit {
#
# Limit the number of simultaneous TCP connections from a client
#
# The default is 16.
# Setting this to 0 means "no limit"
max_connections = 16
# The per-socket "max_requests" option does not exist.
#
# The lifetime, in seconds, of a TCP connection. After
# this lifetime, the connection will be closed.
#
# Setting this to 0 means "forever".
lifetime = 0
#
# The idle timeout, in seconds, of a TCP connection.
# If no packets have been received over the connection for
# this time, the connection will be closed.
#
# Setting this to 0 means "no timeout".
#
# We STRONGLY RECOMMEND that you set an idle timeout.
#
idle_timeout = 30
}
}
# IPv6 Client
client localhost_ipv6 {
ipv6addr = ::1
secret = testing123
}
# All IPv6 Site-local clients

#client sitelocal_ipv6 {
# ipv6addr = fe80::/16
# secret = testing123
#}
# máquinas que se conectan al radius

# Mi PC
client pc_jose {
ipaddr = 10.165.18.175
secret = testing123
}
client sw_cisco {
ipaddr = 10.165.18.27
secret = testing123
}
client sw_3com {
ipaddr = 10.165.18.27
secret = testing123
}
client controladora_wifi {
ipaddr = 10.165.18.216
74
secret = testing123
}
#client example.org {
# ipaddr = radius.example.org
#}
#
# You can now specify one secret for a network of clients.
# When a client request comes in, the BEST match is chosen.
# i.e. The entry from the smallest possible network.
#
#client private-network-1 {
# ipaddr = 192.0.2.0/24
# secret = testing123-1
#}
#client private-network-2 {
# ipaddr = 198.51.100.0/24
# secret = testing123-2
#}
#######################################################################
#
# Per-socket client lists. The configuration entries are exactly
# the same as above, but they are nested inside of a section.
#
# You can have as many per-socket client lists as you have "listen"
# sections, or you can re-use a list among multiple "listen" sections.
#
# Un-comment this section, and edit a "listen" section to add:
# "clients = per_socket_clients". That IP address/port combination
# will then accept ONLY the clients listed in this section.
#
#clients per_socket_clients {
# client socket_client {
# ipaddr = 192.0.2.4
# }
#}
A.1.2 users
#
# Configuration file for the rlm_files module.
# Please see rlm_files(5) manpage for more information.
#
# This file contains authentication security and configuration
# information for each user. Accounting requests are NOT processed
# through this file. Instead, see 'accounting', in this directory.
#
# The first field is the user's name and can be up to
# 253 characters in length. This is followed (on the same line) with
# the list of authentication requirements for that user. This can
# include password, comm server name, comm server port number, protocol
# type (perhaps set by the "hints" file), and huntgroup name (set by
# the "huntgroups" file).
#
# If you are not sure why a particular reply is being sent by the
# server, then run the server in debugging mode (radiusd -X), and
# you will see which entries in this file are matched.
#
# When an authentication request is received from the comm server,
# these values are tested. Only the first match is used unless the
# "Fall-Through" variable is set to "Yes".
#
# A special user named "DEFAULT" matches on all usernames.
# You can have several DEFAULT entries. All entries are processed
# in the order they appear in this file. The first entry that
# matches the login-request will stop processing unless you use
# the Fall-Through variable.
#
# Indented (with the tab character) lines following the first
# line indicate the configuration values to be passed back to
# the comm server to allow the initiation of a user session.
# This can include things like the PPP configuration values
# or the host to log the user onto.
#
# You can include another `users' file with `$INCLUDE users.other'
#
76
# For a list of RADIUS attributes, and links to their definitions,

# see: http://www.freeradius.org/rfc/attributes.html
#
# Entries below this point are examples included in the server for
# educational purposes. They may be deleted from the deployed
# configuration without impacting the operation of the server.
#
#
# Deny access for a specific user. Note that this entry MUST
# be before any other 'Auth-Type' attribute which results in the user
# being authenticated.
#
# Note that there is NO 'Fall-Through' attribute, so the user will not
# be given any additional resources.
#
#lameuser Auth-Type := Reject
# Reply-Message = "Your account has been disabled."
#
# Deny access for a group of users.
#
# Note that there is NO 'Fall-Through' attribute, so the user will not
# be given any additional resources.
#
#DEFAULT Group == "disabled", Auth-Type := Reject
# Reply-Message = "Your account has been disabled."
#
#
# This is a complete entry for "steve". Note that there is no Fall-Through
# entry so that no DEFAULT entry will be used, and the user will NOT
# get any attributes in addition to the ones listed here.
#
#steve Cleartext-Password := "testing"
# Service-Type = Framed-User,
# Framed-Protocol = PPP,
# Framed-IP-Address = 172.16.3.33,
# Framed-IP-Netmask = 255.255.255.0,
# Framed-Routing = Broadcast-Listen,
# Framed-Filter-Id = "std.ppp",
# Framed-MTU = 1500,
# Framed-Compression = Van-Jacobsen-TCP-IP
# usuarios locales del servidor radius
radius1 Cleartext-Password := "radius123"

radius2 Cleartext-Password := "radius123"
# usuarios para los switches 3Com
usuario3com Cleartext-Password := "1234"
3Com-User-Access-Level = 3Com-Administrator
# usuarios para los dispositivos móviles
tablet1@n4 Auth-Type = Local, User-Password == "tablet1", Calling-Station-
Id=="34690040219"
Ascend-Client-Primary-DNS = 192.168.100.1,
tablet2@n4 Auth-Type = Local, User-Password == "tablet2", Calling-Station-

Id=="34690040233"
Ascend-Client-Primary-DNS = 192.168.100.1,
#
# The canonical testing user which is in most of the
# examples.
#
#bob Cleartext-Password := "hello"
# Reply-Message := "Hello, %{User-Name}"
#
#
# This is an entry for a user with a space in their name.
# Note the double quotes surrounding the name. If you have
# users with spaces in their names, you must also change
# the "filter_username" policy to allow spaces.
#
# See raddb/policy.d/filter, filter_username {} section.
#
#"John Doe" Cleartext-Password := "hello"
# Reply-Message = "Hello, %{User-Name}"
78
#
# Dial user back and telnet to the default host for that port
#
#Deg Cleartext-Password := "ge55ged"
# Service-Type = Callback-Login-User,
# Login-IP-Host = 0.0.0.0,
# Callback-Number = "9,5551212",
# Login-Service = Telnet,
# Login-TCP-Port = Telnet
#
# Another complete entry. After the user "dialbk" has logged in, the
# connection will be broken and the user will be dialed back after which
# he will get a connection to the host "timeshare1".
#
#dialbk Cleartext-Password := "callme"
# Service-Type = Callback-Login-User,
# Login-IP-Host = timeshare1,
# Login-Service = PortMaster,
# Callback-Number = "9,1-800-555-1212"
#
# user "swilson" will only get a static IP number if he logs in with
# a framed protocol on a terminal server in Alphen (see the huntgroups file).
#
# Note that by setting "Fall-Through", other attributes will be added from
# the following DEFAULT entries
#
#swilson Service-Type == Framed-User, Huntgroup-Name == "alphen"
# Fall-Through = Yes
#
# If the user logs in as 'username.shell', then authenticate them
# using the default method, give them shell access, and stop processing
# the rest of the file.
#
#DEFAULT Suffix == ".shell"
# Service-Type = Login-User,
# Login-Service = Telnet,
# Login-IP-Host = your.shell.machine
#
# The rest of this file contains the several DEFAULT entries.
# DEFAULT entries match with all login names.
# Note that DEFAULT entries can also Fall-Through (see first entry).
# A name-value pair from a DEFAULT entry will _NEVER_ override
# an already existing name-value pair.
#
#
# Set up different IP address pools for the terminal servers.
# Note that the "+" behind the IP address means that this is the "base"
# IP address. The Port-Id (S0, S1 etc) will be added to it.
#
#DEFAULT Service-Type == Framed-User, Huntgroup-Name == "alphen"
# Framed-IP-Address = 192.0.2.32+,
#DEFAULT Service-Type == Framed-User, Huntgroup-Name == "delft"

# Framed-IP-Address = 198.51.100.32+,
#
# Sample defaults for all framed connections.
#
#DEFAULT Service-Type == Framed-User
# Framed-MTU = 576,
# Service-Type = Framed-User,
#
# Default for PPP: dynamic IP address, PPP mode, VJ-compression.
# NOTE: we do not use Hint = "PPP", since PPP might also be auto-detected
# by the terminal server in which case there may not be a "P" suffix.
# The terminal server sends "Framed-Protocol = PPP" for auto PPP.
#
DEFAULT Framed-Protocol == PPP
Framed-Compression = Van-Jacobson-TCP-IP
#
# Default for CSLIP: dynamic IP address, SLIP mode, VJ-compression.
#
DEFAULT Hint == "CSLIP"
80
Framed-Protocol = SLIP,
Framed-Compression = Van-Jacobson-TCP-IP
#
# Default for SLIP: dynamic IP address, SLIP mode.
#
DEFAULT Hint == "SLIP"
Framed-Protocol = SLIP
#
# Last default: rlogin to our main server.
#
#DEFAULT
# Service-Type = Login-User,
# Login-Service = Rlogin,
# Login-IP-Host = shellbox.ispdomain.com
# #
# # Last default: shell on the local terminal server.
# #
# DEFAULT
# Service-Type = Administrative-User
#por último hacemos que el resto de usuarios se autentiquen en Kerberos
DEFAULT AUTH-Type = kerberos
# On no match, the user is denied access.
DEFAULT AUTH-Type = reject
#########################################################
# You should add test accounts to the TOP of this file! #
# See the example user "bob" above. #
#########################################################
A.1.3 ./mods-enabled/eap
# -*- text -*-

##
## eap.conf -- Configuration for EAP types (PEAP, TTLS, etc.)
##
## $Id: f67cbdbff9b6560cec9f68da1adb82b59723d2ef $
#######################################################################
#
# Whatever you do, do NOT set 'Auth-Type := EAP'. The server
# is smart enough to figure this out on its own. The most
# common side effect of setting 'Auth-Type := EAP' is that the
# users then cannot use ANY other authentication method.
#
eap {
# Invoke the default supported EAP type when
# EAP-Identity response is received.
#
# The incoming EAP messages DO NOT specify which EAP
# type they will be using, so it MUST be set here.
#
# For now, only one default EAP type may be used at a time.
#
# If the EAP-Type attribute is set by another module,
# then that EAP type takes precedence over the
# default type configured here.
default_eap_type = peap
# A list is maintained to correlate EAP-Response

# packets with EAP-Request packets. After a
# configurable length of time, entries in the list
# expire, and are deleted.
#
timer_expire = 60
# There are many EAP types, but the server has support
# for only a limited subset. If the server receives
# a request for an EAP type it does not support, then
# it normally rejects the request. By setting this
# configuration to "yes", you can tell the server to
# instead keep processing the request. Another module
# MUST then be configured to proxy the request to
# another RADIUS server which supports that EAP type.
#
# If another module is NOT configured to handle the
# request, then the request will still end up being
# rejected.
82
ignore_unknown_eap_types = no
# Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given

# a User-Name attribute in an Access-Accept, it copies one
# more byte than it should.
#
# We can work around it by configurably adding an extra
# zero byte.
cisco_accounting_username_bug = no
#
# Help prevent DoS attacks by limiting the number of
# sessions that the server is tracking. For simplicity,
# this is taken from the "max_requests" directive in
# radiusd.conf.
max_sessions = ${max_requests}
# Supported EAP-types
#
# We do NOT recommend using EAP-MD5 authentication
# for wireless connections. It is insecure, and does
# not provide for dynamic WEP keys.
#
md5 {
}
#
# EAP-pwd -- secure password-based authentication
#
# pwd {
# group = 19
#
# server_id = theserver@example.com
# This has the same meaning as for TLS.

# fragment_size = 1020
# The virtual server which determines the

# "known good" password for the user.
# Note that unlike TLS, only the "authorize"
# section is processed. EAP-PWD requests can be
# distinguished by having a User-Name, but

# no User-Password, CHAP-Password, EAP-Message, etc.
# virtual_server = "inner-tunnel"
# }
# Cisco LEAP
#
# We do not recommend using LEAP in new deployments. See:
# http://www.securiteam.com/tools/5TP012ACKE.html
#
# Cisco LEAP uses the MS-CHAP algorithm (but not
# the MS-CHAP attributes) to perform it's authentication.
#
# As a result, LEAP *requires* access to the plain-text
# User-Password, or the NT-Password attributes.
# 'System' authentication is impossible with LEAP.
#
leap {
}
# Generic Token Card.

#
# Currently, this is only permitted inside of EAP-TTLS,
# or EAP-PEAP. The module "challenges" the user with
# text, and the response from the user is taken to be
# the User-Password.
#
# Proxying the tunneled EAP-GTC session is a bad idea,
# the users password will go over the wire in plain-text,
# for anyone to see.
#
gtc {
# The default challenge, which many clients
# ignore..
#challenge = "Password: "
# The plain-text response which comes back

# is put into a User-Password attribute,
# and passed to another module for
# authentication. This allows the EAP-GTC
# response to be checked against plain-text,
# or crypt'd passwords.
#
# If you say "Local" instead of "PAP", then
84
# the module will look for a User-Password

# configured for the request, and do the
# authentication itself.
#
auth_type = PAP
}
## Common TLS configuration for TLS-based EAP types

#
# See raddb/certs/README for additional comments
# on certificates.
#
# If OpenSSL was not found at the time the server was
# built, the "tls", "ttls", and "peap" sections will
# be ignored.
#
# If you do not currently have certificates signed by
# a trusted CA you may use the 'snakeoil' certificates.
# Included with the server in raddb/certs.
#
# If these certificates have not been auto-generated:
# cd raddb/certs
# make
#
# These test certificates SHOULD NOT be used in a normal
# deployment. They are created only to make it easier
# to install the server, and to perform some simple
# tests with EAP-TLS, TTLS, or PEAP.
#
# See also:
#
# http://www.dslreports.com/forum/remark,9286052~mode=flat
#
# Note that you should NOT use a globally known CA here!
# e.g. using a Verisign cert as a "known CA" means that
# ANYONE who has a certificate signed by them can
# authenticate via EAP-TLS! This is likely not what you want.
tls-config tls-common {
private_key_password = whatever
private_key_file = ${certdir}/server.pem
# If Private key & Certificate are located in

# the same file, then private_key_file &
# certificate_file must contain the same file

# name.
#
# If ca_file (below) is not used, then the
# certificate_file below MUST include not
# only the server certificate, but ALSO all
# of the CA certificates used to sign the
# server certificate.
certificate_file = ${certdir}/server.pem
# Trusted Root CA list

#
# ALL of the CA's in this list will be trusted
# to issue client certificates for authentication.
#
# In general, you should use self-signed
# certificates for 802.1x (EAP) authentication.
# In that case, this CA file should contain
# *one* CA certificate.
#
ca_file = ${cadir}/ca.pem
# OpenSSL will automatically create certificate chains,

# unless we tell it to not do that. The problem is that
# it sometimes gets the chains right from a certificate
# signature view, but wrong from the clients view.
#
# When setting "auto_chain = no", the server certificate
# file MUST include the full certificate chain.
# auto_chain = yes
#
# If OpenSSL supports TLS-PSK, then we can use
# a PSK identity and (hex) password. When the
# following two configuration items are specified,
# then certificate-based configuration items are
# not allowed. e.g.:
#
# private_key_password
# private_key_file
# certificate_file
# ca_file
# ca_path
#
86
# For now, the identity is fixed, and must be the

# same on the client. The passphrase must be a hex
# value, and can be up to 256 hex digits.
#
# Future versions of the server may be able to
# look up the shared key (hexphrase) based on the
# identity.
#
# psk_identity = "test"
# psk_hexphrase = "036363823"
#
# For DH cipher suites to work, you have to
# run OpenSSL to create the DH file first:
#
# openssl dhparam -out certs/dh 2048
#
dh_file = ${certdir}/dh
#
# If your system doesn't have /dev/urandom,
# you will need to create this file, and
# periodically change its contents.
#
# For security reasons, FreeRADIUS doesn't
# write to files in its configuration
# directory.
#
# random_file = /dev/urandom
#
# This can never exceed the size of a RADIUS
# packet (4096 bytes), and is preferably half
# that, to accommodate other attributes in
# RADIUS packet. On most APs the MAX packet
# length is configured between 1500 - 1600
# In these cases, fragment size should be
# 1024 or less.
#
# fragment_size = 1024
# include_length is a flag which is

# by default set to yes If set to
# yes, Total Length of the message is

# included in EVERY packet we send.
# If set to no, Total Length of the
# message is included ONLY in the
# First packet of a fragment series.
#
# include_length = yes
# Check the Certificate Revocation List

#
# 1) Copy CA certificates and CRLs to same directory.
# 2) Execute 'c_rehash <CA certs&CRLs Directory>'.
# 'c_rehash' is OpenSSL's command.
# 3) uncomment the lines below.
# 5) Restart radiusd
# check_crl = yes
# Check if intermediate CAs have been revoked.

# check_all_crl = yes
ca_path = ${cadir}
# Accept an expired Certificate Revocation List

#
# allow_expired_crl = no
#
# If check_cert_issuer is set, the value will
# be checked against the DN of the issuer in
# the client certificate. If the values do not
# match, the certificate verification will fail,
# rejecting the user.
#
# This check can be done more generally by checking
# the value of the TLS-Client-Cert-Issuer attribute.
# This check can be done via any mechanism you
# choose.
#
# check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd"
#
# If check_cert_cn is set, the value will
# be xlat'ed and checked against the CN
88
# in the client certificate. If the values

# do not match, the certificate verification
# will fail rejecting the user.
#
# This check is done only if the previous
# "check_cert_issuer" is not set, or if
# the check succeeds.
#
# In 2.1.10 and later, this check can be done
# more generally by checking the value of the
# TLS-Client-Cert-CN attribute. This check
# can be done via any mechanism you choose.
#
# check_cert_cn = %{User-Name}
#
# Set this option to specify the allowed
# TLS cipher suites. The format is listed
# in "man 1 ciphers".
#
# For EAP-FAST, use "ALL:!EXPORT:!eNULL:!SSLv2"
#
cipher_list = "DEFAULT"
# If enabled, OpenSSL will use server cipher list

# (possibly defined by cipher_list option above)
# for choosing right cipher suite rather than
# using client-specified list which is OpenSSl default
# behavior. Having it set to yes is a current best practice
# for TLS
cipher_server_preference = no
#
# You can selectively disable TLS versions for
# compatability with old client devices.
#
# If your system has OpenSSL 1.1.0 or greater, do NOT
# use these. Instead, set tls_min_version and
# tls_max_version.
#
# disable_tlsv1_2 = no
# disable_tlsv1_1 = no
# disable_tlsv1 = no
#
# Set min / max TLS version. Mainly for Debian
# "trusty", which disables older versions of TLS, and
# requires the application to manually enable them.
#
# If you are running Debian trusty, you should set
# these options, otherwise older clients will not be
# able to connect.
#
# Allowed values are "1.0", "1.1", and "1.2".
#
# The values must be in quotes.
#
# tls_min_version = "1.0"
# tls_max_version = "1.2"
#
# Elliptical cryptography configuration
#
# Only for OpenSSL >= 0.9.8.f
#
ecdh_curve = "prime256v1"
#
# Session resumption / fast reauthentication
# cache.
#
# The cache contains the following information:
#
# session Id - unique identifier, managed by SSL
# User-Name - from the Access-Accept
# Stripped-User-Name - from the Access-Request
# Cached-Session-Policy - from the Access-Accept
#
# The "Cached-Session-Policy" is the name of a
# policy which should be applied to the cached
# session. This policy can be used to assign
# VLANs, IP addresses, etc. It serves as a useful
# way to re-apply the policy from the original
# Access-Accept to the subsequent Access-Accept
# for the cached session.
#
# On session resumption, these attributes are
90
# copied from the cache, and placed into the

# reply list.
#
# You probably also want "use_tunneled_reply = yes"
# when using fast session resumption.
#
cache {
#
# Enable it. The default is "no". Deleting the entire "cache"
# subsection also disables caching.
#
# As of version 3.0.14, the session cache requires the use
# of the "name" and "persist_dir" configuration items, below.
#
# The internal OpenSSL session cache has been permanently
# disabled.
#
# You can disallow resumption for a particular user by adding
the
# following attribute to the control item list:
#
# Allow-Session-Resumption = No
#
# If "enable = no" below, you CANNOT enable resumption for just
one
# user by setting the above attribute to "yes".
#
enable = no
#
# Lifetime of the cached entries, in hours. The sessions will be
# deleted/invalidated after this time.
#
lifetime = 24 # hours
#
# Internal "name" of the session cache. Used to
# distinguish which TLS context sessions belong to.
#
# The server will generate a random value if unset.
# This will change across server restart so you MUST
# set the "name" if you want to persist sessions (see
# below).
#
#name = "EAP module"
#
# Simple directory-based storage of sessions.
# Two files per session will be written, the SSL
# state and the cached VPs. This will persist session
# across server restarts.
#
# The default directory is ${logdir}, for historical
# reasons. You should ${db_dir} instead. And check
# the value of db_dir in the main radiusd.conf file.
# It should not point to ${raddb}
#
# The server will need write perms, and the directory
# should be secured from anyone else. You might want
# a script to remove old files from here periodically:
#
# find ${logdir}/tlscache -mtime +2 -exec rm -f {} \;
#
# This feature REQUIRES "name" option be set above.
#
#persist_dir = "${logdir}/tlscache"
}
#
# As of version 2.1.10, client certificates can be
# validated via an external command. This allows
# dynamic CRLs or OCSP to be used.
#
# This configuration is commented out in the
# default configuration. Uncomment it, and configure
# the correct paths below to enable it.
#
# If OCSP checking is enabled, and the OCSP checks fail,
# the verify section is not run.
#
# If OCSP checking is disabled, the verify section is
# run on successful certificate validation.
#
verify {
# If the OCSP checks succeed, the verify section
# is run to allow additional checks.
#
# If you want to skip verify on OCSP success,
92
# uncomment this configuration item, and set it

# to "yes".
# skip_if_ocsp_ok = no
# A temporary directory where the client

# certificates are stored. This directory
# MUST be owned by the UID of the server,
# and MUST not be accessible by any other
# users. When the server starts, it will do
# "chmod go-rwx" on the directory, for
# security reasons. The directory MUST
# exist when the server starts.
#
# You should also delete all of the files
# in the directory when the server starts.
# tmpdir = /tmp/radiusd
# The command used to verify the client cert.

# We recommend using the OpenSSL command-line
# tool.
#
# The ${..ca_path} text is a reference to
# the ca_path variable defined above.
#
# The %{TLS-Client-Cert-Filename} is the name
# of the temporary file containing the cert
# in PEM format. This file is automatically
# deleted by the server when the command
# returns.
# client = "/path/to/openssl verify -CApath ${..ca_path} %{TLS-
Client-Cert-Filename}"
}
#
# OCSP Configuration
# Certificates can be verified against an OCSP
# Responder. This makes it possible to immediately
# revoke certificates without the distribution of
# new Certificate Revocation Lists (CRLs).
#
ocsp {
#
# Enable it. The default is "no".
# Deleting the entire "ocsp" subsection
# also disables ocsp checking

#
enable = no
#
# The OCSP Responder URL can be automatically
# extracted from the certificate in question.
# To override the OCSP Responder URL set
# "override_cert_url = yes".
#
override_cert_url = yes
#
# If the OCSP Responder address is not extracted from
# the certificate, the URL can be defined here.
#
url = "http://127.0.0.1/ocsp/"
#
# If the OCSP Responder can not cope with nonce
# in the request, then it can be disabled here.
#
# For security reasons, disabling this option
# is not recommended as nonce protects against
# replay attacks.
#
# Note that Microsoft AD Certificate Services OCSP
# Responder does not enable nonce by default. It is
# more secure to enable nonce on the responder than
# to disable it in the query here.
# See http://technet.microsoft.com/en-
us/library/cc770413%28WS.10%29.aspx
#
# use_nonce = yes
#
# Number of seconds before giving up waiting
# for OCSP response. 0 uses system default.
#
# timeout = 0
#
# Normally an error in querying the OCSP
# responder (no response from server, server did
94
# not understand the request, etc) will result in

# a validation failure.
#
# To treat these errors as 'soft' failures and
# still accept the certificate, enable this
# option.
#
# Warning: this may enable clients with revoked
# certificates to connect if the OCSP responder
# is not available. Use with caution.
#
# softfail = no
}
}
## EAP-TLS
#
# As of Version 3.0, the TLS configuration for TLS-based
# EAP types is above in the "tls-config" section.
#
tls {
# Point to the common TLS configuration
tls = tls-common
#
# As part of checking a client certificate, the EAP-TLS
# sets some attributes such as TLS-Client-Cert-CN. This
# virtual server has access to these attributes, and can
# be used to accept or reject the request.
#
# virtual_server = check-eap-tls
}
## EAP-TTLS
#
# The TTLS module implements the EAP-TTLS protocol,
# which can be described as EAP inside of Diameter,
# inside of TLS, inside of EAP, inside of RADIUS...
#
# Surprisingly, it works quite well.
#
ttls {
# Which tls-config section the TLS negotiation parameters

# are in - see EAP-TLS above for an explanation.
#
# In the case that an old configuration from FreeRADIUS
# v2.x is being used, all the options of the tls-config
# section may also appear instead in the 'tls' section
# above. If that is done, the tls= option here (and in
# tls above) MUST be commented out.
#
tls = tls-common
# The tunneled EAP session needs a default EAP type

# which is separate from the one for the non-tunneled
# EAP module. Inside of the TTLS tunnel, we recommend
# using EAP-MD5. If the request does not contain an
# EAP conversation, then this configuration entry is
# ignored.
#
default_eap_type = md5
# The tunneled authentication request does not usually

# contain useful attributes like 'Calling-Station-Id',
# etc. These attributes are outside of the tunnel,
# and normally unavailable to the tunneled
# authentication request.
#
# By setting this configuration entry to 'yes',
# any attribute which is NOT in the tunneled
# authentication request, but which IS available
# outside of the tunnel, is copied to the tunneled
# request.
#
# allowed values: {no, yes}
#
copy_request_to_tunnel = no
#
# As of version 3.0.5, this configuration item
# is deprecated. Instead, you should use
#
# update outer.session-state {
# ...
#
# }
96
#
# This will cache attributes for the final Access-Accept.
#
# The reply attributes sent to the NAS are usually
# based on the name of the user 'outside' of the
# tunnel (usually 'anonymous'). If you want to send
# the reply attributes based on the user name inside
# of the tunnel, then set this configuration entry to
# 'yes', and the reply to the NAS will be taken from
# the reply to the tunneled request.
#
#
use_tunneled_reply = no
#
# The inner tunneled request can be sent
# through a virtual server constructed
# specifically for this purpose.
#
# If this entry is commented out, the inner
# tunneled request will be sent through
# the virtual server that processed the
# outer requests.
#
virtual_server = "inner-tunnel"
# This has the same meaning, and overwrites, the

# same field in the "tls" configuration, above.
# The default value here is "yes".
#
# include_length = yes
#
# Unlike EAP-TLS, EAP-TTLS does not require a client
# certificate. However, you can require one by setting the
# following option. You can also override this option by
# setting
#
# EAP-TLS-Require-Client-Cert = Yes
#
# in the control items for a request.
#
# Note that the majority of supplicants do not support using a

# client certificate with EAP-TTLS, so this option is unlikely
# to be usable for most people.
#
# require_client_cert = yes
}
## EAP-PEAP
#
##################################################
#
# !!!!! WARNINGS for Windows compatibility !!!!!
#
##################################################
#
# If you see the server send an Access-Challenge,
# and the client never sends another Access-Request,
# then
#
# STOP!
#
# The server certificate has to have special OID's
# in it, or else the Microsoft clients will silently
# fail. See the "scripts/xpextensions" file for
# details, and the following page:
#
# http://support.microsoft.com/kb/814394/en-us
#
# For additional Windows XP SP2 issues, see:
#
# http://support.microsoft.com/kb/885453/en-us
#
#
# If is still doesn't work, and you're using Samba,
# you may be encountering a Samba bug. See:
#
# https://bugzilla.samba.org/show_bug.cgi?id=6563
#
# Note that we do not necessarily agree with their
# explanation... but the fix does appear to work.
#
##################################################
98
#
# The tunneled EAP session needs a default EAP type
# which is separate from the one for the non-tunneled
# EAP module. Inside of the TLS/PEAP tunnel, we
# recommend using EAP-MS-CHAPv2.
#
peap {
# Which tls-config section the TLS negotiation parameters
# are in - see EAP-TLS above for an explanation.
#
# In the case that an old configuration from FreeRADIUS
# v2.x is being used, all the options of the tls-config
# section may also appear instead in the 'tls' section
# above. If that is done, the tls= option here (and in
# tls above) MUST be commented out.
#
tls = tls-common
# The tunneled EAP session needs a default

# EAP type which is separate from the one for
# the non-tunneled EAP module. Inside of the
# PEAP tunnel, we recommend using MS-CHAPv2,
# as that is the default type supported by
# Windows clients.
#
default_eap_type = mschapv2
# The PEAP module also has these configuration

# items, which are the same as for TTLS.
#
copy_request_to_tunnel = no
#
# As of version 3.0.5, this configuration item
# is deprecated. Instead, you should use
#
# update outer.session-state {
# ...
#
# }
#
# This will cache attributes for the final Access-Accept.
#
use_tunneled_reply = no
# When the tunneled session is proxied, the

# home server may not understand EAP-MSCHAP-V2.
# Set this entry to "no" to proxy the tunneled
# EAP-MSCHAP-V2 as normal MSCHAPv2.
#
# proxy_tunneled_request_as_eap = yes
#
# The inner tunneled request can be sent
# through a virtual server constructed
# specifically for this purpose.
#
# If this entry is commented out, the inner
# tunneled request will be sent through
# the virtual server that processed the
# outer requests.
#
virtual_server = "inner-tunnel"
# This option enables support for MS-SoH

# see doc/SoH.txt for more info.
# It is disabled by default.
#
# soh = yes
#
# The SoH reply will be turned into a request which
# can be sent to a specific virtual server:
#
# soh_virtual_server = "soh-server"
#
# Unlike EAP-TLS, PEAP does not require a client certificate.
# However, you can require one by setting the following
# option. You can also override this option by setting
#
# EAP-TLS-Require-Client-Cert = Yes
#
# in the control items for a request.
#
# Note that the majority of supplicants do not support using a
100
# client certificate with PEAP, so this option is unlikely to

# be usable for most people.
#
# require_client_cert = yes
}
#
# This takes no configuration.
#
# Note that it is the EAP MS-CHAPv2 sub-module, not
# the main 'mschap' module.
#
# Note also that in order for this sub-module to work,
# the main 'mschap' module MUST ALSO be configured.
#
# This module is the *Microsoft* implementation of MS-CHAPv2
# in EAP. There is another (incompatible) implementation
# of MS-CHAPv2 in EAP by Cisco, which FreeRADIUS does not
# currently support.
#
mschapv2 {
# Prior to version 2.1.11, the module never
# sent the MS-CHAP-Error message to the
# client. This worked, but it had issues
# when the cached password was wrong. The
# server *should* send "E=691 R=0" to the
# client, which tells it to prompt the user
# for a new password.
#
# The default is to behave as in 2.1.10 and
# earlier, which is known to work. If you
# set "send_error = yes", then the error
# message will be sent back to the client.
# This *may* help some clients work better,
# but *may* also cause other clients to stop
# working.
#
# send_error = no
# Server identifier to send back in the challenge.

# This should generally be the host name of the
# RADIUS server. Or, some information to uniquely
# identify it.
# identity = "FreeRADIUS"
}
## EAP-FAST
#
# The FAST module implements the EAP-FAST protocol
#
# fast {
# Point to the common TLS configuration
#
# tls = tls-common
#
# If 'cipher_list' is set here, it will over-ride the
# 'cipher_list' configuration from the 'tls-common'
# configuration. The EAP-FAST module has it's own
# over-ride for 'cipher_list' because the
# specifications mandata a different set of ciphers
# than are used by the other EAP methods.
#
# cipher_list though must include "ADH" for anonymous provisioning.
# This is not as straight forward as appending "ADH" alongside
# "DEFAULT" as "DEFAULT" contains "!aNULL" so instead it is
# recommended "ALL:!EXPORT:!eNULL:!SSLv2" is used
#
# Note - for OpenSSL 1.1.0 and above you may need
# to add ":@SECLEVEL=0"
#
# cipher_list = "ALL:!EXPORT:!eNULL:!SSLv2"
# PAC lifetime in seconds (default: seven days)

#
# pac_lifetime = 604800
# Authority ID of the server

#
# if you are running a cluster of RADIUS servers, you should make
# the value chosen here (and for "pac_opaque_key") the same on all
# your RADIUS servers. This value should be unique to your
# installation. We suggest using a domain name.
#
# authority_identity = "1234"
# PAC Opaque encryption key (must be exactly 32 bytes in size)

102
#
# This value MUST be secret, and MUST be generated using
# a secure method, such as via 'openssl rand -hex 32'
#
# pac_opaque_key = "0123456789abcdef0123456789ABCDEF"
# Same as for TTLS, PEAP, etc.

#
# virtual_server = inner-tunnel
# }
}
A.1.4 radiusd.conf
# -*- text -*-

##
## radiusd.conf -- FreeRADIUS server configuration file - 3.0.17
##
## http://www.freeradius.org/
## $Id: 59e59f3ac443e75663333a5b7732664b67c5567d $
##
######################################################################
#
# Read "man radiusd" before editing this file. See the section
# titled DEBUGGING. It outlines a method where you can quickly
# obtain the configuration you want, without running into
# trouble.
#
# Run the server in debugging mode, and READ the output.
#
# $ radiusd -X
#
# We cannot emphasize this point strongly enough. The vast
# majority of problems can be solved by carefully reading the
# debugging output, which includes warnings about common issues,
# and suggestions for how they may be fixed.
#
# There may be a lot of output, but look carefully for words like:
# "warning", "error", "reject", or "failure". The messages there
# will usually be enough to guide you to a solution.
#
# If you are going to ask a question on the mailing list, then
# explain what you are trying to do, and include the output from
# debugging mode (radiusd -X). Failure to do so means that all
# of the responses to your question will be people telling you
# to "post the output of radiusd -X".
######################################################################
#
# The location of other config files and logfiles are declared
# in this file.
#
# Also general configuration for modules can be done in this
# file, it is exported through the API to modules that ask for
# it.
#
# See "man radiusd.conf" for documentation on the format of this
# file. Note that the individual configuration items are NOT
# documented in that "man" page. They are only documented here,
# in the comments.
#
# The "unlang" policy language can be used to create complex
# if / else policies. See "man unlang" for details.
#
prefix = /usr/local
exec_prefix = ${prefix}
sysconfdir = ${prefix}/etc
localstatedir = ${prefix}/var
sbindir = ${exec_prefix}/sbin
logdir = ${localstatedir}/log/radius
raddbdir = ${sysconfdir}/raddb
radacctdir = ${logdir}/radacct
#
# name of the running server. See also the "-n" command-line option.
name = radiusd
# Location of config and logfiles.

confdir = ${raddbdir}
modconfdir = ${confdir}/mods-config
certdir = ${confdir}/certs
cadir = ${confdir}/certs
run_dir = ${localstatedir}/run/${name}
104
# Should likely be ${localstatedir}/lib/radiusd

db_dir = ${raddbdir}
#
# libdir: Where to find the rlm_* modules.
#
# This should be automatically set at configuration time.
#
# If the server builds and installs, but fails at execution time
# with an 'undefined symbol' error, then you can use the libdir
# directive to work around the problem.
#
# The cause is usually that a library has been installed on your
# system in a place where the dynamic linker CANNOT find it. When
# executing as root (or another user), your personal environment MAY
# be set up to allow the dynamic linker to find the library. When
# executing as a daemon, FreeRADIUS MAY NOT have the same
# personalized configuration.
#
# To work around the problem, find out which library contains that symbol,
# and add the directory containing that library to the end of 'libdir',
# with a colon separating the directory names. NO spaces are allowed.
#
# e.g. libdir = /usr/local/lib:/opt/package/lib
#
# You can also try setting the LD_LIBRARY_PATH environment variable
# in a script which starts the server.
#
# If that does not work, then you can re-configure and re-build the
# server to NOT use shared libraries, via:
#
# ./configure --disable-shared
# make
# make install
#
libdir = ${exec_prefix}/lib
# pidfile: Where to place the PID of the RADIUS server.

#
# The server may be signalled while it's running by using this
# file.
#
# This file is written when ONLY running in daemon mode.

#
# e.g.: kill -HUP `cat /var/run/radiusd/radiusd.pid`
#
pidfile = ${run_dir}/${name}.pid
#
# correct_escapes: use correct backslash escaping
#
# Prior to version 3.0.5, the handling of backslashes was a little
# awkward, i.e. "wrong". In some cases, to get one backslash into
# a regex, you had to put 4 in the config files.
#
# Version 3.0.5 fixes that. However, for backwards compatibility,
# the new method of escaping is DISABLED BY DEFAULT. This means
# that upgrading to 3.0.5 won't break your configuration.
#
# If you don't have double backslashes (i.e. \\) in your configuration,
# this won't matter to you. If you do have them, fix that to use only
# one backslash, and then set "correct_escapes = true".
#
# You can check for this by doing:
#
# $ grep '\\\\' $(find raddb -type f -print)
#
correct_escapes = true
# panic_action: Command to execute if the server dies unexpectedly.

#
# FOR PRODUCTION SYSTEMS, ACTIONS SHOULD ALWAYS EXIT.
# AN INTERACTIVE ACTION MEANS THE SERVER IS NOT RESPONDING TO REQUESTS.
# AN INTERACTICE ACTION MEANS THE SERVER WILL NOT RESTART.
#
# THE SERVER MUST NOT BE ALLOWED EXECUTE UNTRUSTED PANIC ACTION CODE
# PATTACH CAN BE USED AS AN ATTACK VECTOR.
#
# The panic action is a command which will be executed if the server
# receives a fatal, non user generated signal, i.e. SIGSEGV, SIGBUS,
# SIGABRT or SIGFPE.
#
# This can be used to start an interactive debugging session so
# that information regarding the current state of the server can
# be acquired.
#
106
# The following string substitutions are available:

# - %e The currently executing program e.g. /sbin/radiusd
# - %p The PID of the currently executing program e.g. 12345
#
# Standard ${} substitutions are also allowed.
#
# An example panic action for opening an interactive session in GDB would be:
#
#panic_action = "gdb %e %p"
#
# Again, don't use that on a production system.
#
# An example panic action for opening an automated session in GDB would be:
#
#panic_action = "gdb -silent -x ${raddbdir}/panic.gdb %e %p 2>&1 | tee ${logdir}/gdb-
${name}-%p.log"
#
# That command can be used on a production system.
#
# max_request_time: The maximum time (in seconds) to handle a request.

#
# Requests which take more time than this to process may be killed, and
# a REJECT message is returned.
#
# WARNING: If you notice that requests take a long time to be handled,
# then this MAY INDICATE a bug in the server, in one of the modules
# used to handle a request, OR in your local configuration.
#
# This problem is most often seen when using an SQL database. If it takes
# more than a second or two to receive an answer from the SQL database,
# then it probably means that you haven't indexed the database. See your
# SQL server documentation for more information.
#
# Useful range of values: 5 to 120
#
max_request_time = 30
# cleanup_delay: The time to wait (in seconds) before cleaning up

# a reply which was sent to the NAS.
#
# The RADIUS request is normally cached internally for a short period
# of time, after the reply is sent to the NAS. The reply packet may be
# lost in the network, and the NAS will not see it. The NAS will then
# re-send the request, and the server will respond quickly with the
# cached reply.
#
# If this value is set too low, then duplicate requests from the NAS
# MAY NOT be detected, and will instead be handled as separate requests.
#
# If this value is set too high, then the server will cache too many
# requests, and some new requests may get blocked. (See 'max_requests'.)
#
# Useful range of values: 2 to 10
#
cleanup_delay = 5
# max_requests: The maximum number of requests which the server keeps

# track of. This should be 256 multiplied by the number of clients.
# e.g. With 4 clients, this number should be 1024.
#
# If this number is too low, then when the server becomes busy,
# it will not respond to any new requests, until the 'cleanup_delay'
# time has passed, and it has removed the old requests.
#
# If this number is set too high, then the server will use a bit more
# memory for no real benefit.
#
# If you aren't sure what it should be set to, it's better to set it
# too high than too low. Setting it to 1000 per client is probably
# the highest it should be.
#
# Useful range of values: 256 to infinity
#
max_requests = 16384
# hostname_lookups: Log the names of clients or just their IP addresses

# e.g., www.freeradius.org (on) or 206.47.27.232 (off).
#
# The default is 'off' because it would be overall better for the net
# if people had to knowingly turn this feature on, since enabling it
# means that each client request will result in AT LEAST one lookup
# request to the nameserver. Enabling hostname_lookups will also
# mean that your server may stop randomly for 30 seconds from time
# to time, if the DNS requests take too long.
#
# Turning hostname lookups off also means that the server won't block
# for 30 seconds, if it sees an IP address which has no name associated
108
# with it.
#
#
hostname_lookups = no
#
# Logging section. The various "log_*" configuration items
# will eventually be moved here.
#
log {
#
# Destination for log messages. This can be one of:
#
# files - log to "file", as defined below.
# syslog - to syslog (see also the "syslog_facility", below.
# stdout - standard output
# stderr - standard error.
#
# The command-line option "-X" over-rides this option, and forces
# logging to go to stdout.
#
destination = files
#
# Highlight important messages sent to stderr and stdout.
#
# Option will be ignored (disabled) if output if TERM is not
# an xterm or output is not to a TTY.
#
colourise = yes
#
# The logging messages for the server are appended to the
# tail of this file if destination == "files"
#
# If the server is running in debugging mode, this file is
# NOT used.
#
file = ${logdir}/radius.log
#
# Which syslog facility to use, if ${destination} == "syslog"
#
# The exact values permitted here are OS-dependent. You probably
# don't want to change this.
#
syslog_facility = daemon
# Log the full User-Name attribute, as it was found in the request.

#
#
stripped_names = no
# Log authentication requests to the log file.

#
#
auth = no
# Log passwords with the authentication requests.

# auth_badpass - logs password if it's rejected
# auth_goodpass - logs password if it's correct
#
#
auth_badpass = no
auth_goodpass = no
# Log additional text at the end of the "Login OK" messages.

# for these to work, the "auth" and "auth_goodpass" or "auth_badpass"
# configurations above have to be set to "yes".
#
# The strings below are dynamically expanded, which means that
# you can put anything you want in them. However, note that
# this expansion can be slow, and can negatively impact server
# performance.
#
# msg_goodpass = ""
# msg_badpass = ""
# The message when the user exceeds the Simultaneous-Use limit.

#
msg_denied = "You are already logged in - access denied"
}
110
# The program to execute to do concurrency checks.

checkrad = ${sbindir}/checkrad
# SECURITY CONFIGURATION
#
# There may be multiple methods of attacking on the server. This
# section holds the configuration items which minimize the impact
# of those attacks
#
security {
# chroot: directory where the server does "chroot".
#
# The chroot is done very early in the process of starting
# the server. After the chroot has been performed it
# switches to the "user" listed below (which MUST be
# specified). If "group" is specified, it switches to that
# group, too. Any other groups listed for the specified
# "user" in "/etc/group" are also added as part of this
# process.
#
# The current working directory (chdir / cd) is left
# *outside* of the chroot until all of the modules have been
# initialized. This allows the "raddb" directory to be left
# outside of the chroot. Once the modules have been
# initialized, it does a "chdir" to ${logdir}. This means
# that it should be impossible to break out of the chroot.
#
# If you are worried about security issues related to this
# use of chdir, then simply ensure that the "raddb" directory
# is inside of the chroot, end be sure to do "cd raddb"
# BEFORE starting the server.
#
# If the server is statically linked, then the only files
# that have to exist in the chroot are ${run_dir} and
# ${logdir}. If you do the "cd raddb" as discussed above,
# then the "raddb" directory has to be inside of the chroot
# directory, too.
#
# chroot = /path/to/chroot/directory
# user/group: The name (or #number) of the user/group to run radiusd as.
#
# If these are commented out, the server will run as the
# user/group that started it. In order to change to a

# different user/group, you MUST be root ( or have root
# privileges ) to start the server.
#
# We STRONGLY recommend that you run the server with as few
# permissions as possible. That is, if you're not using
# shadow passwords, the user and group items below should be
# set to radius'.
#
# NOTE that some kernels refuse to setgid(group) when the
# value of (unsigned)group is above 60000; don't use group
# "nobody" on these systems!
#
# On systems with shadow passwords, you might have to set
# 'group = shadow' for the server to be able to read the
# shadow password file. If you can authenticate users while
# in debug mode, but not in daemon mode, it may be that the
# debugging mode server is running as a user that can read
# the shadow info, and the user listed below can not.
#
# The server will also try to use "initgroups" to read
# /etc/groups. It will join all groups where "user" is a
# member. This can allow for some finer-grained access
# controls.
#
# user = radius
# group = radius
# Core dumps are a bad thing. This should only be set to

# 'yes' if you're debugging a problem with the server.
#
#
allow_core_dumps = no
#
# max_attributes: The maximum number of attributes
# permitted in a RADIUS packet. Packets which have MORE
# than this number of attributes in them will be dropped.
#
# If this number is set too low, then no RADIUS packets
# will be accepted.
#
# If this number is set too high, then an attacker may be
112
# able to send a small number of packets which will cause

# the server to use all available memory on the machine.
#
# Setting this number to 0 means "allow any number of attributes"
max_attributes = 200
#
# reject_delay: When sending an Access-Reject, it can be
# delayed for a few seconds. This may help slow down a DoS
# attack. It also helps to slow down people trying to brute-force
# crack a users password.
#
# Setting this number to 0 means "send rejects immediately"
#
# If this number is set higher than 'cleanup_delay', then the
# rejects will be sent at 'cleanup_delay' time, when the request
# is deleted from the internal cache of requests.
#
# As of Version 3.0.5, "reject_delay" has sub-second resolution.
# e.g. "reject_delay = 1.4" seconds is possible.
#
# Useful ranges: 1 to 5
reject_delay = 1
#
# status_server: Whether or not the server will respond
# to Status-Server requests.
#
# When sent a Status-Server message, the server responds with
# an Access-Accept or Accounting-Response packet.
#
# This is mainly useful for administrators who want to "ping"
# the server, without adding test users, or creating fake
# accounting packets.
#
# It's also useful when a NAS marks a RADIUS server "dead".
# The NAS can periodically "ping" the server with a Status-Server
# packet. If the server responds, it must be alive, and the
# NAS can start using it for real requests.
#
# See also raddb/sites-available/status
#
status_server = yes
#
# allow_vulnerable_openssl: Allow the server to start with
# versions of OpenSSL known to have critical vulnerabilities.
#
# This check is based on the version number reported by libssl
# and may not reflect patches applied to libssl by
# distribution maintainers.
#
allow_vulnerable_openssl = no
}
# PROXY CONFIGURATION
#
# proxy_requests: Turns proxying of RADIUS requests on or off.
#
# The server has proxying turned on by default. If your system is NOT
# set up to proxy requests to another server, then you can turn proxying
# off here. This will save a small amount of resources on the server.
#
# If you have proxying turned off, and your configuration files say
# to proxy a request, then an error message will be logged.
#
# To disable proxying, change the "yes" to "no", and comment the
# $INCLUDE line.
#
#
proxy_requests = yes
$INCLUDE proxy.conf
# CLIENTS CONFIGURATION
#
# Client configuration is defined in "clients.conf".
#
# The 'clients.conf' file contains all of the information from the old
# 'clients' and 'naslist' configuration files. We recommend that you
# do NOT use 'client's or 'naslist', although they are still
# supported.
#
# Anything listed in 'clients.conf' will take precedence over the
# information from the old-style configuration files.
114
#
$INCLUDE clients.conf
# THREAD POOL CONFIGURATION

#
# The thread pool is a long-lived group of threads which
# take turns (round-robin) handling any incoming requests.
#
# You probably want to have a few spare threads around,
# so that high-load situations can be handled immediately. If you
# don't have any spare threads, then the request handling will
# be delayed while a new thread is created, and added to the pool.
#
# You probably don't want too many spare threads around,
# otherwise they'll be sitting there taking up resources, and
# not doing anything productive.
#
# The numbers given below should be adequate for most situations.
#
thread pool {
# Number of servers to start initially --- should be a reasonable
# ballpark figure.
start_servers = 5
# Limit on the total number of servers running.

#
# If this limit is ever reached, clients will be LOCKED OUT, so it
# should NOT BE SET TOO LOW. It is intended mainly as a brake to
# keep a runaway server from taking the system with it as it spirals
# down...
#
# You may find that the server is regularly reaching the
# 'max_servers' number of threads, and that increasing
# 'max_servers' doesn't seem to make much difference.
#
# If this is the case, then the problem is MOST LIKELY that
# your back-end databases are taking too long to respond, and
# are preventing the server from responding in a timely manner.
#
# The solution is NOT do keep increasing the 'max_servers'
# value, but instead to fix the underlying cause of the
# problem: slow database, or 'hostname_lookups=yes'.
#
# For more information, see 'max_request_time', above.
#
max_servers = 32
# Server-pool size regulation. Rather than making you guess

# how many servers you need, FreeRADIUS dynamically adapts to
# the load it sees, that is, it tries to maintain enough
# servers to handle the current load, plus a few spare
# servers to handle transient load spikes.
#
# It does this by periodically checking how many servers are
# waiting for a request. If there are fewer than
# min_spare_servers, it creates a new spare. If there are
# more than max_spare_servers, some of the spares die off.
# The default values are probably OK for most sites.
#
min_spare_servers = 3
max_spare_servers = 10
# When the server receives a packet, it places it onto an

# internal queue, where the worker threads (configured above)
# pick it up for processing. The maximum size of that queue
# is given here.
#
# When the queue is full, any new packets will be silently
# discarded.
#
# The most common cause of the queue being full is that the
# server is dependent on a slow database, and it has received
# a large "spike" of traffic. When that happens, there is
# very little you can do other than make sure the server
# receives less traffic, or make sure that the database can
# handle the load.
#
# max_queue_size = 65536
# Clean up old threads periodically. For no reason other than

# it might be useful.
#
# '0' is a special value meaning 'infinity', or 'the servers never
# exit'
max_requests_per_server = 0
116
# Automatically limit the number of accounting requests.

# This configuration item tracks how many requests per second
# the server can handle. It does this by tracking the
# packets/s received by the server for processing, and
# comparing that to the packets/s handled by the child
# threads.
#
# If the received PPS is larger than the processed PPS, *and*

# the queue is more than half full, then new accounting
# requests are probabilistically discarded. This lowers the
# number of packets that the server needs to process. Over
# time, the server will "catch up" with the traffic.
#
# Throwing away accounting packets is usually safe and low
# impact. The NAS will retransmit them in a few seconds, or
# even a few minutes. Vendors should read RFC 5080 Section 2.2.1
# to see how accounting packets should be retransmitted. Using
# any other method is likely to cause network meltdowns.
#
auto_limit_acct = no
}
######################################################################
#
# SNMP notifications. Uncomment the following line to enable
# snmptraps. Note that you MUST also configure the full path
# to the "snmptrap" command in the "trigger.conf" file.
#
#$INCLUDE trigger.conf
# MODULE CONFIGURATION
#
# The names and configuration of each module is located in this section.
#
# After the modules are defined here, they may be referred to by name,
# in other sections of this configuration file.
#
modules {
#
# Each module has a configuration as follows:
#
# name [ instance ] {
# config_item = value
# ...
# }
#
# The 'name' is used to load the 'rlm_name' library
# which implements the functionality of the module.
#
# The 'instance' is optional. To have two different instances
# of a module, it first must be referred to by 'name'.
# The different copies of the module are then created by
# inventing two 'instance' names, e.g. 'instance1' and 'instance2'
#
# The instance names can then be used in later configuration
# INSTEAD of the original 'name'. See the 'radutmp' configuration
# for an example.
#
#
# As of 3.0, modules are in mods-enabled/. Files matching
# the regex /[a-zA-Z0-9_.]+/ are loaded. The modules are
# initialized ONLY if they are referenced in a processing
# section, such as authorize, authenticate, accounting,
# pre/post-proxy, etc.
#
$INCLUDE mods-enabled/
}
# Instantiation
#
# This section orders the loading of the modules. Modules
# listed here will get loaded BEFORE the later sections like
# authorize, authenticate, etc. get examined.
#
# This section is not strictly needed. When a section like
# authorize refers to a module, it's automatically loaded and
# initialized. However, some modules may not be listed in any
# of the following sections, so they can be listed here.
#
# Also, listing modules here ensures that you have control over
# the order in which they are initialized. If one module needs
# something defined by another module, you can list them in order
# here, and ensure that the configuration will be OK.
#
# After the modules listed here have been loaded, all of the modules
118
# in the "mods-enabled" directory will be loaded. Loading the

# "mods-enabled" directory means that unlike Version 2, you usually
# don't need to list modules here.
#
instantiate {
#
# We list the counter module here so that it registers
# the check_name attribute before any module which sets
# it
# daily
# subsections here can be thought of as "virtual" modules.

#
# e.g. If you have two redundant SQL servers, and you want to
# use them in the authorize and accounting sections, you could
# place a "redundant" block in each section, containing the
# exact same text. Or, you could uncomment the following
# lines, and list "redundant_sql" in the authorize and
# accounting sections.
#
# The "virtual" module defined here can also be used with
# dynamic expansions, under a few conditions:
#
# * The section is "redundant", or "load-balance", or
# "redundant-load-balance"
# * The section contains modules ONLY, and no sub-sections
# * all modules in the section are using the same rlm_
# driver, e.g. They are all sql, or all ldap, etc.
#
# When those conditions are satisfied, the server will
# automatically register a dynamic expansion, using the
# name of the "virtual" module. In the example below,
# it will be "redundant_sql". You can then use this expansion
# just like any other:
#
# update reply {
# Filter-Id := "%{redundant_sql: ... }"
# }
#
# In this example, the expansion is done via module "sql1",
# and if that expansion fails, using module "sql2".
#
# For best results, configure the "pool" subsection of the
# module so that "retry_delay" is non-zero. That will allow

# the redundant block to quickly ignore all "down" SQL
# databases. If instead we have "retry_delay = 0", then
# every time the redundant block is used, the server will try
# to open a connection to every "down" database, causing
# problems.
#
#redundant redundant_sql {
# sql1
# sql2
#}
}
######################################################################
#
# Policies are virtual modules, similar to those defined in the
# "instantiate" section above.
#
# Defining a policy in one of the policy.d files means that it can be
# referenced in multiple places as a *name*, rather than as a series of
# conditions to match, and actions to take.
#
# Policies are something like subroutines in a normal language, but
# they cannot be called recursively. They MUST be defined in order.
# If policy A calls policy B, then B MUST be defined before A.
#
######################################################################
policy {
$INCLUDE policy.d/
}
######################################################################
#
# Load virtual servers.
#
# This next $INCLUDE line loads files in the directory that
# match the regular expression: /[a-zA-Z0-9_.]+/
#
# It allows you to define new virtual servers simply by placing
# a file into the raddb/sites-enabled/ directory.
#
$INCLUDE sites-enabled/
######################################################################
120
#
# All of the other configuration sections like "authorize {}",
# "authenticate {}", "accounting {}", have been moved to the
# the file:
#
# raddb/sites-available/default
#
# This is the "default" virtual server that has the same
# configuration as in version 1.0.x and 1.1.x. The default
# installation enables this virtual server. You should
# edit it to create policies for your local site.
#
# For more documentation on virtual servers, see:
#
# raddb/sites-available/README
#
######################################################################
A.1.5 ./sites-enabled/default
######################################################################
#
# As of 2.0.0, FreeRADIUS supports virtual hosts using the
# "server" section, and configuration directives.
#
# Virtual hosts should be put into the "sites-available"
# directory. Soft links should be created in the "sites-enabled"
# directory to these files. This is done in a normal installation.
#
# If you are using 802.1X (EAP) authentication, please see also
# the "inner-tunnel" virtual server. You will likely have to edit
# that, too, for authentication to work.
#
# $Id: 3616050e7625eb6b5e2ba44782fcb737b2ae6136 $
#
######################################################################
#
# Read "man radiusd" before editing this file. See the section
# titled DEBUGGING. It outlines a method where you can quickly
# obtain the configuration you want, without running into
# trouble. See also "man unlang", which documents the format
# of this file.
#
# This configuration is designed to work in the widest possible
# set of circumstances, with the widest possible number of
# authentication methods. This means that in general, you should
# need to make very few changes to this file.
#
# The best way to configure the server for your local system
# is to CAREFULLY edit this file. Most attempts to make large
# edits to this file will BREAK THE SERVER. Any edits should
# be small, and tested by running the server with "radiusd -X".
# Once the edits have been verified to work, save a copy of these
# configuration files somewhere. (e.g. as a "tar" file). Then,
# make more edits, and test, as above.
#
# There are many "commented out" references to modules such
# as ldap, sql, etc. These references serve as place-holders.
# If you need the functionality of that module, then configure
# it in radiusd.conf, and un-comment the references to it in
# this file. In most cases, those small changes will result
# in the server being able to connect to the DB, and to
# authenticate users.
#
######################################################################
server default {
#
# If you want the server to listen on additional addresses, or on
# additional ports, you can use multiple "listen" sections.
#
# Each section make the server listen for only one type of packet,
# therefore authentication and accounting have to be configured in
# different sections.
#
# The server ignore all "listen" section if you are using '-i' and '-p'
# on the command line.
#
listen {
# Type of packets to listen for.
# Allowed values are:
# auth listen for authentication packets
# acct listen for accounting packets
# proxy IP to use for sending proxied packets
# detail Read from the detail file. For examples, see
122
# raddb/sites-available/copy-acct-to-home-server
# status listen for Status-Server packets. For examples,
# see raddb/sites-available/status
# coa listen for CoA-Request and Disconnect-Request
# packets. For examples, see the file
# raddb/sites-available/coa
#
type = auth
# Note: "type = proxy" lets you control the source IP used for
# proxying packets, with some limitations:
#
# * A proxy listener CANNOT be used in a virtual server section.
# * You should probably set "port = 0".
# * Any "clients" configuration will be ignored.
#
# See also proxy.conf, and the "src_ipaddr" configuration entry
# in the sample "home_server" section. When you specify the
# source IP address for packets sent to a home server, the
# proxy listeners are automatically created.
# ipaddr/ipv4addr/ipv6addr - IP address on which to listen.

# If multiple ones are listed, only the first one will
# be used, and the others will be ignored.
#
# The configuration options accept the following syntax:
#
# ipv4addr - IPv4 address (e.g.192.0.2.3)
# - wildcard (i.e. *)
# - hostname (radius.example.com)
# Only the A record for the host name is used.
# If there is no A record, an error is returned,
# and the server fails to start.
#
# ipv6addr - IPv6 address (e.g. 2001:db8::1)
# - wildcard (i.e. *)
# - hostname (radius.example.com)
# Only the AAAA record for the host name is used.
# If there is no AAAA record, an error is returned,
# and the server fails to start.
#
# ipaddr - IPv4 address as above
# - IPv6 address as above
# - wildcard (i.e. *), which means IPv4 wildcard.

# - hostname
# If there is only one A or AAAA record returned
# for the host name, it is used.
# If multiple A or AAAA records are returned
# for the host name, only the first one is used.
# If both A and AAAA records are returned
# for the host name, only the A record is used.
#
# ipv4addr = *
# ipv6addr = *
ipaddr = *
# Port on which to listen.

# Allowed values are:
# integer port number (1812)
# 0 means "use /etc/services for the proper port"
port = 0
# Some systems support binding to an interface, in addition

# to the IP address. This feature isn't strictly necessary,
# but for sites with many IP addresses on one interface,
# it's useful to say "listen on all addresses for eth0".
#
# If your system does not support this feature, you will
# get an error if you try to use it.
#
# interface = eth0
# Per-socket lists of clients. This is a very useful feature.

#
# The name here is a reference to a section elsewhere in
# radiusd.conf, or clients.conf. Having the name as
# a reference allows multiple sockets to use the same
# set of clients.
#
# If this configuration is used, then the global list of clients
# is IGNORED for this "listen" section. Take care configuring
# this feature, to ensure you don't accidentally disable a
# client you need.
#
# See clients.conf for the configuration of "per_socket_clients".
#
# clients = per_socket_clients
124
#
# Connection limiting for sockets with "proto = tcp".
#
# This section is ignored for other kinds of sockets.
#
limit {
#
# Limit the number of simultaneous TCP connections to the socket
#
# The default is 16.
# Setting this to 0 means "no limit"
# The per-socket "max_requests" option does not exist.
#
# The lifetime, in seconds, of a TCP connection. After
# this lifetime, the connection will be closed.
#
# Setting this to 0 means "forever".
lifetime = 0
#
# The idle timeout, in seconds, of a TCP connection.
# If no packets have been received over the connection for
# this time, the connection will be closed.
#
# Setting this to 0 means "no timeout".
#
# We STRONGLY RECOMMEND that you set an idle timeout.
#
idle_timeout = 30
}
}
#
# This second "listen" section is for listening on the accounting
# port, too.
#
listen {
ipaddr = *
# ipv6addr = ::
port = 0
type = acct
# interface = eth0
limit {
# The number of packets received can be rate limited via the
# "max_pps" configuration item. When it is set, the server
# tracks the total number of packets received in the previous
# second. If the count is greater than "max_pps", then the
# new packet is silently discarded. This helps the server
# deal with overload situations.
#
# The packets/s counter is tracked in a sliding window. This
# means that the pps calculation is done for the second
# before the current packet was received. NOT for the current
# wall-clock second, and NOT for the previous wall-clock second.
#
# Useful values are 0 (no limit), or 100 to 10000.
# Values lower than 100 will likely cause the server to ignore
# normal traffic. Few systems are capable of handling more than
# 10K packets/s.
#
# It is most useful for accounting systems. Set it to 50%
# more than the normal accounting load, and you can be sure that
# the server will never get overloaded
#
# max_pps = 0
# Only for "proto = tcp". These are ignored for "udp" sockets.
#
# idle_timeout = 0
# lifetime = 0
# max_connections = 0
}
}
# IPv6 versions of the above - read their full config to understand options
listen {
type = auth
ipv6addr = :: # any. ::1 == localhost
port = 0
# interface = eth0
126
limit {
lifetime = 0
idle_timeout = 30
}
}
listen {
ipv6addr = ::
port = 0
type = acct
# interface = eth0
limit {
# max_pps = 0
# idle_timeout = 0
# lifetime = 0
# max_connections = 0
}
}
# Authorization. First preprocess (hints and huntgroups files),

# then realms, and finally look in the "users" file.
#
# Any changes made here should also be made to the "inner-tunnel"
# virtual server.
#
# The order of the realm modules will determine the order that
# we try to find a matching realm.
#
# Make *sure* that 'preprocess' comes before any realm if you
# need to setup hints for the remote radius server
authorize {
#
# Take a User-Name, and perform some checks on it, for spaces and other
# invalid characters. If the User-Name appears invalid, reject the
# request.
#
# See policy.d/filter for the definition of the filter_username policy.
#
filter_username
#
# Some broken equipment sends passwords with embedded zeros.
# i.e. the debug output will show
#
# User-Password = "password\000\000"
#
# This policy will fix it to just be "password".
#
# filter_password
#
# The preprocess module takes care of sanitizing some bizarre
# attributes in the request, and turning them into attributes
# which are more standard.
#
# It takes care of processing the 'raddb/mods-config/preprocess/hints'
# and the 'raddb/mods-config/preprocess/huntgroups' files.
preprocess
# If you intend to use CUI and you require that the Operator-Name
# be set for CUI generation and you want to generate CUI also
# for your local clients then uncomment the operator-name
# below and set the operator-name for your clients in clients.conf
# operator-name
#
# If you want to generate CUI for some clients that do not
# send proper CUI requests, then uncomment the
# cui below and set "add_cui = yes" for these clients in clients.conf
# cui
#
# If you want to have a log of authentication requests,
# un-comment the following line.
# auth_log
#
# The chap module will set 'Auth-Type := CHAP' if we are
# handling a CHAP request and Auth-Type has not already been set
chap
#
# If the users are logging in with an MS-CHAP-Challenge
# attribute for authentication, the mschap module will find
128
# the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'

# to the request, which will cause the server to then use
# the mschap module for authentication.
mschap
#
# If you have a Cisco SIP server authenticating against
# FreeRADIUS, uncomment the following line, and the 'digest'
# line in the 'authenticate' section.
digest
#
# The WiMAX specification says that the Calling-Station-Id
# is 6 octets of the MAC. This definition conflicts with
# RFC 3580, and all common RADIUS practices. Un-commenting
# the "wimax" module here means that it will fix the
# Calling-Station-Id attribute to the normal format as
# specified in RFC 3580 Section 3.21
# wimax
#
# Look for IPASS style 'realm/', and if not found, look for
# '@realm', and decide whether or not to proxy, based on
# that.
# IPASS
#
# If you are using multiple kinds of realms, you probably
# want to set "ignore_null = yes" for all of them.
# Otherwise, when the first style of realm doesn't match,
# the other styles won't be checked.
#
suffix
# ntdomain
#
# This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP
# authentication.
#
# It also sets the EAP-Type attribute in the request
# attribute list to the EAP type from the packet.
#
# The EAP module returns "ok" or "updated" if it is not yet ready
# to authenticate the user. The configuration below checks for

# "ok", and stops processing the "authorize" section if so.
#
# Any LDAP and/or SQL servers will not be queried for the
# initial set of packets that go back and forth to set up
# TTLS or PEAP.
#
# The "updated" check is commented out for compatibility with
# previous versions of this configuration, but you may wish to
# uncomment it as well; this will further reduce the number of
# LDAP and/or SQL queries for TTLS or PEAP.
#
eap {
ok = return
# updated = return
}
#
# Pull crypt'd passwords from /etc/passwd or /etc/shadow,
# using the system API's to get the password. If you want
# to read /etc/passwd or /etc/shadow directly, see the
# mods-available/passwd module.
#
# unix
#
# Read the 'users' file. In v3, this is located in
# raddb/mods-config/files/authorize
files
#
# Look in an SQL database. The schema of the database
# is meant to mirror the "users" file.
#
# See "Authorization Queries" in mods-available/sql
-sql
#
# If you are using /etc/smbpasswd, and are also doing
# mschap authentication, the un-comment this line, and
# configure the 'smbpasswd' module.
# smbpasswd
#
130
# The ldap module reads passwords from the LDAP database.

-ldap
#
# Enforce daily limits on time spent logged in.
# daily
#
expiration
logintime
#
# If no other module has claimed responsibility for
# authentication, then try to use PAP. This allows the
# other modules listed above to add a "known good" password
# to the request, and to do nothing else. The PAP module
# will then see that password, and use it to do PAP
# authentication.
#
# This module should be listed last, so that the other modules
# get a chance to set Auth-Type for themselves.
#
pap
#
# If "status_server = yes", then Status-Server messages are passed
# through the following section, and ONLY the following section.
# This permits you to do DB queries, for example. If the modules
# listed here return "fail", then NO response is sent.
#
# Autz-Type Status-Server {
#
# }
}
# Authentication.
#
#
# This section lists which modules are available for authentication.
# Note that it does NOT mean 'try each module in order'. It means
# that a module from the 'authorize' section adds a configuration
# attribute 'Auth-Type := FOO'. That authentication type is then
# used to pick the appropriate module from the list below.

#
# In general, you SHOULD NOT set the Auth-Type attribute. The server
# will figure it out on its own, and will do the right thing. The
# most common side effect of erroneously setting the Auth-Type
# attribute is that one authentication method will work, but the
# others will not.
#
# The common reasons to set the Auth-Type attribute by hand
# is to either forcibly reject the user (Auth-Type := Reject),
# or to or forcibly accept the user (Auth-Type := Accept).
#
# Note that Auth-Type := Accept will NOT work with EAP.
#
# Please do not put "unlang" configurations into the "authenticate"
# section. Put them in the "post-auth" section instead. That's what
# the post-auth section is for.
#
authenticate {
#
# PAP authentication, when a back-end database listed
# in the 'authorize' section supplies a password. The
# password can be clear-text, or encrypted.
Auth-Type PAP {
pap
}
krb5
}
#
# Most people want CHAP authentication
# A back-end database listed in the 'authorize' section
# MUST supply a CLEAR TEXT password. Encrypted passwords
# won't work.
Auth-Type CHAP {
chap
}
#
# MSCHAP authentication.
Auth-Type MS-CHAP {
132
mschap
}
#
# For old names, too.
#
mschap
#
# If you have a Cisco SIP server authenticating against
# FreeRADIUS, uncomment the following line, and the 'digest'
# line in the 'authorize' section.
digest
#
# Pluggable Authentication Modules.
# pam
# Uncomment it if you want to use ldap for authentication

#
# Note that this means "check plain-text password against
# the ldap database", which means that EAP won't work,
# as it does not supply a plain-text password.
#
# We do NOT recommend using this. LDAP servers are databases.
# They are NOT authentication servers. FreeRADIUS is an
# authentication server, and knows what to do with authentication.
# LDAP servers do not.
#
# Auth-Type LDAP {
# ldap
# }
#
# Allow EAP authentication.
eap
#
# The older configurations sent a number of attributes in
# Access-Challenge packets, which wasn't strictly correct.
# If you want to filter out these attributes, uncomment
# the following lines.
#
# Auth-Type eap {
# eap {
# handled = 1
# }
# if (handled && (Response-Packet-Type == Access-Challenge)) {
# attr_filter.access_challenge.post-auth
# handled # override the "updated" code from attr_filter
# }
# }
}
#
# Pre-accounting. Decide which accounting type to use.
#
preacct {
preprocess
#
# Merge Acct-[Input|Output]-Gigawords and Acct-[Input-Output]-Octets
# into a single 64bit counter Acct-[Input|Output]-Octets64.
#
# acct_counters64
#
# Session start times are *implied* in RADIUS.
# The NAS never sends a "start time". Instead, it sends
# a start packet, *possibly* with an Acct-Delay-Time.
# The server is supposed to conclude that the start time
# was "Acct-Delay-Time" seconds in the past.
#
# The code below creates an explicit start time, which can
# then be used in other modules. It will be *mostly* correct.
# Any errors are due to the 1-second resolution of RADIUS,
# and the possibility that the time on the NAS may be off.
#
# The start time is: NOW - delay - session_length
#
# update request {
# &FreeRADIUS-Acct-Session-Start-Time = "%{expr: %l - %{%{Acct-Session-
Time}:-0} - %{%{Acct-Delay-Time}:-0}}"
# }
134
#
# Ensure that we have a semi-unique identifier for every
# request, and many NAS boxes are broken.
acct_unique
#
# Look for IPASS-style 'realm/', and if not found, look for
# '@realm', and decide whether or not to proxy, based on
# that.
#
# Accounting requests are generally proxied to the same
# home server as authentication requests.
# IPASS
suffix
# ntdomain
#
# Read the 'acct_users' file
files
}
#
# Accounting. Log the accounting data.
#
accounting {
# Update accounting packet by adding the CUI attribute
# recorded from the corresponding Access-Accept
# use it only if your NAS boxes do not support CUI themselves
# cui
#
# Create a 'detail'ed log of the packets.
# Note that accounting requests which are proxied
# are also logged in the detail file.
detail
# daily
# Update the wtmp file

#
# If you don't use "radlast", you can delete this line.
unix
#
# For Simultaneous-Use tracking.

#
# Due to packet losses in the network, the data here
# may be incorrect. There is little we can do about it.
# radutmp
# sradutmp
# Return an address to the IP Pool when we see a stop record.

# main_pool
#
# Log traffic to an SQL database.
#
# See "Accounting queries" in mods-available/sql
-sql
#
# If you receive stop packets with zero session length,
# they will NOT be logged in the database. The SQL module
# will print a message (only in debugging mode), and will
# return "noop".
#
# You can ignore these packets by uncommenting the following
# three lines. Otherwise, the server will not respond to the
# accounting request, and the NAS will retransmit.
#
# if (noop) {
# ok
# }
# Cisco VoIP specific bulk accounting

# pgsql-voip
# For Exec-Program and Exec-Program-Wait

exec
# Filter attributes from the accounting response.

attr_filter.accounting_response
#
# See "Autz-Type Status-Server" for how this works.
#
# Acct-Type Status-Server {
#
136
# }
}
# Session database, used for checking Simultaneous-Use. Either the radutmp

# or rlm_sql module can handle this.
# The rlm_sql module is *much* faster
session {
# radutmp
#
# See "Simultaneous Use Checking Queries" in mods-available/sql
# sql
}
# Post-Authentication
# Once we KNOW that the user has been authenticated, there are
# additional steps we can take.
post-auth {
#
# If you need to have a State attribute, you can
# add it here. e.g. for later CoA-Request with
# State, and Service-Type = Authorize-Only.
#
# if (!&reply:State) {
# update reply {
# State := "0x%{randstr:16h}"
# }
# }
#
# For EAP-TTLS and PEAP, add the cached attributes to the reply.
# The "session-state" attributes are automatically cached when
# an Access-Challenge is sent, and automatically retrieved
# when an Access-Request is received.
#
# The session-state attributes are automatically deleted after
# an Access-Reject or Access-Accept is sent.
#
update {
&reply: += &session-state:
}
# Get an address from the IP Pool.

# main_pool
# Create the CUI value and add the attribute to Access-Accept.

# Uncomment the line below if *returning* the CUI.
# cui
#
# If you want to have a log of authentication replies,
# un-comment the following line, and enable the
# 'detail reply_log' module.
# reply_log
#
# After authenticating the user, do another SQL query.
#
# See "Authentication Logging Queries" in mods-available/sql
-sql
#
# Un-comment the following if you want to modify the user's object
# in LDAP after a successful login.
#
# ldap
# For Exec-Program and Exec-Program-Wait

exec
#
# Calculate the various WiMAX keys. In order for this to work,
# you will need to define the WiMAX NAI, usually via
#
# update request {
# WiMAX-MN-NAI = "%{User-Name}"
# }
#
# If you want various keys to be calculated, you will need to
# update the reply with "template" values. The module will see
# this, and replace the template values with the correct ones
# taken from the cryptographic calculations. e.g.
#
# update reply {
138
# WiMAX-FA-RK-Key = 0x00
# WiMAX-MSK = "%{EAP-MSK}"
# }
#
# You may want to delete the MS-MPPE-*-Keys from the reply,
# as some WiMAX clients behave badly when those attributes
# are included. See "raddb/modules/wimax", configuration
# entry "delete_mppe_keys" for more information.
#
# wimax
# If there is a client certificate (EAP-TLS, sometimes PEAP

# and TTLS), then some attributes are filled out after the
# certificate verification has been performed. These fields
# MAY be available during the authentication, or they may be
# available only in the "post-auth" section.
#
# The first set of attributes contains information about the
# issuing certificate which is being used. The second
# contains information about the client certificate (if
# available).
#
# update reply {
# Reply-Message += "%{TLS-Cert-Serial}"
# Reply-Message += "%{TLS-Cert-Expiration}"
# Reply-Message += "%{TLS-Cert-Subject}"
# Reply-Message += "%{TLS-Cert-Issuer}"
# Reply-Message += "%{TLS-Cert-Common-Name}"
# Reply-Message += "%{TLS-Cert-Subject-Alt-Name-Email}"
#
# Reply-Message += "%{TLS-Client-Cert-Serial}"
# Reply-Message += "%{TLS-Client-Cert-Expiration}"
# Reply-Message += "%{TLS-Client-Cert-Subject}"
# Reply-Message += "%{TLS-Client-Cert-Issuer}"
# Reply-Message += "%{TLS-Client-Cert-Common-Name}"
# Reply-Message += "%{TLS-Client-Cert-Subject-Alt-Name-Email}"
# }
# Insert class attribute (with unique value) into response,

# aids matching auth and acct records, and protects against duplicate
# Acct-Session-Id. Note: Only works if the NAS has implemented
# RFC 2865 behaviour for the class attribute, AND if the NAS
# supports long Class attributes. Many older or cheap NASes

# only support 16-octet Class attributes.
# insert_acct_class
# MacSEC requires the use of EAP-Key-Name. However, we don't

# want to send it for all EAP sessions. Therefore, the EAP
# modules put required data into the EAP-Session-Id attribute.
# This attribute is never put into a request or reply packet.
#
# Uncomment the next few lines to copy the required data into
# the EAP-Key-Name attribute
# if (&reply:EAP-Session-Id) {
# update reply {
# EAP-Key-Name := &reply:EAP-Session-Id
# }
# }
# Remove reply message if the response contains an EAP-Message

remove_reply_message_if_eap
#
# Access-Reject packets are sent through the REJECT sub-section of the
# post-auth section.
#
# Add the ldap module name (or instance) if you have set
# 'edir_account_policy_check = yes' in the ldap module configuration
#
# The "session-state" attributes are not available here.
#
Post-Auth-Type REJECT {
# log failed authentications in SQL, too.
-sql
attr_filter.access_reject
# Insert EAP-Failure message if the request was

# rejected by policy instead of because of an
# authentication failure
eap
# Remove reply message if the response contains an EAP-Message

remove_reply_message_if_eap
}
#
140
# Filter access challenges.

#
Post-Auth-Type Challenge {
# remove_reply_message_if_eap
# attr_filter.access_challenge.post-auth
}
#
# When the server decides to proxy a request to a home server,
# the proxied request is first passed through the pre-proxy
# stage. This stage can re-write the request, or decide to
# cancel the proxy.
#
# Only a few modules currently have this method.
#
pre-proxy {
# Before proxing the request add an Operator-Name attribute identifying
# if the operator-name is found for this client.
# No need to uncomment this if you have already enabled this in
# the authorize section.
# operator-name
# The client requests the CUI by sending a CUI attribute

# containing one zero byte.
# Uncomment the line below if *requesting* the CUI.
# cui
# Uncomment the following line if you want to change attributes

# as defined in the preproxy_users file.
# files
# Uncomment the following line if you want to filter requests

# sent to remote servers based on the rules defined in the
# 'attrs.pre-proxy' file.
# attr_filter.pre-proxy
# If you want to have a log of packets proxied to a home

# server, un-comment the following line, and the
# 'detail pre_proxy_log' section, above.
# pre_proxy_log
}
#
# When the server receives a reply to a request it proxied
# to a home server, the request may be massaged here, in the
# post-proxy stage.
#
post-proxy {
# If you want to have a log of replies from a home server,

# un-comment the following line, and the 'detail post_proxy_log'
# section, above.
# post_proxy_log
# Uncomment the following line if you want to filter replies from

# remote proxies based on the rules defined in the 'attrs' file.
# attr_filter.post-proxy
#
# If you are proxying LEAP, you MUST configure the EAP
# module, and you MUST list it here, in the post-proxy
# stage.
#
# You MUST also use the 'nostrip' option in the 'realm'
# configuration. Otherwise, the User-Name attribute
# in the proxied request will not match the user name
# hidden inside of the EAP packet, and the end server will
# reject the EAP request.
#
eap
#
# If the server tries to proxy a request and fails, then the
# request is processed through the modules in this section.
#
# The main use of this section is to permit robust proxying
# of accounting packets. The server can be configured to
# proxy accounting packets as part of normal processing.
# Then, if the home server goes down, accounting packets can
# be logged to a local "detail" file, for processing with
# radrelay. When the home server comes back up, radrelay
# will read the detail file, and send the packets to the
# home server.
#
# With this configuration, the server always responds to
142
# Accounting-Requests from the NAS, but only writes

# accounting packets to disk if the home server is down.
#
# Post-Proxy-Type Fail-Accounting {
# detail
# }
}
}
A.2 Kerberos
En esta sección mostraremos los archivos de configuración completos del sistema Kerberos
A.2.1 /etc/krb5.conf
[libdefaults]
default_realm = JOSE.RTS
# The following krb5.conf variables are only for MIT Kerberos.

kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
# The following encryption type specification will be used by MIT Kerberos

# if uncommented. In general, the defaults in the MIT Kerberos code are
# correct and overriding these specifications only serves to disable new
# encryption types as they are added, creating interoperability problems.
#
# The only time when you might need to uncomment these lines and change
# the enctypes is if you have local software that will break on ticket
# caches containing ticket encryption types it doesn't know about (such as
# old versions of Sun Java).
# default_tgs_enctypes = des3-hmac-sha1
# default_tkt_enctypes = des3-hmac-sha1
# permitted_enctypes = des3-hmac-sha1
# The following libdefaults parameters are only for Heimdal Kerberos.

fcc-mit-ticketflags = true
[realms]
DOMINIOSES.RTS = {
kdc = dc.dominioses.rts
admin_server = dc.dominioses.rts
}
JOSE.RTS = {
kdc = kdc01.jose.rts
admin_server = kdc01.jose.rts
}
[domain_realm]
.dominioses.rts = DOMINIOSES.RTS
dominioses.rts = DOMINIOSES.RTS
.jose.rts = JOSE.RTS
jose.rts = JOSE.RTS
A.2.2 /etc/krb5kdc/kdc.conf
[kdcdefaults]
kdc_ports = 750,88
[realms]
JOSE.RTS = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
#supported_enctypes = aes256-cts:normal aes128-cts:normal
default_principal_flags = +preauth
}
145

PFC 2446 Acero PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PFC 2446 Acero PDF

Cargado por

Copyright:

Formatos disponibles

Proyecto Fin de Carrera

Diseño e implantación de un servidor RADIUS

Autor: José Mª Acero Vázquez

Equation Chapter 1 Section 1

Departamento de Ingeniería Telemática

Diseño e implantación de un servidor RADIUS

Departamento de Ingeniería Telemática

Autor: José Mª Acero Vázquez

Tutor: Germán Madinabeitia Luque

Acuerdan otorgarle la calificación de:

El Secretario del Tribunal

José Mª Acero Vázquez

Tabla 2–1. Tipos de atributos 9

Figura 2-1. Formato de mensaje RADIUS 5

Ahora vamos a ver cómo podemos responder a estas tres preguntas.

2.2 Propiedades del servidor RADIUS

2.3 Funcionamiento del servidor RADIUS

2.3.1 Formato de mensaje

Figura 2-1. Formato de mensaje RADIUS

2.3.2 Tipos de paquetes RADIUS

2.3.3 Clave compartida (shared-secret)

2.3.4 Parejas atributo-valor

Las parejas atributo-valor tienen el siguiente formato:

Figura 2-2. Formato de parejas atributo-valor

Y los siguientes son los significados de cada campo

2.3.4.2 Tipos de atributos

2.3.4.3 Atributos específicos del fabricante

Figura 2-3. Formato de atributos específicos del fabricante

Tabla 2–1. Tipos de atributos

2.4 Métodos de autenticación

2.4.3 Extensible Authentication Protocol (EAP)

Figura 2-4. Autenticación EAP

2.7 Alta disponibilidad

3.2 Descripción del protocolo Kerberos

3.2.1 Pre-authentication. Ticket Granting Ticket

Figura 3-1. Mecanismo de autenticación Kerberos. Fuente: web.mit.edu

3.2.2 Uso de servicios. Ticket Granting Service

Podemos resumir el mecanismo de obtención del TGS con esta imagen:

Figura 3-2. Mecanismo de obtención TGS Kerberos. Fuente: web.mit.edu

4.2 Algunas definiciones

unidireccionales y bidireccionales. Pueden ser transitivas (A confía B, B confía en C, por lo tanto A

Figura 4-1. Esquema Directorio Activo

4.3 Cómo funciona

5.1 Switch 3Com

5.2 Switch Cisco

Figura 5-1. Esquema funcionamiento 802.1X

Figura 5-2. Esquema funcionamiento RADA

6.1.2 Conexiones desde los switches y otro equipamiento de red

6.1.3 Autenticación de red usando 802.1X

6.1.4 Conexiones desde equipamiento inalámbrico

Figura 6-1. Esquema funcionamiento WPA

6.2 Tipos de usuarios

6.2.2 Usuarios ocasionales

6.2.3 Usuarios de switches

6.3 Otros requisitos

7.1 Elementos de la solución

 Soporte para poder limitar el número de usuarios simultáneos.

7.2 Interoperabilidad de la solución

 Tiene múltiples funcionalidades

7.5.1.1 Fichero clients.conf

El formato para añadir un nuevo equipo es el siguiente:

7.5.1.2 Fichero users

7.5.1.3.2 Usuario con solo autenticacion

# -- text --

# Only one of ipaddr, ipv4addr, ipv6addr may be specified for