Posts etiquetados ‘SFU’

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 http://www.nico.schottelius.org/blog/nscd-bugs/):

  • 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…

(más…)

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.
    Soluciones:

    • 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.
    Solució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.