OpenLDAP, Samba y envejecimiento de contraseña

Estoy configurando un sistema en el que todos los recursos de TI están disponibles a través de un solo par de contraseña de usuario, ya sea el acceso a la shell en los servidores, el inicio de sesión en el dominio Samba, WiFi, OpenVPN, Mantis, etc. (con acceso a servicios específicos regidos por membresía de grupo o campos de objeto de usuario). Debido a que tenemos datos personales en nuestra red, necesitamos implementar el envejecimiento de la contraseña, de acuerdo con la Directiva de Protección de Datos de la UE (o más bien la versión polaca de la misma).

El problema es que las cuentas Samba y POSIX en LDAP usan información de hashing y antigüedad de contraseñas diferente. Mientras sincroniza las contraseñas sí mismos es fácil (el ldap password sync = Yesde smb.conf), la adición de caducidad de las contraseñas a los saltos de mezclar las cosas: Samba no actualiza shadowLastChange. Junto con obey pam restrictions = Yescrea un sistema en el que un usuario de Windows no puede cambiar la contraseña antigua, pero si no la uso, los directorios principales no se crearán automáticamente. La alternativa es usar la operación extendida LDAP para cambiar la contraseña, pero el smbk5pwdmódulo tampoco la configura. Lo que es peor, el mantenedor de OpenLDAP no lo actualizará / aceptará parches ya que este campo se considera obsoleto.

Entonces, mi pregunta es, ¿cuál es la mejor solución? ¿Cuáles son sus ventajas y desventajas?

1. ¿Utiliza LDAP ppolicyy el envejecimiento interno de la contraseña LDAP?

   1. ¿Qué tan bien funciona con NSS, módulos PAM, samba, otros sistemas?
   2. ¿Los módulos NSS y PAM deben configurarse de manera especial para usar ppolicy, no shadow?
   3. ¿ GOsa² funciona con ppolicy?
   4. ¿Existen otras herramientas administrativas que puedan funcionar con ppolicyLDAP habilitado?

2. Hackea un script de cambio de contraseña que actualiza el campo en LDAP. (dejando la posibilidad de que el usuario mismo actualice el campo sin cambiar la contraseña)

Escribí mi propia superposición de OpenLDAP llamada shadowlastchangepara actualizar el shadowLastChangeatributo cada vez que se produce un cambio de contraseña EXOP. Se activa en slapd.conf:

moduleload smbk5pwd
moduleload shadowlastchange
...

database bdb
...
overlay smbk5pwd
overlay shadowlastchange

He configurado smb.confpara cambiar las contraseñas a través de EXOP:

ldap passwd sync = Only

Luego, para cada cuenta, establezca shadowMaxel número de días que una contraseña es válida. ¡Los módulos OpenLDAP se encargan del resto!

Como stop-gap creé un script para Samba que actualizará el shadowLastChangecambio de contraseña:

#!/bin/sh
# script to update shadowLastChange when samba updates passwords
# it's not needed when using 'passwd', it does update the field,
# even if pam_ldap is using LDAP Extented Operation to change password

LDAP_MODIFY="/usr/bin/ldapmodify"
LDAP_SEARCH="/usr/bin/ldapsearch"
LDAP_USER="uid=shadow-update,ou=Services,dc=example,dc=com"
LDAP_PASSWORD="change-me"
LDAP_HOST="localhost"

# get date
SLC=$((`date '+%s'` / 24 / 3600))

# get user login name
user=$1

# find user's DN
dn=$($LDAP_SEARCH -x -h $LDAP_HOST -LLL -b dc=example,dc=com "(uid=$user)" dn)
dn=${dn#dn:}

# check if DN is not base64 encoded
if [ "${dn:0:1}" = ":" ]; then
        # update password change date
        echo "dn:$dn
changetype: modify
replace: shadowLastChange
shadowLastChange: $SLC" | cat | $LDAP_MODIFY -x -h "$LDAP_HOST" \
 -D "$LDAP_USER" -w "$LDAP_PASSWORD" > /dev/null 2>&1
else
        # update password change date
        echo "dn: $dn
changetype: modify
replace: shadowLastChange
shadowLastChange: $SLC" | cat | $LDAP_MODIFY -x -h "$LDAP_HOST" \
 -D "$LDAP_USER" -w "$LDAP_PASSWORD" > /dev/null 2>&1
fi

err=$?

if [ ! $err -eq 0 ]; then
   echo "error: can't update shadowLastChange: $err"
   echo "`date`: shadow.sh: can't update shadowLastChange: $err"\
       >> /var/log/shadow-update.log
   exit;
fi

echo OK

En la configuración de Samba, debe unix password syncestablecerse en yes, passwd chatestablecer en *OK*y passwd programpara el script anterior con "%u"como param.

Una cuenta especificada en LDAP_USERdebe crearse en LDAP y tener permisos de lectura para uidtodos los usuarios de Samba y el derecho a escribir shadowLastChange.

(trabajo en progreso, agregaré detalles más adelante)

¡Buenas noticias para todos! Lo tengo todo funcionando, más o menos ..., en un entorno de prueba ...:

1. La política de contraseñas (tanto de calidad como de tiempo) se aplica en el nivel de OpenLDAP (gracias a ppolicy, not24getypasswdqc )
2. Las contraseñas se sincronizan entre Samba y POSIX en ambos sentidos (gracias a smbk5pwd). Nota: El control de calidad con Samba y ppolicy no es obvio: el password check script( pwqcheck -1desde passwdqc) debe realizar las mismas comprobaciones que LDAP o el usuario obtendrá un Permiso denegado en lugar de "Contraseña demasiado fácil, pruebe diferente".
3. Tanto PAM como Samba advierten al usuario que la contraseña caducará pronto.
4. Los directorios de usuarios se crean usandopam_mkhomedir
5. La implementación GOsa² de RFC2307bis (y el esquema asociado) se inserta uidpara agrupar entradas, por lo que las aplicaciones que esperan NIS (la mayoría de las cosas "UNIXy") o el esquema RFC2307bis (la mayoría de las aplicaciones "diseñadas para AD") funcionan bien.

El único problema es que deshabilitar una cuenta requiere el uso de herramientas CLI (o escribir un script postmodify de GOsa) o la cuenta no se bloqueará a nivel LDAP, solo para PAM y Samba. La expiración de la contraseña aún se aplicará, por lo que no es un gran problema.

Tengo respuesta de uno de los desarrolladores de GOsa. En este momento, GOsa no admite la superposición de políticas de ninguna manera.