Sponsored by Specops Software
Microsoft Active Directory performs a variety of functions, but it is above all else an authentication provider. But what happens if no domain controller is available to authenticate a login request?
When Microsoft first created Active Directory, they realized that there could potentially be situations in which a domain controller failure would make it impossible to log in. Not only would such a failure be an inconvenience for end-users, but it could also prevent the IT staff from being able to log in and fix the problem. As such, Microsoft introduced the cached credentials feature, which allows users to logon even if no domain controller is available to authenticate the logon request.
Today, of course, Active Directory failures are far rarer than they once were. Active Directory has been around for well over two decades now, and in that time, it has become extremely stable and reliable. Even so, cached credentials are perhaps even more relevant today than they were in the early days of Active Directory simply because users’ work has changed.
Early on, users commonly work from domain-joined desktop computers. Over time though, desktops began giving way to laptops, which allow users to work both in the corporate office and remotely. It has become the norm for users to work from home, coffee shops, airports, hotel rooms, and just about anywhere else.
When a user powers up a domain-joined laptop in a remote location, there will not typically be a domain controller available to authenticate the user’s login. The user is only able to log into their laptop because it contains cached credentials.
How do cached credentials work?
Suppose for a moment that a user is working from a domain-joined laptop that is presently connected to the corporate network. When the user logs in, a domain controller authenticates the user’s request. Once this authentication process completes, Windows creates an MD5 hash of the user’s password and stores the hash within the Windows registry at HKLM\SECURITY\Cache. If at a later time the user logs in from a location in which no domain controller is available, the credentials that the user enters during the login process are hashed and then compared against the hash values stored in the registry. If the hashes match, the user has entered the correct password and can log into the device.
If, on the other hand, a remote user who has never logged into that particular device before attempts to log in while the device is in a remote location with no Active Directory access, the user will receive a message stating that there are currently no logon servers available to service the logon request. This happens because the user has not previously logged into the device, and the device, therefore, does not contain any cached credentials for the user.
Can cached credentials cause problems?
Cached credentials are an undeniably useful feature. In fact, they are essential for anyone who works remotely from a domain-joined Windows device. Even so, cached credentials can be something of a double-edged sword. In the right circumstances, cached credentials can lead to end-user confusion and even account lockouts.
These types of problems often stem from the fact that users so often work from more than one device. A user might, for example, use a desktop computer while at work but use a domain-joined laptop when working remotely.
With that in mind, imagine what would happen if a user who is working onsite decides to change their password. Because the user is working from a domain-joined computer that is able to communicate with a domain controller, the user’s password is updated within the Active Directory. Windows also deletes the user’s cached password and replaces it with an MD5 hash of the user’s new password.
Just to make things interesting, let’s assume that the user has left their domain-joined laptop at home. Because the laptop has not recently been connected to the Active Directory environment, its credential cache still contains a hash of the user’s old password. This means that the user now has a password mismatch. Active Directory and their corporate desktop contain one password, while the user’s laptop contains a different password.
At this point, the user can still log into their laptop using their old password. Imagine what might happen, however, the next time the user brings their laptop into the office. Because the laptop is domain-joined, it will always try to use a domain controller for authentication and will only resort to using cached credentials if a domain controller is unavailable. When the user attempts to log into their laptop, they will quite naturally enter the password that they have been using all along. However, because the laptop is now connected to the corporate network, that password becomes invalid. The correct password is the one that the user most recently used on their desktop. In all likelihood, however, the user will simply assume that they mistyped their password and try entering it again. Depending on how many times the user does this, they will eventually lock themselves out of their account, prompting a call to the helpdesk.
Specops uReset to the rescue
The idea that a user who works from multiple devices may experience a password mismatch is not theoretical. It’s a very common problem. Fortunately, Specops has a solution that can keep this issue at bay. Specops uReset automatically synchronizes passwords across all of a user’s devices, updating the local cache at the same time. This can go a long way toward preventing user confusion and account lockouts. But if a user does somehow manage to lock themselves out of their device, Specops uReset contains a self-service mechanism that the user can use to securely change their password and unlock their account without the need for a call to the helpdesk.
Featured image: Shutterstock
