Campus Active Directory - Windows Endpoints - Caching Credentials for Remote Users

This document is meant for IT technicians and explains how to facilitate caching credentials for end-users on domain-joined Windows OS devices.


Why Cache Credentials?

Caching credentials is a feature in Windows that locally stores an unsalted hash of a user's password. The password itself is never saved, only the hash. This hash can be used to authenticate a login when no domain controllers are available. This can be very useful for mobile workstations that may connect to off-site networks. However it also create issues when first deploying new workstations or when a user's domain password is changed while the workstation is not connected to the domain. The steps below outline methods to resolve these two issues. 


***The latest version of the campus VPN Global Protect agent (5.2.8-23) can allow a secure connection to the campus network, prior to Windows authentication, effectively resolving these issues - Palo Alto documentation for configuring that process can be found here: Deploy Connect Before Logon Settings in the Windows Registry (paloaltonetworks.com) 


These instructions make two assumptions. The first is that you are using a screen sharing software that allows giving control to others. Microsoft Teams and Zoom both have this functionality and have campus licenses. Microsoft Quick Assist is also a free, built-in, Windows tool for screen-sharing and remote control. The second assumption is that your orgUnit in Campus AD or separate AD environment allows credential caching for domain-joined Windows devices.


Target Machine In Technician's Possession

  1. Once the workstation is imaged and set up properly, connect the target machine to a campus network that's open to ad.wisc.edu. (Campus VPN is open to ad.wisc.edu) 
  2. Depending on your imaging process or group policy, remote desktop access may already be allowed on the target device. However, you may want to check that setting by logging into the target machine through remote desktop with your account. If you need assistance with remote desktop settings on the target machine please consult this Microsoft article: Remote Desktop - Allow access to your PC | Microsoft Docs
  3. Begin a MS Teams or Zoom meeting and share the target machine's IP address or computer name with the remote user. To ensure the process is working you can ask the remote user to share their screen.
  4. Make sure the remote user is on the campus VPN or on a network open to the network the target machine is on.
  5. Have the remote user sign into the machine via Remote Desktop with their NetID/username and password to authenticate their credentials on the target machine.
  6. To ensure the credentials are indeed cached have the user run Notepad.exe as a different user, but enter in the same credentials they are presently logged in with. To run Notepad.exe as a different user: 
    • Navigate to C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Accessories
    • On the Notepad shortcut, press Ctrl + Shift + Right-click, and select 'Run as different user' from the context menu
    • Have the user enter their credentials again when the authentication window pops up

Once the above steps are complete. Lock or shutdown the target machine and arrange for pickup or delivery with the user. 


***Please note that Step 6 can be used independently of the previous steps. It can also be used if another person is logged into the target machine***


Password Change When Target Machine Offline & In User's Possession

If a user has changed their NetID password while their target machine is not connected to the domain, their new password will not work on the target machine. In order to fix this you will need to connect the machine to a network open to ad.wisc.edu. This can be done by physically connecting the target machine's NIC to network open to ad.wisc.edu. If this is not possible, you will need some way to login to the device. In some cases the user's old password may still work, or a local administrator account may be utilized. As a reminder local administrator passwords should not be shared and managed by LAPS whenever possible.