☰

La búsqueda del grupo Winbind es tremendamente lenta

tag-icon • tag-icon linux samba active-directory redhat-enterprise-linux
La búsqueda del grupo Winbind es tremendamente lenta

Estoy ejecutando winbind en un sistema RHEL 6. Todo funciona bien excepto las búsquedas grupales, por lo que muchos comandos (incluido sudo) son tremendamente lentos. Hice un análisis straceque muestra que winbind busca en cada grupo y en cada usuario dentro de cada grupo el usuario actual. Algunos de estos grupos tienen más de 20.000 usuarios, por lo que un simple sudopuede tardar 60 segundos en completarse.

Realmente sólo me importa acelerar el comando sudo. Las soluciones ideales harían que así fuera:

  1. los grupos con más de X número de usuarios no serán buscados, o
  2. sudo omite por completo las búsquedas de grupos.

Aquí está mi "smb.conf" actual paraenlace ganador:

workgroup = EXAMPLE
password server = AD1.EXAMPLE.ORG
realm = EXAMPLE.ORG
security = ads
idmap uid = 10000-19999
idmap gid = 10000-19999
idmap config EXAMPLE:backend = rid
idmap config EXAMPLE:range = 10000000-19999999
winbind enum users = no
winbind enum groups = no
winbind separator = +
template homedir = /home/%U
template shell = /bin/bash
winbind use default domain = yes
winbind offline logon = false

Respuesta1

Tuve el mismo problema después de actualizar Sudo y descubrí por Red Hat que sudo cambió su algoritmo de resolución de membresía de grupo al pasar de Sudo-1.7.4p5-13.el6_3.x86_64 a Sudo-1.8.6p3-7.el6.x86_64. En sudo-1.7.4, la pertenencia al grupo se resolvió para todos los grupos enumerados en /etc/sudoers y, si el nombre de usuario se encontraba en la lista, se le otorgaban privilegios de sudo. En sudo-1.8.6, esto se cambió para que fuera al revés: sudo obtuvo una lista de grupos de los que el usuario es miembro y luego verificó si alguno de esos grupos figuraba en sudoers.

Esto da como resultado getgrgid() para cada grupo del que el usuario es miembro, por lo que si algunos grupos son grandes, esto será bastante lento. Puede degradar sudo o colocar los grupos grandes como grupos vacíos en su archivo /etc/group local para que no se contacte a AD por ellos (suponiendo que el sistema Linux no haga referencia a los grupos grandes para ningún control de acceso).

Respuesta2

El método antiguo (es decir, 1.7.x) se puede revertir mediante complementos de grupo:

Defaults group_plugin="system_group.so"

Alternativamente, simplemente fuerce el uso /etc/groupúnicamente (sin búsquedas de winbind, etc.):

Defaults group_plugin="group_file.so /etc/group"

Respuesta3

deshabilitar grupos anidados winbind nested groups = false

Respuesta4

o simplemente agregue "winbind expand groups = 0" a su archivo /etc/samba/smb.cnf (luego cambie a la cuenta raíz local y "/etc/init.d/winbind stop; /etc/init.d/samba restart; /etc/init.d/winbind inicio")

El primer sudo después de reiniciar puede tardar un momento (pero no será melaza como lo que está experimentando) y, con seguridad, el siguiente será el esperado (rápido); para cualquier otra persona, puede usar una cuenta de administrador local para los comandos sudo (ya que está obligado a crear una cuenta local, ¿no?)

información relacionada