By default, UCS users can enter the password incorrectly any number of times without being locked out by the system. In order to make brute force attacks to crack passwords more difficult, admins can set up an automatic lockout that prevents an account from being accessed after a user-defined number of failed attempts.

Univention Corporate Server offers several methods for authentication and authorization. In this blog article I will show you how to log failed login attempts to the system via PAM stack, OpenLDAP and Samba respectively and how you as an admin can set a limit for the number of unsuccessful logins.

What is a Brute-force Attack?

There are several ways to crack passwords. One of them is the so-called Brute-force method. This means a computer program is testing every possible combination of letters, numbers and special characters until the correct password is found. Even though it takes some time for longer passwords, it is possible to guess every password.

Decisive for a (quick) success is the computer speed as well as the length of the password. Furthermore, the combination is important: A password only consisting of numbers (10 characters) is significantly easier to crack than a combination made up of numbers and letters (52). If special characters are added (32), brute-force attacks will take more time. However, they do lead to a successful decryption. Therefore, setting up an automatic lockout after a certain number of failed attempts is a good way to prevent this.

What can you do about it? First of all, we will start with the PAM stack (Pluggable Authentication Modules) in Univention Corporate Server which you can configure for one or for all computers within the UCS environment.

Limiting Failed Attempts for the PAM Stack

The PAM libraries (Pluggable Authentication Modules) are a firm component of every Linux distribution and thus also of UCS. UCS admins can activate the automatic blocking of users after failed logins in the PAM stack via a variable in the Univention Configuration Registry (UCR). The UCR variables can be accessed via System / Univention Configuration Registry. Search for the entry auth/faillog and change the default from no to yes. Then you can define an upper limit. This means you can define how often users are allowed to enter an incorrect password before the system locks them out. The variable auth/faillog/limit is responsible for this. Enter a number for the maximum of permitted attempts; the default is 5.

Screenshot: UCS auth faillog limit UCR variable

Please be aware that the counter for incorrect entries is reset to 0 each time users enter their password correctly.

In the default settings of UCS a lock via the PAM stack is valid infinitely. But you can define an expiry interval. Thus, the lock is released after a certain amount of time. To do this, specify a time interval in seconds in the variable auth/faillog/unlock_time. If you enter a 0 , the lock will be removed immediately.

The superuser account (root) is excluded from the automatic account lockout. Nonetheless, the root account can also be included. In order to do this, change the default setting no to yes in the UCR variable auth/faillog/root.

The lockout via the PAM stack is initially locally assigned to a single system. Therefore, after the number of failed attempts has been reached, users could try to authenticate themselves on another computer in the UCS environment and, of course, log on if they enter the correct password. To prevent this, admins can use the UCR variable auth/faillog/lock_global to extend the lockout to the entire UCS environment.

As a result, the lock is also registered in the OpenLDAP directory service. Attention: The global lock can only be configured on a DC Master/Backup because other system roles do not have the necessary permissions in the LDAP directory. A listener module ensures that the setting also applies to the other systems.

Let’s move on to OpenLDAP: You can also activate the automatic account locking for repeatedly failed LDAP authentications.

OpenLDAP: Configuring an Automatic Account Blocking

You can also enable such a lock for access for repeated LDAP authentication failures on each domain controller. Therefore, the directory service has to use the MDB backend. MDB (Memory-Mapped Database) is set as default since UCS 4; older systems have to be updated and migrated to the MDB backend. Our user manual explains the necessary steps.

The automatic account blocking has to be activated on each DC. For this purpose, set the UCR variables ldap/ppolicy and ldap/ppolicy/enabled to yes.

Screenshot: UCS ldap policy enabled

Afterwards restart the directory service for the changes to take effect. You can either perform this by using the Management Console (System / System Services) or by entering the command systemctl restart slapd.service in a terminal window.

By default, five repeated LDAP authentication errors within five minutes will result in suspension of the account. You can change the number and duration as described in the corresponding section of our user manual.

Samba und Active Directory: Locking Accounts Automatically

UCS with Samba AD processes logins to clients differently than logins to servers. This also applies to login attempts with Kerberos e. g. from Windows clients, which is covered by . If Samba/Active Directory runs in your environment, you can use the samba-tool to display and change the current configuration. You use the tool with root permissions on the console – either locally on the UCS server or via remote login per SSH. To display the current configuration use for example the command samba-tool domain passwordsettings show.

Screenshot: Kommando samba tool domain passwordsettings

You can modify the Samba configuration with various parameters and options:

  • samba-tool domain passwordsettings set --account-lockout-threshold=5
    Defines the number of attempts users have to log in (here: 5). Thereafter the account will be locked.
  • samba-tool domain passwordsettings set --account-lockout-duration=3
    Sets the amount of minutes to lock up after the users have entered an incorrect password too many times.
  • samba-tool domain passwordsettings set --reset-account-lockout-after=5
    Configures the amount of minutes until the counter is reset.

If an account is automatically unlocked after the configured duration, the counter will not be reset. In consequence, the account remains under surveillance for a while. After the end of the lockout and before the counter is finally reset, a new failed attempt will lead to a lockout of the account immediately.

Release of the Lock

As UCS administrator you can also unblock an account manually. For the PAM stack you do this with the command faillog. The parameter -r resets the counter for failed login attempts. It is followed by -u and the user name of the locked account: faillog -r -u USERNAME.
If it relates to a global lock in the directory service, i.e. in the complete UCS environment, admins can remove the lock via the Univention Management Console in the user administration. For this switch to the tab Account and tick the checkbox Reset lockout . This manual unlock also applies to accounts being locked in an Active Directory domain. Optionally, it is possible to define a time for unlocking in the field below.

Screenshot: UCS locked login

If you have any questions or comments about this article and the account lockout, feel free to leave a comment.

Use UCS Core Edition for Free!

Download now
Ingo Steuwer

Using Linux since 1999, Ingo Steuwer started working at Univention in 2004. As Head of Product Management he focusses on the further development of UCS.


  1. Hi Ingo,
    Nice article!
    In my projects I use fail2ban. So I was wondering if you guys have any comparative matrix, which shows pros and cons of UCS, Fail2ban and other supervisors as such?
    Best wishes,

  2. Hi Iuri,

    thank you for your feedback!

    IMHO a comparsion between UCS and fail2ban would be misleading. The objective of UCS is to provide a preconfigured stack of Open Source tools, where fail2ban is one tool that can be used. Actually we even have an example for configuring fail2ban on UCS for a ransomware protection:

    In this article we described some “included” options of services included in UCS. These options are easier to configure than fail2ban, but less flexible. In case the functionality given by these options, fail2ban is a good way to cover more usecases.

    Best Regards

  3. Is there a way to notify a user by mail their account is locked.
    People attempt to connect to service and don’t know why their known password isn’t workin anymore.


  4. As of now there is no integrated way to notify users about expired passwords. I suggest to discuss this topic on – this thread might be a good starting point:

  5. how to go round a scenario where all users (including admins) cannot login on to the portal??!!

  6. In case all administrative accounts are “locked” you can unlock them using the command line client of UDM ( as “root” user. For Details I recommend to start a thread on

  7. THX