The challenge of updating locally cached credentials

As organizations work to ensure remote workforce productivity, the issue of cached credentials will inevitably appear, causing a problem for the impacted user, and the IT service desk.

It’s no secret that some material portion of nearly every workforce is functioning remotely. You’ve spent the last few months scurrying to establish remote connectivity, cloud-based productivity, and some form of encompassing security – all to allow your remote employees to get their job done while meeting corporate governance requirements around security and compliance to as best a degree as possible. But with approximately 40% of remote workforces using corporate devices while working from home, there’s an issue that may be just around the corner that is likely on the cusp of becoming an issue that will involve that subset of your entire remote workforce – expiring locally cached credentials.

For those of you new to IT who aren’t familiar with locally cached credentials, here’s the very brief primer: Because the user is remote, they can’t easily (if at all) connect to a domain controller (DC) on the corporate network. So, Windows keeps a copy of the user’s credentials cached on the local device and the user can freely log in locally while remote without needing to connect to the corporate network. Despite Microsoft killing the requirement to require users to change passwords frequently, there are still scenarios where passwords need to be reset:

• Old policy remains in place and a password does expire
• The user’s credential is suspected to have been compromised by insider threat or cyberattack and needs to be administratively reset
• The currently established password is found to be using a compromised/leaked password and is administratively reset
• The user forgets their password (as in, it’s been cached for so long, they don’t even know what it is)

The issue at hand is when the password needs to be reestablished on the Active Directory side of the equation, how do you update the locally cached credentials? The affected user needs to be connected to the corporate network (specifically, to a Domain Controller (DC)) to have a newly established set of credentials cache locally. Now, some of you are already ahead of me thinking, “my users use a VPN and are, therefore, logically on the network, so we’re fine.” But according to a recent study by Proofpoint, only 39% of users have a VPN installed and only 47% of those folks use it consistently. Additionally, many VPN connections to the DC are established post login so not all potential scenarios that may arise will be resolved without IT support.

In short, eventually, the problem of locally cached credentials is going to catch up with you.

So, what are your options to update expired credentials, and what are the security ramifications for each?

First off, because the problem we’re solving for is that the remote endpoint device needs to update the cached credentials, the underlying process is largely the same: The device needs to be logically connected to the corporate network (again, specifically with access to a DC) via VPN, and will need to (assuming you’re running Windows 10) press Ctrl-Alt-Del and choose Change a Password.

When seeing this process in practical application, there are a few scenarios to consider around the updating of locally cached credentials and how each impacts corporate security and IT.

1. Known, Non-Expired Password, Able to Connect – this is the gold standard of possible scenarios. The tech-savvy user simply connects to the VPN, and changes their password, and goes about their day. Pure IT nirvana.

2. Known, Expired Password, Unable to Connect – without third-party password reset solutions, the VPN is a requirement here. The service desk is going to be involved to help facilitate at least the “connecting to the corporate network”, by manually resetting their password to the existing one as a potential solution and having them change it immediately, which can involve helping with finding the keys needed to get to Change a Password.

3. Unknown Password – Putting the connectivity issue aside, this is where true security risk begins. When users don’t know what their password is to begin with, it obviously requires an initial reset by the service desk, and then a password change upon first logon, just like the scenario above. The security risk comes in the form of identifying the user as the credential owner before handing over the reset password. In the first scenario at least, they knew the old password although not a very secure verification method it’s a start. So, in this case, without some form of a second authentication factor that goes beyond, “who’s this?” or “what’s your employee ID?” is really risky.

4. Forced Reset – in cases where IT forces a reset of a user’s credential (again, due to issues like suspecting it has been compromised by cyberattack), the act of working with the user to communicate a newly reset password needs to involve some very specific and secure form of validating the credential owner before handing over the reset password.

Getting cached credential updating correct

The issue here is two-pronged, cached credentials will ultimately lead to an increase in IT support calls and loss in productivity however there is a security issue at hand here. The handoff between the user claiming to be the credential owner and the service desk agent that needs to hand off a temporary password to facilitate the credential update can leave an organization exposed to attacks.

Users within your organization have varying levels of access and, therefore, inherent risk. So, add to the mix here that those with elevated levels of access to sensitive, proprietary, and otherwise valuable information need much more validation than any of the simplistic methods often times utilized at the IT service desk.

Updating the locally cached credentials is a security issue. And the best security is the one the user doesn’t know about. Add to that, the best solution is the one IT doesn’t need to get involved with. It’s obvious, from the scenarios above, the scenario involving a proactive, tech-savvy user meets the criteria. But that just isn’t the reality most of the time. So, there may be a need to look to third-party password self-service solution that integrate with the Windows logon process to help simplify the three unknowns I’ve mentioned in this article: the user’s technical prowess, their ability to connect to the corporate network, and IT’s ability to validate the person requesting a password reset is in fact the credential owner.

Without any third-party solution, the answer is simple: VPN, change the password. When that’s not generally feasible, I recommend you look for a solution that meets your remote workforce where they are while helping to maintain productivity and corporate security.