LAPS: Complete Implementation Guide

Introduction: Why LAPS Matters

Shared local administrator passwords are one of the fastest paths to lateral movement and privilege escalation in enterprise environments. A single compromised workstation gives attackers instant admin access to every other machine in the domain using that same password.

LAPS (Local Administrator Password Solution) solves this by:

• Unique passwords per device — Every local admin account gets a randomly generated, unique password
• Automatic rotation — Passwords change on a schedule (30 days default)
• Centralized management — Active Directory stores encrypted passwords; only authorized users can retrieve them
• Breaks lateral movement chains — Even if one workstation is compromised, the attacker cannot use that password anywhere else
• Audit trail — Active Directory logs all password retrievals for compliance

What is LAPS?

LAPS is a Microsoft security solution that manages local administrator account passwords across networked computers. It integrates with Active Directory to rotate and store these passwords securely. Retrieving the password is only possible for authorized administrators, or delegated groups.

How LAPS Works (High Level)

1. Installation — Deploy LAPS agent (Windows Update on Win11/2022, or legacy installer for older versions)
2. Generation — Agent generates a random 30-character password locally
3. Storage — Password is encrypted and stored in Active Directory (computer object) or Entra ID
4. Rotation — Every 30 days (default), a new password is generated and stored
5. Retrieval — Authorized admins query AD or EntraID to retrieve the password via UI or PowerShell
6. Usage — Admin uses the password for remote access, recovery, etc. Password expires in AD after use window

LAPS v1 vs LAPS v2: Key Differences

Microsoft released LAPS v2 in 2023, which is now the recommended approach. Here's how they differ:

Feature	LAPS v1 (Legacy)	LAPS v2 (Modern)
Release	2015	2023
OS Support	Windows Server 2012 R2+, Win10	Windows 11 21H2+, Server 2022+
Deployment	MSI installer via GPO/SCCM	Built-in; enabled via GPO
Password Storage	Active Directory (ms-Mcs-AdmPwd attribute)	Active Directory + option for EntraID
Password Length	4-64 characters	4-64 characters
Authentication Method	Kerberos (AD only)	Kerberos + hybrid support
Supported Machines	Domain-joined only	Domain-joined + Entra-joined + hybrid
Recommendation	Legacy; use if Win10/2012R2 support needed	Use for all new deployments

Prerequisites & Requirements

Infrastructure Requirements

• Active Directory — Windows Server 2008 R2 or later (schema update required for v1)
• Operating Systems:
  • LAPS v2: Windows 11 (21H2+), Windows Server 2022+
  • LAPS v1: Windows 10 (any version), Server 2012 R2+
• Network Connectivity — Machines must reach a domain controller for LAPS operations
• Group Policy — GPO infrastructure for deploying LAPS settings (optional for v2 on Entra-only environments)

Permissions & Security

• AD Schema Admin — Required for initial LAPS v1 schema update (one-time)
• GPO Edit Rights — To create/modify LAPS GPOs
• RBAC for Password Retrieval — Define which groups can retrieve local admin passwords
• No Domain Admin Required — LAPS agents run under SYSTEM, not privileged accounts

Software & Tools

• LAPS Management UI (v1) — GUI tool to retrieve passwords (optional; PowerShell alternative available)
• PowerShell Module — For scripting password retrieval and reporting
• Group Policy Editor — For LAPS configuration

Planning & Design Considerations

Enterprise Deployment Design Model

For enterprise environments, LAPS design is not a single GPO task. It is an identity, operations, and recovery design exercise. The choices below determine whether deployment is sustainable at scale or becomes a recurring incident source.

1. Choose the Right Rollout Pattern

Rollout Pattern	When to Choose It	Strengths	Trade-offs	Enterprise Control Requirement
Phased by Risk Tier (Tier 0/servers first)	Security-driven programs where privileged assets must be hardened first	Fastest reduction of high-impact attack paths	Longer overall rollout timeline	Clear tier classification and explicit exception process
Phased by Business Unit	Federated IT models with separate support teams and change windows	Aligns with operational ownership and local change cadence	Inconsistent policy posture during transition	Central baseline with delegated but auditable local implementation
Big Bang	Small, homogeneous environments with mature endpoint governance	Fast standardization and reduced coexistence complexity	Highest blast radius if scoping or RBAC is wrong	Validated pilot, tested rollback, and staffed incident window

2. Design Decisions and Their Operational Implications

