A Practical Guide to Windows LAPS — Retiring the Shared Local Administrator Password Across All PCs

PC provisioning work has a long-standing shortcut that never quite goes away: bake a shared local administrator password into the master image and roll it out to every machine. As a procedure it looks entirely reasonable — when you need to do maintenance, you simply log on with that password. But this setup has become one of the first things attackers go after, because it amounts to mass-producing a single master key: compromise one machine, and you have effectively compromised all of them.

This article is aimed at IT staff at small and medium-sized businesses, and at developers who handle PC provisioning and maintenance. It lays out why a shared local administrator password is dangerous, then, based on primary-source documentation as of August 2026, walks through the mechanics of the OS-built-in solution — Windows LAPS (Local Administrator Password Solution) — how to choose a configuration for each environment, the rollout procedure, and the operational pitfalls. It is the latest instalment in our IT-department security series, following on from BitLocker, the retirement of WSUS, firewalls, and the certificate store.

1. The Bottom Line First

• A shared local administrator password across every PC is fertile ground for lateral movement, spreading the compromise of one machine to all of them. If the password is the same everywhere, the NTLM hash is the same everywhere too — extract the hash from one machine and an attacker can Pass-the-Hash their way into the rest.¹
• Windows LAPS is a built-in OS feature that randomises the local administrator password per machine and rotates it automatically. Microsoft lists protection against Pass-the-Hash and lateral-movement attacks as its foremost benefit.¹
• It is built into Windows 10/11 from the 11 April 2023 update onward, and into Windows Server 2019/2022 and later. Unlike legacy LAPS (distributed as an MSI), no additional installation is required. Legacy LAPS was deprecated as of Windows 11 23H2.¹
• The password is stored in either Active Directory or Microsoft Entra ID — one or the other. Domain-only-joined machines store to AD, Entra-only-joined machines store to Entra ID, and hybrid-joined machines choose one or the other. It cannot be used on workgroup machines joined to neither.¹
• By default, nothing happens. BackupDirectory defaults to “Disabled”, so Windows LAPS only starts working once you set a policy (GPO, or Intune/CSP) that explicitly names a storage destination.²
• AD storage needs three pieces of preparation up front: schema extension (Update-LapsADSchema), granting computers write permission on their own password attribute (Set-LapsADComputerSelfPermission), and designing read permissions (Set-LapsADReadPasswordPermission).³
• Retrieve the password with Get-LapsADPassword / Get-LapsAADPassword, force immediate policy application with Invoke-LapsPolicyProcessing, and trigger an immediate rotation on the machine itself with Reset-LapsPassword.⁴
• A password that has been used is automatically discarded. After authentication with the managed account, a reset plus sign-out (PostAuthenticationActions) runs 24 hours later by default.²

2. Why a Shared Local Administrator Password Is Dangerous

Let’s pin down the threat model precisely first. What actually happens when you give the local administrator account — whether the built-in Administrator account or a maintenance account created during provisioning — the same password on every machine?

Windows does not store a local account’s password as such; it stores the NT hash computed from the password. And in NTLM authentication, that hash itself is the material used for authentication. In other words, if the password is the same, the hash is the same on every machine too. Once an attacker gains administrator rights on one machine, via malware or a targeted attack, they can pull the hash out of that machine’s memory or its local database (the SAM). From there it’s game over: the extracted hash can be used to authenticate as-is, with no need to reverse it back into the plaintext password. This is the Pass-the-Hash attack. In a shared-password environment, the hash obtained from one machine becomes a “master key” to all the others, and the compromise spreads sideways in one move. The mechanics of NTLM authentication, and why a hash alone is enough to authenticate, are explained in detail in “NTLM and Kerberos Explained with Diagrams”.

