Introduction
Local administrator accounts are one of those things that every Windows administrator needs, but few security teams are comfortable leaving unmanaged.
In many organizations, devices still contain powerful local accounts such as Administrator, admin, or a dedicated support account. When the same password is used across hundreds or thousands of machines, that convenience can quickly become a security problem. A compromised password on one workstation can become a stepping stone to other systems.
This is where Windows Local Administrator Password Solution, better known as Windows LAPS, comes in.
Windows LAPS is Microsoft's built-in capability for automatically managing local administrator passwords on supported Windows devices. It can generate and rotate passwords automatically, control how long passwords remain valid, and securely back up those credentials to either Windows Server Active Directory or Microsoft Entra ID.
For organizations running a hybrid identity environment, however, deploying LAPS is not simply a matter of switching on a policy. The real challenge is deciding where passwords should be stored, how administrators should retrieve them, how permissions should be controlled, and how the rollout should be introduced without disrupting support operations.
This article walks through that problem from an infrastructure and security perspective.
What Windows LAPS Actually Solves
The fundamental problem LAPS addresses is password reuse.
Imagine an organization with 1,000 Windows computers. Each computer has a local administrator account called Administrator, and all 1,000 machines use the same password.
That might make life easier for IT support, but from a security perspective it creates a large blast radius.
If an attacker obtains that password from one machine, the same credential may work on hundreds of others. The attacker does not necessarily need to compromise a domain administrator account. A local administrator credential can provide enough access to move laterally, deploy malware, disable security controls, dump credentials, or establish persistence.
LAPS changes this model.
Instead of maintaining one shared password, each device receives its own unique local administrator password. Windows LAPS automatically manages that password and periodically rotates it according to the policy configured by the organization.
The result is a much smaller security blast radius.
A compromised password becomes a problem for one machine rather than an organization-wide reusable credential.
That is the most important security benefit of LAPS.
Why Hybrid Environments Make LAPS More Interesting
A traditional Active Directory environment is relatively straightforward. Devices are domain joined, Group Policy is readily available, and administrators are accustomed to working with Active Directory as the source of identity and device information.
Modern enterprises are rarely that simple.
Many organizations now operate a hybrid environment where devices are joined to on-premises Active Directory while also being registered as Microsoft Entra hybrid joined devices. Intune may be managing endpoint policies while Active Directory continues to provide traditional domain services.
This creates an important architectural decision:
Where should the LAPS password be stored?
Microsoft supports Windows LAPS backups to either Windows Server Active Directory or Microsoft Entra ID. A hybrid-joined device can use either destination, but it cannot back up the same LAPS password to both at the same time.
That one design decision has consequences for administration, recovery, security and troubleshooting.
Understanding the Two Storage Models
Windows Server Active Directory as the LAPS Password Store
With the Active Directory model, the managed password is stored against the computer object in on-premises Active Directory.
This approach fits organizations that still rely heavily on traditional domain infrastructure and have their support processes built around Active Directory.
Administrators can use Windows LAPS PowerShell commands such as:
Get-LapsADPassword -Identity COMPUTERNAME -AsPlainText
Microsoft also provides specific PowerShell commands for configuring the required Active Directory permissions. For example, computer accounts need appropriate permissions to update their own LAPS information, while designated administrators or support groups should receive controlled password-read permissions.
The major advantage is operational familiarity.
Your existing infrastructure team can continue using Active Directory-based workflows, while access to passwords can be delegated to a dedicated security or help-desk group instead of giving everyone Domain Admin privileges.
This model is particularly attractive when machines must continue operating reliably in environments where on-premises Active Directory remains critical.
Microsoft Entra ID as the LAPS Password Store
The second model is to back up LAPS credentials to Microsoft Entra ID.
This is particularly useful for organizations moving toward cloud-managed endpoints and Microsoft Intune. Intune can configure Windows LAPS, rotate the password and provide an administrative interface for viewing password information where the administrator has sufficient permissions.
Microsoft also provides the Get-LapsAADPassword PowerShell cmdlet for retrieving credentials stored in Microsoft Entra ID.
For example:
Get-LapsAADPassword -Identity COMPUTERNAME
Microsoft Entra provides granular permissions for LAPS retrieval. A custom role can be granted permission to read LAPS metadata without necessarily giving it permission to retrieve the password itself. The password-reading permission is:
microsoft.directory/deviceLocalCredentials/password/read
while the metadata-only permission is:
microsoft.directory/deviceLocalCredentials/standard/read
This is important because the ability to see that a password exists is very different from the ability to retrieve the actual credential.
The Architecture I Would Use in a Hybrid Environment
There is no universal answer for every organization.
The correct design depends on where endpoint management is heading.
If an organization is heavily dependent on on-premises Active Directory, traditional domain support and on-premises administrative workflows, backing up LAPS passwords to Active Directory is a logical choice.
If the organization is moving toward Intune, Microsoft Entra ID and cloud-first endpoint management, using Microsoft Entra ID as the backup directory can provide a cleaner long-term architecture.
The important point is not to configure both.
A hybrid-joined device can back up its LAPS password either to Active Directory or Microsoft Entra ID, but not to both.
For a modern hybrid organization, I would make the decision based on the target operating model rather than simply copying the existing infrastructure.
If the long-term strategy is "Active Directory forever", AD-backed LAPS makes sense.
If the long-term strategy is "cloud-managed Windows endpoints", Entra-backed LAPS becomes more attractive.
LAPS Is More Than Password Rotation
One misconception about LAPS is that it simply changes the Administrator password every 30 days.
That is only part of the solution.
Windows LAPS supports password length, password complexity, password age and post-authentication actions. It can also manage the local account itself on supported newer Windows releases.
Post-authentication actions are particularly interesting.
An administrator might use the LAPS password to perform emergency maintenance on a device. After authentication, Windows LAPS can provide a defined grace period and subsequently reset the password. Depending on the configured policy, it can also sign out the account or restart the computer.
That means the security model becomes:
retrieve credential → perform required administrative task → credential becomes invalid again
rather than:
retrieve credential → continue using the same credential indefinitely
That is a much stronger approach.
A Practical Password Policy
A LAPS deployment should not be designed around the shortest possible password that passes a compliance check.
The password should be long enough to resist offline and automated attacks while remaining compatible with operational requirements.
Windows LAPS supports configurable password length, complexity and password age. It also supports passphrase-based configuration.
For example, an organization might decide that the local administrator password should rotate every 7 days, or use another interval based on its risk profile.
The exact value should not be copied blindly from another organization.
A highly restricted environment may choose a shorter rotation period.
A large enterprise with thousands of devices may prefer a longer interval combined with strong passwords and aggressive post-authentication controls.
The important point is to treat password lifetime as a risk decision rather than an arbitrary number.
The Account Itself Matters
Another area that deserves attention is the local administrator account.
Many organizations already have accounts named:
Administrator
admin
SupportAdmin
LocalAdmin
LAPS can manage a specified local administrator account. It can also support automatic account management on supported versions of Windows 11 and Windows Server, allowing organizations to simplify the management of the built-in account or a custom account.
This creates an opportunity to standardise endpoint administration instead of continuing to maintain several unmanaged local administrator accounts.
One important limitation is that Windows LAPS manages one local administrator account per device at a time. Changing the account targeted by the policy means the previous account is no longer managed by that LAPS policy.
That is something that should be considered before deployment.
Permissions Are More Important Than the Password
A technically correct LAPS deployment can still be insecure if too many people can retrieve the passwords.
This is where least privilege becomes critical.
An organization should not give the entire IT department unrestricted access to every local administrator password.
Instead, access should be delegated according to operational responsibility.
For example, a service desk team might have permission to retrieve passwords for workstation devices, while a server administration team might have access to server OUs.
With Active Directory-backed LAPS, Microsoft provides commands such as:
Set-LapsADReadPasswordPermission
to delegate password-query permissions to specific principals. Microsoft also distinguishes between reading the password and having the necessary permission to decrypt encrypted passwords stored in Active Directory.
The same principle applies in Microsoft Entra ID.
Microsoft Entra supports separate permissions for reading LAPS metadata and reading the actual password, which makes custom least-privilege administrative roles possible.
The password is valuable, but the ability to retrieve thousands of passwords is even more valuable to an attacker.
That permission therefore deserves the same level of attention as other privileged access.
Active Directory LAPS and Entra LAPS: The Security Comparison
From a security perspective, neither storage location should be treated as automatically "more secure" simply because it is cloud or on-premises.
The question is where the organization can enforce the strongest access controls and monitoring.
An Active Directory implementation can be strong when administrative access is tightly delegated, LAPS passwords are protected with the appropriate encryption controls, and the relevant OUs are carefully secured.
An Entra implementation can be strong when Microsoft Entra RBAC, Intune RBAC, privileged identity management, logging and conditional access controls are properly implemented.
The weak point is usually not the technology.
The weak point is excessive administrative access.
A LAPS password that is rotated every seven days but can be retrieved by dozens of unnecessary administrators is still a security problem.
Rolling LAPS Out Without Breaking the Environment
A large LAPS deployment should be treated as an infrastructure change, not simply an Intune policy.
The rollout should begin with discovery.
Before creating the production policy, determine which Windows versions are actually deployed, which devices are hybrid joined, which devices are Entra joined, which devices are domain joined, which local administrator accounts exist, which devices are already using legacy Microsoft LAPS, and which administrative teams currently depend on shared local passwords.
This discovery phase often reveals the real complexity.
For example, an organization may discover that some machines use Administrator, others use admin, and others have a custom support account.
Trying to deploy a single LAPS policy without understanding those differences is how migrations become messy.
Pilot Before Production
The next stage should be a controlled pilot.
A small group of test devices should receive the LAPS policy first.
The goal is not simply to verify that the password changes.
The goal is to verify the entire process.
The device should receive the policy, generate or set the password, successfully back up the credential to the selected directory, allow the correct support team to retrieve it, allow the administrator to use it, rotate the password, and record the appropriate events.
Windows LAPS processes policy periodically, and administrators can trigger policy processing with:
Invoke-LapsPolicyProcessing
This makes testing much easier because administrators do not always need to wait for the next processing cycle.
For an Active Directory deployment, administrators can verify successful updates through Windows LAPS events, including event ID 10018 for successful password updates to Active Directory.
For Microsoft Entra-backed deployments, event ID 10029 can be used to verify successful password backup activity.
The Production Rollout
Once the pilot is successful, rollout should happen in controlled waves.
A good production deployment is not "deploy to 5,000 machines and see what happens".
Instead, begin with a small production OU or Intune device group, review compliance and password-backup success, then expand to additional device groups.
This also makes troubleshooting easier.
If a deployment suddenly shows hundreds of failures, administrators need to be able to identify what changed between the successful and unsuccessful groups.
Phased rollout makes that possible.
What Happens When a Device Is Offline?
This is one of the practical questions that usually comes up during a hybrid LAPS deployment.
The answer depends on which backup directory and management mechanism are being used, as well as the device's connectivity.
A device does not need to be permanently connected to the corporate network simply because it uses LAPS. However, the device must be able to process its policy and successfully communicate with the directory used for password backup.
This is one of the reasons why the backup-directory decision should be made together with the endpoint connectivity and support model.
The architecture should reflect how users actually work, not how the environment looked five years ago.
Monitoring the Deployment
A LAPS deployment should be monitored like any other security control.
The important question is not simply:
"Is LAPS enabled?"
The better questions are:
"Are passwords rotating?"
"Are passwords being successfully backed up?"
"Who is retrieving them?"
"Are there devices that have stopped updating?"
"Are any devices still using unmanaged local administrator passwords?"
"Are administrators using the retrieved credentials for longer than necessary?"
Microsoft provides monitoring options through Intune, event logs, Active Directory attributes and PowerShell. Intune can also show password rotation information and device-level account details to administrators who have the required RBAC permissions.
This is where LAPS becomes part of the organization's broader identity and endpoint security strategy rather than just another configuration policy.
LAPS and Security Monitoring
LAPS should also be considered alongside Microsoft Defender, Microsoft Sentinel and endpoint logging.
A local administrator account suddenly being used on dozens of machines is suspicious.
A password retrieval event followed by privileged activity, remote connections or attempts to disable security tooling may deserve investigation.
The more mature approach is to combine LAPS with endpoint telemetry.
For example, LAPS can control the credential while Defender for Endpoint identifies suspicious activity performed using that credential.
Neither system replaces the other.
They work better together.
What About Legacy Microsoft LAPS?
Organizations that already use the older Microsoft LAPS implementation should plan a migration rather than running the legacy solution indefinitely.
Microsoft recommends migrating existing environments to Windows LAPS. Windows LAPS can coexist temporarily with legacy LAPS, but the policies need to target different local accounts for side-by-side operation.
Microsoft documents two main migration approaches.
The first is an immediate transition where the legacy policy is removed and Windows LAPS is introduced.
The second is a temporary side-by-side deployment using a different local account before the legacy configuration is eventually retired.
Whichever approach is chosen, the migration should be tested before the legacy deployment is removed from production.
Common Mistakes During a LAPS Deployment
The biggest mistake is treating LAPS as a password-change tool.
It is actually an identity security control.
Another common mistake is giving too many people permission to retrieve credentials.
A third is deploying the policy before identifying the actual local administrator accounts in the organization.
Another problem is failing to decide where passwords belong before deployment.
Hybrid environments make this especially important because Microsoft allows hybrid-joined devices to back up passwords to either Active Directory or Microsoft Entra ID, but not both.
A final mistake is failing to test the recovery process.
A password that rotates successfully but cannot be retrieved by the help desk is not a successful deployment.
My Recommended Hybrid Strategy
For an organization that is still heavily dependent on on-premises Active Directory, I would normally start with Active Directory-backed Windows LAPS, provided the organization can properly delegate password access and protect the relevant OUs.
For organizations that are already strongly invested in Intune and are deliberately moving toward cloud-managed endpoints, Microsoft Entra-backed LAPS is a compelling long-term architecture.
The important part is to make the decision based on the organisation's target state rather than its current state.
LAPS should form part of the migration toward stronger endpoint security, not become another legacy dependency.
A Simple Rollout Model
The deployment can be thought of as a sequence rather than a single change.
First, assess the current environment.
Then decide whether Active Directory or Microsoft Entra ID will be the authoritative LAPS password store.
Next, define the local account that LAPS will manage and design the password and rotation policy.
After that, configure the required permissions and test password retrieval.
The pilot should then validate the complete lifecycle from policy deployment to password rotation and administrative recovery.
Only after that should the organization expand the deployment into production in controlled waves.
Finally, monitoring should become part of normal security operations.
This approach dramatically reduces the risk of introducing an endpoint security policy without understanding its operational consequences.
The Bigger Security Picture
LAPS does not solve every local administrator problem.
It does something more specific and arguably more important: it removes the need for organizations to rely on shared, static local administrator passwords.
That single change can significantly reduce lateral-movement risk.
The real value of LAPS appears when it is combined with the rest of the Microsoft security stack.
Microsoft Entra ID provides identity and role-based access control.
Intune provides policy management.
Windows LAPS manages privileged local credentials.
Microsoft Defender provides endpoint visibility.
Microsoft Sentinel can provide broader security monitoring and correlation.
Together, these controls create a much stronger security architecture than any single product could provide.
Final Thoughts
Rolling out LAPS in a hybrid Active Directory and Microsoft Entra environment is not difficult because the technology is complicated.
It is difficult because the environment itself is complicated.
The organization has to make decisions about identity, endpoint management, administrative permissions, password storage, help-desk access, monitoring and migration.
Windows LAPS gives administrators the technology needed to solve the local administrator password problem.
The architecture and governance determine whether that technology becomes a real security improvement.
For organizations still using shared local administrator passwords, LAPS should not be viewed as an optional optimization.
It should be viewed as one of the foundational controls for securing Windows endpoints.
The goal is simple:
Every device should have a strong local administrator credential.
That credential should be unique.
It should rotate automatically.
Only authorized administrators should be able to retrieve it.
And the organization should know when and where that credential is being used.
That is the real value of Windows LAPS.
Top comments (0)