Rotating every local admin password with Intune LAPS

The classic lateral-movement enabler is a single local Administrator password reused across the estate. Dump it from one machine (or find it in a deployment script) and it works everywhere — no privilege escalation needed, just reuse. Windows LAPS (Local Administrator Password Solution) kills that by giving every device a unique, regularly rotated local-admin password, stored centrally so only authorised admins can retrieve it. Deployed through Intune, it applies to your whole managed fleet from one policy.

01The concept

Unique password per device, rotated automatically, escrowed centrally.

Piece	What it does
Managed local admin	A designated local administrator account whose password LAPS owns and rotates
Rotation	The password changes automatically on a schedule (and after each use, if configured)
Backup directory	The rotated password is escrowed to Entra ID (or on-prem AD), readable only by authorised roles
Post-authentication action	After the password is retrieved and used, LAPS can reset it again after a grace period

Why this shrinks the blast radius

With unique per-device passwords, compromising one local-admin credential buys the attacker exactly one machine — not the fleet. And because the password rotates (especially after use), even a retrieved password has a short useful life. You've turned a master key into a set of single-use keys.

02Prerequisites

Get these wrong and the policy applies but nothing is backed up.

# before the policy will actually work
- Windows 10/11 with current LAPS support (in-box on current builds)
- Devices Entra joined or hybrid joined and enrolled in Intune
- Entra ID LAPS ENABLED at the tenant level
  (Entra admin center → Devices → Device settings → "Enable Entra Local
   Administrator Password Solution (LAPS)" = Yes)
- A local admin account for LAPS to manage (built-in or a named one)

The tenant toggle is the one everyone forgets

If Entra ID LAPS isn't enabled at the tenant level, the Intune policy still deploys and reports success on the settings — but the password has nowhere to be backed up to, so retrieval fails. Flip the tenant toggle first. Also make sure the account named in the policy actually exists as a local admin on the devices, or LAPS has nothing to manage.

03The configuration

A Windows device-configuration profile, assigned broadly.

Create an Intune device configuration profile (Windows, LAPS category) and assign it — typically to All devices, since every managed machine benefits. The settings that matter, with sensible values:

Setting	Value	Why
Backup Directory	Microsoft Entra ID only	Escrow the password to Entra for cloud-managed devices
Password Age Days	30	Rotate at least monthly
Administrator Account Name	a named local admin	The account LAPS manages (must exist locally)
Password Complexity	Upper + lower + numbers + symbols	Full character set
Password Length	14	Long enough to resist cracking
Post-Auth Actions	Reset on grace-period expiry	Rotate again after the password is used
Post-Auth Reset Delay	8 (hours)	Grace window before the post-use reset

The post-authentication action is the underrated one: after someone retrieves and uses the password, LAPS resets it again once the grace delay expires — so a password pulled for a legitimate support task doesn't linger as a valid credential.

04Reading the results

Check-in counts tell you coverage; retrieval proves it works.

On the policy's overview, the device and user check-in status shows how many devices Succeeded vs hit Error or Conflict. A large succeeded count with a small error count is the normal healthy picture. But the real proof isn't the count — it's retrieving a password: in the Entra admin center, open a device → Local administrator password recovery, and confirm a rotated password is present and readable. If devices show "succeeded" but no password is stored, that's the tenant-toggle prerequisite biting.

05Failures & remediation

The errors cluster into a handful of causes.

What the errors usually mean

Backup fails / no password stored → Entra LAPS not enabled at tenant level, or the device isn't properly Entra/hybrid joined. Managed account not found → the account named in the policy doesn't exist locally; either point the policy at the built-in admin or create the named account. Conflict → another policy (or legacy on-prem GPO LAPS) is also configuring LAPS on the same devices; remove the duplicate. Stale "error" on a handful of devices → often offline / not-yet-checked-in machines; give them a sync (Company Portal → sync, or Intune → Sync) and re-evaluate before chasing it as a real fault.

Work the errors by grouping them: a uniform failure across all devices points at a prerequisite (tenant toggle, join state); a scattered handful of errors against a mostly-succeeded fleet is almost always device-specific (offline, stale, or a local account mismatch) and clears with a sync or a targeted fix.

The takeaway

Intune LAPS replaces one reused local-admin password with a unique, auto-rotating one per device, escrowed to Entra where only authorised admins can read it — so one cracked credential no longer owns the fleet. Enable Entra LAPS at the tenant level first (the #1 gotcha), deploy the config profile to All devices, prove it by actually retrieving a password, and triage errors by whether they're uniform (a prerequisite) or scattered (device-specific).