Design Area	Decision You Must Make	If Done Well	If Done Poorly	Recommended Enterprise Pattern
Scope	Which endpoint classes are in policy (Tier 0 servers, member servers, workstations, kiosks, privileged admin workstations)	Predictable coverage and measurable risk reduction	Blind spots where shared local admin credentials remain exploitable	Start with privileged and server tiers, then expand to all managed endpoints
OU and GPO Topology	Whether to split policy by endpoint type, risk tier, or lifecycle state (pilot/production)	Controlled rollout and safer change management	Mislinked GPOs affecting unintended OUs or unsupported device classes	Separate pilot and production GPOs; separate workstation and server policy scope
Password Policy	Rotation interval, length, complexity, and post-authentication behavior	Lower credential exposure with acceptable support overhead	Too permissive increases attack surface; too aggressive breaks operations	Define by tier: stricter rotation and post-auth actions for higher privilege systems
Access Control	Who can retrieve passwords, under what workflow, and with what approvals	Least-privilege retrieval with auditable accountability	Password access sprawl through broad delegated rights	Dedicated retrieval groups, JIT workflow, and mandatory ticket correlation
Legacy Coexistence	How v1 and v2 are separated during transition	Smooth migration with no policy collision	Confusion on retrieval path and inconsistent endpoint behavior	Time-box coexistence with explicit migration milestones and retirement date
Backup Target	Whether passwords are backed up to Active Directory or Entra ID per endpoint class	Aligned retrieval model for each identity plane	Incident delays due to uncertainty about where password data is stored	Use one backup target per endpoint category and document retrieval runbooks
Monitoring and Audit	What events are collected, retained, and reviewed (retrieval, rotation, failures, denied access)	Early detection of misuse and deployment drift	No evidence trail for forensic analysis or compliance proof	Forward LAPS-relevant events to SIEM and alert on anomalous retrieval patterns

3. Minimum Design Artifacts Required Before Pilot

• Scope Map — Endpoint categories, ownership, and rollout waves
• GPO Topology Diagram — OU links for pilot and production paths
• Retrieval RBAC Model — Named groups, approval flow, and emergency access rules
• Policy Baseline — Rotation, length, complexity, post-auth actions by tier
• Monitoring Specification — Event sources, alert rules, retention, reporting cadence
• Rollback and Break-glass Runbook — Tested recovery path for failed policy or endpoint lockout scenarios

LAPS v2 Deployment (Recommended)

LAPS v2 is built into Windows 11 (21H2+) and Server 2022+. You enable it via Group Policy.

Step 1: Prepare Active Directory (Schema Check)

LAPS v2 requires AD schema updates. Check if they're applied:

Step 2: Create LAPS Group Policy Objects (GPOs)

Create and link the GPO manually in GPMC to avoid hardcoded OU paths and ensure the configuration matches your production OU design:

1. Open Group Policy Management (gpmc.msc).
2. Navigate to your domain and identify the OU that contains the target computers (workstations, servers, or pilot OU).
3. Right-click the OU and select Create a GPO in this domain, and Link it here...
4. Name it clearly, for example: LAPS v2 - Workstations or LAPS v2 - Servers.
5. Confirm the new GPO is linked to the intended OU only (no broad domain-level linking unless explicitly required).

Step 3: Configure LAPS Password Policy

Configure policy settings directly in GPMC so values are explicit, reviewed, and aligned with your security baseline:

1. In Group Policy Management, right-click your LAPS v2 GPO and select Edit.
2. Go to Computer Configuration > Policies > Administrative Templates > System > LAPS.
3. Configure at minimum:
   • Enable local admin password management: Enabled
   • Password settings: Length and complexity per your baseline
   • Password age (days): Rotation interval (for example, 30 days)
   • Name of administrator account to manage: Only if using a custom local admin name
   • Directory backup: Active Directory (or Entra ID for applicable scenarios)
4. Close the editor and allow normal refresh cycle, or force policy update on a pilot client with gpupdate /force.

LAPS GPO Settings Reference (What Each Setting Does)

Use this reference when defining your baseline. Every setting should be decided by risk, operational model, and recovery requirements.

