Windows LAPS removes the need to reuse local administrator passwords by generating a different password for each managed device, rotating it automatically and storing it in Active Directory or Microsoft Entra ID. A compromised credential is then limited to that device rather than exposing every computer sharing the same password.
Deployment still needs controlled retrieval, tested rotation and reliable recovery. Start by separating those requirements from simply enabling the policy.
Key Takeaways
- Windows LAPS creates a unique local administrator password for each managed device, rotates it on a configured schedule and backs it up to either Active Directory or Microsoft Entra ID.
- Active Directory password encryption requires a Windows Server 2016 domain functional level or later. Schema preparation, computer write permissions, password retrieval rights and decryption rights need separate planning.
- Test policy application, password backup, authorised retrieval and rotation on a pilot device before expanding deployment. A policy assignment alone doesn’t confirm that recovery works.
- During migration, don’t let legacy LAPS and Windows LAPS manage the same account at the same time. Keep a working recovery route until the new configuration is proven, then remove legacy attributes after acceptance.
What Windows LAPS changes
Windows Local Administrator Password Solution (LAPS) manages a designated local administrator account. It generates complex passwords and can rotate them on a configured schedule of 7 to 365 days.
Microsoft’s Windows LAPS architecture supports password backup to Active Directory or Microsoft Entra ID, formerly Azure Active Directory. Each device uses 1 backup directory at a time.
Unique passwords reduce lateral movement through reused passwords or password hashes. They don’t remove malware, restrict every administrator account or replace practical endpoint hardening.
Unlike legacy Microsoft LAPS, which required a separate client, Windows LAPS is the built-in Microsoft LAPS implementation. It’s built into eligible Windows versions through updates released on 11 April 2023, or included in newer releases.
Establish platform and directory prerequisites
Operating system support and Active Directory functional level are separate requirements. Installing a supported operating system does not enable encrypted password storage unless the domain also meets the functional-level requirement.
Use this platform baseline when planning deployment.
| Platform | Windows LAPS availability |
|---|---|
| Windows 11 Pro, Enterprise and Education | Included in newer releases; earlier eligible releases require April 2023 updates or later |
| Windows 10 Pro, Enterprise and Education | Requires April 2023 updates or later, plus an appropriate supported servicing arrangement |
| Windows Server 2019 and Windows Server 2022, including applicable Server Core installations | Requires April 2023 updates or later |
| Windows Server 2025 | Included |
Windows 10 standard support ended on 14 October 2025. Having LAPS installed does not make an unsupported Windows installation secure or supported.
Active Directory password encryption requires a Windows Server 2016 domain functional level or later. Directory Services Restore Mode (DSRM) password management also requires encryption and a supported Windows Server domain controller running Windows Server 2019 or later, including 2022 and 2025.
DSRM protects domain-controller recovery credentials. Those passwords are backed up to Active Directory, not Entra ID.
Prepare Active Directory schema and permissions
Active Directory deployment needs a schema extension, computer write permissions and controlled administrator access. These permissions serve different purposes; granting computers permission to update credentials does not authorise support staff to retrieve them.
Extend the schema once per forest
Use a patched management computer with the LAPS PowerShell module. Confirm the commands are available:
Get-Command -Module LAPS
With Schema Admin privileges, run:
Update-LapsADSchema -Verbose
Type A when prompted to accept all required schema extensions. Allow directory replication before expanding the deployment.
Microsoft’s Active Directory deployment guidance describes the schema and permission sequence. Establish the schema administrator and change owner before starting; ordinary workstation administration rights are insufficient.
Delegate writing, reading and decryption separately
Grant computer self-update rights on the chosen organisational unit (OU) or Computers container. For the domain’s default computer location:
Set-LapsADComputerSelfPermission -Identity (Get-ADDomain).ComputersContainer
For an OU-scoped deployment, supply that OU’s distinguished name instead. Repeat the delegation for each relevant location.
Use Set-LapsADReadPasswordPermission to delegate retrieval to a restricted support group. Review inherited extended rights with Find-LapsADExtendedRights; existing permissions may expose more credentials than intended.
For encrypted passwords, configure the authorised decryptor group as well. Directory read permission and cryptographic authorisation are separate controls, and both must permit the intended administrator.
Configure Windows LAPS through Group Policy
Open Group Policy Management and edit a policy linked to the target computers. The path is Computer Configuration, Policies, Administrative Templates, System, LAPS.
Select storage and password settings
Enable Configure password backup directory and select Active Directory for on-premises storage. Selecting Azure Active Directory chooses Entra ID storage instead.
In Group Policy, explicitly configure Password Settings rather than relying on defaults. A practical starting point is a 24-character password with suitable password complexity and a 30-day rotation interval, adjusted to the organisation’s recovery requirements.
Identify the managed account. Leaving the account-name setting unconfigured targets the built-in Administrator account by its well-known identity, even if renamed.
On systems without automatic account management enabled, specifying a custom account name doesn’t create that account. Provision it first.
Configure encryption and behaviour after use
Enable AD password encryption where prerequisites are met, then restrict authorised decryptors to the approved group. Encrypted password history can retain 0 to 12 previous passwords, as described in Microsoft’s schema reference.
Set password-expiration protection to prevent expiry dates exceeding policy. Configure post-authentication actions and a grace period in hours according to the support process.
Password reset alone doesn’t necessarily end an existing session. Select sign-out or restart actions where required, and account for interrupted maintenance or unsaved work before deployment.
Use Intune for Entra-managed devices
For Entra backup, enable Windows LAPS in the Entra admin centre under Entra ID, Devices, Device settings, using Enable Microsoft Entra Local Administrator Password Solution (LAPS).
Eligible devices must be Entra joined or hybrid joined. Entra-registered-only devices aren’t supported for this backup route.
In the Microsoft Intune admin centre, open Endpoint security, Account protection, then create the Local Admin Password Solution (Windows LAPS) profile. Configure the backup directory, account, password settings and post-authentication actions, then assign a pilot device group.
Entra ID Free supports the identity component. Intune deployment requires an appropriate Intune entitlement, normally Intune Plan 1. Microsoft’s LAPS FAQ confirms that Intune isn’t mandatory for LAPS itself.
Restrict password retrieval through Entra roles or appropriately scoped custom permissions. LAPS recovery also remains separate from Entra emergency access accounts: a local administrator password can’t recover tenant administration.
Verify retrieval, rotation and failures
A saved policy proves configuration, not successful password backup. Before expanding deployment, demonstrate that a pilot device receives policy for Windows LAPS, backs up its password, permits authorised retrieval and completes a subsequent password rotation.
Apply policy and test recovery
For Group Policy deployment, run:
gpupdate /force
Trigger LAPS processing without waiting for its next cycle:
Invoke-LapsPolicyProcessing
In Active Directory Users and Computers, open the computer object’s LAPS tab. Review the password and expiration information using an authorised administrator.
For PowerShell retrieval, replace PC01 with the managed computer name:
Get-LapsADPassword -Identity "PC01" -AsPlainText
This displays the managed local account’s password, not a domain user’s password. Avoid copying the output into tickets, transcripts or shared terminal recordings.
Run Reset-LapsPassword locally on the pilot device to request immediate rotation. Confirm that the stored password changes and the replacement supports approved recovery.
Investigate missing or overdue passwords
Review Applications and Services Logs, Microsoft, Windows, LAPS, Operational in Event Viewer. Event 10004 records successful processing; event 10005 records a failure.
Use the accompanying error details to distinguish missing accounts, write-permission failures, directory connectivity and conflicting policies. Microsoft’s LAPS troubleshooting guidance covers these failure paths.
LAPS processes policy approximately hourly. A device unable to reach its backup directory cannot complete normal backup and rotation; passing the expiry date does not disable the account.
Track overdue passwords alongside endpoint security metrics. Include offline devices and retrieval failures, rather than reporting only how many policies were assigned.
Migrate legacy LAPS without losing recovery
Legacy Microsoft LAPS and Windows LAPS must not manage the same account concurrently. A mixed estate needs a device-by-device transition with a working recovery credential throughout.
Choose direct cutover or separate accounts
For direct cutover, remove the legacy policy and client extension from the pilot device before enabling native policy for that account. Confirm new password backup and retrieval before proceeding.
For a gradual transition, create a separately named local administrator account for Windows LAPS. Legacy LAPS can continue managing the original account until the new route is proven.
Microsoft’s migration guidance supports these approaches. Retain the previous recovery route during testing, but remove unnecessary administrator accounts after acceptance.
Remove old attributes after acceptance
Once Windows LAPS recovery works and legacy processing has been removed, clear the old attributes. Replace PC01 with the target computer name:
Set-ADComputer -Identity "PC01" -Clear ms-Mcs-AdmPwd,ms-Mcs-AdmPwdExpirationTime
Clearing these attributes removes the legacy stored credential; it does not rotate the current password or complete migration by itself.
Document rollback before deployment, and record whether recovery uses the old Microsoft LAPS client or native Windows LAPS policy. Restore legacy management only after disabling conflicting native management for that account. Leave unsupported devices under a separate, documented control until replacement or migration is complete.
Frequently Asked Questions
What does Windows LAPS do?
Windows LAPS manages a designated local administrator account, creates a unique password for each device and rotates it on a configured schedule. It backs up the password to either Active Directory or Microsoft Entra ID.
What does Active Directory need for encrypted password storage?
The domain must meet the Windows Server 2016 domain functional level or later. The deployment also needs the Windows LAPS schema extension and correctly delegated permissions for computer updates, password retrieval and decryption.
Is Intune required to use Windows LAPS?
No. Intune isn’t required for LAPS itself, but deploying a Windows LAPS profile through Intune requires an appropriate Intune entitlement, normally Intune Plan 1. Entra backup supports Entra-joined and hybrid-joined devices, not Entra-registered-only devices.
How can I confirm that Windows LAPS works?
On a pilot device, confirm that it receives policy, backs up its password, allows authorised retrieval and completes a password rotation. Check the LAPS Operational log for processing events and investigate any failures before expanding deployment.
Can legacy LAPS and Windows LAPS manage the same account during migration?
No. For direct cutover, remove the legacy policy and client extension before enabling Windows LAPS for that account, or use a separate account during a gradual transition. Keep the previous recovery route available until the new one is proven.
Make rotation part of controlled recovery
Windows LAPS reduces password reuse when devices receive unique credentials, backup succeeds and retrieval remains restricted. A deployed policy alone is insufficient; overdue rotation and untested recovery leave gaps.
Ask our team to review local administrator access, directory permissions and recovery procedures as part of your IT support or cyber security programme. Establish a working pilot before extending the configuration across the estate.
