Frederic Dussurget frederic.dussurget@univ-lyon2.fr schrieb am 16.02.2022
um 14:53 in Nachricht ec3544578b4c4fa19c2cc61376d304af@univ-lyon2.fr:
Hi, We're facing the following issue :
- From one side, we have to store two values (same password with two
different encodings) within the userPassword attribute (eg. https://datatracker.ietf.org/doc/html/rfc4519#section%E2%80%912.41)
- On the other side, we do have to use the ppolicy overlay in order to
hash to Argon2 automatically passwords that are sent in cleartext, in order
to to use the pwdLastSuccess attribute (storing last authentication date)
and
pwdAccountLockedTime (account deactivation), but this overlay does not seem
to support multiple values in the userPassword attribute as it looks to be described in the following abstract :
https://datatracker.ietf.org/doc/html/draft%E2%80%91behera%E2%80%91ldap%E2%8...
3 and https://www.openldap.org/software/man.cgi?query=slapo%E2%80%91ppolicy&se...
pos=0&manpath=OpenLDAP+2.5‑Release
We're not able to add a user account with two values in the userPassword attribute : [root@openldap25 ~]# cat testuser_add.ldif dn: uid=testuser,ou=people,dc=my‑domain,dc=fr objectClass: person objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: top uid: testuser cn: testuserCN sn: testuserSN userPassword: password userPassword: drowssap
Interestingly I found that userPassword is commented out in core.schema, and the commented-out entry does not have "single-value". Also I couldn't find it when querying cn=schema,cn=config on my server. Is it "special"?
[root@openldap25 ~]# ldapadd ‑H ldaps://localhost:636 ‑x ‑D "cn=Manager,dc=my‑domain,dc=fr" ‑W ‑f testuser_add.ldif Enter LDAP Password: adding new entry "uid=testuser,ou=people,dc=my‑domain,dc=fr" ldap_add: Constraint violation (19) additional info: Password policy only allows one password value
However, we're able to add a user with a single value in the userPassword attribute, then, adding a second value thru the next LDAP request :
[root@openldap25 ~]# cat testuser_add.ldif dn: uid=testuser,ou=people,dc=my‑domain,dc=fr objectClass: person objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: top uid: testuser cn: testuserCN sn: testuserSN userPassword : password
[root@openldap25 ~]# ldapadd ‑H ldaps://localhost:636 ‑x ‑D "cn=Manager,dc=my‑domain,dc=fr" ‑W ‑f testuser_add.ldif Enter LDAP Password: adding new entry "uid=testuser,ou=people,dc=my‑domain,dc=fr"
[root@openldap25 ~]# cat testuser_mod.ldif dn: uid=testuser,ou=people,dc=my‑domain,dc=fr changetype: modify add: userPassword userPassword: drowssap
[root@openldap25 ~]# ldapmodify ‑H ldaps://localhost:636 ‑x ‑D "cn=Manager,dc=my‑domain,dc=fr" ‑W ‑f testuser_mod.ldif Enter LDAP Password: modifying entry "uid=testuser,ou=people,dc=my‑domain,dc=fr"
[root@openldap25 ~]# ldapsearch ‑x ‑H ldaps://localhost:636 ‑D "cn=Manager,dc=my‑domain,dc=fr" ‑W ‑LLL ‑b "ou=people,dc=my‑domain,dc=fr" "(uid=testuser)" userPassword Enter LDAP Password: dn: uid=testuser,ou=people,dc=my‑domain,dc=fr userPassword:: e0FSR09OMn0kYXJnb24yaWQkdj0xOSRtPTY1NTM2LHQ9MixwPTEkZjlPc3NtRFZ
DWmlzQk1IVEhWczRMZyRsMVAvbWdEdTA1bEpBc2pxcVF6aERYaENMV1BudnQyeDlRTDdweXFnVDF
V userPassword:: e0FSR09OMn0kYXJnb24yaWQkdj0xOSRtPTY1NTM2LHQ9MixwPTEkVk5ST1FMZFp
2Q0ptajNIcHQxYWtZdyRRcjJDYUpKSjZSWlhvZjFicDJmNGNOaGlRa3E5czlCU0FTbEtVNFoxYjB
j
Considering configuration, we're running an OpenLDAP 2.5.7 server (LTB project) on a RHEL8 OS.
- ppolicy overlay
dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: FALSE olcPPolicyForwardUpdates: FALSE olcPPolicyDisableWrite: FALSE olcPPolicySendNetscapeControls: FALSE olcPPolicyDefault: cn=default,ou=ppolicies,dc=my‑domain,dc=fr
- default password policy
dn: ou=ppolicies,dc=my‑domain,dc=fr objectClass: organizationalUnit objectClass: top ou: ppolicies
dn: cn=default,ou=ppolicies,dc=my‑domain,dc=fr objectClass: pwdPolicy objectClass: organizationalRole cn: default pwdAttribute: userPassword pwdLockout: TRUE
- password storage
dn: olcDatabase={‑1}frontend,cn=config olcPasswordHash: {ARGON2}
Question :
- Is that behaviour normal ?
- May we keep on leaning on this behaviour without fearing that this
ability of adding a second value to the userPassword attribute will be revoked in the future versions/fix/patches of the service ?
Thank you in advance for your assistance.
Best regards,
Frédéric Dussurget / Maxime Schmutz Université Lumière Lyon 2