Heredé varios servidores RHEL5 que se configuraron para autenticar usuarios en sus cuentas AD a través de winbind. Todo funciona bien hasta que actualice la membresía del grupo en AD. Para algunos usuarios, los cambios nunca llegan a la salida del comando "grupos", aunque se reflejan en la salida de "getent group <groupname>".
Por ejemplo, considere lo siguiente:
[root@hcc1pl1 ~]# grupos plubans
plubans: dominio usuarios sistemas infraestructura desarrollo
[root@hcc1pl1 ~]# getent grupo q1esb
q1esb:*:23136:q1qai,q1prodi
Si me agrego a q1esb en el DC que usa winbind, puedes ver que la membresía está actualizada:
[root@hcc1pl1 ~]# lsof -i | grep winbind
winbindd 31339 root 17u IPv4 63817934 TCP hcc1pl1:56541->hcnas01:microsoft-ds (ESTABLECIDO)
winbindd 31339 root 21u IPv4 63817970 TCP hcc1pl1:53622->hcnas01:ldap (ESTABLECIDO)
[root@hcc] 1pl1 ~]# ldapsearch -u -x -LLL -h hcnas01 -D "[correo electrónico protegido]" -W -b "CN=Peter Lubans,OU=Cuentas de usuario estándar,OU=Usuarios,OU=XXX,DC=XXX,DC=XXX" "(sAMAccountName=*)" memberOf
Introduzca la contraseña LDAP:
...
memberOf: CN=q1esb,OU=Grupos de seguridad,OU=Grupos,OU=XXX,DC=XXX,DC=XXX
...
Tenga en cuenta que winbind se ejecuta sin almacenamiento en caché (indicador -n):
[root@hcc1pl1 ~]# ps -ef | grep winbind
raíz 31339 1 0 13:50? 00:00:00 winbindd -n
raíz 31340 31339 0 13:50? 00:00:00 winbindd -n
raíz 31351 31339 0 13:50? 00:00:00 winbindd -n
raíz 31352 31339 0 13:50? 00:00:00 winbindd -n
raíz 31353 31339 0 13:50? 00:00:00 winbindd-n
Ahora getent muestra que ese grupo tiene los miembros correctos:
[root@hcc1pl1 ~]# grupo getent q1esb
q1esb:*:23136:q1qai,plubans,q1prodi
Pero la membresía actualizada no se refleja en los detalles de mi cuenta:
[root@hcc1pl1 ~]# grupos plubans
plubans: desarrollo de infraestructura de sistemas de usuarios de dominio
[root@hcc1pl1 ~]#
La parte realmente molesta de este problema es que funciona bien para otras cuentas en esta máquina y para mi cuenta en máquinas que he configurado desde cero.
¿Algunas ideas?
Respuesta1
Parece que esto se debió a que la información del grupo se almacenó en caché al momento de iniciar sesión en /var/cache/samba/netsamlogon_cache.tdb. Supongo que aunque '-n' indicó a winbind que no almacenara en caché sus consultas contra LDAP, la presencia de la información de membresía en ese archivo TDB fue suficiente para estropear las cosas.
Respuesta2
Logré encontrar el artículo perdido de Marcin (https://marcinm.co.uk/group-membership-not-updating-in-winbind/) preguntándole por correo electrónico. Como estoy seguro de que esto ayudará al menos a algunas personas, aquí está la publicación completa de su blog:
Guión
El servidor de archivos que ejecuta smbd security=ads(es decir, actúa como miembro del dominio), el usuario se conecta al recurso compartido Samba y captura correctamente la membresía del grupo cuando se conecta por primera vez, y nunca se actualiza después de eso.
Causa principal
Samba actualiza la membresía del grupo cuando la calcula el controlador de dominio AD y se calcula solo cuando el usuario inicia sesión en un servidor que ejecuta smbd y winbind. Que se activa wbinfo -aúnicamente mediante el inicio de sesión SMB o kerberizado. Como se trata de una limitación grave, lo que significa que no se conocería ninguna pertenencia a un grupo en las máquinas en las que el usuario nunca inicia sesión, se desarrolló un código de pertenencia a un grupo alternativo que extrae la pertenencia a un grupo del usuario de AD sin que el usuario inicie sesión, sino como una cuenta de máquina utilizada por winbind. no tiene los derechos para solicitar membresía en un grupo de usuarios, se considera inestable y sus resultados no son confiables. Por lo tanto, winbind nunca depende de él: lo llamará cuando no se conozca ninguna pertenencia al grupo, pero nunca se utilizará para actualizar las membresías del grupo almacenadas en caché. Como resultado de eso, en algunos escenarios, winbind captura las membresías de grupos de usuarios una vez y nunca las actualiza después de eso.
No es posible desactivar el almacenamiento en caché de la pertenencia a un grupo, es decir, no hay forma de desactivar dicho comportamiento poniendo una línea en smb.conf. Tenga en cuenta que esto no es un problema de Samba sino un problema de diseño de AD; dicho comportamiento es consistente con la forma en que se comporta Windows, que efectivamente es que la membresía del grupo AD se actualiza cuando un usuario se autentica durante el inicio de sesión.
Cómo forzar la actualización de la membresía del grupo para un usuario
La membresía del grupo se almacena en caché en un archivo llamado netsamlogon_cache.tdbque puede ser investigado por tdbtool (todas las versiones de Samba) o net cache samlogon(Samba 4.7 o posterior). La eliminación de entradas almacenadas en caché de ese archivo activa una actualización única de las membresías del grupo llamando al código de actualización alternativa y volviendo a colocar su resultado netsamlogon_cache.tdb, y luego se almacenan en caché para siempre nuevamente.
forma tdbtool:
$ wbinfo -n user.name
S-1-5-21-3023451936-689652692-1079546996-40725 SID_USER (1)
agregue \0al SID y póngalo entre comillas:
$ tdbtool netsamlogon_cache.tdb delete "S-1-5-21-3023451936-689652692-1079546996-40725\0"
La membresía del grupo se actualizará la primera vez que el sistema operativo la necesite, espere unos minutos hasta que se complete el archivo tdb.
forma de Samlogon de caché de red:
$ net cache samlogon list|head
SID Name When cached
---------------------------------------------------------------------------------------------------------------------------
S-1-5-21-3023451936-689652692-1079546996-40725 DOM\user.name Tue Apr 27 07:59:19 AM 2018 BST
S-1-5-21-3023451936-689652692-1079546996-41432 DOM\user.name2 Tue Apr 27 02:13:33 PM 2018 BST
$ net cache samlogon delete S-1-5-21-3023451936-689652692-1079546996-40725
Igual que antes: la membresía del grupo se actualizará la primera vez que el sistema operativo la necesite, espere unos minutos hasta que se complete el archivo tdb.
Respuesta3
Mi único pensamiento, y es muy vago, es que podría tener algo que ver con la comunicación con su Maestro de Infraestructura (que es responsable de actualizar las membresías de grupos en todos los dominios).
Respuesta4
Yo tenia algo parecido. Para solucionar el problema ejecuté "authconfig --disablecache --update". Por supuesto, hizo que los inicios de sesión fueran lentos.