GPO Setting	What It Controls	Recommended Baseline	Pros	Cons / Risks
Configure password backup directory	Where LAPS stores managed local admin passwords (Active Directory or Entra ID)	Choose per device identity model; do not mix without clear scope boundaries	AD: mature delegation model, familiar ops workflows. Entra ID: cloud-native management, better for Entra-joined endpoints.	AD: requires reliable line-of-sight to domain services. Entra ID: operational change for teams used to AD-only retrieval and RBAC patterns.
Enable local admin password management	Turns LAPS management on or off for targeted devices	Enabled for all in-scope endpoints via phased rollout	Eliminates shared static local admin passwords and reduces lateral movement	If enabled without scoping/validation, can impact break-glass processes
Password age (days)	How frequently the managed local admin password rotates	30 days for most environments; reduce for high-risk tiers	Frequent rotation limits password exposure window	Very short intervals may increase support workload during recovery operations
Password length	Character length for generated local admin passwords	20-30+ characters (30 is common enterprise default)	Longer passwords significantly increase brute-force resistance	Long values can increase manual entry friction in emergency console scenarios
Password complexity	Allowed character sets and entropy requirements	Use full complexity for privileged tiers and servers	Higher entropy makes offline guessing and password spray far less practical	May be harder to transcribe manually if out-of-band access is needed
Name of administrator account to manage	Which local account LAPS rotates (built-in Administrator or custom)	Define only if you use a custom local admin standard	Supports environments that renamed/standardized local admin naming	Wrong account mapping can leave the intended privileged account unmanaged
Post-authentication actions	Action after password use (for example rotate and optionally sign out sessions)	Rotate immediately after use for privileged tiers	Reduces persistence risk after administrative sign-in	Aggressive actions can interrupt active troubleshooting sessions
Post-authentication reset delay	Time window before post-authentication rotation/action occurs	Short delay aligned with operational runbooks	Allows controlled admin work while still enforcing rapid credential turnover	If too long, exposure window remains open after privileged access
Password expiration protection	Prevents policy conflicts from causing stale/expired managed passwords	Enabled	Improves reliability and prevents unmanaged credential state	Requires policy consistency; conflicting baselines still need remediation

Step 4: Define Access Control (Who Can Retrieve Passwords?)

Access control is the most critical part of LAPS design. If password retrieval rights are too broad, LAPS becomes a password distribution system instead of a security control. Build retrieval rights with the same tier model and delegation principles used for privileged AD administration.

Use these EguibarIT references as the design baseline:

• Enterprise Access Model (EAM) — define Tier 0, Tier 1, and Tier 2 boundaries before assigning retrieval rights
• RBAC in Active Directory — model access by role, not by individual admin accounts
• Delegation Model — map tasks to scoped permissions and accountable owners
• How to Build the Delegation Model — implement AD groups and OU-level delegation consistently

Role Model for LAPS Retrieval (Enterprise Pattern)

Platform Type	Password Context	Primary Use Case	RBAC Recommendation
Member Servers / Workstations	Managed local administrator account password	Operational admin, break-fix, remote maintenance	Tier-scoped reader groups by OU and business scope
Domain Controllers	Recovery-oriented account context (for example DSRM)	Directory Services recovery and emergency domain controller maintenance	Dedicated Tier 0 recovery reader group with stricter approval and audit controls

Role	Tier	What It Can Do	What It Must NOT Do	Implementation Guidance
LAPS Policy Admins	Tier 0	Create and modify LAPS GPO settings and delegation ACLs	Routine password retrieval for endpoints	Use dedicated admin accounts and PAW-only administration path
LAPS Password Readers - Tier 0	Tier 0	Retrieve passwords for Tier 0 endpoints and approved recovery contexts (for example DC recovery/DSRM workflows)	Access Tier 1/2 endpoints by default	Separate group; require approval/ticket reference for each retrieval
LAPS Password Readers - Tier 1	Tier 1	Retrieve passwords for server/admin infrastructure in assigned scope	Read Tier 0 assets or workstation estates outside scope	Delegate only to specific OUs; enforce named-user accountability
LAPS Password Readers - Tier 2	Tier 2	Retrieve workstation local admin passwords in assigned business scope	Any server, DC, or privileged admin workstation password retrieval	Time-bound access where possible; deny broad inherited rights
LAPS Auditors / Security Operations	Tier 0/1 security oversight	Review retrieval logs, failed access, and anomaly patterns	Operational password retrieval unless explicitly approved	Read-only monitoring role with SIEM correlation and periodic review

Delegation Design Rules (Before Applying ACLs)

1. Separate by Tier and Scope: Never use one global "LAPS Readers" group. Build role groups per tier and per OU scope.
2. Delegate to Groups, Not Users: Keep identity lifecycle in group membership workflows; avoid direct user ACE assignments.
3. Enforce Retrieval Accountability: Require ticket IDs/change IDs and log requester, target device, and reason for every retrieval.
4. Protect the Delegation Path: Only Tier 0 admins can alter LAPS ACLs, GPO links, or policy settings.
5. Define Break-glass Flow: Establish an emergency path with dual approval, short-lived access, and post-incident review.

Step 5: Verify LAPS v2 is Working

Validate deployment manually on a pilot endpoint and in Active Directory before broad rollout:

1. On a test client in scope, run gpupdate /force and confirm the LAPS GPO is applied with gpresult /r.
2. Open Event Viewer and review LAPS-related events under Applications and Services Logs for processing and rotation outcomes.
3. In Active Directory Users and Computers (Advanced Features enabled), open the computer object and verify LAPS password metadata is present and updated.
4. From an authorized admin account, perform a controlled password retrieval test and confirm access is blocked for unauthorized accounts.
5. Document result timestamps and move from pilot OU to wider deployment only after successful validation.

LAPS v1 Deployment (Legacy / Mixed Environments)

If you support Windows 10 or Server 2019, use LAPS v1 for those machines. Here's a quick workflow:

Step 1: Update Active Directory Schema

Step 2: Download and Distribute LAPS v1 Installer

Download the LAPS v1 MSI from Microsoft and deploy via Group Policy or SCCM:

PowerShell Automation & Reporting

Retrieve LAPS passwords, generate reports, and audit access via PowerShell:

Get LAPS Password for a Single Machine

Bulk Export: All LAPS Passwords by OU

Audit: Who Retrieved Passwords and When?

Security & Hardening Considerations

📋 LAPS Security Checklist

• ✅ Use v2 for new deployments — v1 is legacy; v2 has modern protections
• ✅ Limit password retrieval groups — Only Tier 0/1 admins, never help desk
• ✅ Enable AD auditing — Log all LAPS password attribute reads
• ✅ Require MFA for admin accounts — Even with LAPS, require MFA for AD admin accounts that retrieve passwords
• ✅ Rotate passwords on schedule — 30 days default; consider 14 days for critical systems
• ✅ Monitor failed LAPS operations — Alert on rotation failures (often indicates malware/tampering)
• ✅ Enforce Tier Model — Tier 0 machines should have shorter rotation intervals (7-14 days)
• ✅ Encrypt AD traffic — Use LDAP over SSL (LDAPS) for password retrieval

Mitigating Common LAPS Risks

Risk	Mitigation
Attacker reads LAPS from AD	Implement RBAC; restrict retrieval to specific groups; require MFA on admin accounts
Local admin account is disabled	Monitor LAPS rotation failures; audit events for account disablement
LAPS password cached locally	Configure LAPS to NOT cache password; enforce clean-up on retrieval
Compromise of admin account with retrieval rights	Use Tier 0 PAW for password retrieval; require MFA; use JIT access (temporary elevation)

Operations & Maintenance

LAPS operational success depends on monitoring, maintenance, and rapid response to failures. These operational procedures are based on enterprise best practices and should be tailored to your environment's size and complexity. Automate as much as possible using PowerShell and scheduled tasks to reduce manual effort and human error.

Daily Tasks

Weekly Tasks

Monthly Tasks

Quarterly Tasks

Troubleshooting

LAPS Password Not Appearing in AD

Symptom: Ran gpupdate on client, but ms-Mcs-AdmPwd attribute is still empty.

Solutions:

• Check Event Viewer > Windows Logs > System for LAPS-related errors
• Verify LAPS GPO has applied (run `gpresult /h report.html` and search for LAPS policy)
• Ensure the machine account has permissions to update the ms-Mcs-AdmPwd attribute
• On v2, verify the machine is running Windows 11 21H2+ or Server 2022+
• Force a LAPS cycle: `Invoke-LapsCycle` (if using v2 PowerShell module)

Cannot Retrieve LAPS Password (Access Denied)

Symptom: Error: "Access Denied" when trying to read LAPS password via PowerShell.

Solutions:

• Verify your user account is a member of the group granted LAPS retrieval permissions
• Check AD permissions on the computer object: `dsacls "CN=COMPUTERNAME,OU=Computers,DC=domain,DC=com"`
• Ensure you're querying from a machine that can reach a domain controller
• Verify your user has "Read" permission on the ms-Mcs-AdmPwd attribute

LAPS Rotation Fails Repeatedly

Symptom: Event ID 10016 in System log; password not updating.

Solutions:

• Check if the local Administrator account is disabled or locked
• Verify network connectivity to a domain controller
• Check if antivirus/EDR is blocking LAPS operations
• Review LAPS GPO for syntax errors or policy conflicts
• On v1, confirm the LAPS agent service is running (`Get-Service LAPS`)

Resources & References

• Microsoft Learn: LAPS (Local Administrator Password Solution)
• LAPS Overview and Architecture
• LAPS PowerShell Module Reference
• EguibarIT: Privileged Access Workstations (PAW) — Complement LAPS with PAW for secure admin access
• EguibarIT: Tier 0 Delegation Model — Apply Tier Model to LAPS access controls