flowchart TB
    subgraph BEFORE["Shared-password environment"]
        A1["PC-01 compromised<br/>malware, targeted attack"] --> H["Attacker obtains admin NT hash"]
        H -->|"Pass-the-Hash"| B1["PC-02"]
        H -->|"Pass-the-Hash"| B2["PC-03"]
        H -->|"Pass-the-Hash"| B3["...lateral movement to every machine"]
    end
    subgraph AFTER["After adopting LAPS"]
        C1["PC-01 compromised"] --> H2["Attacker obtains PC-01's hash"]
        H2 -->|"Password differs per machine, so"| STOP["Hash does not authenticate<br/>on other PCs - blocks lateral<br/>movement via local admin"]
    end

The direction of the fix is clear: give every machine a different local administrator password, and change it regularly. Do that, and even if one machine’s hash leaks, it is useless against the others — you close off the lateral-movement route that runs through a reused local administrator account. (Bear in mind this does not close every lateral-movement route — theft of domain credentials cached on a compromised PC, for instance, is a separate problem.) But doing this by hand is not realistic. Generating individual passwords for dozens of machines, tracking them in a register, and rotating them on a schedule — the sheer operational cost of that is exactly why the shared-password shortcut has survived for so long. Windows LAPS is the OS taking on this “automate individualisation and periodic change”, packaged together with secure storage in a directory. Microsoft itself lists “protection from Pass-the-Hash attacks and lateral-traversal attacks” as the foremost benefit of Windows LAPS.¹

For the more basic privilege-management principle — not doing day-to-day work under an administrator account in the first place, and keeping maintenance accounts narrowly scoped — see also “When Do You Actually Need Administrator Privileges on Windows?”.

3. What Is Windows LAPS — How It Differs From Legacy LAPS

The name LAPS carries some history, and in practice a conversation goes nowhere unless you’re clear about which LAPS you mean.

Legacy LAPS (legacy Microsoft LAPS) is a separately-installed tool that Microsoft released in 2016.¹ The configuration — deploy an MSI package to every machine to install a Group Policy client-side extension (CSE), then store the password in plaintext in Active Directory’s ms-Mcs-AdmPwd attribute — was the de facto standard for a long time.

Windows LAPS is its successor: a separate implementation built into the OS. It’s included in Windows 10, Windows 11 21H2/22H2 from the 11 April 2023 update onward, and in Windows Server 2019/2022; Windows 11 23H2 and later, and Windows Server 2025 and later, ship with it from the start.¹ In other words, if you’re applying updates normally, Windows LAPS is already sitting on your company’s PCs. All that’s left is to configure a policy.

The important point is that Windows LAPS is not a revised version of legacy LAPS but a completely separate implementation, with its own AD schema attributes (msLAPS-*) distinct from legacy LAPS’s.⁴ To help with migration from legacy LAPS, an “emulation mode” is also provided, in which Windows LAPS interprets legacy LAPS’s GPO settings and runs from them — but it comes with a lot of restrictions (Section 6), and there’s no reason to deliberately use it for a fresh deployment.

4. Where the Password Is Stored — A Decision Table by Environment

Windows LAPS “backs up” the password it generates to a directory. The storage destination is determined by the machine’s join state, and you cannot store to both AD and Entra ID.¹

For AD storage, the password is written into an attribute on the computer object — msLAPS-Password in plaintext, msLAPS-EncryptedPassword if encryption is enabled, and the expiry into msLAPS-PasswordExpirationTime.⁶ Of these, the attributes that contain the password itself (msLAPS-Password and the encryption-related msLAPS-Encrypted* attributes) are marked confidential, and cannot be read with ordinary read permission. The expiry attribute msLAPS-PasswordExpirationTime, by contrast, carries no confidential marking (SearchFlags: 0) and is metadata readable with default read permission.⁶ Encrypted storage and password history require domain functional level (DFL) 2016 or higher.³ One thing to watch for is that the encryption setting (ADPasswordEncryptionEnabled) defaults to enabled.² Encryption doesn’t work on a domain whose DFL is older than 2016, so don’t rely on it silently falling back to plaintext — explicitly disable encryption in policy and configure storage as plaintext plus ACL protection instead.³

For Entra ID storage, the standard configuration is to enable “local administrator password management” on the tenant side, then distribute the policy from Intune via the LAPS CSP. On the licensing side, the Windows LAPS feature itself is free, AD storage has no additional requirements, and Entra ID storage is available on Microsoft Entra ID Free or above.¹

