General

Caché de credenciales de autenticación y servicio de nombres

Hoy en día una gran cantidad de redes basadas en Linux utilizan exclusivamente un servidor OpenLDAP para la autenticación de usuarios en distintos recursos (inicio de sesión, correo, aplicaciones Web y un largo etcétera) — otro porcentaje importante de estas redes basan sus credenciales en un servidor Samba para mantener la compatiblidad con clientes Windows que aun puedan estar en la red. Finalmente, cuando Linux es la oveja negra de una red, suele utilizarse Kerberos para autenticar equipos contra un servidor Active Directory.En cualquiera de estos casos se condiciona la autenticación a servicios basados en la red, por lo que se suele depender del medio para garantizar que los procesos de autenticación sean eficientes. La pesadilla de muchos administradores de sistemas que basan sus esquemas de autenticación en la mayoría de los tutoriales en castellano que hay por ahí es que cuando la red falla, los usuarios quedan bloqueados: no pueden iniciar sesión, algunas aplicaciones fallan y en general la experiencia del usuario standalone es terrible.Una parte de la solución es tener una red sana y redundancia en los servicios. No obstante, no todo el mundo puede garantizarse redundancia, y no siempre puedes sanear una red a nivel nacional, por ejemplo. Y en todo caso, hay usuarios rogue que están trabajando parte de su tiempo en la red de la organización y otra parte de su tiempo en sus casas o remotamente en equipos portátiles. En estos casos es necesario garantizar que el usuario puede seguir trabajando de forma uniforme.Una de las formas más sencillas y estables que he conseguido de mantener este comportamiento es a través de un caché de nombres y credenciales utilizando libpam-ccreds y nss-updatedb con libnss-db. El primero se encarga de almacenar temporalmente las credenciales utilizadas al momento de iniciar sesión (p.ej., la contraseña) siempre y cuando estas credenciales se provean por el sistema de módulos apilables de autenticación PAM y el segundo se encarga de mantener una base de datos local del servicio de nombres NSS.Instalación y configuraciónEn Debian y Ubuntu basta con hacer uno de nuestros queridos:

aptitude update && aptitude install libpam-ccreds nss-updatedb libnss-db

Tanto PAM como NSS ofrecen mecanismos de fallback en caso de que algún servicio no esté disponible o no reporte resultados para una solicitud de resolución de nombres o de autenticación. Haremos uso de esos mecanismos para establecer un comportamiento sistemático que nos permita hacer efectivamente un caché de autenticación para nuestros sistemas Linux.En primer lugar, suponiendo que las búsquedas de nombres se hagan en OpenLDAP, debemos tener un archivo /etc/libnss-ldap.conf correctamente configurado (si te interesa esto, probablemente ya tengas uno funcionando) y un correcto orden de búsqueda en /etc/nsswitch.conf, algo como passwd: files ldap. Queremos que las resoluciones de nombres se procesen primero por la base de datos local, por lo que cambiamos las entradas a algo como passwd: files db [NOTFOUND=continue] ldap — buscamos en la base de datos local, y si no lo conseguimos, buscamos en el LDAP. Esto trae dos ventajas: en primer lugar, si un usuario inicia sesión correctamente estando en la red, se habrán almacenado sus datos correctamente; en segundo lugar, si el LDAP no está disponible o está respondiendo muy lentamente, es posible ahorrar tiempo buscando en la base de datos local.nss-updatedb es la aplicación que descargará la información de nombres (y no de las credenciales, NSS no se encarga de eso) en una base de datos local, que NSS consultará según la línea que antes explicamos. Es importante resaltar que nss-updatedb solo permite cachear las bases de datos passwd y group — no tendría sentido cachear las demás, y para eso hay otras aplicaciones. Para hacer un snapshot de la información de nombres de usuarios y grupos basta con:

nss_updatedb ldap passwd && nss_updatedb ldap group

