>> Felix Natter <fnatter(a)gmx.net> schrieb am 23.02.2022 um
21:45 in Nachricht
<87wnhl9uru.fsf(a)bitburger.home.felix>:
hello Ulrich,
thanks for your reply! My replies are inline:
"Ulrich Windl" <Ulrich.Windl(a)rz.uni-regensburg.de> writes:
>>>> Felix Natter <fnatter(a)gmx.net> schrieb am 22.02.2022 um 19:00 in
Nachr=
icht
> <87h78qlr1i.fsf(a)bitburger.home.felix>:
>> hello Michael,
>>=20
>> many thanks for your reply!
>>=20
>> Michael Str=C3=B6der <michael(a)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.
>>>
>>> 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!