Sponsored by Specops Software
Active Directory account locking serves as a security mechanism that can help to protect user accounts against brute force password cracks. Once an attacker has entered an incorrect password several times in a row, the account is automatically locked and remains locked until someone from the IT staff unlocks it. As important as the account lockout feature might be, however, it’s extremely common for end-users to lock themselves out accidentally. If a user is required to change their password and cannot remember their new password, they might lock themselves out as they try to gain access to their account.
Active Directory procedure for unlocking a user account
From a technical standpoint, unlocking a locked user account is a simple process. An authorized IT staff member would open the Active Directory Users and Computers console and select the user’s folder. Next, they need to right-click on the locked account and choose the Properties command from the shortcut menu. This causes Windows to display the account’s Properties dialog box. To complete the process, the IT professional would need to select the dialog box’s Account tab, click on the Unlock Account checkbox, and then click OK. You can see what this looks like in the image below.
As you can see, unlocking a user account is a simple process that usually only takes a minute or two to complete. Even so, this type of manual unlocking is less than desirable. In fact, there are at least two significant issues associated with unlocking an account in this way.
The first of these issues is security. Even though the account lockout feature was designed as a mechanism for protecting user accounts, account lockouts can actually undermine security.
Consider what happens when a user becomes locked out of their account. Typically, the user will place a phone call to the helpdesk, who then assists the user with unlocking their account. The problem with this is that unless the organization is relatively small, the helpdesk technician is unlikely to be able to positively identify the user by their voice over the phone. Hence, anyone could conceivably make a phone call to the helpdesk requesting an account lockout for a given account, and the helpdesk staff would have no way of knowing whether or not it was the account owner who actually made the call.
Account lockouts usually entail password resets
On the surface, this might seem to be a nonissue. After all, if a cybercriminal were to call and ask to have an account unlocked, then the account would most likely become locked once again shortly after the criminal resumed their efforts to try to break in. The problem, however, is that almost no one contacts the helpdesk just asked to have their account unlocked. Account lockouts almost always go hand-in-hand with password resets. Hence, if a user contacts the helpdesk to unlock their account, the helpdesk might actually reset the account password and give that password out over the phone to a user whose ID has not been thoroughly verified.
The other problem that occurs with regard to account lockouts is that they always seem to occur at the most inconvenient time. A user might, for example, find themselves locked out on a weekend, holiday, or late at night when the helpdesk staff is not available to unlock the account. Even if the organization does have a 24-hour helpdesk, the user still wastes time by having to pick up the phone, call the helpdesk, and wait for them to unlocked the account. In other words, account lockouts adversely impact user productivity.
Giving users the ability to unlock their own accounts
The solution to these problems is not to do away with account lockouts. Account lockouts remain one of the most effective mechanisms in protecting user accounts against brute force password cracking attempts. Rather than turning off the account lockout feature, organizations should consider adopting third-party tools such as Specops uReset, which can help to make the process of unlocking an account more efficient and secure.
uReset gives users the ability to unlock their own accounts and reset their own passwords. In doing so, uReset first verifies the user’s identity through multifactor authentication. The user might, for example, provide their Google password or perhaps answer a security question. A user can even be required to prove their identity in multiple ways.
If the user does choose to phone the helpdesk, the helpdesk can positively identify the user before unlocking the user’s account. Historically, helpdesk software has sometimes prompted a user to answer a security question to confirm their identity. The problem with this approach is that the helpdesk technician learns the answer to the user’s security question. Specops gets around this problem by not exposing the full answer to a security question to the end-user. Rather than asking the user for the name of the street that they grew up on, for example, the helpdesk technician might ask the user for the last letter of the name of the street that they grew up on. That way, the technician can positively identify the user without compromising their account’s security in the process.
Windows Active Directory does not natively support self-service account unlocks. Adopting a third-party solution such as Specops uReset is the only way to gain this type of functionality.
Featured image: Shutterstock
