Windows LAPS Entra-Integrated Rollout: Local Admin Without Lateral Movement (2026)

The shared local administrator password is the single highest-leverage gap in most Windows fleets. Once an attacker has it - and after years of being copy-pasted into runbooks, ticketing systems and onboarding docs, it is rarely a secret - they can move laterally to every device that uses it. The defence has existed since 2015 (Microsoft LAPS) and was rebuilt and integrated into the OS in 2023 as Windows LAPS, with native Entra ID storage in 2024. In 2026 there is no good reason for a shared local admin password to exist on any new fleet, and a great reason to retire it on every legacy fleet. This guide is the production rollout - the policy CSP for Intune, the RBAC for password retrieval, the recovery story, and the migration path from legacy LAPS or no LAPS at all - with a free PDF cheat sheet of the exact steps.

Why a shared local admin password is the primary lateral-movement vector

The pattern is identical across every Windows-fleet incident report. Attacker phishes a user, lands on the workstation, harvests credentials with Mimikatz or a similar tool, finds the local admin password (cached in LSASS, in the unattend file, in the shared note where IT documented it), and uses Pass-the-Hash or a remote desktop session against every other workstation that has the same local admin. Within minutes the attacker is admin on hundreds of devices. The fix is not "make the password longer" - it is "make every device's password different and rotate them automatically". Windows LAPS does exactly that.

What Windows LAPS actually does

Windows LAPS is built into Windows 11 22H2 and Windows Server 2022/2025. Its job is to:

• Generate a strong random password for a designated local account on each device.
• Set the password on the local SAM.
• Store the password (encrypted at rest) in either Active Directory or Entra ID.
• Rotate the password on a configured schedule (default 30 days), or after the password is read (post-authentication rotation), or after the device backs up.

The password is retrievable only by accounts with explicit RBAC on the device object. Every read is audited. There is one tunable (the password complexity profile) and a small number of policy knobs; everything else is sensible defaults.

AD-joined vs Entra-joined vs hybrid

Three storage backends exist; the choice is dictated by the join type:

• AD-joined (on-prem domain) - passwords stored as encrypted attributes on the computer object in AD (ms-LAPS-EncryptedPassword). Schema extension required (one-time, takes 5 minutes). Requires Windows Server 2016+ schema.
• Entra-joined (cloud-only) - passwords stored as a property on the device object in Entra ID. No schema work, no on-prem dependency. Recommended for new fleets and for any organisation whose endpoints are Entra-joined (most modern Intune-managed shops).
• Hybrid-joined - choose either backend. The recommended pattern is Entra ID storage, because the retrieval tooling (Entra portal, Graph API, Intune) is unified with the rest of the cloud control plane.

You can choose only one backend per device. Pick by join type and stick with it; mixed estates are confusing during incident response.

The policy - Intune CSP and Group Policy

For Intune-managed devices, the policy lives at Endpoint security > Account protection > Local admin password solution (Windows LAPS). The settings that matter:

Backup Directory               : Backup the password to Azure AD only
Password Age (Days)            : 30  (production default)
Administrator Account Name     : LapsAdmin   (custom is safer than "Administrator")
Password Complexity            : Large letters + small letters + numbers + special
Password Length                : 20
Post-Authentication Actions    : Reset the password and logoff the managed account
Post-Authentication Reset Delay: 8  (hours)

For on-prem domain-joined devices the same settings live under Group Policy at Computer Configuration > Administrative Templates > System > LAPS. The semantics are identical; only the policy delivery channel changes.

Two settings deserve a callout. Custom administrator account name: do not use the built-in "Administrator" SID; create a separate account named something like LapsAdmin. Attackers enumerate the well-known account by SID; the custom account does not change the security guarantee, but it adds a small layer of indirection in tooling. Post-authentication actions: this is the killer feature. Once an admin retrieves the password and uses it (which logs into the device), Windows LAPS notices the use and rotates the password. The retrieved credential is therefore good for one session only.

RBAC - who can read the password

Read access is the entire security model. Be deliberate.

For Entra-joined devices, password reads require either the Cloud Device Administrator role on the device, or an explicit Entra ID role assignment with the microsoft.directory/deviceLocalCredentials/password/read action. Assign through Privileged Identity Management (PIM) so the role is just-in-time, not permanent.

For AD-joined devices, the read permission is an ACL on the computer object: ms-LAPS-EncryptedPassword read for the helpdesk group. Use Set-LapsADReadPasswordPermission to set it at an OU level - never grant it at the domain root.

The principle is uniform: name a small group, scope the read permission to a small set of devices, audit every retrieval, expect the audit to be reviewed.

Rotation cadence and post-use rotation

Three rotation triggers exist:

• Schedule (default 30 days) - the device rotates on its own.
• Post-use - after a successful interactive logon with the LAPS account, the device rotates after the configured delay (8 hours is the typical setting; gives the operator time to finish the work and logs them off).
• On demand - Reset-LapsPassword from PowerShell or the Entra portal "Reset" button. Use after every break-glass.

Combine all three: schedule rotates without operator action, post-use rotates after every legitimate use, on-demand handles incidents. The result is that any password retrieved from Entra ID has a single-use, single-session lifetime in practice.

How to retrieve a password (and audit it)

# PowerShell against Entra ID (Microsoft Graph)
Connect-MgGraph -Scopes "DeviceLocalCredential.Read.All"
Get-LapsAADPassword -DeviceName "WIN-DEV-042" -IncludePasswords

# AD-joined
Get-LapsADPassword -Identity "WIN-DEV-042" -AsPlainText

# On the device itself (admin only)
Get-LapsLocalManagedAccountName
Get-LapsLocalPasswordExpirationTime

Every retrieval generates an Entra ID audit-log entry with the actor, the device, the time, and (for the on-demand variant) the post-use trigger. Forward the Audit Logs - DeviceLocalCredential stream to the SIEM and alert on retrievals outside business hours or by accounts not in the helpdesk group.

Recovery scenarios

Three scenarios cover the practical recovery surface:

• User locked themselves out, device online. Helpdesk reads the LAPS password, signs in, fixes the user account. Post-use rotation triggers; password is now invalidated.
• Device offline / cannot reach Entra ID. The last-known LAPS password works locally, but only the helpdesk has it. Once the device is online again the next rotation cycle proceeds.
• Device wiped, rejoining. The Entra-stored password is for the old device record (different device ID); after Autopilot/manual rejoin a fresh password is generated and stored against the new device record.

The recovery story stays the same as before: a documented procedure, scoped permissions, audit on every read.

Migrating from legacy LAPS

If you are running Microsoft LAPS (the 2015 MSI), the migration is in-place and supported:

1. Update the AD schema for Windows LAPS: Update-LapsADSchema. The legacy schema attributes stay in place; the new ones are additive.
2. Configure the new LAPS policy via Group Policy (or Intune if endpoints are Intune-managed). Set BackupDirectory to Active Directory (or Entra ID if you are crossing over).
3. Disable the legacy CSE (Client Side Extension) by removing the legacy LAPS GPO assignment from the OU.
4. Remove the legacy LAPS MSI from devices via your software-management tool (uninstall is silent and reversible).
5. After all devices have rotated under the new policy (allow one rotation cycle - 30 days), the legacy attributes can be cleared.

Run both side-by-side for the rotation cycle to keep a recovery path; do not flip the switch on day one and find out the new CSE has not made it everywhere.

Common pitfalls

• Granting password-read at the domain or tenant root. Scope to OUs / device groups; prefer PIM for just-in-time elevation.
• Leaving the built-in Administrator account managed. Use a custom account name; disable the built-in if not needed.
• Disabling post-authentication rotation. Defeats the main benefit. Keep it on with an 8-hour delay.
• No SIEM forwarding for password retrievals. A read should be a logged event that someone reviews; otherwise you are running LAPS without observability.
• Mixing storage backends in the same fleet. Entra-joined devices to Entra ID, AD-joined devices to AD, hybrid pick one. Mixed retrieval paths are an incident-time confusion.

Audit checklist

1. Every Windows endpoint has a LAPS-managed local admin account (1 pt)
2. Password storage backend matches join type, no mixing (1 pt)
3. Password retrieval requires PIM-elevated role assignment (1 pt)
4. Post-authentication rotation enabled with =< 24h delay (1 pt)
5. DeviceLocalCredential audit log forwarded to SIEM with after-hours alert (1 pt)

5/5 = PASS, 3-4 = WARN, <3 = FAIL.

FAQ

Does Windows LAPS replace the Local Administrator built-in?

It manages whichever local account you point it at. The recommendation is to create a custom account (e.g. LapsAdmin) and disable the built-in Administrator wherever possible.

Does it work on Windows Server?

Yes - Windows Server 2022 and 2025 ship Windows LAPS. Recommended for member servers and standalone hosts; not used for domain controllers (DCs do not have a local admin SAM in the same way).

What if Entra ID is unreachable when I need the password?

For AD-joined devices, AD storage continues to work over the LAN. For Entra-only devices, plan a break-glass for an offline scenario - documented physical-access procedure with a sealed master credential, used twice a decade.

Can I export passwords for auditing?

The intent is the opposite - passwords should not be exported in bulk. Audit the retrieval log, not the credential store.

Does it work with Azure Virtual Desktop?

Yes. Pooled session hosts use the same policy as physical devices; the post-use rotation behaviour is especially useful for shared session hosts.

Related Dargslan resources

• Windows Server 2025 Security Baseline
• Microsoft Graph API MFA Audit
• All free IT cheat sheets