There’s no getting around the lack of an alternative for workgroup machines — without a directory to store to, there’s nothing to be done. In practice this means a manual approach: set a different password per machine at provisioning time and keep a register in a password manager or similar. If your provisioning is already scripted, the surest approach is to build per-machine password generation into that script (see “Automating PC Provisioning With winget + PowerShell”).

5. Rolling It Out in Practice — Centred on an AD+GPO Configuration

This section walks through the actual steps centred on an AD domain + GPO configuration, since that covers the most common case. The differences for an Entra + Intune configuration are summarised at the end.

5.1. Prerequisites (One-Time Setup)

For AD storage, complete the forest-side preparation before distributing any policy.³

# 1. Schema extension (once per forest; run with Schema Admins rights)
Update-LapsADSchema

# 2. Grant computers under the target OU permission to update their own password attribute
Set-LapsADComputerSelfPermission -Identity "OU=CorporatePCs,DC=example,DC=co,DC=jp"

# 3. Grant a group permission to read the password (Domain Admins can read by default)
Set-LapsADReadPasswordPermission -Identity "OU=CorporatePCs,DC=example,DC=co,DC=jp" `
    -AllowedPrincipals @("EXAMPLE\HelpdeskAdmins")

# 4. Grant a group permission to manipulate the password expiry (immediate expiry = force a reset)
#    (needed for Set-LapsADPasswordExpirationTime in 5.4; Domain Admins can do this by default)
Set-LapsADResetPasswordPermission -Identity "OU=CorporatePCs,DC=example,DC=co,DC=jp" `
    -AllowedPrincipals @("EXAMPLE\HelpdeskAdmins")

# 5. Check for unexpected holders of read permission (details in Section 6)
Find-LapsADExtendedRights -Identity "OU=CorporatePCs,DC=example,DC=co,DC=jp"

If you’re using encrypted storage (DFL 2016+, enabled by default), one more setting is needed. Read permission and decryption permission are separate things, and by default only Domain Admins can decrypt.³ If you want the help desk group to actually be able to retrieve the password, also specify that same group (EXAMPLE\HelpdeskAdmins) in the policy’s ADPasswordEncryptionPrincipal.² Forget this, and even after granting read permission exactly as above, you end up in a state where the attribute can be read but not decrypted.

Update-LapsADSchema is a separate thing from legacy LAPS’s Update-AdmPwdADSchema, and what it adds are the msLAPS-* attributes. Even in an environment that already has legacy LAPS deployed, the Windows LAPS schema extension is required again.⁴ Note also that if you use a GPO Central Store, Windows Update does not copy the Windows LAPS templates into the Central Store, so you need to copy them there manually.² When doing this, copy not just %windir%\PolicyDefinitions\LAPS.admx but also the language resource LAPS.adml (in the ja-JP subfolder for a Japanese UI, or the corresponding folder for your locale) into the matching language folder. Without the ADML file, the LAPS policy display in the GPMC will show a resource error.

5.2. Configuring Policy

The GPO setting location is Computer Configuration > Policies > Administrative Templates > System > LAPS.² At minimum, you must specify the storage destination — until you set BackupDirectory to “Active Directory” (value 2), Windows LAPS does nothing (the default is “Disabled”).² The main settings and their defaults are as follows.

One thing that’s easy to overlook here is whether the managed account is enabled or disabled. The built-in Administrator account is disabled at the point of Windows Setup.⁷ Windows LAPS will manage a password for an account that stays disabled, but it does not enable the account for you.² So under the default configuration, you can end up with the password sitting in the directory while nobody can actually sign in with that account. To use it as a recovery mechanism, explicitly choose one of: enable and operate the built-in Administrator account; put an already-enabled custom maintenance account under management; or, on Windows 11 24H2 / Server 2025 and later, manage the enabled state itself via the automatic account management settings (the AutomaticAccountManagement family).²

5.3. Verifying Operation and Retrieving the Password