Por otro lado, pam_ccreds es el módulo de PAM que nos permitirá almacenar la información de autenticación. El módulo solo provee símbolos para auth, por lo que, en Debian y Ubuntu, solo basta con editar /etc/pam.d/common-auth para agregar el módulo en nuestros procesos de autenticación. En este punto le pido al lector que haga uso de la lógica y de su conocimiento sobre PAM para hacer el archivo de configuración apropiado a su esquema de autenticación. La lógica del que voy a publicar es la siguiente: verificas si el usuario existe localmente (puedes dejar un usuario local para salvar el sistema si fallan todos los demás mecanismos de autenticación), luego lo buscas en el LDAP, y si el servicio no está disponible, busca las credenciales en el caché. Si las credenciales se encuentran, todo bien. Si no, almacena y actualiza tu caché y otorga acceso al usuario.

auth    [success=done default=ignore]   pam_unix.so nullok_secure try_first_pass  auth    [authinfo_unavail=ignore success=1 default=2] pam_ldap.so use_first_pass  auth    [default=done]  pam_ccreds.so action=validate use_first_pass  auth    [default=done]  pam_ccreds.so action=store  auth    [default=bad]   pam_ccreds.so action=update

Es necesario, por supuesto, que /etc/pam_ldap.conf esté correctamente configurado. En muchos casos, los administradores de sistemas lo dejan igual que libnss-ldap.conf atendiendo al hecho de que PADL se ha esforzado en hacer estándar el formato de configuración.Así mismo es importante resaltar que pam_ccreds no ofrece información de autorización, por lo que no puede utilizarse para volver a identificarse dentro de una sesión. Por lo que (sí, adivinó) es necesaria una trampa para que este mecanismo conviva con los protectores de pantalla, al menos con gnome-screensaver y xscreensaver — hay más información sobre esto en el código fuente del programa, y la trampa que yo utilizo es colocar auth require pam_permit.so al final del common_auth, de forma tal que, cuando el LDAP no esté disponible, el usuario siempre podrá desbloquear el protector de pantalla.Importante: esta última recomendación deja un agujero de seguridad obvio en equipos portátiles que, aunque no están en la red de su organización, podrían ser desbloqueados por un usuario malicioso (p.ej., un usuario desconecta un laptop bloqueado en la red, se autentica con cualquier clave, y luego la conecta de nuevo — piece of cake) Mi recomendación es que utilice otro factor de autenticación; yo recomiendo pam_rsa, pam_usb o pam_blue para autenticarse con llaves públicas RSA en un dispositivo removible, con el USB ID de un dispositivo USB o con un dispositivo Bluetooth en la vecindad de su equipo personal.Por supuesto, también debe haber al menos un login exitoso en la red con este mecanismo para que se almacenen las credenciales, y es conveniente que nss-updatedb se ejecute regularmente. Ya que podría ser contraproducente que nss-updatedb se ejecutara cuando el servidor OpenLDAP no está disponible, mi recomendación es hacer un script del estilo:

#!/bin/bashSERVIDOR=`grep host /etc/libnss-ldap.conf | cut -f2 -d' '`ping -c 1 $SERVIDORif [ "$?" -eq "0" ]then   nss_updatedb ldap passwd && nss_updatedb ldap groupfi

Este método es bastante útil para acelerar los procesos de autenticación cuando se usan módulos de PAM basados en la red, y además garantiza que los usuarios móviles (p.ej., laptops) puedan continuar autenticándose incluso fuera de la red de la organización. Muchos de los paráme
tros que expongo en estos ejemplos pueden (y en ocasiones deben) ser modificados y adaptados a las necesidades de cada red. Para ello, lo mejor es consultar el HOWTO de pam_ccreds en el Wiki de Ubuntu, y el sitio del proveedor sobre nss_updatedb y pam_ccreds. Por supuesto, si va a incursionar con otros módulos de PAM para establecer autenticación con dos o más factores, lo mejor es el sitio de Linux-PAM. (Update — hay un artículo bastante bueno en Debian Administration titulado Implementing cost effective dual factor authentication.)

Standard

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s