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#s... and https://www.openldap.org/software/man.cgi?query=slapo-ppolicy&sektion=5&...
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
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
--On Thursday, February 17, 2022 11:20 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
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"?
Yes, it's compiled into slapd. see servers/slapd/schema_prep.c:
{ "userPassword", "( 2.5.4.35 NAME 'userPassword' " "DESC 'RFC4519/2307: password of user' " "EQUALITY octetStringMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )",
--Quanah
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 17.02.2022 um 18:19
in Nachricht <49ADC11B5FB3A8060B8AC3C5@[192.168.1.12]>:
‑‑On Thursday, February 17, 2022 11:20 AM +0100 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
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"?
Yes, it's compiled into slapd. see servers/slapd/schema_prep.c:
{ "userPassword", "( 2.5.4.35 NAME 'userPassword' " "DESC 'RFC4519/2307: password of user' " "EQUALITY octetStringMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )",
But I should be able to query it, right? If so what is the correct filter expression?
Regards, Ulrich
‑‑Quanah
--On Friday, February 18, 2022 9:03 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
But I should be able to query it, right? If so what is the correct filter expression?
Yes, if you query the right place. I.e., cn=subschema:
ldapsearch ... -s base -b "cn=subschema" +
Regards, Quanah
Hi Quanah, let me ask again about this topic issue, any idea if anything is going to be fixed, changed or just kept as it is about the ability of adding another userPassword value (considering the ppolicy overlay has been activated) ?
Best regards,
Frédéric Dussurget / Maxime Schmutz Université Lumière Lyon 2
-----Message d'origine----- De : Quanah Gibson-Mount quanah@fast-mail.org Envoyé : vendredi 18 février 2022 22:37 À : Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de; openldap-technical@openldap.org; Frederic Dussurget frederic.dussurget@univ-lyon2.fr Objet : Re: Antw: [EXT] Problem with ppolicy overlay and userPassword attribute
--On Friday, February 18, 2022 9:03 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
But I should be able to query it, right? If so what is the correct filter expression?
Yes, if you query the right place. I.e., cn=subschema:
ldapsearch ... -s base -b "cn=subschema" +
Regards, Quanah
--On Monday, February 21, 2022 4:54 PM +0000 Frederic Dussurget frederic.dussurget@univ-lyon2.fr wrote:
Hi Quanah, let me ask again about this topic issue, any idea if anything is going to be fixed, changed or just kept as it is about the ability of adding another userPassword value (considering the ppolicy overlay has been activated) ?
Is what going to be fixed?
The LDAP RFC's mandate multi-valued userPassword be possible. It's not possible for ppolicy to function in that manner, so if using ppolicy it must be treated as single value.
Regards, Quanah
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 18.02.2022 um 22:37
in Nachricht <8A1ED4C1E941394D45838C24@[192.168.1.12]>:
‑‑On Friday, February 18, 2022 9:03 AM +0100 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
But I should be able to query it, right? If so what is the correct filter expression?
Yes, if you query the right place. I.e., cn=subschema:
ldapsearch ... ‑s base ‑b "cn=subschema" +
When I try that I get "No such object", and when I try "cn=schema,cn=config" with "(olcAttributeTypes=*)" and "sub" I see cn=schema,cn=config cn={0}core,cn=schema,cn=config cn={1}cosine,cn=schema,cn=config ... cn={6}sudo,cn=schema,cn=config
but no userPassword anywhere. That's why I was asking. Or is it available only recently?
However the string is in the binary: # strings /usr/lib/openldap/slapd |grep userPass ( 2.5.4.35 NAME 'userPassword' DESC 'RFC4519/2307: password of user' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
Regards, Ulrich
Regards, Quanah
--On Tuesday, February 22, 2022 12:44 PM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 18.02.2022 um 22:37
in Nachricht <8A1ED4C1E941394D45838C24@[192.168.1.12]>:
‑‑On Friday, February 18, 2022 9:03 AM +0100 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
But I should be able to query it, right? If so what is the correct filter expression?
Yes, if you query the right place. I.e., cn=subschema:
ldapsearch ... ‑s base ‑b "cn=subschema" +
When I try that I get "No such object", and when I try
Then you used a bind identity that doesn't have access to cn=subschema. Generally it is advised that cn=subschema should be readable by anyone.
--Quanah
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 22.02.2022 um 17:49
in Nachricht <6D8946CEFE1406A76522A36F@[192.168.1.12]>:
--On Tuesday, February 22, 2022 12:44 PM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 18.02.2022 um 22:37
in Nachricht <8A1ED4C1E941394D45838C24@[192.168.1.12]>:
‑‑On Friday, February 18, 2022 9:03 AM +0100 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
But I should be able to query it, right? If so what is the correct filter expression?
Yes, if you query the right place. I.e., cn=subschema:
ldapsearch ... ‑s base ‑b "cn=subschema" +
When I try that I get "No such object", and when I try
Then you used a bind identity that doesn't have access to cn=subschema. Generally it is advised that cn=subschema should be readable by anyone.
I have this in "dn: olcDatabase={-1}frontend,cn=config": olcAccess: {0}to dn.exact="" by * read olcAccess: {1}to dn.base="cn=Subschema" by * read
Shouldn't that do?
--Quanah
--On Wednesday, February 23, 2022 8:25 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Yes, if you query the right place. I.e., cn=subschema:
ldapsearch ... ‑s base ‑b "cn=subschema" +
When I try that I get "No such object", and when I try
Then you used a bind identity that doesn't have access to cn=subschema. Generally it is advised that cn=subschema should be readable by anyone.
I have this in "dn: olcDatabase={-1}frontend,cn=config": olcAccess: {0}to dn.exact="" by * read olcAccess: {1}to dn.base="cn=Subschema" by * read
Shouldn't that do?
Generally yes, but your stated results would indicate otherwise.
--Quanah
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 23.02.2022 um 17:46
in Nachricht <930DB73AD6C9D8388B3A80F5@[192.168.1.12]>:
--On Wednesday, February 23, 2022 8:25 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Yes, if you query the right place. I.e., cn=subschema:
ldapsearch ... ‑s base ‑b "cn=subschema" +
When I try that I get "No such object", and when I try
Then you used a bind identity that doesn't have access to cn=subschema. Generally it is advised that cn=subschema should be readable by anyone.
I have this in "dn: olcDatabase={-1}frontend,cn=config": olcAccess: {0}to dn.exact="" by * read olcAccess: {1}to dn.base="cn=Subschema" by * read
Shouldn't that do?
Generally yes, but your stated results would indicate otherwise.
I don't get it: The ACL is there, and the subschema seems to be there, but I cannot find it. In Perl the root_dse indicates: ... 6 HASH(0x2d49578) 'type' => 'subschemaSubentry' 'vals' => ARRAY(0x2d49800) 0 'cn=Subschema' ...
So it seems to be there. Likewise when I diesplay the "schema" entry I get: 'userpassword' => HASH(0x2e483b0) 'aliases' => ARRAY(0x2e48440) empty array 'desc' => 'RFC4519/2307: password of user' 'equality' => 'octetStringMatch' 'max_length' => 128 'name' => 'userPassword' 'oid' => '2.5.4.35' 'syntax' => '1.3.6.1.4.1.1466.115.121.1.40' 'type' => 'at'
So my guess is that my query is still wrong: # ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=Subschema' -s sub '(objectClass=*)' '* +' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <cn=Subschema> with scope subtree # filter: (objectClass=*) # requesting: * + #
# search result search: 2 result: 32 No such object
# numResponses: 1 ------------------
Regards, Ulrich
--On Thursday, February 24, 2022 8:22 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
So my guess is that my query is still wrong: # ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=Subschema' -s sub '(objectClass=*)' '* +'
Why did you use -s sub? I clearly used -s base in my example I provided you.
Additionally, '* +' is invalid. It should be:
'*' '+'
--Quanah
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 24.02.2022 um 16:41
in Nachricht <5634EEEFC927B18BF1B59D49@[192.168.1.12]>:
‑‑On Thursday, February 24, 2022 8:22 AM +0100 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
So my guess is that my query is still wrong: # ldapsearch ‑Y EXTERNAL ‑H ldapi:/// ‑b 'cn=Subschema' ‑s sub '(objectClass=*)' '* +'
Why did you use ‑s sub? I clearly used ‑s base in my example I provided
you.
Additionally, '* +' is invalid. It should be:
'*' '+'
OK, I thought ("<=" meaning subset relation) that "base <= one <= sub", but it seems "base < one <= sub" instead. And I mixed up the syntax for attributes as well.
So I found userPassword, but I had to use a vcombination of ldapsearch and grep like this: ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=Subschema' -s base '(attributeTypes=*)' '+' |grep userPassword
What I don't understand is that for
ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=Subschema' -s base '(olcSchemaConfig=*)' 'attributeTypes'
I get no results:
# search result search: 2 result: 0 Success
Is there a filter to get the definition for userPassword specifically?
Regards, Ulrich
‑‑Quanah
--On Monday, February 28, 2022 8:01 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=Subschema' -s base '(olcSchemaConfig=*)' 'attributeTypes'
olcSchemaConfig is not a valid objectClass to filter on for cn=subschema
--Quanah
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 28.02.2022 um 18:13
in Nachricht <E3CC2CA46714326DFC9DA9F8@[192.168.1.12]>:
‑‑On Monday, February 28, 2022 8:01 AM +0100 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
ldapsearch ‑Y EXTERNAL ‑H ldapi:/// ‑b 'cn=Subschema' ‑s base '(olcSchemaConfig=*)' 'attributeTypes'
olcSchemaConfig is not a valid objectClass to filter on for cn=subschema
Yes, I know many ways how _not_ to do it; insted I was hoping the other way 'round ;-)
‑‑Quanah
openldap-technical@openldap.org
-
Frederic Dussurget -
Quanah Gibson-Mount -
Ulrich Windl