passwordExpirationTime vs password admin

[Mike Wohlgemuth]

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!

[Mark Reynolds]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- 
Directory Server Development Team

[Mike Wohlgemuth]

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!

[Mike Wohlgemuth]

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!

[Mark Reynolds]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- 
Directory Server Development Team

[Mike Wohlgemuth]

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

[Mark Reynolds]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- 
Directory Server Development Team

[Mak, David]

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