>>> Felix Natter <[email protected]> schrieb am 23.02.2022 um 21:45 in Nachricht
<[email protected]>:
> hello Ulrich,
> 
> thanks for your reply! My replies are inline:
> 
> "Ulrich Windl" <[email protected]> writes:
>>>>> Felix Natter <[email protected]> schrieb am 22.02.2022 um 19:00 in Nachr=
> icht
>> <[email protected]>:
>>> hello Michael,
>>>=20
>>> many thanks for your reply!
>>>=20
>>> Michael Str=C3=B6der <[email protected]> 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?

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
>>>>
>>>> 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!


Reply via email to