Ha pasado algo más de un año desde que me fui al cuadrante AWS e hice mi última publicación en este blog, y si algún visitante tiene ojo avizor, se habrá percatado de que aunque no aparecieran nuevas publicaciones, sí que iba actualizando el motor (Ghost y su theme, el genial Mapache). Todo ello con el objetivo de que llegado un día como el de hoy, volviese a publicar curiosidades tecnológicas.

Y dado que la publicación más vista de este blog es la de Uniendo GNU/Linux a nuestro Active Directory mediante Samba y SSSD me ha parecido muy conveniente volver a este tema con algo que me he encontrado recientemente.

Mis shares SMB en GNU/Linux dejan de funcionar con SSSD

Siempre velo por mantener al día las versiones de software y sistema operativo que se ejecutan en mi infraestructura doméstica. Un día tras una actualización rutinaria de GNU/Linux en una máquina unida a dominio mediante SSSD me encontré con que no podía acceder a las carpetas por SMB. Revisando el log de SAMBA, me encuentro algo parecido a lo siguiente:

check_winbind_security: winbindd not running - but required as domain member: NT_STATUS_NO_LOGON_SERVERS

El mensaje me extrañaba bastante porque hasta ahora no estaba necesitando ejecutar winbind en mis instalaciones. La respuesta al misterio mapeaba a una de las novedades de la versión 4.8.0 de Samba:

Setups with "security = domain" or "security = ads" require a running 'winbindd' now. The fallback that smbd directly contacts domain controllers is gone.

Bingo, tal y como explica en Reddit el usuario hortimech en este hilo, una instalación de SSSD y Samba no necesitaba utilizar winbindd porque smbd podía hablar directamente con Active Directory. Con la versión 4.8.0 esto deja de ser así y si bien SSSD sigue funcionando para autenticarnos en el sistema, perdemos la capacidad de integrar esta autenticación en carpetas compartidas mediante Samba. Este tema también se comenta en este hilo de la lista oficial de usuarios de SSSD.

La convivencia de SSSD y winbind plantea retos adicionales tales como que el mapeo de IDs entre Active Directory y POSIX coincida en ambos servicios. Si no necesitamos las capacidades adicionales de seguridad que SSSD provee en la autenticación, una forma simple de solucionar la situación es eliminar SSSD y volver a windbind.

IMPORTANTE: Si te vas a aventurar a sustituir SSSD por winbind ten en cuenta que las acciones para conseguirlo son potencialmente destructivas así que haz copia de seguridad o una snapshot de la máquina sobre la que vayas a proceder a hacer el cambio. Asegúrate siempre de poder volver a estado inicial si algo no sale bien.

Volviendo a windbind desde SSSD

La documentación de AWS Directory Service tiene una excelente guía para unir máquinas GNU/Linux a dominio de Active Directory mediante winbind. Como siempre, voy a suponer que estamos en una distro de GNU/Linux basada en Debian, aunque estos pasos se pueden seguir en casi cualquier otra salvando las distancias de los gestores de paquetes.

  1. Hacemos backup de toda nuestra configuración y/o un snapshot de la máquina sobre la que vamos a actuar.
  2. Eliminamos sssd y procedemos a instalar winbind:
$ sudo apt -y purge sssd
$ sudo apt -y install samba winbind libnss-winbind libpam-winbind
  1. Editamos el archivo /etc/krb5.conf y comprobamos que existe -al menos- la siguiente configuración
[libdefaults]
   default_realm = MIDOMINIO.COM
   dns_lookup_realm = false
   dns_lookup_kdc = true
  1. Editamos el archivo /etc/samba/smb.conf y establecemos la nueva configuración acorde a winbind, por ejemplo:
[global]
 workgroup = MIDOMINIO
 security = ads
 realm = MIDOMINIO.COM 
 vfs objects = acl_xattr
 map acl inherit = Yes
 store dos attributes = Yes
 dedicated keytab file = /etc/krb5.keytab
 kerberos method = secrets and keytab
 winbind use default domain = yes
 winbind enum users = yes
 winbind enum groups = yes
 winbind refresh tickets = Yes
 idmap config * : backend = autorid
 idmap config * : range = 10000-24999999
 template shell = /bin/bash
 template homedir = /home/%U
  1. Volvemos a ejecutar la operación de unir la máquina a dominio, especificando un usuario que tenga permisos para ello:
$ sudo net ads join -U usuariojoin@midominio.com
  1. Editamos el archivo /etc/nsswitch.conf y reemplazamos las ocurrencias donde tengamos sss por winbind, concretamente:
passwd: compat winbind
group:  compat winbind
shadow: compat winbind
  1. Finalmente, reiniciamos la suite de Samba:
$ sudo systemctl restart smbd nmbd winbind

Comprobando que todo ha ido bien

Para comprobar que todo ha ido bien sin necesidad de reiniciar la máquina o cerrar la sesión de usuario podemos probar la emisión de tickets de Kerberos.

$ kinit miusuario
Password for miusuario@MIDOMINIO.COM:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: miusuario@MIDOMINIO.COM

Valid starting       Expires              Service principal
01/30/2022 19:49:30  01/31/2022 05:49:30  krbtgt/MIDOMINIO.COM@MIDOMINIO.COM
        renew until 01/31/2022 19:49:25

Si ha ido bien podemos proceder a comprobar si ahora tenemos acceso SMB a la máquina utilizando las credenciales de Active Directory.

Conclusiones

Si tienes una máquina GNU/Linux unida a dominio de Active Directory mediante sssd y la versión de Samba instalada es igual o superior a la 4.8.0, podrás observar que no puedes acceder a las carpetas compartidas por SMB con tus credenciales de dominio. Samba obliga ahora a que winbind esté presente. Este problema se puede solucionar fácilmente sustituyendo sssd por winbind siempre que las características de este último sean suficientes para cubrir nuestros requisitos.

Si estás en el contexto de una máquina GNU/Linux unida a dominio que no comparte archivos por SMB, ¡no necesitas hacer nada!

Happy winbinding!