>>> Frederic Dussurget <[email protected]> schrieb am 16.02.2022 um 14:53 in Nachricht <[email protected]>: > 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‑2.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‑behera‑ldap‑password‑policy‑10#section‑ > 3 and > https://www.openldap.org/software/man.cgi?query=slapo‑ppolicy&sektion=5&apro > 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
