He buscado toneladas de webs y tutoriales pero no pude encontrar una respuesta a mi problema.
Configuré OpenLDAP 2.4 en una máquina OpenSUSE 12.3 con una política de contraseña superpuesta. El cliente es una máquina Linux Mint 17.1 con los paquetes libnss-ldap y libpam-ldap instalados. El cliente y el servidor están configurados para utilizar TLS con certificados autofirmados (el servidor funciona como CA y firma su propio certificado). Todo funciona bien hasta que agrego el atributo pwdReset: TRUEa un usuario.
Mi intención esobligar al usuario a cambiar su contraseña en el próximo inicio de sesión. Sin embargo, después de configurar este atributo, el usuario ya no puede autenticarse: si intento 'su' (o iniciar sesión con) el usuario, aparece el error "Error de autenticación". Además, el syslog muestra los siguientes mensajes:
Mar 4 07:27:11 client-desktop nslcd[3198]: [90cde7] <authc="johndoe"> ldap_result() failed: Insufficient access: Operations are restricted to bind/unbind/abandon/StartTLS/modify password
Mar 4 07:27:11 client-desktop nslcd[3198]: [dcc233] <authc="johndoe"> cn=John Doe,ou=people,cd=domain,dc=com: lookup failed: Invalid credentials
Estos mensajes me dicen que las credenciales del usuario ya no son válidas, lo cual es razonable ya que restablecí su contraseña pero no se le pregunta al usuario sobre la necesidad de cambiar su contraseña ni nada por el estilo. Además, quiero evitar el uso de utilidades openldap como ldappasswd ya que los clientes no son expertos. Por lo tanto, quiero que sigan usando el típico comando passwd para cambiar sus propias contraseñas. Al menos, esto es posible cuando pwdReset no está configurado. Además, puedo obtener este comportamiento estableciendo el shadowLastChangeatributo en 0, pero me gustaría hacer todo con políticas de contraseña, ya que también estoy intentando imponer el uso de contraseñas de al menos 8 caracteres. Por cierto, esta característica funciona perfectamente.
Este es un extracto de mi DN base para que pueda verificar si me falta algo. Tenga en cuenta que pwdResetse establece en VERDADERO en el usuario y pwdMustChangela variable se establece en VERDADERO en la propia política.
# John Doe, people, domain.com
dn: cn=John Doe,ou=people,dc=domain,dc=com
cn: John Doe
sn: Doe
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
uid: johndoe
uidNumber: 1003
gidNumber: 1000
homeDirectory: /home/johndoe
loginShell: /bin/bash
userPassword: e1NTSEF9VWFSMDVsSGNIWFMxcnJ5VzBtaWRkOHFmTDE1ai9RYlQ=
pwdReset: TRUE # This attribute only appears if I explicitly request it
# policies, domain.com
dn: ou=policies,dc=domain,dc=com
objectClass: top
objectClass: organizationalUnit
ou: policies
(Los siguientes atributos pertenecen a cn=default,ou=policies pero por alguna razón no aparecen a menos que escriba algo aquí)
pwdInHistory: 3
pwdLockout: TRUE
pwdMaxFailure: 3
pwdLockoutDuration: 30
pwdMustChange: TRUE
pwdSafeModify: FALSE
pwdAllowUserChange: TRUE
pwdFailureCountInterval: 0
pwdGraceAuthNLimit: 0
Y esta es la configuración de mi backend y las políticas de contraseñas:
# {1}hdb, config
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=domain,dc=com
olcAccess: {0}to attrs=userPassword by self write by * auth
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to attrs=userPKCS12 by self read by * none
olcAccess: {3}to * by * read
olcRootDN: cn=admin,dc=domain,dc=com
olcRootPW: {SSHA}############## omited
olcDbCacheSize: 10000
olcDbCheckpoint: 1024 5
olcDbConfig: {0}set_cachesize 0 15000000 1
olcDbConfig: {1}set_lg_regionmax 262144
olcDbConfig: {2}set_lg_bsize 2097152
olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE
olcDbConfig: {4}set_lk_max_locks 30000
olcDbConfig: {5}set_lk_max_objects 30000
olcDbIDLcacheSize: 30000
olcDbIndex: objectclass eq
[...more indexes...]
# {0}ppolicy, {1}hdb, config
dn: olcOverlay={0}ppolicy,olcDatabase={1}hdb,cn=config
objectClass: top
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=domain,dc=com
olcPPolicyHashCleartext: TRUE
(Los dos atributos siguientes también pertenecen a {0}ppolicy)
olcPPolicyUseLockout: FALSE
olcPPolicyForwardUpdates: FALSE
Espero que alguien pueda arrojar algo de luz sobre esto. ¡Cualquier ayuda es muy apreciada!
Saludos
Editar:
He realizado algunas modificaciones a la política predeterminada para obtener información sobre lo que impedía la autenticación del usuario. Me he dado cuenta de que si pwdMustChangeestá configurado en VERDADERO y pwdResettambién está configurado en VERDADERO (este en la entrada del usuario), entonces la autenticación del usuario falla con el error 'su: Fallo de autenticación'. Sin embargo, si pwdResetes VERDADERO y pwdMustChangeFALSO, entonces inicio sesión tantas veces como quiera con ese usuario. Creo que tener dos variables para esto es inútil y contradictorio. En su lugar, se debe usar una única variable solo en la entrada del usuario, como quiera llamarla pwdReseto pwdMustChange.
Respuesta1
Las políticas del servidor LDAP no necesariamente equivalen a políticas dentro del sistema operativo. Parece que te estás imaginando un marco en el que configuras esta propiedad de superposición y elSOse da cuenta de la necesidad de cambiar la contraseña, pero como puede ver, no es así como funciona.
Para activar un aviso dentro del sistema operativo, un módulo de contabilidad (normalmente PAM) debe detectar la condición. La superposición de la política de contraseñas de OpenLDAP no es un estándar POSIX. A diferencia de lo que sucede cuando ajustas las shadowpropiedades de un usuario para establecer la política, pam_unixno tiene conocimiento de estos atributos que estás configurando. No se puede decir lo mismo del propio servidor OpenLDAP. Esto da como resultado un bloqueo del usuario porque el usuario no puede autenticarse en el servidor Linux y carece de información suficiente sobre LDAP (como usted mismo observa) para trabajar directamente con el servidor LDAP para cambiar su contraseña.
Si está buscando activar solicitudes de cambio de contraseña dentro del sistema operativo, esta no es la herramienta adecuada para el trabajo. Personalmente, le recomendaría que se familiarice con los shadowatributos relevantes, los almacene en LDAP si es necesario administrarlos de forma centralizada y los utilice para activar los comportamientos que está buscando.
Desde la pam_unix(8)página de manual:
El componente de cuenta realiza la tarea de establecer el estado de la cuenta y la contraseña del usuario en función de los siguientes elementos ocultos: expirar, último_cambio, máximo_cambio, mínimo_cambio, advertencia_cambio. En el caso de este último, podrá ofrecer asesoramiento al usuario sobre el cambio de su contraseña o, a través de la devolución PAM_AUTHTOKEN_REQD, retrasar la prestación del servicio al usuario hasta que haya establecido una nueva contraseña. Las entradas enumeradas anteriormente están documentadas en la página del manual de Shadow(5). Si el registro del usuario no contiene una o más de estas entradas, no se realiza la verificación paralela correspondiente.