Configurar PAM para utilizar kerberos

En artículos anteriores se explicó cómo funciona kerberos y la forma de utilizarlo en GNU/Linux. Las workstations con Linux instalado pueden autenticar sus usuarios contra servidores de este tipo, ya sea que los mismos utilicen Linux, Windows (Active Directory), o cualquier otro SO que implemente el estándar. La configuración descripta a continuación es la misma sin importar sobre qué plataforma se implemente el servicio kerberos. Es decir, se puede utilizar, por ejemplo, para autenticar clientes Linux contra el servicio Active Directory de Windows.

Para la autenticación con kerberos, hay que instalar el módulo de PAM correspondiente, en todos los clientes. En debian, el paquete se denomina libpam-krb5:

# apt-get install krb5-{config,user} libpam-krb5

Durante la instalación, debconf requerirá algunos datos para continuar:

- el nombre del realm: DEMASIADOVIVO.ORG
- servidores kerberos para el realm, separados con espacios.
- servidor administrativo para el realm, para administrar cambio de contraseña.

Estos son los mismos datos que configuramos al instalar el servidor kerberos. Toda esta configuración se puede cambiar en el archivo /etc/krb5.conf.
En este archivo, como se explicó en la instalación del servidor, pueden eliminar todos los realms que aparecen en la instalación default (athena, mit, etc), y deberán agregar el dominio de su realm en la sección domain_realm:

[domain_realm]
.demasiadovivo.org = DEMASIADOVIVO.ORG
demasiadovivo.org = DEMASIADOVIVO.ORG

Luego de que se instala el módulo de kerberos, debian automáticamente establece en PAM que la autenticación de usuarios debe utilizar este protocolo. Si no están utilizando debian, tal vez requieran una configuración adicional para empezar a utilizarlo.

Veamos entonces cómo deberían quedar cada uno de los archivos de PAM, y el significado de cada configuración:

/etc/pam.d/common-account

account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so
account required pam_krb5.so minimum_uid=1000

Se puede observar que este archivo es muy similar a cuando se utiliza sólo autenticación Unix. Para agregar la autenticación de kerberos, se agrega una línea final que invoca el módulo pam_krb5 con el argumento minimum_uid=1000.
En este caso, el sistema invoca tanto el módulo pam_unix como pam_krb5 como required, lo cual implica que si alguno de estos falla, la operación falla. El argumento "minimum_uid=1000" hace que la autenticación kerberos se aplique a los usuarios cuyo user ID sea mayor a 1000. Esto permite tener cuentas locales como la de root (uid=0), la cual no autentica contra kerberos.

/etc/pam.d/common-auth

auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=1 default=ignore] pam_unix.so nullok_secure try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so

En este archivo podemos ver como funciona la autenticación propiamente dicha. Primero se intenta autenticar con kerberos a los usuarios cuyo uid es mayor o igual a 1000. Si esto tiene éxito, se salta a la línea pam_permit (success=2) y el usuario puede entrar. Si la autenticación kerberos falla, se intenta con la autenticación unix tradicional, permitiendo password en blanco (nullok_secure), y utilizando el mismo password que se utilizó en la autenticación kerberos (try_first_pass). Esto último se hace para que el sistema no requiera el password dos veces cuando la autenticación kerberos falla. Si ninguna de las autenticaciones es exitosa, se niega el acceso (pam_deny).

/etc/pam.d/common-pasword

password requisite pam_krb5.so minimum_uid=1000
password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512
password requisite pam_deny.so
password required pam_permit.so

Para el cambio de password se utiliza como requisito pam_krb5 con uid mayor igual a 1000. Si esto falla, el password no se actualiza. Si el password kerberos se actualiza correctamente, se intenta actualizar el password local, utilizando el mismo pass ingresado para kerberos (use_authtok). El resto de los argumentos de pam_unix son los mismos que cuando se utiliza autenticación tradicional, donde obscure checkea fortaleza del pass, y sha512 es el algoritmo para hashear el pass.
Algo a tener en cuenta aquí es que si la actualización del password local falla, la operación falla aunque el password kerberos no haya tenido problemas.

/etc/pam.d/common-session

session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_krb5.so minimum_uid=1000
session required pam_unix.so

Finalmente en el archivo de session encontramos una regla adicional y opcional que es la de kerberos. Algo interesante que podemos hacer en este archivo es agregar una regla para la creación del directorio home del usuario.
Si creamos un usuario en kerberos y no en la máquina cliente, cuando éste intente ingresar, el sistema arrojará error si el home no existe, porque este directorio no se crea al agregar el usuario.
Para esto, existe un módulo denominado pam_mkhomedir. Este módulo crea el directorio home del usuario cuando éste se loguea por primera vez. Si el directorio ya existe, no hace nada. Un argumento interesante para este módulo es skel, que permite especificar el esqueleto del directorio home.
Podemos modificar el archivo anterior para agregar esta funcionalidad, de la siguiente manera:

session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session required pam_mkhomedir.so skel=/etc/skel/
session optional pam_krb5.so minimum_uid=1000
session required pam_unix.so

Con esto, la próxima vez que se autentique un usuario en el cliente configurado, éste utilizará kerberos en lugar del tradicional sistema Unix. Claro que el usuario a utilizar debe estar previamente creado en el servidor kerberos.
Una vez autenticados, se puede ver el ticket generado ejecutando klist:

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_s6uumi
Default principal: demasiadovivo@DEMASIADOVIVO.ORG

Valid starting Expires Service principal
09/24/11 08:08:07 09/24/11 18:07:57 krbtgt/DEMASIADOVIVO.ORG@DEMASIADOVIVO.ORG
renew until 09/24/11 18:08:07