Connect Using Different Credentials: The Admin Password Risk

Picture a normal support visit. A user can't open the finance share, so you sit at their laptop, open Map network drive, tick Connect using different credentials and type your admin account. The drive appears, the user is happy and the ticket gets closed.

The drive works fine. The problem is what happens to the password you just typed. Windows needs those credentials to keep talking to the file server, so it holds on to them. On a machine you don't fully control, with a privileged account, that's a risk most admins never think about.

Quick answer

When you map a drive with Connect using different credentials, Windows keeps those credentials in memory for the session and can save them in Credential Manager. Enable the Group Policy setting Network access: Do not allow storage of passwords and credentials for network authentication, check that Credential Guard is actually running on each device, and keep domain admin accounts off workstations entirely.

What happens when you use different credentials

Two separate things happen, and most people only think about the first one.

Credential Manager may save the password

If Remember my credentials is ticked in the Windows Security prompt, Windows writes the username and password into Credential Manager so the drive reconnects after a restart. That vault is protected with the user's own DPAPI keys. In practice, anything running as that user, including malware from a phishing email, can ask Windows to use those credentials.

Run this on a few desktops and you may be surprised by what's sitting there:

cmdkey /list

LSASS keeps it in memory for the session

Even with that box unticked, Windows still has to authenticate to the share for as long as the drive is connected. So the Local Security Authority Subsystem Service (LSASS) keeps the credentials in memory for that logon session.

Anyone who gets local admin on the PC can dump LSASS memory with freely available tools. Public demonstrations of this exact scenario show the admin username and password readable in the dump, attached to a standard user's session.

The person logged on is a standard user, but the most valuable secret on that machine now belongs to you.

Why the account type changes everything

Exposure is relative. A leaked standard user password gives an attacker that user's mailbox and files. That's bad, but it's contained. A leaked server admin or domain admin password gives them a direct path to the systems everyone depends on.

Account typed into the prompt	What an attacker gets from that PC	Risk
Standard user	The same access the user already had	Low
Helpdesk or workstation admin	Admin rights on other workstations, often many	Medium to high
Server admin (Tier 1)	File servers, application servers, backups	High
Domain admin (Tier 0)	Active Directory and every machine joined to it	Critical

This is why Microsoft's tiered administration model has one simple rule: credentials from a higher tier are never entered on a lower-tier machine. A workstation is the lowest tier there is. It's where phishing links get clicked and unknown USB drives get plugged in.

Local admin access on a Windows PC is already a big deal on its own. I showed how little it takes in resetting a forgotten Windows password with the Utilman method. Put a privileged password in that machine's memory and the damage is no longer limited to one PC.

Fix 1: Stop Windows storing network credentials with Group Policy

Open Group Policy Management, edit a GPO linked to your workstation OU and go to:

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options

Set Network access: Do not allow storage of passwords and credentials for network authentication to Enabled. The registry value behind it is:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
DisableDomainCreds    REG_DWORD    1

Microsoft notes that the change needs a restart, so plan it with your patch cycle rather than expecting it after the next gpupdate.

Be clear about what this setting does. It stops Credential Manager from saving passwords for domain authentication. It does not wipe credentials already held in memory for an active session, and it doesn't remove entries saved before the policy arrived. Clean those up yourself:

cmdkey /list
cmdkey /delete:fileserver01

Expect a little friction. Users will be prompted every time they reach a resource that needs a different account, such as a NAS outside the domain. Scheduled tasks set to run whether the user is logged on or not have to store a password, and this setting can stop them saving it. Link the GPO to a pilot OU first and leave task servers out until you've checked them.

Fix 2: Check Credential Guard is running, not just switched on

Credential Guard uses virtualization-based security to isolate NTLM password hashes, Kerberos ticket-granting tickets and credentials that applications store as domain credentials. Malware running with admin rights in Windows can't read what's inside that isolated environment, which makes the LSASS dump above far less useful.

The catch is the gap between configured and running. Windows 11 version 22H2 and later turns it on by default, but only on Enterprise and Education editions, only on hardware that meets the requirements, and only where nobody disabled it earlier. Windows 11 Pro isn't supported at all. A GPO showing Enabled tells you nothing about a laptop with virtualization switched off in the BIOS.

So check the device itself. There are three reliable ways.

System Information

Run msinfo32 and stay on System Summary. Look for Credential Guard next to Virtualization-based security Services Running. If it only shows next to Services Configured, it isn't protecting anything yet.

PowerShell

From an elevated PowerShell window:

$dg = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
if ($dg.SecurityServicesRunning -contains 1) {
    "Credential Guard is running"
} else {
    "Credential Guard is NOT running"
}

A value of 1 in SecurityServicesRunning means Credential Guard is active. Run the same check through Intune, your RMM tool or remote PowerShell and you'll have a report for every machine in a few minutes.

Event Viewer

Open Windows Logs > System and filter on the source WinInit. Event ID 13 means Credential Guard started and is protecting LSA credentials. Event IDs 15 and 16 are warnings that it was configured but didn't start.

Don't rely on spotting LsaIso.exe in Task Manager. Microsoft says that isn't a reliable check.

Know the limits too. Credential Guard doesn't protect the SAM database or the Active Directory database, and Microsoft doesn't recommend it on domain controllers. It reduces what can be stolen from a workstation. It doesn't make it safe to type a domain admin password on one.

Fix 3: Change the habit that causes it

Settings help, but the real fix is how admin work gets done.

• Fix the access, not the session. If a user needs a share, add them to the right security group and let them map it with their own account. A group change lasts. A drive mapped with your password is a liability.
• Use the right account for the tier. Keep separate accounts for workstation admin, server admin and domain admin, and only use the workstation account on user PCs. Use Windows LAPS so every machine has its own local administrator password.
• Add privileged accounts to Protected Users. Members can't authenticate with NTLM and their credentials aren't cached for offline sign-in. Test first, because anything that still depends on NTLM will break for those accounts.
• Do admin work from an admin workstation or jump server, not from the user's desk.
• If you've already done it, have the user sign out or restart when you finish, which ends the logon session the credentials belong to. If there's any chance the machine was compromised, change that account's password.

Quick checklist

Check	How
Saved credentials on desktops	cmdkey /list
Network credential storage blocked	GPO set to Enabled, DisableDomainCreds = 1
Credential Guard actually running	SecurityServicesRunning contains 1, WinInit event 13
Privileged accounts kept off workstations	Separate tiered accounts, Protected Users group
Unique local admin passwords	Windows LAPS

If you run a small office in Nepal and want someone to check these settings across your machines, it's part of my Office Network Review.

Frequently asked questions

Does unticking Remember my credentials make it safe?

No. It only stops the password being saved in Credential Manager. Windows still keeps the credentials in memory while the drive is connected, and anyone with local admin on that PC can try to extract them.

Is mapping a drive with net use any different?

Not really. Giving net use a username and password hands Windows the same credentials to hold for the session, and the /savecred switch stores them in Credential Manager.

Will this Group Policy setting break mapped drives?

Drives mapped with the user's own domain account keep working. Users get prompted each time for resources that need a different account, and scheduled tasks that store a password can fail, so test it on a pilot group first.

Can I use Credential Guard on Windows 11 Pro?

No. Microsoft supports Credential Guard on Enterprise and Education editions only. On Pro machines, the Group Policy setting, separate admin accounts and Windows LAPS matter even more.