Kerberos es un protocolo de autenticación utilizado en redes no seguras para permitir autenticación recíproca entre un cliente y un servidor y se utiliza principalmente para centralizar la autenticación de usuarios y equipos en una red.
Kerberos proporciona lo que se denomina SSO (Single Sign-On), de manera que un usuario sólo tiene que autenticarse una vez en cada sesión, sirviendo esta autenticación para todos los servicios y equipos de la organización.
Existen diferentes implementaciones de kerberos, tres en el caso de Debian: MIT, heimdal y shishi (no, no voy a hacer ningún chiste fácil sobre esta última ;) ). En esta entrada presentamos la implantación de un servidor MIT kerberos 5 (master) en un equipo con Debian GNU/Linux (lenny) y el proceso de autenticación elemental desde un equipo cliente.
Definiciones previas
Kerberos utiliza su propia terminología que es necesario conocer previamente.
- Realm (reino): Define el dominio de autenticación del que se hará cargo el servidor kerberos. Para un realm se suele utilizar el dominio DNS de la organización y se suele poner en mayúsculas.
- Principal: Es una entrada en la base de datos kerberos que puede incluir definciones de usuarios, equipos o servicios entre otros: usuario@DOMINIO.BIZ para un usuario o imap/correo.dominio.biz@DOMINIO.BIZ para definir el servidor imap de la organización.
- Ticket: Se utilizan como identificadores de los principales y los facilita el servidor kerberos de la organización (autentication server de forma más precisa), los tickets se solicitan al iniciar la sesión y tienen un determinado tiempo de caducidad (normalmente 10 horas)
- Key Distribution Center (KDC): Servidor kerberos encargado de la autenticación
- kadmin-server: Servidor maestro de kerberos, que se utiliza para modificar los principales.
Una descripción más detallada de todos los componentes está en http://kerberos.org/software/tutorial.html.
Recomendaciones
Aunque no es imprescindible, es recomendable utilizar kerberos en un entorno con un servidor DNS correctamente configurado (aunque para pruebas se puede suplir esto por resolución estática a través de definiciones en el fichero /etc/hosts) y un servidor de hora, ya que kerberos es muy exigente con respecto a la sincronización de los relojes de los equipos implicados.
En nuestro caso vamos a utilizar un equipo que va a funcionar como servidor DNS, NTP y kerberos de una organización con dominio DNS «dominio.biz», que se denomina chucky.dominio.biz, pero con una entrada tipo CNAME (un alias) apuntando a kerberos.dominio.biz.
Instalación de paquetes en el servidor kerberos5
Instalamos el kdc y kadmin:
aptitude install krb5-kdc krb5-admin-server
que instala por dependencias los paquetes krb5-config y krb5-user
Dependiendo de la configuración de debconf, habrá que contestar a varias cuestiones, en mi caso tuve que poner el nombre del servidor kerberos y el servidor administrativo (kerberos.dominio.biz en ambos casos).
Tras la instalación de estos paquetes obtenemos el siguiente mensaje:
krb5kdc: cannot initialize realm DOMINIO.BIZ - see log file for details
Ya que no hay todavía un realm definido.
Vamos a comprobar los parámetros que hay en los diferentes ficheros de configuración y a realizar unas pequeñas modificaciones.
/etc/krb5kdc/kdc.conf
Este fichero incluye los parámetros de configuración del kdc y su contenido inicial es:
[kdcdefaults]
kdc_ports = 750,88
[realms]
DOMINIO.BIZ = {
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 arcfour-hmac:normal .....
default_principal_flags = +preauth
}
La única modificación que haremos será quitar el puerto 750 y dejar sólo el 88 en el parámetrokdc_ports, ya que el puerto 750/udp se utiliza sólo en kerberos4.
/etc/default/krb5-kdc
Ponemos los siguientes valores para no utilizar kerberos4:
KRB4_MODE=disable RUN_KRB524D=false
/etc/krb5.conf
Este fichero realmente se utiliza para configurar el equipo como cliente kerberos y simplemente hay que especificar el nombre de realm y del equipo que es el servidor. Hay que verificar que tenemos las siguientes líneas en los diferentes apartados:
[libdefaults]
default_realm = DOMINIO.BIZ
...
[realms]
DOMINIO.BIZ = {
kdc = kerberos.dominio.biz
admin_server = kerberos.dominio.biz
}
...
[domain_realm]
.dominio.biz = DOMINIO.BIZ
dominio.biz = DOMINIO.BIZ
Puesta en marcha de los servicios
Para definir el realm de nuestro servidor kerberos, ejecutaremos la siguiente instrucción que se incluye en Debian:
krb5_newrealm
que nos pedirá definir la clave maestra de la base de datos del KDC.
Ahora ya podemos iniciar los dos demonios:
/etc/init.d/krb5-admin-server start /etc/init.d/krb5-kdc start
Podemos comprobar ahora los puertos en los que están escuchando ambos servicios, haciendo:
netstat -putan |grep "krb5kdc\|kadmind" tcp 0 0 0.0.0.0:749 0.0.0.0:* LISTEN 11954/kadmind udp 0 0 0.0.0.0:464 0.0.0.0:* 11954/kadmind udp 0 0 10.0.0.1:88 0.0.0.0:* 12137/krb5kdc
kdc escucha en el puerto 88/udp, mientras que kadmind escucha en los puertos 749/tcp para utilizar la aplicación kadmin y 464/udp para kpasswd.
kadmin.local
Inicialmente kerberos incluye sólo unos pocos principales, por lo que no se puede acceder con ningún usuario utilizando kadmind, para eso existe kadmin.local, que permite administrar kerberos desde el propio servidor sin necesidad de contraseña y sin establecer una comunicación TCP/IP por el puerto 749/tcp. Al ejecutar esta apliación:
kadmin.local Authenticating as principal root/admin@DOMINIO.BIZ with password. kadmin.local: (pulsamos doble tabulador para ver todas las opciones) ? change_password exit getpol ktrem listprincs modprinc add_policy cpw get_policies getpols ktremove lock q add_principal delete_policy get_policy getprinc list_policies lr quit addpol delete_principal get_principal getprincs list_principals modify_policy unlock addprinc delpol get_principals getprivs list_requests modify_principal xst ank delprinc get_privs ktadd listpols modpol
por lo que podemos ver que podemos crear o modificar principales, políticas y demás.
Con la instrucción list_principals podemos ver los principales definidos en una configuración inicial:
kadmin.local: list_principals K/M@DOMINIO.BIZ kadmin/admin@DOMINIO.BIZ kadmin/changepw@DOMINIO.BIZ kadmin/kerberos.dominio.biz@DOMINIO.BIZ kadmin/history@DOMINIO.BIZ krbtgt/DOMINIO.BIZ@DOMINIO.BIZ
Creamos nuestro primer usuario autenticado en kerberos dentro de la instancia /admin:
kadmin.local: add_principal alberto/admin@DOMINIO.BIZ
Ahora hay que editar el fichero /etc/krb5kdc/kadm5.acl y dar a este usuario (o a todos los de la instancia /admin) todos los permisos sobre el realm DOMINIO.BIZ (o sobre todos los realms del servidor), de forma simple añadiríamos la siguiente línea:
*/admin *
O bien, sólo para el usuario alberto/admin en DOMINIO.BIZ:
alberto/admin@DOMINIO.BIZ *
Una vez creado este usuario es posible acceder a la consola de administración de kerberos (denominada kadmin (sin .local)) desde cualquier equipo en el que tengamos instalado el paquete krb5-user. La aplicación kadmin y kadmin.local son totalmente equivalentes, aunque para utilizar la primera es necesario que exista un usuario dado de alta y el demonio kadmind funcionando.
Configuración de un equipo cliente
En todos los equipos de la organización hay que instalar los paquetes krb5-user y krb5-config. La única configuración necesaria es la del fichero /etc/krb5.conf, que debe ser idéntico al del servidor kerberos presentado anteriormente.
klist
klist nos muestra los tickets de la sesión del usuario, si lo ejecutamos sin habernos autenticado, obtenemos la siguiente salida:
klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000) Kerberos 4 ticket cache: /tmp/tkt1000 klist: You have no tickets cached
kinit
kinit se utiliza para autenticarse de forma manual contra un servidor kerberos definido en /etc/krb5.conf, por ejemplo:
kinit alberto/admin Password for alberto/admin@DOMINIO.BIZ:
Si ahora volvemos a utilizar la instrucción klist, obtenemos:
klist -5 Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: alberto/admin@DOMINIO.BIZ Valid starting Expires Service principal 06/11/09 18:30:00 06/12/09 04:30:00 krbtgt/DOMINIO.BIZ@DOMINIO.BIZ renew until 06/12/09 18:30:37
kdestroy
Se utiliza para eliminar los tickets
kpasswd
Se utiliza para cambiar la contraseña de un usuario en la base de datos de kerberos.
Por hacer
En esta entrada se describe sólo la instalación y configuración de un servidor maestro kerberos y la autenticación «manual» de un usuario desde un equipo cualquiera, pero una configuración como la anterior es poco útil todavía porque necesita muchos complementos como PAM, LDAP, SASL (GSSAPI), configuración de todos los servicios de la organización (ssh, ftp, etc.), entradas DNS tipo SRV, ficheros keytab, servidores kerberos esclavos, etc. Eso quedará para posteriores entradas :-)
Desde lo alto del Cerro 
Al poner utentificacion por kerberos en una pc, al iniciar el gdm el nombre de usuario/contraseña es la de la pc server.Cada vez que cree un user me podre loquear con este en el cliente.Y disculpen la ignorancia.
Me gustaMe gusta
El objetivo es ése, aunque para poder realizarlo no basta con utilizar sólo kerberos. El proceso de login necesita que además de autenticar al usuario (proceso que se encarga kerberos) se nos dé información adicional como UID, GID, etc. y esto suele hacerse con LDAP. La explicación completa es bastante extensa y es mi intención hacerlo en una nueva entrada de este blog.
Me gustaMe gusta
lo que pasa es que me encomendaron la tarea de montar computadores sin disco duro (diskless) lo cual ya realice inician co ubuntu 9.04.Pero para crear un usuario se me hace necesario iniciar un diskless y crearlo,algo muy tedioso, así que me hablaron de kerberos y llevo 2 semanas navegando y no encuentro nada que me sirva.Gracias por tu respuesta.
Me gustaMe gusta