Hi!
We are running Red Hat Enterprise Linux release 8.3 with 389-ds-base-1.4.3.16-19.module+el8.4.0+11894+f5bb5c43.x86_64 installed. We have configured password expiration, and passwordExpirationTime is getting updated properly when the end user binds and changes the password, or when cn=directory manager changes the password. We have an API that is invoked to allow the users to change their password when they have forgotten it, so it cannot bind as the end user, but we also do not want it to have to bind as cn=directory manager. However, we haven't had any luck getting any other user to update passwordExpirationTime when updating the password. Looking at the code, it looks like password admins should be allowed to update passwordExpirationTime, but we have those configured and it's not working. Is there something we are missing?
Thanks!
Hi Mike,
I'm not sure I understand the issue. If a userpassword is changed, and password expiration is tuned on, then the attribute is always updated. It doesn't matter who makes the password change. A "password Administrator" is just allowed to bypass syntax checks - that's it.
Anyway this all works for me. Here I show the audit log as I make changes and I see passwordExpirationtime being updated:
dn: cn=mark,ou=people,dc=example,dc=com result: 0 changetype: add objectClass: top objectClass: nsPerson objectClass: nsAccount objectClass: nsOrgPerson cn: mark displayName: mark passwordExpirationTime: 20220624152751Z userPassword:: ... modifiersName: cn=directory manager
Then I change this user's password with a regualr database user (cn=delegated admin...) that has access rights to change passwords:
dn: cn=mark,ou=people,dc=example,dc=com result: 0 changetype: modify replace: userPassword userPassword:: ... - replace: modifiersname modifiersname: cn=delegated admin,ou=people,dc=example,dc=com - replace: modifytimestamp modifytimestamp: 20220316153143Z -
time: 20220316113143 dn: cn=mark,ou=people,dc=example,dc=com result: 0 changetype: modify replace: passwordgraceusertime passwordgraceusertime: 0 - replace: passwordExpirationTime passwordExpirationTime: 20220624153143Z - replace: passwordExpWarned passwordExpWarned: 0
I also tried this same test with "cn=delegated admin" set as a password admin, and it still works correctly.
Am I misunderstanding your issue?
Mark
On 3/16/22 11:01 AM, Mike Wohlgemuth wrote:
Hi!
We are running Red Hat Enterprise Linux release 8.3 with 389-ds-base-1.4.3.16-19.module+el8.4.0+11894+f5bb5c43.x86_64 installed. We have configured password expiration, and passwordExpirationTime is getting updated properly when the end user binds and changes the password, or when cn=directory manager changes the password. We have an API that is invoked to allow the users to change their password when they have forgotten it, so it cannot bind as the end user, but we also do not want it to have to bind as cn=directory manager. However, we haven't had any luck getting any other user to update passwordExpirationTime when updating the password. Looking at the code, it looks like password admins should be allowed to update passwordExpirationTime, but we have those configured and it's not working. Is there something we are missing?
Thanks! _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Thanks for the reply. The issue that only cn=directory manager is able to change another user's password and have passwordExpirationTime updated. I tried the password admins as a shot in the dark, though, so I'm not surprised it shouldn't have any impact.
Thanks!
Here's a test performed with Apache Directory Studio to bind as a user with ACI access to change the password, as logged within our audit log (I sanitized his hashes) which shows only that the pwdUpdateTime attribute is updated but not the passwordExpirationTime, before replication of the change happens:
time: 20220314160259 dn: uid=woogie,ou=facultyandstaff,dc=neu,dc=edu result: 0 changetype: modify delete: userPassword userPassword:: DELETED HASH - add: userPassword userPassword:: DELETED HASH - replace: modifiersName modifiersName: uid=jesidm.admin,ou=special users,dc=neu,dc=edu - replace: modifyTimestamp modifyTimestamp: 20220314200259Z -
time: 20220314160301 dn: uid=woogie,ou=facultyandstaff,dc=neu,dc=edu result: 0 changetype: modify replace: pwdUpdateTime pwdUpdateTime: 20220314200259Z -
time: 20220314161119 dn: cn=repl keep alive 2,dc=neu,dc=edu result: 0 changetype: modify replace: keepalivetimestamp keepalivetimestamp: 20220314201119Z - replace: modifiersName modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20220314201119Z -
When the same transaction is performed as Directory Manager, we see the following in our audit logs:
time: 20220314161734 dn: uid=woogie,ou=facultyandstaff,dc=neu,dc=edu result: 0 changetype: modify delete: userPassword userPassword:: DELETED HASH - add: userPassword userPassword:: DELETED HASH - replace: modifiersname modifiersname: cn=directory manager - replace: modifytimestamp modifytimestamp: 20220314201734Z -
time: 20220314161734 dn: uid=woogie,ou=facultyandstaff,dc=neu,dc=edu result: 0 changetype: modify replace: passwordExpirationTime passwordExpirationTime: 20230314201734Z - replace: passwordExpWarned passwordExpWarned: 0 -
time: 20220314161939 dn: cn=repl keep alive 2,dc=neu,dc=edu result: 0 changetype: modify replace: keepalivetimestamp keepalivetimestamp: 20220314201939Z - replace: modifiersName modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20220314201939Z -
I do find it unusual that in this last case, the pwdUpdateTime isn't updated...
Thanks!
On 3/16/22 2:28 PM, Mike Wohlgemuth wrote:
Here's a test performed with Apache Directory Studio to bind as a user with ACI access to change the password, as logged within our audit log (I sanitized his hashes) which shows only that the pwdUpdateTime attribute is updated but not the passwordExpirationTime, before replication of the change happens:
time: 20220314160259 dn: uid=woogie,ou=facultyandstaff,dc=neu,dc=edu result: 0 changetype: modify delete: userPassword userPassword:: DELETED HASH
add: userPassword userPassword:: DELETED HASH
replace: modifiersName modifiersName: uid=jesidm.admin,ou=special users,dc=neu,dc=edu
replace: modifyTimestamp modifyTimestamp: 20220314200259Z
time: 20220314160301 dn: uid=woogie,ou=facultyandstaff,dc=neu,dc=edu result: 0 changetype: modify replace: pwdUpdateTime pwdUpdateTime: 20220314200259Z
time: 20220314161119 dn: cn=repl keep alive 2,dc=neu,dc=edu result: 0 changetype: modify replace: keepalivetimestamp keepalivetimestamp: 20220314201119Z
replace: modifiersName modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
replace: modifyTimestamp modifyTimestamp: 20220314201119Z
When the same transaction is performed as Directory Manager, we see the following in our audit logs:
time: 20220314161734 dn: uid=woogie,ou=facultyandstaff,dc=neu,dc=edu result: 0 changetype: modify delete: userPassword userPassword:: DELETED HASH
add: userPassword userPassword:: DELETED HASH
replace: modifiersname modifiersname: cn=directory manager
replace: modifytimestamp modifytimestamp: 20220314201734Z
time: 20220314161734 dn: uid=woogie,ou=facultyandstaff,dc=neu,dc=edu result: 0 changetype: modify replace: passwordExpirationTime passwordExpirationTime: 20230314201734Z
replace: passwordExpWarned passwordExpWarned: 0
time: 20220314161939 dn: cn=repl keep alive 2,dc=neu,dc=edu result: 0 changetype: modify replace: keepalivetimestamp keepalivetimestamp: 20220314201939Z
replace: modifiersName modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
replace: modifyTimestamp modifyTimestamp: 20220314201939Z
I do find it unusual that in this last case, the pwdUpdateTime isn't updated...
It is odd. I don't see this behavior in our latest version, but once I get your settings I'll try and reproduce it again.
Can you share the output from the following commands?
# dsconf slapd-YOUR_INSTANCE pwpolicy get
# dsconf slapd-YOUR_INSTANCE localpwp list
Then for each DN (if any) run:
# dsconf slapd-YOUR_INSTANCE localpwp get <DN>
Thanks,
Mark
Thanks! _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Here is the dsconf output:
# dsconf slapd-neuTestMain pwpolicy get Global Password Policy: cn=config ------------------------------------ nsslapd-pwpolicy-local: on passwordstoragescheme: PBKDF2_SHA256 passwordchange: on passwordmustchange: off passwordhistory: off passwordinhistory: 6 passwordadmindn: cn=password_admins,ou=groups,dc=neu,dc=edu passwordtrackupdatetime: on passwordwarning: 86400 passwordisglobalpolicy: off passwordexp: off passwordmaxage: 8640000 passwordminage: 0 passwordgracelimit: 0 passwordsendexpiringtime: off passwordlockout: off passwordunlock: on passwordlockoutduration: 3600 passwordmaxfailure: 3 passwordresetfailurecount: 600 passwordchecksyntax: off passwordminlength: 8 passwordmindigits: 0 passwordminalphas: 0 passwordminuppers: 0 passwordminlowers: 0 passwordminspecials: 0 passwordmin8bit: 0 passwordmaxrepeats: 0 passwordpalindrome: off passwordmaxsequence: 0 passwordmaxseqsets: 0 passwordmaxclasschars: 0 passwordmincategories: 3 passwordmintokenlength: 3 passwordbadwords: passworduserattributes: passworddictcheck: off passworddictpath: nsslapd-allow-hashed-passwords: off nsslapd-pwpolicy-inherit-global: off
# dsconf slapd-neuTestMain localpwp list ou=facultyandstaff,dc=neu,dc=edu (subtree policy) ou=people,dc=neu,dc=edu (subtree policy) ou=student,dc=neu,dc=edu (subtree policy)
# dsconf slapd-neuTestMain localpwp get ou=facultyandstaff,dc=neu,dc=edu Local Subtree Policy Policy for "ou=facultyandstaff,dc=neu,dc=edu": cn=cn\3DnsPwPolicyEntry_subtree\2Cou\3Dfacultyandstaff\2Cdc\3Dneu\2Cdc\3Dedu,cn=nsPwPolicyContainer,ou=facultyandstaff,dc=neu,dc=edu ------------------------------------ passwordexp: on passwordmaxage: 31536000
# dsconf slapd-neuTestMain localpwp get ou=people,dc=neu,dc=edu Local Subtree Policy Policy for "ou=people,dc=neu,dc=edu": cn=cn\3DnsPwPolicyEntry_subtree\2Cou\3Dpeople\2Cdc\3Dneu\2Cdc\3Dedu,cn=nsPwPolicyContainer,ou=people,dc=neu,dc=edu ------------------------------------ passwordexp: on passwordmaxage: 31536000
[root@nb9545 ldap]# dsconf slapd-neuTestMain localpwp get ou=student,dc=neu,dc=edu Local Subtree Policy Policy for "ou=student,dc=neu,dc=edu": cn=cn\3DnsPwPolicyEntry_subtree\2Cou\3Dstudent\2Cdc\3Dneu\2Cdc\3Dedu,cn=nsPwPolicyContainer,ou=student,dc=neu,dc=edu ------------------------------------ passwordexp: on passwordmaxage: 31536000
Well I can not reproduce your issue exactly, but I am on a newer version of DS. Although this code hasn't really changed in a long time. Anyway you have conflicting policies (sort of). You have some things set in the global policy and different settings in the subtree/local policies.
The global policy sets "pwdUpateTime", and the local policies only set passwordExpirationtime. So it's either one of the other depending where the target user is that is modified.
You can try setting nsslapd-pwpolicy-inherit-global to "on". That is supposed to merge the global and local policies, but I would prefer if you added passwordtrackupdatetime to all the local policies. That's one thing. The other is that it looks like you are hitting a bug. Directory Manager is applying the local policy, while your other user is only processing the global policy (which is wrong). This is why the behavior is different, but I can not explain why it's not consistent between the two binding accounts (unless you modified the audit log output you sent me). Now you are on a older version of 389-ds-base-1.4.3, so if it's a bug its been fixed in newer versions.
So trying updating your polices as I mentioned above and see if it helps. Is there a newer version of 389-ds-base you can upgrade to (at least to test this)?
Mark
On 3/16/22 3:20 PM, Mike Wohlgemuth wrote:
Here is the dsconf output:
# dsconf slapd-neuTestMain pwpolicy get Global Password Policy: cn=config
nsslapd-pwpolicy-local: on passwordstoragescheme: PBKDF2_SHA256 passwordchange: on passwordmustchange: off passwordhistory: off passwordinhistory: 6 passwordadmindn: cn=password_admins,ou=groups,dc=neu,dc=edu passwordtrackupdatetime: on passwordwarning: 86400 passwordisglobalpolicy: off passwordexp: off passwordmaxage: 8640000 passwordminage: 0 passwordgracelimit: 0 passwordsendexpiringtime: off passwordlockout: off passwordunlock: on passwordlockoutduration: 3600 passwordmaxfailure: 3 passwordresetfailurecount: 600 passwordchecksyntax: off passwordminlength: 8 passwordmindigits: 0 passwordminalphas: 0 passwordminuppers: 0 passwordminlowers: 0 passwordminspecials: 0 passwordmin8bit: 0 passwordmaxrepeats: 0 passwordpalindrome: off passwordmaxsequence: 0 passwordmaxseqsets: 0 passwordmaxclasschars: 0 passwordmincategories: 3 passwordmintokenlength: 3 passwordbadwords: passworduserattributes: passworddictcheck: off passworddictpath: nsslapd-allow-hashed-passwords: off nsslapd-pwpolicy-inherit-global: off
# dsconf slapd-neuTestMain localpwp list ou=facultyandstaff,dc=neu,dc=edu (subtree policy) ou=people,dc=neu,dc=edu (subtree policy) ou=student,dc=neu,dc=edu (subtree policy)
# dsconf slapd-neuTestMain localpwp get ou=facultyandstaff,dc=neu,dc=edu Local Subtree Policy Policy for "ou=facultyandstaff,dc=neu,dc=edu": cn=cn\3DnsPwPolicyEntry_subtree\2Cou\3Dfacultyandstaff\2Cdc\3Dneu\2Cdc\3Dedu,cn=nsPwPolicyContainer,ou=facultyandstaff,dc=neu,dc=edu
passwordexp: on passwordmaxage: 31536000
# dsconf slapd-neuTestMain localpwp get ou=people,dc=neu,dc=edu Local Subtree Policy Policy for "ou=people,dc=neu,dc=edu": cn=cn\3DnsPwPolicyEntry_subtree\2Cou\3Dpeople\2Cdc\3Dneu\2Cdc\3Dedu,cn=nsPwPolicyContainer,ou=people,dc=neu,dc=edu
passwordexp: on passwordmaxage: 31536000
[root@nb9545 ldap]# dsconf slapd-neuTestMain localpwp get ou=student,dc=neu,dc=edu Local Subtree Policy Policy for "ou=student,dc=neu,dc=edu": cn=cn\3DnsPwPolicyEntry_subtree\2Cou\3Dstudent\2Cdc\3Dneu\2Cdc\3Dedu,cn=nsPwPolicyContainer,ou=student,dc=neu,dc=edu
passwordexp: on passwordmaxage: 31536000 _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Just a quick follow up to close the loop on this bug we encountered. Thanks to your advice, we found that we could correct the behavior after upgrading our 389DS servers to the latest version available in the epel-release repository: 389-Directory/1.4.3.231 B2021.322.1803 in combination with correcting our local and global policies such that they were no longer conflicting. We basically removed the local policies, set the global policy, and setup a single local policy exception for the global policy.
David Mak (Pronouns: He/Him/His) Identity Services Specialist Information Technology Services Northeastern University
389-users@lists.fedoraproject.org