Windows LAPS Deployment Guide: How to Eliminate Shared Local Admin Passwords and Stop Lateral Movement

Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Shared local administrator passwords are one of the most reliable lateral movement paths in Windows environments. An attacker who dumps credentials from one workstation -- via Mimikatz, a memory-scraping malware, or a compromised backup agent -- can reuse that local admin password to authenticate to every other machine in the fleet via SMB or WMI. LAPS eliminates this by making every machine's local admin password unique and rotating it automatically. Deployment takes under an hour for a domain-joined fleet.
Windows LAPS vs Legacy Microsoft LAPS: Which One to Use
Legacy Microsoft LAPS (download from Microsoft, deployed as an MSI + ADMX templates + AD schema extension) stores passwords in cleartext in the AD attribute ms-Mcs-AdmPwd. Any user with read permission on the computer object can retrieve the password. It works on Windows Server 2003+ and is well understood, but the cleartext storage is a significant weakness.
Windows LAPS (built into Windows since April 2023 cumulative update) stores passwords encrypted in AD using DPAPI-NG, supports Azure AD-joined devices, supports backup to both AD and Azure AD simultaneously, and includes post-authentication actions (auto-rotate after use). It requires:
- Windows 10 22H2 / Windows 11 22H2 / Server 2019 or later (with April 2023 CU or later)
- Domain functional level Windows Server 2016 or later for the encrypted storage feature
If you are on legacy LAPS today: migrate to Windows LAPS. The migration path supports running both in parallel during transition. Legacy LAPS will not receive new feature development.
Check which version is active on an endpoint:
Get-LapsAADPassword -DeviceId (Get-AzureADDevice -SearchString $env:COMPUTERNAME).ObjectId
# If this fails, check if Windows LAPS is configured:
Get-LapsAADPasswordPolicy
# Or for AD-backed LAPS:
Get-LapsDiagnostics
Extend the AD Schema and Configure Group Policy
Windows LAPS requires a one-time AD schema extension before the first policy can be applied.
Step 1: Update the AD schema (run on a DC or from a machine with AD Schema snap-in)
Update-LapsADSchema
# Creates the new LAPS attributes:
# msLAPS-Password (encrypted), msLAPS-PasswordExpirationTime, msLAPS-EncryptedPassword
Step 2: Grant computers permission to write their own LAPS attribute
# Grant the OU containing your workstations
Set-LapsADComputerSelfPermission -Identity 'OU=Workstations,DC=domain,DC=com'
# Repeat for each OU containing managed computers
Step 3: Grant help desk or admins read permission
# Grant a specific AD group permission to read LAPS passwords
Set-LapsADReadPasswordPermission `
-Identity 'OU=Workstations,DC=domain,DC=com' `
-AllowedPrincipals 'DOMAIN\HelpDesk-LAPS-Readers'
Step 4: Configure via Group Policy
Path: Computer Configuration > Administrative Templates > System > LAPS
Key settings:
- Configure password backup directory: Active Directory (or Azure AD, or both)
- Password Settings: Enable -- set complexity, length (minimum 14), age (30 days)
- Do not allow password expiration time longer than required by policy: Enabled
- Enable password encryption: Enabled (requires domain functional level 2016+)
- Post-authentication actions: Reset the password and logoff the managed account (prevents reuse after retrieval)
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Deploy Windows LAPS for Azure AD-Joined Devices via Intune
For cloud-only or hybrid Azure AD-joined devices managed via Intune:
Intune path: Endpoint Security > Account Protection > Create Policy > Windows 10 and later > Local admin password solution (Windows LAPS)
Key settings:
- Backup directory: Azure Active Directory
- Password age days: 30
- Administrator account name: (leave blank to manage the built-in Administrator, or specify a custom account name)
- Password complexity: Large letters + small letters + numbers + special characters
- Password length: 14 minimum
- Post authentication actions: Reset password and logoff
- Post authentication reset delay: 24 hours
Retrieve a password from Azure AD (authorized users only):
# Install Microsoft Graph module if needed
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes 'DeviceLocalCredential.Read.All'
# Get password for a specific device
Get-LapsAADPassword -DeviceIds 'device-object-id' -IncludePasswords
Or via the Azure portal: Azure Active Directory > Devices > select device > Local administrator password.
Retrieve LAPS Passwords and Monitor Access
Retrieve from Active Directory:
# Retrieve the current LAPS password for a computer
Get-LapsADPassword -Identity 'WORKSTATION01' -AsPlainText
# Returns: ComputerName, DistinguishedName, Account, Password, PasswordUpdateTime, ExpirationTimestamp
Or use the LAPS UI tool (Windows LAPS includes a GUI accessible from: Start > Windows LAPS > LAPS UI).
Audit LAPS password retrievals:
Every retrieval of a LAPS password generates an event on the domain controller:
- Event ID 4662 in the Security log with Object Type =
msLAPS-PasswordormsLAPS-EncryptedPassword
Alert on these events and correlate: who retrieved the password, for which machine, and at what time. A help desk engineer retrieving a LAPS password for a machine they have a ticket for is expected. A service account or automated process reading LAPS passwords for 50 machines in five minutes is a red flag.
# Query for LAPS read events on DCs
Get-WinEvent -ComputerName dc01 -FilterHashtable @{
LogName = 'Security'
Id = 4662
} | Where-Object { $_.Message -match 'msLAPS' } |
Select-Object TimeCreated, @{N='User';E={$_.Properties[1].Value}}, @{N='Object';E={$_.Properties[4].Value}}
The bottom line
LAPS is a free, low-effort deployment that eliminates one of the most reliable lateral movement paths in Windows environments. Priority order: deploy Windows LAPS (not legacy) to all workstations first, then servers. Enable encrypted password storage. Configure post-authentication reset so passwords rotate after every retrieval. Audit Event 4662 for LAPS password reads -- this is also your detection mechanism for attackers attempting to read LAPS credentials from AD.
Frequently asked questions
Does LAPS manage the built-in Administrator account or a custom account?
By default, Windows LAPS manages the built-in Administrator account (RID 500, regardless of what it has been renamed to). You can configure LAPS to manage a different named account by specifying the account name in the Administrator account name policy setting. If the specified account does not exist on the endpoint, LAPS will not create it -- the account must already exist. Many organizations create a dedicated local admin account (not the built-in one) and configure LAPS to manage it, leaving the built-in Administrator disabled separately.
Can LAPS passwords be read from AD by a compromised domain account?
With Windows LAPS and encrypted storage enabled, no. The password is encrypted with DPAPI-NG and can only be decrypted by accounts explicitly granted read permission via Set-LapsADReadPasswordPermission. With legacy LAPS, the cleartext password attribute (ms-Mcs-AdmPwd) could be read by any account with Read permission on the computer object, which is often broader than intended. This is a key reason to migrate from legacy LAPS to Windows LAPS with encrypted storage enabled.
Does LAPS work if the endpoint cannot reach a domain controller?
LAPS password rotation requires connectivity to a domain controller (for AD-backed LAPS) or Azure AD (for Azure AD-backed LAPS). If a machine is offline or cannot reach the DC at rotation time, the password is not rotated until connectivity is restored. The existing password remains valid. This means machines that are frequently offline (field laptops, infrequently used systems) may go longer than the rotation interval between rotations. This is expected behavior -- the password is still unique to that machine and still provides lateral movement containment.
Should I enable LAPS on domain controllers?
Yes, but carefully. Domain controllers do have a local administrator account (used for Directory Services Restore Mode, DSRM), and LAPS can manage the DSRM password. This is a separate configuration from workstation LAPS. The DSRM password is critical for DC recovery -- losing it means you cannot perform offline AD repairs. Configure LAPS to manage the DSRM password with a long rotation interval (90 days is common) and ensure retrieval is restricted to your most senior AD administrators.
What is the risk of a LAPS password that is readable by too many accounts?
If the AD attribute storing the LAPS password (ms-Mcs-AdmPwd for legacy LAPS, or the encrypted attribute for Windows LAPS) is readable by a broad group such as Domain Users or a large security group, any compromised account in that group can read the local administrator password for every machine where permissions are applied. This effectively makes lateral movement trivial -- an attacker with any domain user account can enumerate all LAPS passwords and use them to authenticate as local admin on every workstation. Audit LAPS read permission using `Find-AdmPwdExtendedRights -Identity 'OU=Workstations,DC=domain,DC=com'` and restrict read access to only IT Helpdesk and break-glass admin groups.
How do I migrate from legacy LAPS to Windows LAPS without disrupting existing password management?
Windows LAPS (introduced in April 2023 updates for Windows 10 22H2 and Windows 11) uses a different AD attribute (msLAPS-Password) and schema extension than legacy LAPS (ms-Mcs-AdmPwd). They can coexist during migration. Migration sequence: extend the AD schema for Windows LAPS by running Update-LapsADSchema on a Domain Admin account, deploy the Windows LAPS policy via GPO or Intune that targets the new attribute, leave the legacy LAPS policy in place on machines not yet migrated. As each machine processes the Windows LAPS policy it starts writing to the new attribute. Verify the new attribute is populated using Get-LapsADPassword, then remove the legacy LAPS policy from migrated machines. The legacy and Windows LAPS attributes are independent -- the machine writes to whichever attribute its active policy targets. Do not try to run both policies on the same machine simultaneously as this can cause confusion about which password is current.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.

Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.
