Univention Bugzilla – Bug 31907
Prevent user login via LDAP after defined number of failed logins
Last modified: 2020-09-18 13:58:48 CEST
If a user tries to login to a web frontend provided by a third party application (e.g. Zarafa WebApp), the login will always be granted as long as the password is correct. If the user tries to login with a wrong password several times, the account won't be locked. If the user account is deactivated the user can still login to the web frontend. The expected behaviour is that deactivated or locked user accounts are taken into consideration be LDAP authentications, as well. Users expect the same behaviour as with PAM on failed logins: http://docs.univention.de/handbuch-3.1-1.html#users:faillog The behaviour has been requested by some partners and technology partners. A suggested solution was to use the password policy overlay for OpenLDAP: http://www.openldap.org/doc/admin24/overlays.html The implementation would not only benefit the above mentioned example Zarafa WebApp, but all applications using LDAP for direct user authentication.
* Who locks the account? * What kind of locking semantic is employed? * Why doesn't the locker check the lock? See also Bug 7163 Comment 4.
(In reply to Arvid Requate from comment #1) > * Who locks the account? The user account is either actively locked by an administrator. Or the user triggers the lock after a defined number of failed logins. > * What kind of locking semantic is employed? The lock occurs after a defined number of failed logins, e.g. providing the wrong password. It should be up the administrator and the configuration, how the lock can be unlocked: * Unlock after a defined timeout, e.g. 5 Minutes * The user account can only be unlocked by an administrator, e.g. the helpdesk > * Why doesn't the locker check the lock? The application should not check for any locks. It just needs to know whether to grant the user access or not. IMHO it should be the job of the authentication service to check the lock. Isn't it the same behaviour with PAM, as well?
Ok, I see the use case now. Workaround: If the service could use the PAM stack, then the ppolicy overlay would not be required?
(In reply to Arvid Requate from comment #3) > Ok, I see the use case now. Workaround: If the service could use the PAM > stack, then the ppolicy overlay would not be required? I already suggested that as well, but they see it either LDAP or PAM and not both. From their point of view using PAM at the expense of LDAP would not be a good idea. Maybe I and the partner are missing some point here. Do you mean it should be possible for the application to switch to PAM and let is use LDAP in the backend on a global way? I suggest to continue this discussion offline and not at this bug and just document the results here. The example mentioned is just one case. For me it generally sounds very interesting to enhance OpenLDAP in UCS in a way that it would yield failed logins for webbased applications using UCS LDAP for authentication.
We should check if it can be implemented for UCS 4.
Ok, I finally got it working after some debugging. The definition of the lockout policy is stored in an LDAP object, so we have to decide if we expose this via UDM/UMC (the generic way IMHO) of via some kind of UCR module. Another thing I noticed was that the useful "pwdMaxTotalAttempts" extension documented by zytrax is not implemented in OpenLDAP (ITS http://www.openldap.org/its/index.cgi/Software%20Enhancements?id=5911 ), but has been implemented by zytrax for a customer: http://inchoate-clatter.blogspot.de/2009/05/ldap-password-policy-how-i-learned-to.html . What is this about? This patch allows the administrator to differenciate between failed logons due to someone/something trying the same password over and over again and attempts with varying passwords. This way, you can avoid lockouts due to programs which retry a cached password for too long. The OpenLDAP team has been reluctant to pick up this enhancement due to security concerns (hashes of the attempted passwords are stored). I just note this here as it might be an interesting feature in the future. If those hases are removed when the accunt is unlocked I guess the risc is ok. And it would be optional and at the Administrators choice. Btw: The unlocking of accounts is only possible by "the Administrator" and requires an overlay specific LDAP modification. So something probably needs to be exposed in UDM/UMC for this.
As discussed: * The pwdAccountLockedTime attribute should probably be exposed in users/user to let the admin detect a lockout situation and be able to unlock the account by removing the attribute. This may be done via a custom attribute, but Felix recommended to hide this field in the GUI in case no LDAP-bind-lockout-policy has been activated in the domain. * The ppolicy overlay requires the "rootdn" setting to be configured in slapd.conf, otherwise the LDAP-ACLs prevent it to actually set the pwdAccountLockedTime attribute. * Password changes via ppolicy should be blocked (pwdAllowUserChange: FALSE). * Configuring the ppolicy should be domain wide, so a listener module is probably required too. * The ppolicy overlay, as it is today, only locks LDAP-Bind. Samba-Logon and Kerberos Authentication continue to work. This may lead to pretty intransparent situations for the admin. One option might be to enhance the policy overlay, e.g. to do a python call to udm. Hopefully this doesn't interfere with slapd threading (I guess this is a non-issue). * Another thing to keep in mind is, that our Kerberos doesn't do "lockout-on-repeated-auth-failure" yet. Looks like MIT has some kind of support for it, but last time I checked Heimdal didn't.
(In reply to Arvid Requate from comment #7) > * The pwdAccountLockedTime attribute should probably be exposed in > users/user to let the admin detect a lockout situation and be able to unlock > the account by removing the attribute. This may be done via a custom > attribute, but Felix recommended to hide this field in the GUI in case no > LDAP-bind-lockout-policy has been activated in the domain. Is the pwdAccountLockedTime attribute global and replicated among the different servers? Or is it a local attribute?
> Is the pwdAccountLockedTime attribute global and replicated among the different > servers? Or is it a local attribute? Yeah, excelent question. Two points: A) The ppolicy schema declares the attribute as "NO-USER-MODIFICATION USAGE directoryOperation". So, there might be an issue with writing it to the remote LDAP, but I would bet the cn=update DN is allowed to do this. B) AFAIK the ppolicy overlay modifies the attribute in the local LDAP. So, if an attacker chooses to do LDAP-bind attempts against an UCS Salve, the overlay would probably only lock the account locally. Excellent case for multimaster! ;-) Just kidding. Seriously: We already discussed that it might make sense to adjust the ppolicy overlay module to also lock other attributes (posix, samba, krb5), e.g. by calling a umc-command (or python-udm). This would at the same time provide a channel to forward the lock back to the master. This in the end would bring us back to the point where we need to modify the pwdAccountLockedTime attribute with an LDAP modify, see point A).
And about my Comment 7: > * Configuring the ppolicy should be domain wide, so a listener module is probably required too. We could probably avoid this by 1) loading the ppolicy overlay everywhere by default, so the schema is always loaded in each LDAP server (Q: how does this work for replication to non-updated servers?). 2) Implement the configuration via UMC/UDM module directly into the LDAP-backend (i.e. avoid local UCR config).
* The installation of the new univention-ldap-server package loads the ppolicy schema and overlay by default. * The overlay itself registers a couple of operational (builtin) attributes, which need to get filtered out in replication.py. * To avoid failed ldifs in update scenarios an UCS 3.2-3 erratum will be released (Bug #36113). Before verifying this bug here, the erratum should be released and the UCS 4.0 release notes should point out the minimal required erratum level required in the domain before updating. * The joinscript 10univention-ldap-server.inst creates an object which provides the default for the ppolicy overlay: cn=default,cn=ppolicy,cn=univention,$ldap_base * Default policy is: locking after 5 authentication failures within 5 minutes * To activate the ppolicy overlay checking, the default policy needs to be set in slapd.conf via UCR: ucr set ldap/ppolicy/enabled=yes; /etc/init.d/slapd restart * The DN above is used if no other is configured via UCR ldap/ppolicy/default * The overlay can be enabled on each UCS domain controllers separately. * Test case: 10_ldap/50ppolicy_account_lockout * The UCS 4.0 changelog provides a minimal explanation for this feature.
The test case failed on DC slaves in Jenkins: ------------------------------------------------------------------------------ *** BEGIN *** ['/bin/bash', '50ppolicy_account_lockout'] *** *** 10_ldap/50ppolicy_account_lockout *** Check account lockout on repeated failed login attempts *** Create ldap/ppolicy/enabled Multifile: /etc/ldap/slapd.conf Restarting ldap server(s). Stopping ldap server(s): slapd ...done. Starting ldap server(s): slapd ...done. modifying entry "cn=default,cn=ppolicy,cn=univention,dc=autotest095,dc=local" info 2014-10-16 01:05:29 create user u44djhäq Object created: uid=u44djhäq,cn=users,dc=autotest095,dc=local Wait until pwdFailureCountInterval (15 seconds) has passed.. Waiting for replication: OK: replication complete (nid=4221 lid=4221) Done: replication complete. Waiting for postrun error 2014-10-16 01:06:02 Account not locked: none error 2014-10-16 01:06:02 **************** Test failed above this line (1) **************** No modification: uid=u44djhäq,cn=users,dc=autotest095,dc=local ldap_bind: Invalid credentials (49) error 2014-10-16 01:06:03 *** Check failed (1), but this might be caused by the error above *** info 2014-10-16 01:06:03 remove user u44djhäq Object removed: uid=u44djhäq,cn=users,dc=autotest095,dc=local debug 2014-10-16 01:06:03 user u44djhäq removed info 2014-10-16 01:06:03 checking whether the user u44djhäq is really removed debug 2014-10-16 01:06:03 user u44djhäq does not exist modifying entry "cn=default,cn=ppolicy,cn=univention,dc=autotest095,dc=local" Unsetting ldap/ppolicy/enabled Multifile: /etc/ldap/slapd.conf Restarting ldap server(s). Stopping ldap server(s): slapd ...done. Starting ldap server(s): slapd ...done. *** END *** 1 *** ------------------------------------------------------------------------------
DC Slaves were not allowed to modify the sambaAcctFlags attribute. I added an LDAP ACL to that effect.
FAIL - please add a note to the release notes that all systems in the domain have to be updated to 4.0 before activating ppolicy OK - lockout for ldap/pam/samba3 authentication (not samba4 or kerberos) OK - default settings OK - activation/UCR variables OK - master and slave setup, lockout works on both, no failed ldif if ppolicy is not configured on the slave
Release notes updated.
OK
Just a note about lockout support Heimdal: With the Samba4 backend this also works "out of the box" once the lockout policy has been defined in Samba. I just tried it with kinit and it "simply works". Great!
*** Bug 35831 has been marked as a duplicate of this bug. ***
*** Bug 28703 has been marked as a duplicate of this bug. ***
UCS 4.0-0 has been released: http://docs.univention.de/release-notes-4.0-0-en.html http://docs.univention.de/release-notes-4.0-0-de.html If this error occurs again, please use "Clone This Bug".