passwordexpirationtime not clearing when user changes password

776 views
Skip to first unread message

andrewdm...@gmail.com

unread,
Aug 25, 2016, 5:54:41 PM8/25/16
to pwm-general
I'm testing a new PWM setup with 389 Directory Server. I'm using PWM 1.8 and 389-ds-base 1.2.11.15-74.el6. I've also tried 389-ds-base 1.3.4 with the same results.

I would like to be able to have Helpdesk staff in PWM change someone's password and force them to change it when the login. To accomplish this, I've enabled the setting "Force Password Expiration On Password Set" in "Modules --> Authenticated --> Help Desk --> Help Desk Profiles --> default". I've also enabled "Use Proxy Connection" on the same settings page. On the Directory Server, the setting "User must change password after reset" is not enabled. Password Expiration is set to "Password never expires".

When a PWM Help Desk admin changes a password for another user, it successfully sets the passwordexpirationtime attribute for that account to "19700101010101Z". In order to make that work, I had to add an additional ACI:

aci: (targetattr = "passwordExpirationTime") (target = "ldap:///ou=People,dc=corp,dc=example,dc=net") (version 3.0; acl "PWM Proxy set and clear passwordExpirationTime"; allow (read,write,delete)(userdn = "ldap:///uid=pwmproxy,ou=People,dc=corp,dc=example,dc=net");)

I use (read,write,delete) during troubleshooting, although (write) may be sufficient.

When I login with this user, I am forced to the "Password expired" page to change my password, as expected. I successfully change the password. However, the passwordexpirationtime attribute remains set for the user. When I login a second time with that user (with the new password), I am once again forced to the "Password expired" page to change my password.


I see different behavior when I set the server to "Password expires after 100 days". I have change the password from PWM Helpdesk, the passwordexpirationattribute is set as expected. But then the user cannot login. I see this error in the PWM.log:

2016-08-25T17:17:42Z, ERROR, auth.SessionAuthenticator, {116} ldap error during search: 5001 ERROR_WRONGPASSWORD (ldap error during password check: unable to create connection: unable to bind to ldaps://ldaptest01.example.net:636 as uid=andy,ou=People,dc=corp,dc=example,dc=net reason: [LDAP: error code 49 - password expired!])

As a test, I disabled the "Force Password Expiration On Password Set" and created at Help Desk Action that set the passwordexpirationtime to "@CurrentTime:yyyyMMddHHmmss@Z". This successfully set the passwordexpirationtime to the current time. But this had the same problem, since that date is by definition already passed.

So I set the rule to "@CurrentTime:yyyyMMdd235959@Z", which sets the time to 23:59:59 of the current date. This worked. I was able to login as the user and was still forced to change my password (since the "Password Pre-Expire Time" in PWM is set to 86400 seconds). Additionally, the passwordexpirationtime was automatically updated to 100 days from today.

That is clearly a hack, and could potentially cause some confusion around 7:59pm EDT. But at least it works.


Additional information:
"Check Expire During Authentication" is enabled in PWM
"Password Policy Source" is set to "Local" in PWM (when set to "Merge", PWM was enforcing a strange policy, which prevented the use of numbers and special characters)


What am I missing? For now, we would like to never expire passwords. Shouldn't the passwordexpirationtime attribute be removed when the user changes her password (if the server is set to "Password never expires")? This feels like it might be a problem (or configuration issue) with the Directory Server, and not PWM, per se. But I'm not sure

leke...@gmail.com

unread,
Apr 21, 2020, 4:31:10 AM4/21/20
to pwm-general
Hello. Have you solved this issue?
I faced the same problem with .

пятница, 26 августа 2016 г., 3:54:41 UTC+6 пользователь andrewdm...@gmail.com написал:

Jason Rivard

unread,
Apr 22, 2020, 5:32:24 PM4/22/20
to pwm-general
PWM doesn't generally set the passwordexpiretime attribute, except in some cases where it is deleted.  The calculation and setting of this value is expected to be handled by the LDAP server.

Jason Everling

unread,
Apr 22, 2020, 6:25:29 PM4/22/20
to pwm-general
I would concur, AD and OpenDJ/OracleDS both set their attribute on the ldap side dynamically when the password attribute value is modified. Maybe you have something configured or even misconfigured on your ldap side
Reply all
Reply to author
Forward
0 new messages