Deploy Windows LAPS through Intune without creating policy conflicts

Source fact: what Microsoft documents

Microsoft Intune manages Windows Local Administrator Password Solution through the Windows LAPS configuration service provider. Microsoft documents that CSP settings take precedence over and overwrite settings from other LAPS sources such as Group Policy or legacy Microsoft LAPS. Intune LAPS manages one local administrator account per device and does not create that account. If a named account does not exist, no account is managed; leaving the account name blank targets the built-in local administrator account identified by its well-known relative identifier.

Microsoft recommends one LAPS policy per device and device-group assignments instead of user groups. Conflicting settings can stop processing or prevent the password from being backed up. The policy’s backup directory must be compatible with the device’s join type. A device can apply an incompatible configuration without an Intune policy error while Windows LAPS still fails to escrow the password.

Retrieving a Microsoft Entra-escrowed password, scheduled rotation, and manual rotation produce audit events. Passwords backed up to on-premises Active Directory cannot be viewed from the Intune device pane. Manual rotation requires the documented Intune permissions and a successful prior backup. The action is available for Windows devices; for Microsoft Entra–joined devices, the device must be online when requested. Bulk rotation is not supported.

Licensing and applicability

Users or devices benefiting from Intune generally require applicable Intune licensing. Windows edition, update level, join type, tenant configuration, directory schema, role permissions, and the chosen escrow location affect support. Microsoft Entra and Intune roles should be limited to the minimum password-read, policy, and rotation rights needed.

DSE recommendation: production-safe operational steps

1. Inventory legacy LAPS, Group Policy, CSP, scripts, local account names, join types, current password custody, and administrators who can retrieve credentials.
2. Confirm tenant and device prerequisites and choose Microsoft Entra ID or Active Directory escrow based on supported join state.
3. Create one pilot policy assigned to a device group. Ensure the intended local account already exists and is enabled only where required.
4. Verify policy success, actual password backup, last and next rotation dates, and the appropriate audit records before relying on the password.
5. Grant retrieval and rotation through least-privileged roles. Test that unauthorized staff cannot view the secret and that authorized retrieval is audited.
6. Test manual rotation on an online pilot, confirm the new password is escrowed, and document the effect on the next scheduled rotation.
7. Resolve every conflict before expanding. Monitor policy, device, retrieval, and rotation reports after each deployment wave.

DSE recommends treating a retrieved password as a temporary sensitive secret. Record the business reason, rotate it after use, and investigate unexpected retrieval. Do not delete old policy sources until pilot reporting proves which authority is effective and rollback has been documented.

Official references

• Deploy Windows LAPS policy with Microsoft Intune — policy behavior, precedence, assignment, escrow, retrieval, and rotation.
• Reports for LAPS policy in Intune — policy status, conflicts, device detail, and audited events.
• Microsoft Intune licensing — general user, device, and administrator licensing boundaries.