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&apropos=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
[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
DWmlzQk1IVEhWczRMZyRsMVAvbWdEdTA1bEpBc2pxcVF6aERYaENMV1BudnQyeDlRTDdweXFnVDFV
userPassword:: e0FSR09OMn0kYXJnb24yaWQkdj0xOSRtPTY1NTM2LHQ9MixwPTEkVk5ST1FMZFp
2Q0ptajNIcHQxYWtZdyRRcjJDYUpKSjZSWlhvZjFicDJmNGNOaGlRa3E5czlCU0FTbEtVNFoxYjBj
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
