Re: Antw: [EXT] Re: Password policies and hashed passwords

>> Felix Natter <fnatter(a)gmx.net&gt; schrieb am 23.02.2022 um 21:45 in Nachricht

hello Ulrich, thanks for your reply! My replies are inline: "Ulrich Windl" <Ulrich.Windl(a)rz.uni-regensburg.de&gt; writes: >>>> Felix Natter <fnatter(a)gmx.net&gt; schrieb am 22.02.2022 um 19:00 in Nachr= icht > <87h78qlr1i.fsf(a)bitburger.home.felix&gt;: >> hello Michael, >>=20 >> many thanks for your reply! >>=20 >> Michael Str=C3=B6der <michael(a)stroeder.com&gt; 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. >>> >>> 1. 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 >>> >>> 2. 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. >>> >>> 1. Implement decent ACLs which forbids any read access to all LDAP clie= nts >>> (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. 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!