October 20, 2026

How to Recover a Locked-Out Windows 11 Laptop When You Don’t Know the Local Admin Password

A step-by-step runbook for broken domain trust, unknown credentials, and account lockouts — from a real incident

By Olatomide "Ola" Olapade

7 min read

A step-by-step runbook for broken domain trust, unknown credentials, and account lockouts — from a real incident

Last month I ran into a situation at work that most IT professionals dread.

A Windows 11 laptop had fallen off the domain network for an extended period. The local admin password was unknown. And when we finally got access, we were greeted with the classic broken domain trust error:

"The trust relationship between this workstation and the primary domain failed."

No working credentials. No password vault entry. No LAPS. Just a locked machine that needed to be back in service.

After working through it I documented every step so neither I — nor anyone else — would have to figure it out from scratch again. This is that document.

Who this is for

  • IT support and sysadmins dealing with locked Windows 11 machines
  • MSPs handling client laptops that have fallen off the domain
  • Help desk engineers dealing with unknown local admin credentials
  • Anyone who has ever stared at a Windows lock screen with no way in

What this covers

  • Booting into WinRE (Windows Recovery Environment)
  • Getting a SYSTEM-level command prompt from the lock screen
  • Resetting the local admin password
  • Handling account lockouts after the password reset
  • Cleaning up the security vulnerability you created (critical — do not skip)
  • Fixing the broken domain trust relationship — two methods

Before you start — check for BitLocker

If BitLocker is enabled on the device, pull the recovery key from AD, Entra ID, or your MBAM/Intune console before starting. This procedure does not itself trigger a recovery key prompt, but it is better to have it in hand before you touch anything.

For Entra ID (Azure AD)-only joined devices — the built-in local Administrator account is disabled by default on those machines. Check whether Intune Autopilot Reset, remote wipe, or LAPS-for-Entra password rotation is a better path before proceeding with the steps below.

Step 1 — Boot into WinRE (Windows Recovery Environment)

If you have physical access:

  1. Power on the laptop
  2. As soon as the Windows logo appears, hold the power button to force a hard shutdown
  3. Repeat 2–3 times — after repeated failed boots, Windows automatically launches Automatic Repair, which leads into WinRE

If you can reach the lock screen:

  • Hold Shift and click Restart
  • This boots directly into WinRE

Step 2 — Open Command Prompt from WinRE

From the blue WinRE screen navigate:

Troubleshoot → Advanced options → Command Prompt

This opens a command prompt running from the recovery environment — not the actual Windows installation. Drive letters will be different here than in normal Windows.

Step 3 — Find the correct Windows drive letter

Drive letters often shift inside WinRE. Do not assume C: is your Windows drive.

Run:

diskpart
list volume
exit

Look for the volume that matches your Windows installation by size and label. Then confirm it:

dir D:\Windows

Adjust the letter (D:, E:, etc.) until the directory listing resolves correctly. In WinRE it is commonly D: or E: — not C:.

Note the correct letter. You will need it in the next step.

Steps 4–6 — Get a SYSTEM-level prompt via the Utilman swap

This is the core technique. It replaces the Ease of Access accessibility tool (utilman.exe) with cmd.exe, which gives you a SYSTEM-privileged command prompt directly from the lock screen — without needing to log in.

Step 4 — Swap the files (still in WinRE)

Using the drive letter you identified in Step 3 — replace D: with your actual letter:

copy D:\Windows\System32\utilman.exe D:\Windows\System32\utilman.exe.bak
copy D:\Windows\System32\cmd.exe D:\Windows\System32\utilman.exe

The first line backs up the original file. The second replaces it with cmd.exe.

Step 5 — Reboot to the lock screen

wpeutil reboot

Let the machine boot normally all the way to the lock screen. Do not attempt to log in yet.

Step 6 — Trigger the SYSTEM prompt

On the lock screen, click the Ease of Access icon in the bottom right corner.

Because utilman.exe was replaced with cmd.exe, clicking this icon now opens a Command Prompt running as SYSTEM — the highest privilege level in Windows, above even Administrator.

Step 7 — Reset the local admin password

From the SYSTEM-level command prompt:

First — list all local accounts to confirm the exact account name:

net user

Do not guess. Account names vary — it might be administrator, admin, localadmin, or something custom.

Reset the password:

net user administrator NewP@ssw0rd!

Replace administrator with whatever name appeared in net user, and NewP@ssw0rd! with your chosen password.

If the built-in Administrator account is disabled:

net user administrator /active:yes

Handling an account lockout after password reset

If you reset the password but login still fails with an "account is locked" error — this is a separate lockout flag, likely set from failed login attempts before you started. The password reset alone does not clear it.

Fix from the same SYSTEM prompt (or re-enter WinRE if you already closed it):

Re-enable the account:

net user administrator /active:yes

If still locked — disable the lockout policy temporarily:

net accounts /lockoutthreshold:0

Verify the account status:

net user administrator

Check the Account active field. If it shows No, re-run:

net user administrator /active:yes

Important notes on lockouts:

  • A machine that fell off the network may still have a cached Group Policy lockout threshold applied locally — even while offline
  • Always confirm the exact account name with net user (no argument) — .\admin and .\administrator are different accounts
  • After regaining access, remember to revert the lockout threshold change if you used net accounts /lockoutthreshold:0

