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

When every PC uses the same local administrator password, a credential leaked from one machine becomes a master key for breaking into the others. The maintenance procedure may be simple, but the configuration leaves a path open for a breach to spread sideways.

Replacing that shared password with a different password on every machine, with periodic changes and storage in a directory automated, is what the built-in OS feature Windows LAPS (Local Administrator Password Solution) does. Being present in the OS is not enough to make it run, though. Decide the storage destination, the managed account, the permissions, and the cleanup after maintenance work before you apply the policy.¹²

This article is written for IT staff at small and midsize companies and for developers who take on PC provisioning and maintenance, based on primary sources as of August 2026. It is one installment in a security series for IT departments, following BitLocker, the WSUS deprecation, the firewall, and the certificate store.

1. Decide These First — Storage, Account, Permissions, Cleanup

Separating what you decide at deployment time from what you verify afterward makes the order of the work clear.

If you want to understand the mechanism, start at Section 2. If you are moving ahead with deployment, settle your approach in Sections 3 and 4, then go to Section 5 for AD + GPO, or Section 6 for Entra ID + Intune. If you are currently running legacy LAPS, also check the migration order in Section 8 before you distribute the new policy.

The first point to grasp is that Windows LAPS is disabled by default. It only starts working once you specify a storage destination with BackupDirectory. And “the password was stored” and “recovery work can be done with that account” are two separate things to verify.²

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (31 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. Which Risk Does Windows LAPS Reduce?

2.1. A Shared Password Becomes a Shared NT Hash

What gets managed is a local administrator account: the built-in Administrator, or a maintenance account created during PC provisioning.

Windows keeps an NT hash computed from the local account’s password. In NTLM authentication, that hash is the material used for authentication. So if the password is the same on every machine, the hash is the same on every machine.

Once an attacker takes administrator rights on one machine and extracts the hash from memory or from the local database (SAM), it can be used for authentication without being turned back into a plaintext password. This is the Pass-the-Hash attack. In a shared-password environment, the hash obtained from one machine works on the other machines as well, so the compromise spreads sideways. The authentication mechanism is explained in detail in “NTLM and Kerberos Explained with Diagrams”.¹³

flowchart TB
    subgraph BEFORE["Shared password environment"]
        A1["PC-01 is compromised<br/>(malware or targeted attack)"] --> H["The administrator NT hash is extracted"]
        H -->|"Pass-the-Hash"| B1["PC-02"]
        H -->|"Pass-the-Hash"| B2["PC-03"]
        H -->|"Pass-the-Hash"| B3["…lateral movement to the whole fleet"]
    end
    subgraph AFTER["After deploying LAPS"]
        C1["PC-01 is compromised"] --> H2["The PC-01 hash is extracted"]
        H2 -->|"the password differs per machine"| STOP["This hash cannot authenticate<br/>on other PCs (lateral movement<br/>via the local administrator is blocked)"]
    end

Figure 1: Varying the password per machine cuts off the path that reuses a local administrator hash obtained from one machine on all the others.

2.2. Do Not Do Per-Machine Passwords and Periodic Changes by Hand

The countermeasure is to vary the local administrator password per machine and to change it periodically as well. Generating dozens of passwords individually, recording them in a register, and keeping them updated is a burden, though. That management cost is the background to why shared passwords have been used.

Windows LAPS takes on the per-machine randomization, the automatic rotation, and the storage in a directory all at once. Microsoft, too, lists protection against Pass-the-Hash and lateral-traversal attacks as the foremost of its benefits.¹

What LAPS cuts off is the lateral movement path created by reusing a local administrator account. It does not close the other lateral movement paths, such as domain credentials being stolen from a compromised PC. You also need to keep daily work off administrator accounts and to keep the maintenance account narrowly scoped. See also “When Do You Actually Need Administrator Privileges on Windows?”.

2.3. Legacy LAPS and Windows LAPS Are Different Implementations

Legacy LAPS (legacy Microsoft LAPS) is an add-on tool that Microsoft released in 2016. An MSI installs a Group Policy client-side extension (CSE) on each machine, and the password is stored in plaintext in the AD ms-Mcs-AdmPwd attribute, protected by an ACL.¹

Windows LAPS is its successor, a separate implementation built into the OS. It is included in Windows 10, Windows 11 21H2/22H2, and Windows Server 2019/2022 from the April 11, 2023 update onward, and it ships in the box with Windows 11 23H2 and later and Windows Server 2025 and later. On a matching OS and update configuration, no additional installation is needed.¹

Windows LAPS is not merely a revised version of legacy LAPS; the AD schema attributes it uses are a different set, named msLAPS-*. Even where legacy LAPS is already deployed, the schema extension for Windows LAPS is still required.⁵

There is also an “emulation mode” in which Windows LAPS interprets the legacy GPO, but it exists for migration, and there is no reason to choose it for a new deployment. Section 8 explains its restrictions and the switchover procedure.

3. Choose the Storage Destination From the Machine’s Join State

3.1. The Storage Destination Is Either AD or Entra ID, Not Both

The password that Windows LAPS generates is “backed up” to a directory. It cannot be stored in both AD and Entra ID at the same time.¹

On a workgroup machine there is no directory to serve as a storage destination, so Windows LAPS cannot be used. If you keep operating that way, set a different password on each machine during provisioning and keep the register safely in something like a password manager. If your provisioning is scripted, build the generation of per-machine passwords into it as well. See also “Automating PC Provisioning With winget + PowerShell”.

3.2. With AD Storage, Distinguish the Password Attribute From the Expiration Attribute

With AD storage, the values are written to attributes on the computer object. The password itself and its expiration time are treated differently with respect to confidentiality.⁷

Encrypted storage and password history require domain functional level (DFL) 2016 or higher. The encryption setting ADPasswordEncryptionEnabled, on the other hand, defaults to enabled. In a domain whose DFL is older than 2016, do not count on an automatic switch to plaintext: disable encryption explicitly in the policy and settle on a plaintext plus ACL protection configuration.⁴²

3.3. Keep the License for LAPS Itself Separate From the License for the Management Service

The Windows LAPS feature itself is free. There are no additional licensing requirements for AD storage, and Entra ID storage is available with Microsoft Entra ID Free or higher.¹

The requirements of the surrounding features are a separate matter to check, though, such as the Intune license needed when you distribute policy through Intune. Entra ID storage also requires enabling the feature on the tenant. Section 6 covers the actual steps.

4. Decide the Managed Account and the Policy to Apply

4.1. “Managing the Password” and “Making the Account Usable” Are Different

If you do not specify AdministratorAccountName, Windows LAPS identifies the built-in Administrator by its well-known RID. Specify a name only when you are managing a custom maintenance account. This setting does not create the custom account, so the account itself has to be prepared separately.²

The other thing you need is to check whether the account is enabled or disabled. The built-in Administrator is disabled by Windows Setup. Windows LAPS manages the password of a disabled account too, but in this ordinary configuration it does not enable the account.³²

That makes the state “the password is stored, but you cannot sign in when you need to recover” possible. If you are going to use the account for recovery, explicitly choose one of the following.

4.2. Nothing Starts Until You Specify the Storage Destination

BackupDirectory in Windows LAPS is disabled (0) by default. Specify 2 to store in AD, or 1 to store in Entra ID. Until this is set, the password backup never starts.²

The main settings are summarized below. The description of AdministratorAccountName assumes the ordinary configuration, without automatic account management. In this table, PasswordExpirationProtectionEnabled and ADPasswordEncryptionEnabled are settings for AD storage and do not apply to Entra ID storage.

Settle the configuration approach in this section, and distribute the actual policy only after the storage destination is prepared. For AD, go to the next section; for Entra ID, go to Section 6.

5. Deploying With an AD + GPO Configuration

5.1. Prepare the Forest Schema and the Permissions on the Target OU

With AD storage, prepare the schema and the permissions before you distribute the policy. The schema extension is done once per forest; the self-update, read, and expiration-change permissions are set to match the target OU and the groups responsible.⁴

The OU, domain name, and group name below, and the PC names that follow, are examples. Replace them with the targets in your own environment before running them.

# 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 expiration (immediate expiry = instruct a reset)
#    (needed by Set-LapsADPasswordExpirationTime in Section 7.1; 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 5.2)
Find-LapsADExtendedRights -Identity "OU=CorporatePCs,DC=example,DC=co,DC=jp"

Update-LapsADSchema is a different cmdlet from legacy LAPS’s Update-AdmPwdADSchema. The attributes it adds are different too, so the preparation done for legacy LAPS is not enough.⁵

5.2. Grant Read, Decrypt, and Expiration Change Separately

When you use encrypted storage, granting read permission alone does not let anyone decrypt the password. By default only Domain Admins can decrypt it. If you delegate retrieval to the help desk, also specify that group (EXAMPLE\HelpdeskAdmins in the example above) in the policy’s ADPasswordEncryptionPrincipal.⁴²

Do not stop at the groups you granted. A principal holding All Extended Rights on the target OU can read confidential attributes as well. If a broad delegation from the past is still in place, groups you never intended end up able to read them. List the holders with Find-LapsADExtendedRights, and if anything other than SYSTEM and Domain Admins shows up, review what was delegated.⁴

With encrypted storage you can separate reading the attribute from decrypting it. A design such as “the help desk can decrypt only the passwords for the OU it is responsible for” is built on these two layers.

5.3. Put the Administrative Template in Place and Distribute the GPO

The GPO settings live under Computer Configuration > Policies > Administrative Templates > System > LAPS. In addition to the managed account and the password settings decided in Section 4, specify BackupDirectory = 2. The combination of DFL and encryption is as described in Section 3.2, and the decrypting group as in Section 5.2.²⁴

If you use the GPO Central Store, you also need to copy the template. Windows Update does not automatically copy the Windows LAPS template into the Central Store.²

Copy %windir%\PolicyDefinitions\LAPS.admx together with the LAPS.adml for the matching language. For a Japanese UI, place the ADML from the ja-JP subfolder into the corresponding language folder in the Central Store. Be careful, because the ADMX alone produces a resource error in GPMC.

5.4. Confirm Storage on the Target Machine and Retrieve It From an Administrative Machine

Windows LAPS processes the effective policy once an hour. To check without waiting for it to apply, run immediate processing on the target machine and check the event log.⁴

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

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

The stored password is retrieved by a user on an administrative machine who holds the read and decrypt 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, and so on

Without -AsPlainText, the string can be handled while it stays masked. In the GUI it can be viewed from the LAPS tab in the computer’s properties in Active Directory Users and Computers.¹

Once storage and retrieval are confirmed, also confirm that the account decided in Section 4.1 can be used for recovery. Rotation after retrieval is in Section 7, and reading the logs apart is in Section 9.

6. Deploying With an Entra ID + Intune Configuration

With Entra ID storage, the AD schema extension and the OU ACL settings are unnecessary. Instead, you enable the feature on the tenant and check the read permissions on the Entra ID side.⁶

If the feature is not enabled on the tenant, machines cannot store their passwords. Also, successful storage in AD is 10018, while for Entra ID it is 10029. Check the event that matches your storage destination.⁶⁸

In Entra ID, privileged roles such as Global Administrator can view the password by default. When you retrieve it through Microsoft Graph as well, run the command on a connection that holds the required permissions. The following is an example of requesting the scopes explicitly with delegated access.⁶

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

The enabled state of the managed account needs the same check as in Section 4.1 under Entra ID storage too. For rotation after maintenance work, use the machine-side action or the Intune action described in Section 7.2, not the AD-only expiration-change cmdlet.

7. Rotate the Password After Maintenance Work

7.1. Distinguish Instructing Expiration From the Change Completing on the Machine

After retrieving a password for maintenance work, or when you suspect a compromise, change it without waiting for the next scheduled rotation. For each command, keep where it runs and what it actually completes apart.⁴⁵

With AD storage, use them as follows. The first two commands run in different places.

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

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

The expiration-change command succeeding is not the same thing as the target machine’s password having become new. Check through to the machine’s processing result and the successful-storage log.

7.2. With Entra ID Storage, Change It From the Target Machine or From Intune

Set-LapsADPasswordExpirationTime is for AD storage only. On a machine that uses Entra ID storage, either run Reset-LapsPassword on the target machine or use Intune’s local administrator password rotation action. Take it that a different storage destination also means a different action from the management side.⁶⁵

7.3. The Automatic Reset Follows Authentication, Not Retrieval

Windows LAPS has PostAuthenticationActions, which detects authentication with the managed account and then cleans up once a grace period has passed. By default it performs a password reset plus a sign-out 24 hours later.²

This is not a feature that invalidates the password the instant you use it. During the grace period the same password remains valid. Beyond that, keep the following two points distinct.

So that passwords are not left sitting in notes or chat, fix it into your procedure that once retrieved, the password is rotated explicitly when the work is finished, whether or not it was used. Use the method in Section 7.1 for AD or Section 7.2 for Entra ID, and check the result.

8. Migrate From Legacy LAPS Without Creating Dual Management

8.1. Windows LAPS Taking Priority and the Legacy CSE Stopping Are Different Things

A configuration where the same account is managed by both legacy LAPS and Windows LAPS is not supported. The two mechanisms change the same password against each other, which makes it a security risk.⁹

The two things that are easy to confuse are these.

In other words, “Windows LAPS takes priority, so it is fine to leave the legacy CSE in place” does not hold. If you enable the new policy while the machine is still in the scope of the legacy GPO, you end up with both of them rotating the same account.⁹

8.2. Check the Conditions Under Which Emulation Mode Runs

Emulation mode, which has Windows LAPS process the legacy LAPS GPO, runs only on machines where the legacy CSE is not installed. It uses the prerequisites of a legacy LAPS environment as they are, including the legacy schema and the legacy ACLs, but newer features such as encryption and Entra ID storage are unavailable.⁹

Simply updating the OS can make a machine that still has the legacy GPO start running in emulation mode unintentionally. If you want to avoid an unexpected password change right after provisioning, you can suppress it by setting BackupDirectory = 0 in the local configuration key.⁹

8.3. Remove the Old Management First, Then Enable the New One

Proceed with the migration in this order.

1. Take the target OU out of the scope of the legacy LAPS GPO, or uninstall the legacy CSE, so that the old management is removed.
2. Apply the Windows LAPS policy.
3. Remove what remains of the legacy GPO and the legacy CSE.

The key point is to make which mechanism manages a machine unambiguous, machine by machine. Do it in the reverse order and you create dual management on machines where the legacy CSE remains.

9. Keep the Operational Logs and the Password-Viewing Audit Separate

9.1. On the Machine, Check the Processing, the Storage Destination, and the Applied Policy

Windows LAPS activity is recorded in Event Viewer under Applications and Services Logs > Microsoft > Windows > LAPS > Operational.⁸

You can retrieve them with the Get-WinEvent from Section 5.4. When it “does not work” or the password “cannot be retrieved”, check separately whether the policy is in effect, whether the storage destination is prepared, whether storage succeeded, and whether the retrieving side has read and decrypt permissions.

9.2. On the Directory Side, Record Who Looked and When

A record that a machine rotated normally is no substitute for a history of administrators viewing passwords. Audit the viewing of centrally stored passwords separately.

With AD storage, configure the audit settings for the target OU with Set-LapsADAuditing so that access to the password attributes is recorded in the domain controllers’ Security log. With Entra ID storage, track it through the audit log and reporting features on the Entra side.⁵¹

10. Summary — The Deployment Is Not Over Once the Password Is Stored

Windows LAPS is a mechanism that turns a local administrator password shared by every PC into per-machine management with automatic rotation. It is built into supported versions of Windows, so no additional installation is needed, but it does not run without a policy that specifies the storage destination. Choose Windows LAPS for a new deployment, and plan a migration for legacy LAPS.¹²

Verification of the deployment and of maintenance should extend this far.

Workgroup machines are out of scope for LAPS, so they need either manual per-machine password management or a reconsideration of moving to Entra join or domain join. And what LAPS deals with is the reuse of the local administrator password; it does not prevent the theft of other credentials.

What matters is verifying “it can be stored”, “the staff who need it can retrieve it”, “it can be used for recovery”, and “it can be changed after the work” as a single operational whole.

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, putting endpoint security configuration in order including Windows LAPS deployment, and building migration plans away from an existing shared-password setup. It is fine to start from a stage such as “we have a provisioning runbook but it only works because one person knows it” or “we want to deploy LAPS but are not 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 in its "legacy LAPS emulation mode", but that comes with restrictions: it does not work on machines where legacy LAPS's CSE is installed, and newer features such as encryption and Entra ID storage are unavailable. A configuration where the same account is managed by both the old and the new system 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 acts after a grace period; by default the password is reset and the session is signed out 24 hours after authentication. Put the other way around, the same password stays valid and usable until that grace period passes, so it does not become invalid the instant you use it. Also, this mechanism fires when you authenticate with the password, not when you merely read it from the directory. What is reliable is explicitly expiring it when the work is finished. For AD storage, expire it with Set-LapsADPasswordExpirationTime (this cmdlet is for 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 requires 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 are 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 is time to consider moving to Entra join (+ Intune) or domain join so that you get the benefit of centralized management, LAPS included.

Who can view the stored password?

With Active Directory storage, members of Domain Admins can view it by default, and other users or groups are granted permission explicitly with Set-LapsADReadPasswordPermission. That said, even though the password attribute is confidential, a principal holding All Extended Rights on the OU can still read it, so at deployment time always check for unexpected holders with Find-LapsADExtendedRights. If you also enable encryption with ADPasswordEncryptionEnabled (domain functional level 2016 or higher is required), you can narrow decryption to the group specified in ADPasswordEncryptionPrincipal. With Entra ID storage, privileged roles such as Global Administrator can view it by default, and retrieving it through 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 with a Microsoft Entra ID Free license or higher. Surrounding Entra and Intune features may carry their own licensing requirements, such as an Intune license if you distribute policy through Intune, so check just those.

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.