pam_ldap not respecting passwordExpirationTime

[Mitch Patenaude]

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(a)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?

[William Brown]

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(a)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...

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, 


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

[Gordon Messmer]

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.)

[Mitch Patenaude]

On 6/26/17, 7:09 PM, "Gordon Messmer" <gordon.messmer(a)gmail.com&gt; 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