Dear openldap-technical users,
my password policies (openldap 2.5.11) are not enforced and Roland Gruber (author of LAM (Pro)) kindly advised me that passwords must be stored in plaintext (Hash=PLAIN) in order to be able to enforce password minimal length, password quality etc (i.e. when using passwd(1) on Linux or an LDAP client on Windows).
Currently we are storing passwords as base64 encoded (::*) Salted SHA1 hashes ("{SSHA}*") (according to slapcat -n 1).
tl;dr: For enforcing password policies, what is the role of "password-hash:PLAIN"(?) and olcPPolicyHashCleartext: TRUE (applied to dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config) and what is the security implication of these changes (we are using starttls on linux / ssl on windows with a self-signed certificate in intranet)?
- Is it (necessary and) enough to switch to "password-hash:PLAIN" to be able to enforce password policies? Does olcPPolicyHashCleartext: TRUE [alone] help as written in this post [1]?
[1] https://www.openldap.org/lists/openldap-technical/201708/msg00024.html
EDIT: I think that olcPPolicyHashCleartext==ppolicy_hash_cleartext (one is OLC, one is trad. config)? -> can we update the documentation [2]?
[2] https://www.openldap.org/doc/admin25/guide.html#Password%20Policies
- I am worried about security when storing/transferring pwds in plain text (we are using starttls on linux / ssl on windows with a self-signed certificate in intranet) [3]. Will "ppolicy_hash_cleartext" [2] help with this?
[3] The manual states "Unfortunately, as dictionary and brute force attacks are generally quite easy for attackers to successfully mount, this advantage is marginal at best (this is why all modern Unix systems use shadow password files)."
Many Thanks and Best Regards, Felix -- Felix Natter
On 2/20/22 18:14, Felix Natter wrote:
my password policies (openldap 2.5.11) are not enforced and Roland Gruber (author of LAM (Pro)) kindly advised me that passwords must be stored in plaintext (Hash=PLAIN) in order to be able to enforce password minimal length, password quality etc (i.e. when using passwd(1) on Linux or an LDAP client on Windows).
Nope. That sounds like misleading advice, or it's a misunderstanding on your side.
1. The LDAP client should support setting new password via LDAP Modify Password extended operation
or
2. as you already found out yourself you can use
olcPPolicyHashCleartext: TRUE
if the LDAP client sends a MODIFY operation with a clear-text userPassword value.
Both options will let slapd hash the password according to the setting of password-hash (slapd.conf) / olcPasswordHash (cn=config).
Processing simple bind requests are not affected by these settings. Existing password hashes will not be altered.
[3] The manual states "Unfortunately, as dictionary and brute force attacks are generally quite easy for attackers to successfully mount, this advantage is marginal at best (this is why all modern Unix systems use shadow password files)."
Well, this all is debatable.
1. Implement decent ACLs which forbids any read access to all LDAP clients (except replicas).
2. Choose a decent hash algorithm, especially understand the parameters. Recent OpenLDAP support {ARGON2} out-of-the-box. Note that choosing the right parameters is trading performance with security. ARGON2 is called "memory-hard" and you should take this literally.
For inspiration read the comments and examples here:
https://code.stroeder.com/AE-DIR/ansible-ae-dir-server/src/branch/main/defau...
Ciao, Michael.
hello Michael,
many thanks for your reply!
Michael Ströder michael@stroeder.com writes:
On 2/20/22 18:14, Felix Natter wrote:
my password policies (openldap 2.5.11) are not enforced and Roland Gruber (author of LAM (Pro)) kindly advised me that passwords must be stored in plaintext (Hash=PLAIN) in order to be able to enforce password minimal length, password quality etc (i.e. when using passwd(1) on Linux or an LDAP client on Windows).
Nope. That sounds like misleading advice, or it's a misunderstanding on your side.
- The LDAP client should support setting new password via LDAP Modify
Password extended operation
I tried with passwd(1), which currently ignores the ppolicy. Does this mean it does not support an LDAP Modify Password *extended* operation? If not, can I enable it?
or
- as you already found out yourself you can use
olcPPolicyHashCleartext: TRUE
if the LDAP client sends a MODIFY operation with a clear-text userPassword value.
Both options will let slapd hash the password according to the setting of password-hash (slapd.conf) / olcPasswordHash (cn=config).
Now I added olcPPolicyHashCleartext: TRUE to the ppolicy overlay:
dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config changetype: modify add: olcPPolicyHashCleartext olcPPolicyHashCleartext: TRUE
sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f ppolicyoverlay2.ldif modifying entry "olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config"
It now looks like this: dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=sidact,dc=com structuralObjectClass: olcPPolicyConfig entryUUID: <uuid> creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20220215121841Z olcPPolicyHashCleartext: TRUE entryCSN: 20220222113122.616521Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20220222113122Z
But still, the password policy is not enforced with passwd(1).
Processing simple bind requests are not affected by these settings.
Bind request means login request, as opposed to password change request?
Existing password hashes will not be altered.
Yes, I read that ppolicies only work if the password is changed or expires.
Could you please advise how to enforce the PP?
[3] The manual states "Unfortunately, as dictionary and brute force attacks are generally quite easy for attackers to successfully mount, this advantage is marginal at best (this is why all modern Unix systems use shadow password files)."
Well, this all is debatable.
- Implement decent ACLs which forbids any read access to all LDAP clients
(except replicas).
- Choose a decent hash algorithm, especially understand the
parameters. Recent OpenLDAP support {ARGON2} out-of-the-box. Note that choosing the right parameters is trading performance with security. ARGON2 is called "memory-hard" and you should take this literally.
For inspiration read the comments and examples here:
https://code.stroeder.com/AE-DIR/ansible-ae-dir-server/src/branch/main/defau...
Ok, thanks.
Many Thanks and Best Regards, Felix
On 2/22/22 19:00, Felix Natter wrote:
- The LDAP client should support setting new password via LDAP
Modify Password extended operation >
I tried with passwd(1), which currently ignores the ppolicy. Does this mean it does not support an LDAP Modify Password *extended* operation? If not, can I enable it?
passwd(1) is not even an LDAP client.
ldappasswd(1) is the right tool for the command-line but takes a DN to specify the user's entry.
But for various reasons I usually disallow changing passwords from an arbitrary system. I'd recommend to force users to use a decent central password self-service web app.
Now I added olcPPolicyHashCleartext: TRUE to the ppolicy overlay: [..] But still, the password policy is not enforced with passwd(1).
passwd(1) should not even cause an LDAP modify operation to reach your OpenLDAP server. Just in case you've added shadow: ldap in your nsswitch.conf then remove that immediately because it's an ancient insecure concept.
Processing simple bind requests are not affected by these settings.
Bind request means login request, as opposed to password change request?
Sorry for the nitpicking but the term "login request" is blurry:
"Simple bind request" means literally a simple bind request as described in RFC 4511:
https://datatracker.ietf.org/doc/html/rfc4511#section-4.2
This simple bind operation is used by NSS/PAM integration components like nss-pam-ldapd or sssd (or my own aehostd for Æ-DIR) to let the PAM stack check the user's password. Maybe this is what you call a "login request".
Could you please advise how to enforce the PP?
I already did. You have to use the right software.
Ciao, Michael.
hello Michael,
thanks for the explanations.
Michael Ströder michael@stroeder.com writes:
On 2/22/22 19:00, Felix Natter wrote:
- The LDAP client should support setting new password via LDAP
Modify Password extended operation >
I tried with passwd(1), which currently ignores the ppolicy. Does this mean it does not support an LDAP Modify Password *extended* operation? If not, can I enable it?
passwd(1) is not even an LDAP client.
ldappasswd(1) is the right tool for the command-line but takes a DN to specify the user's entry.
I tried this (which would be fine as a solution):
ldappasswd -H ldap://<ip> -x -D \ cn=ldaptestuser1,ou=users,dc=company,dc=com -W -A -S
but it does not enforce the pwdMinLength:3 restriction of the PP.
But for various reasons I usually disallow changing passwords from an arbitrary system. I'd recommend to force users to use a decent central password self-service web app.
I will look at whether it can be done with LAMPro.
Now I added olcPPolicyHashCleartext: TRUE to the ppolicy overlay: [..] But still, the password policy is not enforced with passwd(1).
passwd(1) should not even cause an LDAP modify operation to reach your OpenLDAP server. Just in case you've added shadow: ldap in your nsswitch.conf then remove that immediately because it's an ancient insecure concept.
Processing simple bind requests are not affected by these settings.
Bind request means login request, as opposed to password change request?
Sorry for the nitpicking but the term "login request" is blurry:
"Simple bind request" means literally a simple bind request as described in RFC 4511:
https://datatracker.ietf.org/doc/html/rfc4511#section-4.2
This simple bind operation is used by NSS/PAM integration components like nss-pam-ldapd or sssd (or my own aehostd for Æ-DIR) to let the PAM stack check the user's password. Maybe this is what you call a "login request".
Could you please advise how to enforce the PP?
I already did. You have to use the right software.
Agreed.
Thanks and Best Regards,
On 2/23/22 22:02, Felix Natter wrote:
ldappasswd(1) is the right tool for the command-line but takes a DN to specify the user's entry.
I tried this (which would be fine as a solution):
ldappasswd -H ldap://<ip> -x -D \ cn=ldaptestuser1,ou=users,dc=company,dc=com -W -A -S
but it does not enforce the pwdMinLength:3 restriction of the PP.
It works for me:
xkcd@ae-dir-suse-p1:~> ldappasswd uid=aacj,cn=test,ou=ae-dir -s 123 Result: Constraint violation (19) Additional info: Password fails quality checking policy
xkcd@ae-dir-suse-p1:~> ldappasswd uid=aacj,cn=test,ou=ae-dir -s Geheimer123456789
xkcd@ae-dir-suse-p1:~> ldapwhoami -x -D uid=aacj,cn=test,ou=ae-dir -w Geheimer123456789 dn:uid=aacj,cn=test,ou=ae-dir
Are you sure your pwdPolicy entry is applied, and e.g. has pwdCheckQuality: 2?
Ciao, Michael.
hi Michael,
many thanks for the help!
Michael Ströder michael@stroeder.com writes:
On 2/23/22 22:02, Felix Natter wrote:
ldappasswd(1) is the right tool for the command-line but takes a DN to specify the user's entry.
I tried this (which would be fine as a solution): ldappasswd -H ldap://<ip> -x -D \ cn=ldaptestuser1,ou=users,dc=company,dc=com -W -A -S but it does not enforce the pwdMinLength:3 restriction of the PP.
It works for me:
xkcd@ae-dir-suse-p1:~> ldappasswd uid=aacj,cn=test,ou=ae-dir -s 123 Result: Constraint violation (19) Additional info: Password fails quality checking policy
xkcd@ae-dir-suse-p1:~> ldappasswd uid=aacj,cn=test,ou=ae-dir -s Geheimer123456789
xkcd@ae-dir-suse-p1:~> ldapwhoami -x -D uid=aacj,cn=test,ou=ae-dir -w Geheimer123456789 dn:uid=aacj,cn=test,ou=ae-dir
Are you sure your pwdPolicy entry is applied, and e.g. has pwdCheckQuality: 2?
Indeed, I was setting this to 0 :-/ I assumed that since it has "quality" in the name, that it is only for the "pqchecker.so" invocatation!
Now it works, and I'm pretty sure I did not need any changes on the client(s).
For the record: - the passwords are still hashed on the server - it most probably works thanks to "olcPPolicyHashCleartext: TRUE" in the ppolicy overlay (OLC!) - encryption is mandatory
Again, Many Thanks and Best Regards! Felix
Felix Natter fnatter@gmx.net schrieb am 22.02.2022 um 19:00 in Nachricht
87h78qlr1i.fsf@bitburger.home.felix:
hello Michael,
many thanks for your reply!
Michael Ströder michael@stroeder.com writes:
On 2/20/22 18:14, Felix Natter wrote:
my password policies (openldap 2.5.11) are not enforced and Roland Gruber (author of LAM (Pro)) kindly advised me that passwords must be stored in plaintext (Hash=PLAIN) in order to be able to enforce password minimal length, password quality etc (i.e. when using passwd(1) on Linux or an LDAP client on Windows).
Nope. That sounds like misleading advice, or it's a misunderstanding on your side.
- The LDAP client should support setting new password via LDAP Modify
Password extended operation
I tried with passwd(1), which currently ignores the ppolicy. Does this mean it does not support an LDAP Modify Password *extended* operation? If not, can I enable it?
I have these lines in /etc/ldap.conf (and it works): # Search the root DSE for the password policy (works # with Netscape Directory Server). Make use of # Password Policy LDAP Control (as in OpenLDAP) pam_lookup_policy yes ... # Use the OpenLDAP password change # extended operation to update the password. pam_password exop ...
or
- as you already found out yourself you can use
olcPPolicyHashCleartext: TRUE
if the LDAP client sends a MODIFY operation with a clear-text userPassword value.
Both options will let slapd hash the password according to the setting of password-hash (slapd.conf) / olcPasswordHash (cn=config).
Now I added olcPPolicyHashCleartext: TRUE to the ppolicy overlay:
dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config changetype: modify add: olcPPolicyHashCleartext olcPPolicyHashCleartext: TRUE
sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f ppolicyoverlay2.ldif modifying entry "olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config"
It now looks like this: dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=sidact,dc=com structuralObjectClass: olcPPolicyConfig entryUUID: <uuid> creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20220215121841Z olcPPolicyHashCleartext: TRUE entryCSN: 20220222113122.616521Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20220222113122Z
But still, the password policy is not enforced with passwd(1).
Processing simple bind requests are not affected by these settings.
Bind request means login request, as opposed to password change request?
Existing password hashes will not be altered.
Yes, I read that ppolicies only work if the password is changed or expires.
Could you please advise how to enforce the PP?
[3] The manual states "Unfortunately, as dictionary and brute force attacks are generally quite easy for attackers to successfully mount, this advantage is marginal at best (this is why all modern Unix systems use shadow password files)."
Well, this all is debatable.
- Implement decent ACLs which forbids any read access to all LDAP clients
(except replicas).
- Choose a decent hash algorithm, especially understand the
parameters. Recent OpenLDAP support {ARGON2} out-of-the-box. Note that choosing the right parameters is trading performance with security. ARGON2 is called "memory-hard" and you should take this literally.
For inspiration read the comments and examples here:
https://code.stroeder.com/AE-DIR/ansible-ae-dir-server/src/branch/main/defau...
ts/main.yml#L712
Ok, thanks.
Many Thanks and Best Regards, Felix -- Felix Natter
hello Ulrich,
thanks for your reply! My replies are inline:
"Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de writes:
Felix Natter fnatter@gmx.net schrieb am 22.02.2022 um 19:00 in Nachr=
icht
87h78qlr1i.fsf@bitburger.home.felix:
hello Michael, =20 many thanks for your reply! =20 Michael Str=C3=B6der michael@stroeder.com writes:
On 2/20/22 18:14, Felix Natter wrote:
my password policies (openldap 2.5.11) are not enforced and Roland Gruber (author of LAM (Pro)) kindly advised me that passwords must be stored in plaintext (Hash=3DPLAIN) in order to be able to enforce pass=
word
minimal length, password quality etc (i.e. when using passwd(1) on Lin=
ux
or an LDAP client on Windows).
Nope. That sounds like misleading advice, or it's a misunderstanding on your side.
- The LDAP client should support setting new password via LDAP Modify
Password extended operation
=20 I tried with passwd(1), which currently ignores the ppolicy. Does this mean it does not support an LDAP Modify Password *extended* operation? If not, can I enable it?
I have these lines in /etc/ldap.conf (and it works): # Search the root DSE for the password policy (works # with Netscape Directory Server). Make use of # Password Policy LDAP Control (as in OpenLDAP) pam_lookup_policy yes ... # Use the OpenLDAP password change # extended operation to update the password. pam_password exop ...
This is on the client, right?
I tried putting the two above options in /etc/openldap/ldap.conf, rebooted, but no change. Also man ldap.conf does not mention them.
Which OS do you use?
I can find a file with this syntax on Redhat6: /etc/pam_ldap.conf. On Redhat7 (my case), it seems to have been replaced with /etc/nslcd.conf (different syntax) where I could only find this option:
pam_authc_ppolicy yes|no "This option specifies whether password policy controls are requested and handled from the LDAP server when performing user authentication"
Could the password modify extended operation be enabled by default (on Redhat7) and the problem lies elsewhere?
This is supported by the following test with ldappasswd:
ldappasswd -H ldap://<ip> -x -D \ cn=3Dldaptestuser1,ou=3Dusers,dc=3Dcompany,dc=3Dcom -W -A -S
also bypasses the policy's minimal length restriction (pwdMinLength: 3; that is the only PPolicy field that is defined)
According to the man page, this "uses the LDAPv3 Password Modify (RFC 3062) extended operation". Does this mean that password policies are not correctly set up on the server? How can I debug this?
Many Thanks and Best Regards, Felix Natter
=20
or
- as you already found out yourself you can use
olcPPolicyHashCleartext: TRUE
if the LDAP client sends a MODIFY operation with a clear-text userPassw=
ord
value.
Both options will let slapd hash the password according to the setting =
of
password-hash (slapd.conf) / olcPasswordHash (cn=3Dconfig).
=20 Now I added olcPPolicyHashCleartext: TRUE to the ppolicy overlay: =20 dn: olcOverlay=3D{0}ppolicy,olcDatabase=3D{1}mdb,cn=3Dconfig changetype: modify add: olcPPolicyHashCleartext olcPPolicyHashCleartext: TRUE =20 sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f ppolicyoverlay2.ldif modifying entry "olcOverlay=3D{0}ppolicy,olcDatabase=3D{1}mdb,cn=3Dconfi=
g"
=20 It now looks like this: dn: olcOverlay=3D{0}ppolicy,olcDatabase=3D{1}mdb,cn=3Dconfig objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyDefault: cn=3Ddefault,ou=3Dpolicies,dc=3Dsidact,dc=3Dcom structuralObjectClass: olcPPolicyConfig entryUUID: <uuid> creatorsName: gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dexternal,cn=
=3Dauth
createTimestamp: 20220215121841Z olcPPolicyHashCleartext: TRUE entryCSN: 20220222113122.616521Z#000000#000#000000 modifiersName: gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dexternal,c=
n=3Dauth
modifyTimestamp: 20220222113122Z =20 But still, the password policy is not enforced with passwd(1). =20
Processing simple bind requests are not affected by these settings.=20
=20 Bind request means login request, as opposed to password change request? =20
Existing password hashes will not be altered.
=20 Yes, I read that ppolicies only work if the password is changed or expires. =20 Could you please advise how to enforce the PP? =20
[3] The manual states "Unfortunately, as dictionary and brute force attacks are generally quite easy for attackers to successfully mount, this advantage is marginal at best (this is why all modern Unix systems use shadow password files)."
Well, this all is debatable.
- Implement decent ACLs which forbids any read access to all LDAP clie=
nts
(except replicas).
- Choose a decent hash algorithm, especially understand the
parameters. Recent OpenLDAP support {ARGON2} out-of-the-box. Note that choosing the right parameters is trading performance with security. ARG=
ON2
is called "memory-hard" and you should take this literally.
For inspiration read the comments and examples here:
=20
https://code.stroeder.com/AE-DIR/ansible-ae-dir-server/src/branch/main/de=
faul
ts/main.yml#L712 =20 Ok, thanks. =20 Many Thanks and Best Regards, Felix --=20 Felix Natter
--=20 Felix Natter debian/rules!
Felix Natter fnatter@gmx.net schrieb am 23.02.2022 um 21:45 in Nachricht
87wnhl9uru.fsf@bitburger.home.felix:
hello Ulrich,
thanks for your reply! My replies are inline:
"Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de writes:
Felix Natter fnatter@gmx.net schrieb am 22.02.2022 um 19:00 in Nachr=
icht
87h78qlr1i.fsf@bitburger.home.felix:
hello Michael, =20 many thanks for your reply! =20 Michael Str=C3=B6der michael@stroeder.com writes:
On 2/20/22 18:14, Felix Natter wrote:
my password policies (openldap 2.5.11) are not enforced and Roland Gruber (author of LAM (Pro)) kindly advised me that passwords must be stored in plaintext (Hash=3DPLAIN) in order to be able to enforce pass=
word
minimal length, password quality etc (i.e. when using passwd(1) on Lin=
ux
or an LDAP client on Windows).
Nope. That sounds like misleading advice, or it's a misunderstanding on your side.
- The LDAP client should support setting new password via LDAP Modify
Password extended operation
=20 I tried with passwd(1), which currently ignores the ppolicy. Does this mean it does not support an LDAP Modify Password *extended* operation? If not, can I enable it?
I have these lines in /etc/ldap.conf (and it works): # Search the root DSE for the password policy (works # with Netscape Directory Server). Make use of # Password Policy LDAP Control (as in OpenLDAP) pam_lookup_policy yes ... # Use the OpenLDAP password change # extended operation to update the password. pam_password exop ...
This is on the client, right?
Yes!
I tried putting the two above options in /etc/openldap/ldap.conf, rebooted, but no change. Also man ldap.conf does not mention them.
As the "pam_" prefix might indicate, try "man pam_ldap" instead.
... Features of the PADL pam_ldap module include support for transport layer security, SASL authentication, directory server-enforced password policy, and host- and group- based logon authorization. ... pam_lookup_policy <yes|no> Specifies whether to search the root DSE for password policy. The default is "no". ...
Which OS do you use?
SLES 12 SP5
I also have: # grep ldap /etc/nsswitch.conf group: files ldap services: files ldap netgroup: files ldap aliases: files ldap passwd_compat: ldap
and
/etc/pam.d # cat login #%PAM-1.0 auth requisite pam_nologin.so auth [user_unknown=ignore success=ok ignore=ignore auth_err=die default=bad]pam_securetty.so auth include common-auth account include common-account password include common-password session required pam_loginuid.so session include common-session session optional pam_lastlog.so nowtmp session optional pam_mail.so standard
Maybe this helps.
Regards, Ulrich
I can find a file with this syntax on Redhat6: /etc/pam_ldap.conf. On Redhat7 (my case), it seems to have been replaced with /etc/nslcd.conf (different syntax) where I could only find this option:
pam_authc_ppolicy yes|no "This option specifies whether password policy controls are requested and handled from the LDAP server when performing user authentication"
Could the password modify extended operation be enabled by default (on Redhat7) and the problem lies elsewhere?
This is supported by the following test with ldappasswd:
ldappasswd -H ldap://<ip> -x -D \ cn=3Dldaptestuser1,ou=3Dusers,dc=3Dcompany,dc=3Dcom -W -A -S
also bypasses the policy's minimal length restriction (pwdMinLength: 3; that is the only PPolicy field that is defined)
According to the man page, this "uses the LDAPv3 Password Modify (RFC 3062) extended operation". Does this mean that password policies are not correctly set up on the server? How can I debug this?
Many Thanks and Best Regards, Felix Natter
=20
or
- as you already found out yourself you can use
olcPPolicyHashCleartext: TRUE
if the LDAP client sends a MODIFY operation with a clear-text userPassw=
ord
value.
Both options will let slapd hash the password according to the setting =
of
password-hash (slapd.conf) / olcPasswordHash (cn=3Dconfig).
=20 Now I added olcPPolicyHashCleartext: TRUE to the ppolicy overlay: =20 dn: olcOverlay=3D{0}ppolicy,olcDatabase=3D{1}mdb,cn=3Dconfig changetype: modify add: olcPPolicyHashCleartext olcPPolicyHashCleartext: TRUE =20 sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f ppolicyoverlay2.ldif modifying entry "olcOverlay=3D{0}ppolicy,olcDatabase=3D{1}mdb,cn=3Dconfi=
g"
=20 It now looks like this: dn: olcOverlay=3D{0}ppolicy,olcDatabase=3D{1}mdb,cn=3Dconfig objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyDefault: cn=3Ddefault,ou=3Dpolicies,dc=3Dsidact,dc=3Dcom structuralObjectClass: olcPPolicyConfig entryUUID: <uuid> creatorsName: gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dexternal,cn=
=3Dauth
createTimestamp: 20220215121841Z olcPPolicyHashCleartext: TRUE entryCSN: 20220222113122.616521Z#000000#000#000000 modifiersName: gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dexternal,c=
n=3Dauth
modifyTimestamp: 20220222113122Z =20 But still, the password policy is not enforced with passwd(1). =20
Processing simple bind requests are not affected by these settings.=20
=20 Bind request means login request, as opposed to password change request? =20
Existing password hashes will not be altered.
=20 Yes, I read that ppolicies only work if the password is changed or expires. =20 Could you please advise how to enforce the PP? =20
[3] The manual states "Unfortunately, as dictionary and brute force attacks are generally quite easy for attackers to successfully mount, this advantage is marginal at best (this is why all modern Unix systems use shadow password files)."
Well, this all is debatable.
- Implement decent ACLs which forbids any read access to all LDAP clie=
nts
(except replicas).
- Choose a decent hash algorithm, especially understand the
parameters. Recent OpenLDAP support {ARGON2} out-of-the-box. Note that choosing the right parameters is trading performance with security. ARG=
ON2
is called "memory-hard" and you should take this literally.
For inspiration read the comments and examples here:
=20
https://code.stroeder.com/AE-DIR/ansible-ae-dir-server/src/branch/main/de=
faul
ts/main.yml#L712 =20 Ok, thanks. =20 Many Thanks and Best Regards, Felix --=20 Felix Natter
--=20 Felix Natter debian/rules!
On 2/24/22 08:37, Ulrich Windl wrote:
As the "pam_" prefix might indicate, try "man pam_ldap" instead. ... Features of the PADL pam_ldap
Note that there are two different pam_ldap modules out there:
1. The ancient unmaintained PADL modules which directly send LDAP operations and are generally *not recommended* to be used nowadays.
2. The small PAM front-end module of nss-pam-ldapd which pass PAM requests to a long-running aka nslcd over a Unix domain socket.
Basically when integrating NSS and PAM one has to choose which service to use for the integration: nss-pam-ldapd or sssd, both with their own NSS/PAM front-end modules.
Ciao, Michael.
P.S.: Yes, I have to admit I forgot in my former e-mail that passwd(1) sends password change requests via PAM. But I'd strongly recommend to not use that anyway.
hi Ulrich,
"Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de writes:
Felix Natter fnatter@gmx.net schrieb am 23.02.2022 um 21:45 in Nachricht
87wnhl9uru.fsf@bitburger.home.felix:
hello Ulrich,
thanks for your reply! My replies are inline:
"Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de writes:
Felix Natter fnatter@gmx.net schrieb am 22.02.2022 um 19:00 in Nachr=
icht
87h78qlr1i.fsf@bitburger.home.felix:
hello Michael, =20 many thanks for your reply! =20 Michael Str=C3=B6der michael@stroeder.com writes:
On 2/20/22 18:14, Felix Natter wrote:
my password policies (openldap 2.5.11) are not enforced and Roland Gruber (author of LAM (Pro)) kindly advised me that passwords must be stored in plaintext (Hash=3DPLAIN) in order to be able to enforce pass=
word
minimal length, password quality etc (i.e. when using passwd(1) on Lin=
ux
or an LDAP client on Windows).
Nope. That sounds like misleading advice, or it's a misunderstanding on your side.
- The LDAP client should support setting new password via LDAP Modify
Password extended operation
=20 I tried with passwd(1), which currently ignores the ppolicy. Does this mean it does not support an LDAP Modify Password *extended* operation? If not, can I enable it?
I have these lines in /etc/ldap.conf (and it works): # Search the root DSE for the password policy (works # with Netscape Directory Server). Make use of # Password Policy LDAP Control (as in OpenLDAP) pam_lookup_policy yes ... # Use the OpenLDAP password change # extended operation to update the password. pam_password exop ...
This is on the client, right?
Yes!
I tried putting the two above options in /etc/openldap/ldap.conf, rebooted, but no change. Also man ldap.conf does not mention them.
As the "pam_" prefix might indicate, try "man pam_ldap" instead.
... Features of the PADL pam_ldap module include support for transport layer security, SASL authentication, directory server-enforced password policy, and host- and group- based logon authorization. ... pam_lookup_policy <yes|no> Specifies whether to search the root DSE for password policy. The default is "no". ...
pam_ldap does not exist in RH7 (actually Scientific Linux 7), I think your SLES12 is also a bit older. See Michael's reply, which has an explanation for this.
Which OS do you use?
SLES 12 SP5
I also have: # grep ldap /etc/nsswitch.conf group: files ldap services: files ldap netgroup: files ldap aliases: files ldap passwd_compat: ldap
and
/etc/pam.d # cat login #%PAM-1.0 auth requisite pam_nologin.so auth [user_unknown=ignore success=ok ignore=ignore auth_err=die default=bad]pam_securetty.so auth include common-auth account include common-account password include common-password session required pam_loginuid.so session include common-session session optional pam_lastlog.so nowtmp session optional pam_mail.so standard
Maybe this helps.
Thank you. As I wrote in the other reply today, pwdCheckQuality:0 was set, and I'm pretty sure I did not need any client changes to make PPs work on SL7 (with pwdCheckQuality:2 on the server).
Many Thanks and Best Regards, Felix -- Felix Natter
openldap-technical@openldap.org
-
Felix Natter -
Michael Ströder -
Ulrich Windl