Univention Bugzilla – Bug 53231
Automatic unlock of ppolicy lockout (like in faillog and samba)
Last modified: 2023-04-28 09:47:10 CEST
We offer the automatic unlock of a lockout triggered by faillog and samba but not for a lockout triggered by ppolicy. This would be consistently and was expected by the customer. If I trigger a lockout via ppolicy by wrong password in a ldapbind samba will be locked out also (mostly as bug 52893 shows not always). This samba lockout is automaticly removed after the set unlocktime in samba (10min): reiherwald.intranet / 2 / 13:31:43 / ✓ root@dc0:~ # for ((i=1;i<=12;i++)); do ldapsearch -x -D "uid=ttestum,cn=users,dc=reiherwald,dc=intranet" -w $(cat wrong.txt) uid=ttestum dn; done ldap_bind: Invalid credentials (49) ldap_bind: Invalid credentials (49) ldap_bind: Invalid credentials (49) ldap_bind: Invalid credentials (49) ldap_bind: Invalid credentials (49) ldap_bind: Invalid credentials (49) ldap_bind: Invalid credentials (49) ldap_bind: Invalid credentials (49) ldap_bind: Invalid credentials (49) ldap_bind: Invalid credentials (49) ldap_bind: Invalid credentials (49) ldap_bind: Invalid credentials (49) reiherwald.intranet / 2 / 13:31:56 / ✓ root@dc0:~ # ldapsearch -x -D "uid=ttestum,cn=users,dc=reiherwald,dc=intranet" -W uid=ttestum dn Enter LDAP Password: ## <- entered correct password ldap_bind: Invalid credentials (49) reiherwald.intranet / 2 / 13:32:01 / ✓ root@dc0:~ # kinit ttestum ttestum@REIHERWALD.INTRANET's Password: kinit: krb5_get_init_creds: No PKINIT PA found reiherwald.intranet / 2 / 13:32:07 / ✓ root@dc0:~ # univention-ldapsearch uid=ttestum '+' |grep ock pwdAccountLockedTime: 20210506113156Z reiherwald.intranet / 2 / 13:32:07 / ✓ root@dc0:~ # reiherwald.intranet / 2 / 13:41:56 / ✓ root@dc0:~ # kinit ttestum ttestum@REIHERWALD.INTRANET's Password: reiherwald.intranet / 2 / 13:42:03 / ✓ root@dc0:~ # ldapsearch -x -D "uid=ttestum,cn=users,dc=reiherwald,dc=intranet" -W uid=ttestum dn Enter LDAP Password: ldap_bind: Invalid credentials (49) reiherwald.intranet / 2 / 13:42:03 / ✓ root@dc0:~ # ####### The ldapbind stays locked. This is only removeable by deactivate and activate the user. It is also not viewable in the UMC, that the user is locked.
I set the "Waiting Support" flag because of Ticket #2021121421000141.
Another customer is effected Ticket #2023020821000444
This can be configured through the attribute pwdLockoutDuration. ldapmodify -x -D "cn=admin,$(ucr get ldap/base)" -y /etc/ldap.secret <<__EOT__ dn: cn=default,cn=ppolicy,cn=univention,$LB changetype: modify replace: pwdLockoutDuration pwdLockoutDuration: 30 __EOT__ This should be added to our documentation. See also: https://linux.die.net/man/5/slapo-ppolicy
(In reply to Stefan Gohmann from comment #6) > This can be configured through the attribute pwdLockoutDuration. > ... The initial Bug description talks about "automatic unlock" As far as I have seen in the past, using pwdLockoutDuration will not unlock the account automatically. It needs a successful authentication.
I'll reset the Waiting Support flag because it is more a feature request. At least in my opinion. (In reply to Dirk Ahrnke from comment #7) > (In reply to Stefan Gohmann from comment #6) > > This can be configured through the attribute pwdLockoutDuration. > > ... > > The initial Bug description talks about "automatic unlock" > > As far as I have seen in the past, using pwdLockoutDuration will not unlock > the account automatically. It needs a successful authentication. For me, it's still automatic. :) Do you think it is necessary to reset without a successful authentication?
(In reply to Stefan Gohmann from comment #8) > > For me, it's still automatic. :) > > Do you think it is necessary to reset without a successful authentication? lockouts by ppolicy will also lock the account in UDM (see Bug 55501 for an example where it did not work some time ago). This lock will then be valid for signon attempts using other methods than LDAP-signon. Only a successful logon in LDAP after pwdLockoutDuration *should* remove the LDAP-lock in the local LDAP. It is at least not fully clear if, when and how the reset of the lock is designed to work in general. From my experience it doesnt. And this is how I also understand the original bug description.