Windows LAPS processes an effective policy once an hour. If you want to check without waiting for that, run an immediate processing pass on the target machine.³

# On the machine: process the policy immediately (the standard move when testing)
Invoke-LapsPolicyProcessing

# On the machine: check the results in the event log
# 10003 = processing started / 10004 = success / 10005 = failure / 10018 = successfully saved to AD
Get-WinEvent -LogName "Microsoft-Windows-LAPS/Operational" -MaxEvents 20

Retrieve the stored password from an administrative machine that holds the necessary permissions.³

# Retrieve the password from AD (without -AsPlainText the string stays masked)
Get-LapsADPassword -Identity PC-0123 -AsPlainText

# Example output: returns Account, Password, PasswordUpdateTime, ExpirationTimestamp,
#                 Source (EncryptedPassword for encrypted storage), AuthorizedDecryptor, etc.

For those who prefer a GUI, a LAPS tab is added to a computer’s Properties dialog in Active Directory Users and Computers, and you can look it up from there too.¹

5.4. Immediate Rotation

When you’ve finished using a password for maintenance work, or if you suspect a compromise, rotate it immediately instead of waiting for the next scheduled rotation.³

# From an administrative machine: set the expiry to "now" so the next processing pass rotates it
Set-LapsADPasswordExpirationTime -Identity PC-0123
# Kick off immediate processing on the target machine and it switches to a new password on the spot
Invoke-LapsPolicyProcessing

# To rotate immediately directly on the target machine
Reset-LapsPassword

5.5. Differences for an Entra + Intune Configuration

Entra ID storage needs no schema extension or ACL configuration like AD does.³ Instead, you need to enable local administrator password management under Device settings in the Microsoft Entra tenant — forget this and machines will be unable to store their passwords.⁵ Distribute policy from Intune via the LAPS CSP, and retrieve the password from the Entra admin center / Intune admin center, or via Get-LapsAADPassword over Microsoft Graph.⁵

# Retrieve an Entra ID-stored password via Graph (example: delegated access)
# Explicitly request the scopes needed at connection time
Connect-MgGraph -Scopes "Device.Read.All","DeviceLocalCredential.Read.All"
Get-LapsAADPassword -DeviceIds PC-0123 -IncludePasswords -AsPlainText

Where AD’s successful-save event ID is 10018, for Entra ID it’s 10029.⁸

6. Operational Pitfalls

Deployment is not the end of the story. Here, in order, are the pitfalls that actually trip people up in the field.

6.1. Read Permission Is Wider Than You Think

Because the password attribute is marked confidential, ordinary read access doesn’t reveal it — but a principal holding Extended Right All Extended Rights on the target OU can read it. In environments that delegated broad permissions to an OU in the past, this tends to leave unexpected groups able to read the password. At deployment time, enumerate the holders of extended rights with Find-LapsADExtendedRights, and if anyone other than SYSTEM and Domain Admins turns up, review the delegation.³

In addition, enabling encrypted storage (ADPasswordEncryptionEnabled) lets you separate read permission from decryption permission. Granting read permission alone does not let anyone decrypt the encrypted password; by default only Domain Admins can decrypt, and to change that you specify the group that can decrypt via ADPasswordEncryptionPrincipal.³ Design fine-grained restrictions such as “the help desk can only decrypt passwords for the OU they’re responsible for” around this two-tier structure.

6.2. The “Use It, Lose It” Mechanism and Its Limits — PostAuthenticationActions

There’s no point in a password the help desk retrieved if it just sits around on a sticky note or in a chat log. Windows LAPS detects authentication with the managed account, and once a grace period (PostAuthenticationResetDelay, 24 hours by default) has elapsed, it automatically cleans up after itself. The default action is “reset the password and sign out”.²

There are two things to watch for. First, setting the grace period to 0 disables this feature entirely.² Second, the trigger is “authentication”, not “retrieving the password”. If you pull the password out of the directory but never actually use it, this automatic reset does not fire. The safe approach is to fix it into your operating procedure that, regardless of whether you actually used the retrieved password, you expire it with Set-LapsADPasswordExpirationTime when the work is done.

