Bug 31907 - Prevent user login via LDAP after defined number of failed logins
Prevent user login via LDAP after defined number of failed logins
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 3.1
Other Linux
: P5 enhancement (vote)
: UCS 4.0
Assigned To: Arvid Requate
Felix Botner
: interim-3
: 28703 35831 (view as bug list)
Depends on: 36113 36353
Blocks: 46431 48182 37915 45495 51676 51684 52059
  Show dependency treegraph
 
Reported: 2013-07-05 15:11 CEST by Nico Gulden
Modified: 2020-09-18 13:58 CEST (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Gulden univentionstaff 2013-07-05 15:11:29 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.
Comment 1 Arvid Requate univentionstaff 2013-07-08 11:02:22 CEST
* 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.
Comment 2 Nico Gulden univentionstaff 2013-07-08 12:04:45 CEST
(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?
Comment 3 Arvid Requate univentionstaff 2013-07-08 14:28:42 CEST
Ok, I see the use case now. Workaround: If the service could use the PAM stack, then the ppolicy overlay would not be required?
Comment 4 Nico Gulden univentionstaff 2013-07-08 17:12:27 CEST
(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.
Comment 5 Stefan Gohmann univentionstaff 2014-08-29 07:26:20 CEST
We should check if it can be implemented for UCS 4.
Comment 6 Arvid Requate univentionstaff 2014-09-02 20:19:22 CEST
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.
Comment 7 Arvid Requate univentionstaff 2014-09-03 11:41:23 CEST
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.
Comment 8 Stefan Gohmann univentionstaff 2014-09-25 06:56:14 CEST
(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?
Comment 9 Arvid Requate univentionstaff 2014-09-25 12:31:11 CEST
> 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).
Comment 10 Arvid Requate univentionstaff 2014-09-25 12:50:46 CEST
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).
Comment 11 Arvid Requate univentionstaff 2014-10-14 18:23:41 CEST
* 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.
Comment 12 Stefan Gohmann univentionstaff 2014-10-16 07:36:00 CEST
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 ***
------------------------------------------------------------------------------
Comment 13 Arvid Requate univentionstaff 2014-10-22 18:44:57 CEST
DC Slaves were not allowed to modify the sambaAcctFlags attribute. I added an LDAP ACL to that effect.
Comment 14 Felix Botner univentionstaff 2014-10-31 10:33:32 CET
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
Comment 15 Arvid Requate univentionstaff 2014-11-03 13:43:20 CET
Release notes updated.
Comment 16 Felix Botner univentionstaff 2014-11-03 14:21:41 CET
OK
Comment 17 Arvid Requate univentionstaff 2014-11-20 17:31:50 CET
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!
Comment 18 Arvid Requate univentionstaff 2014-11-20 17:32:58 CET
*** Bug 35831 has been marked as a duplicate of this bug. ***
Comment 19 Arvid Requate univentionstaff 2014-11-20 17:59:52 CET
*** Bug 28703 has been marked as a duplicate of this bug. ***
Comment 20 Stefan Gohmann univentionstaff 2014-11-26 06:55:12 CET
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".