Posts etiquetados ‘integracion’

To integrate a Linux system with a centralized user directory (like Microsoft Active Directory) the usual solution is to configure Kerberos for Authentication (password/credential checking) and LDAP for Authorization and Access Control. The “standarized” way to implement this is using libpam_krb5libnss_ldap (by padl software) and nscd (from libc).

Kerberos integration works pretty well and I do not have too many issues with it, but I can not say the same from libnss_ldap and nscd.

In this post I will explain the anoying problems that you can find using libnss_ldap and nscd, and propose some solutions and configurations that will make it work properly. I also recomend read a previous post about the problems and solutions with connecting an Unix server to Active directory (Spanish post).

Read this article if you are experiencing problems with nscd+libnss_ldap (quoting

  • Sometimes it consumes 100% cpu (and does not stop that until being killed)
  • Sometimes it just crashes.
  • Sometimes it causes users to “vanish”
  • Sometimes it hangs and thus slows down the whole system
  • Sometimes it makes all the host work slow
  • Sometimes login a host or execute sudo/su takes a lot of time or never logins.
  • Sometimes sudo or su dies with “Segmentation Fault”
  • Sometimes a simple ‘ls’ command takes minutes.
  • etc…


You want to have a user defined locally but delegate the authentication to a Kerberos server (like active directory). That is ok, specially since secldapclntd is not the most reliable component on aix.

But be careful, if you define a user in the compat registry instead of KRB5files (but with SYSTEM=KRB5files), like in this command:

mkuser -R KRB5files SYSTEM=KRB5files <user>

you will find that the local password policies will be applied to the user. This is a incorrect behaviour, because AIX does not manage the password.

For instance, despite having SYSTEM=KRB5files, the new user will have the ADMCHG attribute defined in its stanza in /etc/security/passwd

        password = *
        lastupdate = 1275046476
        flags = ADMCHG

From man pwdadm:

   Resets the ADMCHG attribute without changing the user's password. This forces the user to change passwords
   the next time a login command or an su command is given for the user. The attribute is cleared when the
   user specified by the User parameter resets the password.

With this attribute set and SYSTEM=KRB5files, we will get this error if we try to login (for instance, via SSH):

May 31 10:10:38 aixhost01 auth|security:info sshd[585730]: Password can't be changed for user jhon: [compat]: 3004-333 A password change is required. 3004-320 Only the system administrator can change
May 31 10:10:38 aixhost01 auth|security:info sshd[585730]: Failed password for jhon from port 62018 ssh2
May 31 10:10:38 aixhost01 auth|security:info syslog: ssh: failed login attempt for jhon from acomputer.localdomain

To avoid this, you can reset the password, or execute pwdadm -c jhon, but the best solution is simply change the registry:

chuser registry=KRB5files jhon


chuser expires=0 maxage=0 maxexpired=-1 minage=0 loginretries=-1 registry=KRB5files $USER
pwdadm -c $USER

Other tipical errors of this:

Sep 15 09:56:56 tcmurexappl1 auth|security:info sshd[344552]: Password can’t be changed for user jhon: [compat]: 3004-330 Yourencrypted password is invalid. \r3004-320 Only the system administrator can c
Sep 15 09:56:14 tcmurexappl1 auth|security:info sshd[213376]: Failed password for jhon from 168.1.1.x port 1632 ssh2
Sep 15 09:56:14 tcmurexappl1 auth|security:info syslog: ssh: failed login attempt for jhon from
Sep 15 09:56:18 tcmurexappl1 auth|security:debug sshd[213376]: [krb_authenticate] Error in getting TGT …
Sep 15 09:56:18 tcmurexappl1 auth|security:debug sshd[213376]: Preauthentication failed

To solve it:

chuser expires=0 maxage=0 maxexpired=-1 minage=0 loginretries=-1 registry=KRB5files $USER
pwdadm -c $USER

AIX LDAP integration is not up to expectations. Its cache daemon, secldapclntd,
has a lot of problems:it often crashes, queries are slow, etc…

To mitigate problems, one workaround could be create the most important users locally,
using the KRB5files repository.

With this idea, this script will query a set of given groups from the AIX LDAP
registry using the AIX command line tools (lsuser, lsgroup), and it will create
them locally (mkgroup, mkuser).

To make it work, the host must be integrated with remote repository and must be able to resolve users and groups with LDAP method. You need LDAP method and KRB5files method configured. It can be easily changed to use other methods.

This script also supports nested groups from Active Directory.

The AIX service secldapclntd “Provides and manages connection between the AIX LDAP load module of the local host and LDAP Security Information Server, and handles transactions from the LDAP load module to the LDAP Security Information Server.”

This services fails too often. Each new version of AIX, brings new failures in this services. Failures appear more often if the LDAP server has a lot of users and groups.

When it fails:

  • sometimes does not reply, its hung
  • sometimes it consumes all CPU and lasts a lot to reply
  • sometimes it simply dies with a core.

This script will check and monitor it and restart it if necesary.

You can test this script stoping the service:

kill -STOP $(ps -fea| grep -v grep |grep /usr/sbin/secldapclntd| awk '{print $2}' )

You can add an entry to cron to execute it:

if crontab -l | grep /usr/local/bin/; then
   echo "Already configured."
  crontab -l > /tmp/$$.crontab
  cat >> /tmp/$$.crontab <<EOF
# Check secldapclntd each 5 minutes
5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/bin/ check-and-restart > /dev/null
  crontab /tmp/$$.crontab
  rm /tmp/$$.crontab

And here goes the script (/usr/local/bin/

Voy a hablar de las conclusiones empíricas a las que hemos llegado implementando la integración de Unix (En nuestro caso AIX y Linux) con el Directorio Activo. Se han descubierto varios problemas, limitaciones, soluciones alternativas y recomendaciones que intentaré resumir ahora.

Para integrar el Directorio Activo con los sistemas Unix lo mejor es emplear LDAP (consulta de usuarios, grupos y sus atributos y relaciones) y Kerberos para autenticar.  Para soportar atributos Unix, se extendió el esquema del DA con las extensiones SFU 3.5 (Services For Unix). Esto agrega nuevos atributos, entre los que destacan:

  • msSFU30Name             Nombre del usuario en Unix. Puede ser substituido por ‘cn’ (ver abajo)
  • msSFU30UidNumber        Identificador UNIX del usuario
  • msSFU30GidNumber        Identificador UNIX del grupo. Dentro de un usuario significa el grupo por defecto.
  • msSFU30HomeDirectory         Directorio $HOME del usuario.
  • msSFU30LoginShell Interprete de comandos por defecto del usuario.
  • msSFU30PosixMember     Referencia a miembros de un grupo (DN del LDAP). Puede ser substituido por ‘member’ (ver abajo)
  • msSFU30MemberUid        Referencia a miembros de un grupo (Mediante UID del usuario). Prácticamente no se usa.

Para cambiar los atributos Unix en el Directorio Activo, debe instalarse una .dll en el sistema del operador para agregar estas nuevas pestañas al diálogo de propiedades de usuarios y grupos.

Veamos los problemas y limitaciones detectados y posibles soluciones:

  • Problema: Cuando se cambia el nombre de usuario, el atributo Unix ‘msSFU30Name’ no cambia. Esto es bueno y malo, porque por un lado puede implicar incongruencias , pero por otro nos permite tener un nombre en Windows y otro en Unix más ‘unix-friendly’.Editarlo es un incordio, debe hacerse a mano con el ‘adsiedit’.

    Solución: Usar el atributo ‘cn’ e vez de ‘msSFU30Name’

  • Problema: Los grupos del mundo Unix se gestionan separados de los del mundo Windows. La ventana de gestión de grupos Unix es tediosa e incómoda (te lista todos los usuarios por UID). No se pueden agregar grupos anidados.Solución: Usar el atributo ‘member’ en vez de ‘msSFU30PosixMember’. Se corresponde con los grupos Windows. Permite grupos anidados, que se aprovechan en Linux (nss_ldap).
  • AIX no soporta grupos anidados.

    • No usar grupos anidados.
    • Clonar el DA “aplanando” los grupos en un servidor LDAP alternativo mediante un proceso de lotes.
    • Compilar y usar nss_ldap en AIX. No se recomienda: no está soportado y es extremadamente lento si hay muchos usuarios y grupos.
  • nss_ldap (Linux) soporta grupos anidados, pero NO sigue los grupos anidados para el Primary Group.
    Solución: No usar grupos anidados para el Primary Group o establecer un grupo Primary Group de relleno.
  • Problema: El grupo por defecto de Windows (habitualmente Domain Users) no pueden leerlo ningún Unix. Para esta referencia se guarda el SID del grupo (última parte del GUID) en el atributo LDAP ‘primaryGroupID’.
    Se suele recomendar que el grupo por defecto de Windows no se emplee para nada, pero muchas veces en las organizaciones suelen usarlo.

    Solución: Podemos poner el mismo grupo en el Primary Group de la pestaña Unix. Así tenemos total consistencia.

    Problema de esta solución: En ocasiones necesitamos que el Primary Group de Unix sea un grupo en particular, para que los ficheros creados pertenezcan a este usuario.

  • Problema: El no interpretar el grupo por defecto Windows, y no soportar grupos anidados en el Primary Group (ver arriba), tendremos problemas si usamos grupos anidados con los grupos por defecto (como Domain Users).
    Solución: Clonar los grupos por defecto de Windows. No usarlos para dar premisos.
  • Problema: Cuando hay muchos grupos con atributos Unix en el dominio, la pestaña de Primary Group no los muestra todos (posible bug).
    Solución: asignar el Primary Group de forma numérica.
  • Problema: En AIX con el ‘secldapclntd’ y en Linux con ‘nscd’, que conecta al LDAP, pierden en rendimiento  y estabilidad si hay muchos usuarios/grupos y agregamos la rama raíz en la configuración.

    • Intentar usar solo las ramas necesarias.
    • Lidiar con el soporte de IBM.
    • Tener la última versión actualizada.
    • Configurar monitores de servicio.
    • El rendimiento de nscd se puede aumentar configurando:
        • nss_initgroups backlink: Uso de “memberOf”
        • nss_getgrent_skipmembers yes: No generar listas de miembros de los grupos.
      • Problema: En AIX (si se usa el framework de autenticación soportado y por defecto: LAM) no se pueden mezclar usuarios y grupos locales y en LDAP. Si existe el mismo usuario en local y en LDAP, prevalece el local. Pero si un usuario LDAP pertenece a un grupo LDAP que también está definido en local, el funcionamiento es el esperado. En Linux sí se mezclan los grupos.
      • Problema: Si existe un mismo usuario o grupo con distintos UID o GID definidos en local y LDAP, el funcionamiento es aleatorio (válido para Linux y AIX).
        Solución: Mantener consistencia entre la BD local y la remota.
      • Problema: Directorio Activo cierra conexiones a los 300 segundos. AIX o Linux pueden fallar la resolución aleatoriamente.
        Solución: Bajar el tiempo de heartbeat (o idle time limit )en los clientes.
      • A tener en cuenta: Directorio Activo agrega un atributo LDAP a los usuarios, ‘memberOf’, que lista los grupos a los que pertenece el usuario o grupo para acelerar las consultas. nss_ldap  (Linux) permite usar este atributo si se emplea el atributo ‘member’ para los grupos.

      Conclusiones y recomendaciones finales:

      • No usar los grupos por defecto de Windows para asignar permisos.
      • Definir el mismo Primary Group que el grupo por defecto de Windows.
      • Evitar el uso de grupos anidados en AIX.
      • Los usuarios y grupos en Unix en minúsculas y máximo 8 caracteres. Nunca con caracteres como acentos, eñes…
        AIX y Linux no soportan otro tipo explícitamente nombres más largos, y aunque “funcionan”, pueden dar problemas. Por ejemplo, las mayúsculas en el programa sudo se emplean para “Alias”.
      • Usar las relaciones grupos de Windows en vez de los de Unix (usar atributo ‘member’ en vez de ‘msSFU30PosixMember’
      • Usar este mapeo de atributos (ala nss_ldap):
        nss_map_attribute cn                cn
        nss_map_attribute uidNumber         msSFU30UidNumber
        nss_map_attribute gidNumber         msSFU30GidNumber
        nss_map_attribute homeDirectory     msSFU30HomeDirectory
        nss_map_attribute loginShell        msSFU30LoginShell
        nss_map_attribute gecos             displayName
        nss_map_attribute shadowLastChange  pwdLastSet
        nss_map_attribute uniqueMember      member
        nss_map_attribute memberUid         msSFU30MemberUid
        nss_map_attribute ipHostNumber      msSFU30IpHostNumber
      • Bajar el heartbeat o el timeout a 250s.
        • Nss_ldap de Linux, en ‘/etc/ldap.conf’: ‘idle_timelimit 250’
        • AIX, en ‘/etc/security/ldap/ldap.cfg’: heartbeatinterval: 250
      • El Directorio Activo no soporta queries LDAP anónimas, debe usarse un usuario:
        • Es conveniente tener un usuario por host
        • que este no se pueda bloquear, si no se quiere abrir un potencial y simple ataque de DoS.
        • Que sólo pueda hacer login desde la máquina necesaria.
      • Tener un directorio activo bien organizado para evitar agregar el nodo raíz. Si no, intentar optimizar el rendimiento con opciones como nss_initgroups o nss_getgrent_skipmembers.