Master in Progress IT blog

Ever had a situation where everything seems to be secure, but sneaky old passwords still work their magic? Recently, we dealt with a curious case from a customer who uses CyberArk to rotate admin credentials daily. Sounds like a solid plan, right? The admins would grab their shiny new password at the start of the day and use it for their daily tasks. Simple, clean, and secure. Or so it seemed.

The Problem: The Ghost of Passwords Past

The issue? Administrators found out they could still use yesterday’s password to elevate tasks on their local machines. They could open a terminal or run any app as admin, using not just the freshly-minted password but also the previous day’s credentials.

The customer was understandably not thrilled. They wanted admins to use only the new password—yesterday’s password needed to stay in the past. But why was the old password still working?

Digging into Event Logs: Sherlock Mode On

Cue our deep dive into the event logs. We found that when admins were using the old password to elevate their tasks, no call was being made to the domain controller. A local authentication was happening instead.

Here’s what we saw in Event ID 4624 (Successful Logon):

SubjectUserSid         S-1-5….
SubjectUserName        SomeUser
SubjectDomainName      SomeDomain
SubjectLogonId         0x3e7
TargetUserSid          S-1-12-1-….
TargetUserName         alex@contoso.com
TargetDomainName       SomeDomain
TargetLogonId          0x123456
LogonType              11
LogonProcessName       User32
AuthenticationPackage  Negotiate

The key here is LogonType 11: CachedInteractive, which means the user logged in using credentials that were stored locally, and no one bothered to check in with the domain controller.

The Root Cause: Cached Credentials Aren’t Playing Fair

After some research (and maybe a few cups of coffee), we discovered this is actually default behavior for elevated tasks. Cached credentials aren’t updated when you run an elevated task with a different account. Even if you change the admin’s group membership in the domain, the cached data on the machine remains, letting the old password through.

The Fix: Taming the Cached Credentials

Luckily, we found a solution! By tweaking the registry, we can force Windows to verify credentials with the domain controller before allowing elevation. Here’s the magic PowerShell script we used:

# Define the path to the registry subkey
$registryPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"

# Check if the registry path exists, if not create it
if (-not (Test-Path $registryPath)) {
    New-Item -Path $registryPath
}

# Define the new registry key and set its value
$registryKey = "InteractiveLogonFirst"
New-ItemProperty -Path $registryPath -Name $registryKey -PropertyType DWORD -Value 1 -Force

# Confirm the value has been set
$registryValue = Get-ItemProperty -Path $registryPath -Name $registryKey
Write-Host "Registry key '$registryKey' set to value:" $registryValue.$registryKey

What’s Happening Here?

• $registryPath: Points to the right spot in the Windows registry.
• Test-Path: Ensures the registry path exists before creating anything.
• New-ItemProperty: Creates a new DWORD (32-bit) registry value called InteractiveLogonFirst and sets it to 1.
• Get-ItemProperty: Checks that the value was set correctly.

Setting InteractiveLogonFirst to 1 forces Windows to verify with the domain controller for any elevation task. If the domain controller is unavailable? Well, cached credentials are still used.

But Wait… The “Admin Workaround”

Administrators are clever creatures. If they disconnect from the network, they can still use cached credentials. You can counter this by configuring the machine to not use cached credentials at all. But do you really want to go to war with your admins? Remember, they are the ADMINISTRATORS.

Final Thoughts and Call to Action

This tweak could save you from a lot of headaches if you’re rotating admin passwords and want to avoid yesterday’s ghosts popping up where they’re not wanted. It’s a simple registry fix, but it can have a big impact on how credentials are handled in your environment.

Have you run into any strange caching behaviors in your environment? Or maybe you’ve got an interesting workaround? Share your experiences in the comments below!

Stay secure, stay smart, and don’t let yesterday’s passwords haunt you!

References

• Default behavior for cached credentials
• Logon types