Windows LAPS gives each managed device a unique, rotating local administrator password and stores it in an authorised directory. It solves the shared-password problem; it does not make local administrator access routine or harmless.

Choose the authority

Windows LAPS can back up to Windows Server Active Directory or Microsoft Entra ID depending on join and management design.

  • AD-joined devices commonly use Group Policy and AD backup.
  • Entra-joined devices commonly use Intune and Entra backup.
  • Hybrid-joined, Intune-managed devices can follow the chosen supported policy/backup design.

Document one effective policy authority. Conflicting Group Policy and device-management settings produce uncertainty at exactly the moment recovery is needed.

Define the managed account

Choose whether LAPS manages the built-in Administrator or a separately provisioned local account supported by the current Windows LAPS policy. Confirm the account exists, is enabled only as intended, belongs to the required local group and is not also used by deployment/autologon workflows.

Microsoft warns that immediate password management can break a deployment logged in as the same account. Stage the account, policy and handoff deliberately.

Prepare AD only when AD is the backup directory

An Entra-only design does not need the AD schema preparation. For AD-backed LAPS, verify OS/domain functional level and current schema. Configure:

  • managed-device SELF permission to update its password;
  • narrowly scoped read-password permissions;
  • separate expiry/reset permissions;
  • encrypted-password decryption principal; and
  • audit/monitoring for retrieval and policy failures.

Microsoft strongly recommends encrypted AD passwords where supported. Encryption requires Windows Server 2016 domain functional level or later. DSRM password management also requires AD backup, encryption and supported DC versions.

Do not grant a broad help-desk group access to every workstation, server and DC password. Tier retrieval by device sensitivity.

Separate the privileges

Reading metadata, reading/decrypting the password and forcing expiry/rotation are different authorities. In Entra/Intune, RBAC and Graph permissions similarly distinguish viewing, retrieval and remote rotation.

Give an operator only the action required for their support tier. Monitor privileged group membership and inherited AD extended rights; an unexpected inherited principal can read many device passwords silently.

Pilot the whole lifecycle

For each device class, prove:

  1. policy applies from the intended authority;
  2. the correct local account is managed;
  3. a password backs up to the correct device/computer object;
  4. an authorised operator can retrieve it;
  5. an unauthorised operator cannot;
  6. local sign-in works when domain/cloud access is unavailable;
  7. use and retrieval are audited; and
  8. password rotation occurs after the configured expiry or authentication grace period.

Do not deploy widely after proving only that an attribute is populated.

Use a recovery password safely

Before retrieval, confirm exact device identity and asset owner. Record business reason, ticket/incident, operator and retrieval time without recording the password itself.

Retrieve through the supported AD, Entra or Intune interface using an individually attributable account. Never paste the password into chat, email, scripts, screenshots or ticket notes. Treat screen sharing and clipboard history as exposure paths.

Use the local account only on the intended device and only for the recovery task. After access, request/allow prompt rotation and confirm the directory holds the new expiration/version. End remote sessions and clear temporary credential material.

Plan DSRM recovery before all DCs are down

Windows LAPS can manage DSRM passwords on supported DCs when AD encryption is enabled. The current password is normally retrievable while a DC in that domain is available.

A forest/domain disaster can remove that lookup path. Follow Microsoft’s offline recovery guidance and ensure trusted backups plus protected recovery material can recover DSRM passwords. Test this in an isolated recovery exercise; “stored in AD” is circular if AD is unavailable.

Migrate from legacy Microsoft LAPS deliberately

Inventory legacy client extension, schema attributes, GPOs, permissions and management tools. Follow Microsoft’s migration states and avoid two authorities trying to manage the same account. Verify new Windows LAPS backup and retrieval before retiring legacy policy/components.

Monitor what matters

Alert on policy processing failures, stale/missing backups, unexpected readers, repeated retrieval, rotation failure and privileged permission changes. Regularly test a sample from each device tier without exposing passwords.

LAPS is successful when every managed device has a unique recoverable credential, only the right people can retrieve it, every use is accountable and the secret becomes useless soon after use.