Active Directory Account Lockout Policy

We’ve touched on the critical importance of password management, and Account Lockout Policy builds on this further. Most failed login attempts are accidental—a user enters their password incorrectly, which happens from time to time. We’re human.

However, user accounts occasionally face unique threats from remote attackers. These include:

• Denial of Service (DoS) attacks
• Malicious, isolated attempts to guess user passwords

While lockouts aren’t preferable, crafting pre-configured lockout strategies is key to protecting internal data. Organizations don’t want attackers to access cherished IP, and companies must galvanize their infrastructure. The fact remains that thwarting initial brute-force attacks gives SecOps teams time to extinguish fires.

Active Directory provides options for security-minded administrators. We’ll assess the authentication tools that professionals can harness.

What is an account lockout?

The practice of locking out users has existed for a long time. Device owners will notice varied lockout practices. For example, iPhone users will be familiar with timed lockouts—where failed passcode entries will lock users out for increasing durations (as failed attempts multiply). Other personal devices have similar measures in place. Users may choose to have their device wiped after a set number of false entries.

However, the situation with remote systems is a bit different. Company servers hold mountains of information. While a personal device is just that—reserved for one person—a server supplies tens or even thousands of employees with shared data. It’s not prudent to wipe a server or resources after multiple, failed login attempts. Cumulative losses would be too severe.

Instead, admins can establish policies blocking troublesome accounts. A targeted account can be an attack vector, so disabling it can be effective. No system is perfect though. True account owners will be temporarily unable to access key resources. Active Directory provides robust security controls without compromising productivity.

Leveraging Active Directory Account Lockout Policies

Essentially, Account Lockout Policy determines what happens after a password is submitted. The system actively monitors login behavior—taking action when necessary, or standing pat when things are shipshape. There are three main elements to Account Lockout Policy:

• Account lockout threshold
• Account lockout duration
• Reset account lockout counter after

Lockout threshold is pretty straightforward. Every login attempt impacts an attribute called badPwdCount. As one might expect, an initial failed login changes this count to one. Successive failed attempts up the count by one. If authentication fails a set number of times, the account is locked. Active Directory permits a number between 0 and 999. While the high end of the range is more lenient, it does leave accounts more vulnerable to brute force attacks. Active Directory’s default is 0. Accounts set to zero are never automatically locked out.

Lockout duration determines how many minutes an account is locked out. Admins can set a value from 0 to 99,999. Once this time elapses, the account is automatically unlocked—unless the duration is set to zero. Only an administrator can unlock these affected accounts manually. This requires a connection between Active Directory and the Active Directory Users and Computers (ADUC) console. Duration is also tied to threshold; the latter must first be defined before duration settings to take effect.

Reset account lockout counter after defines the time required for the failed-login counter to reset. Say a user enters their password incorrectly. The failed-login counter now sits at 1. If the user abstains from trying again for a certain period, that counter will return to 0. This prevents the authentication system from eternally ‘punishing’ the user. Note that this set value mustn’t exceed the lockout duration value. Once an account is unlocked, the counter must reset accordingly to reflect this fresh start.

Special considerations

We mentioned briefly how Denial of Service (DoS) attacks are especially troublesome in the services realm. DoS attacks and their distributed cousins (DDoS) are quite common. For our purposes, they also prevent real users from accessing cloud data; account lockouts can stall productivity for massive amounts of time. After all, a lockout can last up to 69.4 days when considering the accepted duration range. Microsoft recommends a lower value around 15 minutes.

Active Directory Account Lockout Policy allows admins to ward off DoS attacks. Microsoft states that threshold values should be set to 0 or a high number. The former value prevents accounts from locking—preventing denial of service. A high value champions user forgiveness. Microsoft’s Security Compliance Toolkit recommends a value of 10 as a happy medium.

Taking a systematic approach

Remember that Lockout Policy doesn’t operate in a bubble. The configuration is part of a greater system; all pieces can work together to bolster security. For example, best practices dictate that passwords should contain eight or characters. A legitimate user is allowed to err during login, yet bad actors will have a hard time.

Admins should also configure alerts. These inform core team members of failed login events—especially those that occur in rapid succession. A login failure is considered a security event. Accordingly, Active Directory labels this as “event 539.”

Lastly, Active Directory Group Policies are often linked to Default Domain Policies. When granular, customized password settings are implemented, the domain policy may not cover all accounts. A custom Group Policy Object (GPO) may supersede this.

Sound Account Lockout Policy strategies are essential

It’s a given that different teams have different goals. They also encounter different threats. Accordingly, Netflix or Amazon—two massive service providers—may attract more nefarious attention than internal Windows Server users.

While a Distributed Denial of Service (DDoS) attack may be necessary to hinder major companies, smaller teams will typically face smaller threats. Adjusting the Account Lockout Policy accordingly will help counteract any attacks.

Not all account behaviors will be logical. A system may occasionally leave users logged in when they shouldn’t be. Additionally, admins may have trouble dealing with persnickety accounts. Troubleshooting is critical in these instances. Thankfully, Microsoft has a plethora of resources available for when things to awry.

In the event that true account owners are temporarily locked out due to the Account Lockout Policy, Specops uReset can help users unlock their own accounts, after they have verified their identity with multi-factor authentication. With Specops uReset you can balance security with usability, and reduce calls to the service desk.