6.3. Coexisting With and Migrating From Legacy LAPS

The most dangerous thing during the migration period is a state where the same account is managed by both legacy LAPS and Windows LAPS. A configuration where two mechanisms fight over the same account’s password is a security risk and is not supported.⁹ The rules, laid out:

• On a machine where even one Windows LAPS policy is applied, Windows LAPS itself always ignores legacy LAPS’s policy (Windows LAPS takes precedence).⁹ But that’s only a statement about how Windows LAPS interprets things. If legacy LAPS’s CSE (client-side extension) is still installed, the legacy CSE keeps processing the legacy GPO independently. Enable a Windows LAPS policy while the machine is still in scope for the legacy GPO, and you get dual management, with both sides rotating the same account.
• “Emulation mode” — letting Windows LAPS process legacy LAPS’s GPO settings — only works on machines where legacy LAPS’s CSE is not installed. It reuses the legacy environment’s prerequisites as-is (the legacy schema, the legacy ACLs), but newer features such as encryption or Entra storage are not available.⁹
• A machine can start running in emulation mode unintentionally, simply because the OS was updated while a legacy LAPS GPO was still applied to it. If you want to avoid an unexpected password change right after provisioning, you can stop emulation by setting BackupDirectory=0 in the local configuration key.⁹

Migrate in the order: remove the target OU from legacy LAPS’s GPO scope (or uninstall the legacy CSE) → apply the Windows LAPS policy → clean up what’s left of the old GPO and CSE. Turn off the old management before turning on the new, and proceed so that, for every machine, it’s always unambiguous which management regime it falls under. Do it in the reverse order (applying the Windows LAPS policy first) and you get the dual-management problem above on any machine where the legacy CSE is still present.

6.4. Auditing — Recording Who Looked at What, and When

Once you’re centrally storing local administrator passwords, the history of who read them becomes something to audit. On the machine side, everything is recorded to a dedicated event log channel (Event Viewer’s Applications and Services Logs > Microsoft > Windows > LAPS > Operational), where you can check processing started (10003), success (10004), failure (10005), successful save — 10018 (AD) / 10029 (Entra) — and the content of the applied policy (10021–10023) among others.⁸ On the AD side, Set-LapsADAuditing configures auditing on the target OU so that access to the password attribute is recorded in the domain controller’s Security log.⁴ For Entra ID storage, track access via Entra’s own audit log and reporting features.¹

7. Summary

• A shared local administrator password across every PC sets up a scenario where the compromise of one machine spreads to all of them via Pass-the-Hash. Per-machine individualisation and automatic rotation is the fix, and Windows LAPS is what delivers it.
• Windows LAPS is already built into Windows 10/11 from the April 2023 update onward, and into Windows Server 2019/2022 and later — no additional installation is required. Legacy LAPS (distributed as an MSI) is now deprecated, so Windows LAPS is the only choice for a new deployment.
• The storage destination is either AD or Entra ID, determined by the machine’s join state. It cannot be used on workgroup machines, which need either manual per-machine management or a rethink of their join type.
• It’s disabled by default. For an AD configuration, prepare the three pieces — schema extension, self-update permission, and read permission — and it only starts working once you set BackupDirectory in a GPO.
• Day-to-day operation is centred on PowerShell: Get-LapsADPassword / Get-LapsAADPassword to retrieve, Invoke-LapsPolicyProcessing to force immediate application, and Reset-LapsPassword for immediate rotation.
• The pitfalls are unexpected read access via extended rights, PostAuthenticationActions not firing on mere retrieval, dual management alongside legacy LAPS, and unaddressed auditing. At deployment time, verify permissions with Find-LapsADExtendedRights and lock in an expiry procedure to run after every retrieval.

Related Articles

