A strong account lockout policy is one of the most effective tools for stopping brute force authentication attempts on Windows domains.
Once an attacker enters an incorrect password so many times, the account becomes locked. This prevents any additional attempts until an administrator unlocks the account.
Creating an Account Lockout Policy
To create an account lockout policy, begin by opening the group policy object within which you want to create the policy. Next, navigate through the console tree to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy. As you can see in Figure 1, there are three individual settings that make up an account lockout policy.
Account Lockout Policy Settings
1. Lockout duration setting
The first setting used in an account lockout policy is the lockout duration. If an account becomes locked, the lockout duration setting will control how long the lockout will last. Enabling the Account Lockout Duration setting allows you to enter the lockout period in minutes. You can make a lockout last from one minute to 99.999 minutes.
As an alternative, you can force an account lockout to remain in effect until an administrator unlocks the account by setting the account lockout duration value to 0.
2. Account Lockout Threshold setting
The second group policy setting that is used as the basis of an account lockout policy is the Account Lockout Threshold setting. This is the setting that determines the number of failed login attempts that will cause an account to become locked out. Setting the Account Lockout Threshold to a value of five for example, would mean that a user’s account would be locked out following five failed login attempts.
The maximum number of failed login attempts that you can specify (assuming that the setting is enabled) is 999, although most organizations use a value of three or five. Incidentally, if you set the value to 0, then accounts will never be locked out.
3. Reset Account Lockout Counter After setting
The third setting in an account lockout policy is the Reset Account Lockout Counter After setting. This setting determines the amount of time that must elapse before Windows will reset an account’s failed logon count back to zero. The reset period can be set to as little as one minute or as much as 99.999 minutes.
Imagine for a moment that an organization has an account lockout policy that locks a user’s account after three bad login attempts. Now, suppose that a user enters their password incorrectly two times in a row. If the user were to incorrectly enter their password a third time, the account would become locked out.
If however, the user were to wait and attempt to login again the next day then they would be given three more attempts because the reset account lockout counter will eventually expire, essentially making it as though no failed logons have occurred (at least from an account lockout prospective).
The Problem with Account Lockouts
Even though an account lockout policy can be configured to automatically unlock a user’s account after a period of time, most organizations require an administrator to unlock accounts that have become locked. After all, the account was locked for a reason and performing an automated unlock could be a security risk.
Of course, requiring an administrator to unlock an account can be problematic from an end user’s standpoint. Account lockouts might for example, occur late at night or on the weekend when no one is available to unlock the account. Likewise, if the support desk is busy, a user may have to wait for a technician to be available.
Specops uReset solves this problem by allowing users to unlock their own accounts. If a user’s account becomes locked, the user can visit a self-service Web portal and request that the account be unlocked. The portal then requires the user to conclusively prove their identity by way of a customizable multifactor authentication process. The best part—the locally cached credentials problem which can recur with all the hybrid work-from-home happening these days is no longer an issue.
When the user provides the required authentication information, the user’s password is reset and their account is unlocked, all without a call to the helpdesk. Not only is this process convenient for end users who need their accounts unlocked, it can also help to reduce the helpdesk staff’s workload since users can reset their own passwords and unlock their own accounts. You can test out Specops uReset in your Active Directory for free to see if it’s a good fit.
Sponsored by Specops
Source: www.bleepingcomputer.com