Step 8 — Restore utilman.exe (DO NOT SKIP THIS)

This step is not optional.

Leaving the Utilman/cmd.exe swap in place is a serious standing security vulnerability. Anyone who sits at the lock screen can click the Ease of Access icon and get a SYSTEM-level shell — with full control over the machine, no credentials required.

Once you have successfully logged in:

Boot back into WinRE (Step 1–2) and restore the original file:

copy D:\Windows\System32\utilman.exe.bak D:\Windows\System32\utilman.exe /Y

Confirm the drive letter again — it can shift between sessions.

Optionally remove the backup:

del D:\Windows\System32\utilman.exe.bak

Reboot normally. Confirm that clicking the Ease of Access icon on the lock screen now opens the real accessibility settings — not a command prompt.

If it still opens a command prompt, the restore did not take. Repeat the step and confirm you are using the correct drive letter.

Fixing the broken domain trust relationship

Once you are back in Windows with a working local admin account, you may still see:

"The trust relationship between this workstation and the primary domain failed."

This means the laptop's locally stored machine account password no longer matches what Active Directory has on record. This happens when a machine is offline long enough that the machine account password rotates — AD updates its copy, the laptop keeps the old one, and they no longer match.

You have two options.

Option A — Unjoin and rejoin the domain

No domain console access required. Works from the local machine only.

  1. Log in with your local admin account
  2. Go to Settings → System → About → Domain or workgroup (or right-click This PC → Properties → Change settings → Computer Name → Change)
  3. Switch from the domain to a workgroup — use WORKGROUP as the workgroup name
  4. Reboot when prompted
  5. Log back in with the local admin account
  6. Reopen the same dialog and rejoin the domain — enter domain join credentials when prompted
  7. Reboot again

The machine should authenticate normally after the second reboot.

Option B — Reset the computer account from AD (cleaner)

Requires Active Directory admin access. Does not require a workgroup detour.

In Active Directory Users and Computers:

  • Find the computer object
  • Right-click → Reset Account

On the laptop — from an elevated PowerShell prompt:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Enter domain admin credentials when prompted. This resyncs the machine's secure channel password with AD without a full unjoin/rejoin.

When to use Option A instead of Option B:

  • If the computer account no longer exists in AD
  • If the computer account has been disabled and you cannot re-enable it
  • If Reset Account is unavailable in ADUC

Rejoining checklist

Before attempting either option, confirm:

  • Network adapter is working and can reach a domain controller
  • VPN is connected if the DC is not on the local network
  • The machine's computer account exists in AD and is not disabled
  • You have valid domain join credentials ready

For Entra ID-joined (not traditional on-prem AD) devices: Use dsregcmd /leave then re-register through Settings, or re-enroll through Intune — rather than the AD-specific steps above.

Security notes and caveats

BitLocker: This procedure does not touch boot configuration, so it does not itself trigger a BitLocker recovery prompt. However, any unexpected boot changes mid-process could. Pull the recovery key before starting — it takes 30 seconds and saves a potential second crisis.

Entra ID / hybrid-joined devices: The built-in local Administrator account is disabled by default. Verify whether Intune (Autopilot Reset, remote wipe/retire, or LAPS-for-Entra password rotation) is a better path before using WinRE.

Always complete Step 8. The Utilman/cmd.exe swap is a serious standing vulnerability. Anyone with physical access to the lock screen can get a SYSTEM shell. Restore the original file before the machine leaves your hands.

Lockout policy changes: If you used net accounts /lockoutthreshold:0 to clear a lockout, revert it to the organization's standard threshold once normal domain policy is restored via rejoin.

Prefer LAPS. This entire runbook exists because there was no documented local admin credential and no LAPS implementation. Local Administrator Password Solution (LAPS) — available free from Microsoft — rotates and stores local admin passwords in AD automatically. If you go through this process, make the case afterward for implementing LAPS so you never have to do it again.

Summary — the full sequence

1. Boot into WinRE (force shutdown 2–3 times or Shift+Restart)
2. Troubleshoot → Advanced Options → Command Prompt
3. Find Windows drive letter (diskpart → list volume)
4. Swap utilman.exe with cmd.exe
5. Reboot to lock screen (wpeutil reboot)
6. Click Ease of Access icon → SYSTEM command prompt opens
7. net user → net user administrator NewP@ssw0rd!
8. Log in successfully
9. ⚠️ Boot back into WinRE → restore utilman.exe.bak → reboot
10. Fix domain trust (unjoin/rejoin or Test-ComputerSecureChannel)

Final thought

The fact that this procedure works — that you can get SYSTEM-level access to a Windows machine with just a USB boot or repeated hard shutdowns — is a useful reminder that physical access to a machine is effectively full access unless BitLocker or equivalent full-disk encryption is enabled and enforced.

Document your local admin credentials. Implement LAPS. Enable BitLocker. And if you do need this runbook — make sure you complete Step 8.

If this helped you, I write about practical IT tools and cybersecurity for MSPs and IT consultants. I also built a NIST CSF 2.0 Gap Assessment Toolkit — a browser-based tool that runs a complete security assessment and exports a client-ready PDF report. Check it out on this link — https://cyberposture.gumroad.com/l/itaxw.

Tags: Windows Active Directory Cybersecurity Sysadmin IT Support