• BitLocker Practical Guide — Drive Encryption Starting With Recovery Key Management
• NTLM and Kerberos Explained with Diagrams — Why Authentication Falls Back to NTLM
• When Do You Actually Need Administrator Privileges on Windows? - UAC, Protected Areas, and How to Tell by Design
• Automating PC Provisioning With winget + PowerShell — Making the Runbook Executable
• What Is the TPM in Windows? — An Illustrated Guide to the “Safe That Never Lets Keys Out” and Measured Boot
• What to Do Before Disposing of a Windows PC — A Practical Checklist for Data Erasure, Account Unlinking, and Backups

Related Consulting Areas

KomuraSoft LLC handles writing automation scripts for PC provisioning, setting up endpoint security configuration including Windows LAPS deployment, and building migration plans away from an existing shared-password setup. It’s fine to start from a stage like “we have a provisioning runbook but it only works because one person knows it” or “we want to deploy LAPS but aren’t confident about AD permission configuration”.

• Windows Application Development
• Technical Consulting & Design Review
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

We're already running legacy LAPS (Microsoft LAPS distributed as an MSI). Do we need to do anything?

Start planning your migration. Legacy LAPS is deprecated as of Windows 11 23H2, and on newer OS versions the MSI installation itself is blocked. Current OS versions (Windows 10/11 with the April 2023 update applied, Windows Server 2019/2022 and later) already have Windows LAPS built in, so you can migrate without any additional installation. During the transition you can also have Windows LAPS keep processing the old policy via its "legacy LAPS emulation mode", but that comes with restrictions: it doesn't work on machines with legacy LAPS's CSE installed, and newer features such as encryption and Entra ID storage aren't available. A configuration where the same account is managed by both old and new systems is not supported, so switch over with a clear, machine-by-machine understanding of which system is managing which.

Is it fine to just leave things alone after using a retrieved password?

With the default configuration it does get cleaned up automatically, but not immediately. Windows LAPS has PostAuthenticationActions, which detects authentication (logon) with the managed account and then processes after a grace period; by default the password is reset and the session is signed out 24 hours after authentication. Put the other way round, the same password stays valid and usable until that grace period passes, so it doesn't become invalid the instant you use it. Also, this mechanism fires when you authenticate with the password — not when you merely retrieve it from the directory. What's reliable is explicitly expiring it when the work is finished. For AD storage, expire it with `Set-LapsADPasswordExpirationTime` (this cmdlet is AD storage only). For Entra ID storage, either run `Reset-LapsPassword` on the target machine, or use Intune's local administrator password rotation action.

Can it be used on a PC run as a workgroup machine, joined to neither a domain nor Entra ID?

No. Windows LAPS needs either Active Directory or Microsoft Entra ID as the password's storage destination, and a machine joined to neither has nowhere to back the password up to. If you're going to keep running as a workgroup, the realistic alternative is manual operation: set a different local administrator password per machine and keep a register somewhere secure, such as a password manager. Once the fleet grows, it's time to consider moving to Entra join (+ Intune) or domain join, so you can get the benefit of centralised management, LAPS included.

Who can view the stored password?

For Active Directory storage, by default only members of Domain Admins can view it; you grant permission explicitly to other users or groups with `Set-LapsADReadPasswordPermission`. That said, even though the password attribute is marked confidential, a principal holding Extended Right All Extended Rights on the OU can still read it, so at deployment time always check for unexpected holders with `Find-LapsADExtendedRights`. Enable encryption with `ADPasswordEncryptionEnabled` as well (domain functional level 2016 or higher is required), and you can further narrow decryption to the group specified in `ADPasswordEncryptionPrincipal`. For Entra ID storage, privileged roles such as Global Administrator can view it by default, and retrieving it via Microsoft Graph requires the `DeviceLocalCredential.Read.All` permission.

Does using Windows LAPS require an additional license?

The feature itself is free. Windows LAPS is a standard feature built into supported versions of Windows, and there are no additional licensing requirements for storing passwords in Active Directory. Storage in Microsoft Entra ID is also available under a Microsoft Entra ID Free license or higher. Just be aware that surrounding Entra/Intune-related features — such as an Intune license if you're distributing policy via Intune — may carry their own separate licensing requirements, so check those specifically.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.