I'm trying to migrate my organization of FDS, but policy requires a 90 day password expiration, and pam_ldap modules aren't forcing password changes even after the password expired.
I saw in a thread back from 2011 that somebody was having an issue where setting passwordExpirationTime to 19700101000000Z would force a change, but 19700101000001Z wouldn't. Well... even setting to 19700101000000Z doesn't work for me.
intdns1-01-lv:~ mpatenaude$ luser mitchtest2 dn: uid=mitchtest2,ou=People,dc=prod,dc=shutterfly,dc=com passwordExpirationTime: 19700101000000Z loginShell: /bin/bash uid: mitchtest2 cn: Mitch Test2 givenName: Mitch sn: Test2 mail: mitchtest2@shutterfly.com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: ldapPublicKey uidNumber: 5134 gidNumber: 5134 homeDirectory: /home/mitchtest2 gecos: Mitch Test2
But it lets that account log in without prompting for a password change.
Any ideas?
On Mon, 2017-06-26 at 17:16 +0000, Mitch Patenaude wrote:
I'm trying to migrate my organization of FDS, but policy requires a 90 day password expiration, and pam_ldap modules aren't forcing password changes even after the password expired.
I saw in a thread back from 2011 that somebody was having an issue where setting passwordExpirationTime to 19700101000000Z would force a change, but 19700101000001Z wouldn't. Well... even setting to 19700101000000Z doesn't work for me.
intdns1-01-lv:~ mpatenaude$ luser mitchtest2 dn: uid=mitchtest2,ou=People,dc=prod,dc=shutterfly,dc=com passwordExpirationTime: 19700101000000Z loginShell: /bin/bash uid: mitchtest2 cn: Mitch Test2 givenName: Mitch sn: Test2 mail: mitchtest2@shutterfly.com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: ldapPublicKey uidNumber: 5134 gidNumber: 5134 homeDirectory: /home/mitchtest2 gecos: Mitch Test2
But it lets that account log in without prompting for a password change.
Any ideas?
It's probably worth reading
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
I would check that the date-format is correct (enough digits). Check the number of grace logins you have as well. Finally, to help us diagnose this, it would be good to see the password policy related attributes from cn=config,
Thanks,
On 06/26/2017 10:16 AM, Mitch Patenaude wrote:
I'm trying to migrate my organization of FDS, but policy requires a 90 day password expiration, and pam_ldap modules aren't forcing password changes even after the password expired.
As far as I know, pam_ldap doesn't use passwordExpirationTime, it only uses the shadow* attributes.
If you're using a recent version of 389-ds, those attributes should be calculated based on your policy. What version are you running? How did you configure your password policy?
(It should also be noted that sssd is a much better choice than pam_ldap and nss_ldap. Those modules cannot determine network availability or LDAP availability, and can create extremely long delays booting systems. Don't use them.)
On 6/26/17, 7:09 PM, "Gordon Messmer" gordon.messmer@gmail.com wrote:
As far as I know, pam_ldap doesn't use passwordExpirationTime, it only uses the shadow* attributes.
It does respect them actually, I just had the server misconfigured.
If you're using a recent version of 389-ds, those attributes should be calculated based on your policy. What version are you running? How did you configure your password policy?
The policy was configured using 389-console, and it seem that if you select the option "User must change password after reset", then it doesn't enforce expiration, at least that I's what I changed to make enforcement work.
(It should also be noted that sssd is a much better choice than pam_ldap and nss_ldap. Those modules cannot determine network availability or LDAP availability, and can create extremely long delays booting systems. Don't use them.)
I just found out about sssd yesterday, and I'm looking into migrating.
Thanks for your help. -- Mitch Patenaude
389-users@lists.fedoraproject.org
-
Gordon Messmer -
Mitch Patenaude -
William Brown