This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Password Expiration Time Behavior Change in eDir 9.2.7

I wanted to make everyone aware that there is a behavior change in the way eDirectory 9.2.7 handles password expiration time on login.  Prior to eDirectory 9.2.7, you could manually set a passwordExpirationTime on a user object and upon login (in my testing LDAP BINDs), even if the password policy assigned to the user had a password expires setting, the user's password expiration time would not get get reset to match the policy.  So for example, say I had a 30 day expire on my password policy and my password changed time was more than 30 days in the past and hence my password was expired.  Prior to eDirectory 9.2.7, I could just set the password expiration time to some future date and my password would no longer be expired. I could continue to login with that password until it expired on the new date/time set in passwordExpirationTime on my user object.  

Now in eDirectory 9.2.7, when a user logs in, the password expiration time is immediately reset to match the policy.  So if the policy is set for 30 day expire, the passwordExpirationTime is set to 30 days since pwdChangedTime.  Basically, you can no longer override the calculated expiration time like you could in the past.

I'm not sure if this change was done on-purpose or not, but it is something to be aware of.  It was the result of a bug fix, see reply below.

Matt

  • Verified Answer

    +1  

    FYI, it is the result of this bug fix:

    PasswordExpirationTime does not get added to user at login if verify whether existing password comply is false#

    Fix: PasswordExpirationTime does not get added to user at login if verify whether existing password comply is false. This occurs when the user does not change the password after login. As a result, changes have been done for password compliance check and to get the PasswordExpirationTime even if password comply is “False”. (Defect 235437)

    So something to be aware of, especially if you have mixed trees.