Local administrator accounts are one of those things every Windows environment needs — and almost every environment gets wrong.
After more than two decades working across service desks, sysadmin roles, and now cybersecurity, I can confidently say this: shared local admin passwords are one of the most common and most dangerous weaknesses in Windows networks. I’ve seen single compromised desktops lead to full domain takeovers purely because the same local admin password existed everywhere.
That’s exactly the problem LAPS (Local Administrator Password Solution) was designed to solve.
In this article, I’ll explain what LAPS actually does, why it’s still one of the most effective endpoint security controls available, and how to set it up properly — not just “installed”, but deployed in a way that actually reduces risk.
What Is LAPS (Local Administrator Password Solution)?
Microsoft LAPS is a security solution that automatically manages local administrator passwords on domain-joined Windows machines.
At a high level, LAPS:
- Generates a unique, random local admin password per device
- Rotates that password on a defined schedule
- Stores the password securely in Active Directory
- Restricts who can read the password using AD permissions
The practical result is simple but powerful:
If one machine is compromised, that password is useless anywhere else.
From an attacker’s perspective, this completely breaks a huge number of lateral-movement techniques.
Why LAPS Matters (From Real-World Experience)
Without LAPS, most environments fall into one of these traps:
- Same local admin password on every PC
- Password changed manually once a year (if ever)
- Password stored in spreadsheets or wikis
- Helpdesk staff sharing credentials
These patterns are gold for attackers.
Once malware lands on a single endpoint, tools like Mimikatz, BloodHound, or even basic scripts can harvest credentials and move laterally at speed.
LAPS shuts that down.
Even in organisations with strong perimeter security, I’ve seen internal breaches escalate purely because local admin passwords were reused.
Key Benefits of Using LAPS
| Benefit | Why It Matters |
|---|---|
| Unique passwords per device | Prevents lateral movement |
| Automatic rotation | Eliminates stale credentials |
| Centralised storage | No spreadsheets or guesswork |
| AD-based access control | Full auditability |
| No persistent agent | Uses native Windows components |
| Helpdesk-friendly | Passwords retrievable when needed |
From a security-to-effort ratio perspective, LAPS is one of the highest ROI controls you can deploy.
LAPS Versions: Legacy vs Built-In Windows LAPS
This is an important distinction that often causes confusion.
Legacy LAPS
- Deployed via MSI
- Uses
AdmPwdPowerShell module - Still widely used and supported
- Requires AD schema extension
Windows LAPS (New)
- Built into Windows (April 2023+)
- Supports Azure AD / Entra ID
- Integrates with Intune and MDM
- Replaces legacy long term
If you’re running pure on-prem AD, legacy LAPS is still extremely common and perfectly valid. The core principles are identical.
This article focuses primarily on on-prem AD deployment, where most real-world environments still sit.
LAPS Requirements
Before you start, make sure the basics are in place:
- Active Directory domain
- Windows 10/11 or Server 2016+
- Group Policy Management Console
- Permissions to modify GPOs
- Permissions to extend the AD schema (once only)
Tip from experience:
Always test LAPS in a pilot OU before broad deployment. It’s simple, but mistakes in permissions can cause confusion later.
Step-by-Step: How to Set Up LAPS (On-Prem AD)
Step 1: Extend the Active Directory Schema (One Time)
This step is only required once per forest.
Import-Module AdmPwd.PS
Update-AdmPwdADSchema
This adds two attributes to computer objects:
ms-Mcs-AdmPwd– the passwordms-Mcs-AdmPwdExpirationTime– expiry timestamp
No reboot required.
Step 2: Delegate Permissions Correctly
This is where many deployments go wrong.
Allow computers to write their own passwords:
Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Workstations,DC=domain,DC=local"
Allow specific groups to read passwords:
Set-AdmPwdReadPasswordPermission `
-OrgUnit "OU=Workstations,DC=domain,DC=local" `
-AllowedPrincipals "IT-Helpdesk"
Real-world advice:
Never grant read access to “Domain Admins” only. Delegate this intentionally so helpdesk access is logged and limited.
Step 3: Install LAPS Group Policy Templates
Copy the ADMX files:
AdmPwd.admxAdmPwd.adml
Into:
C:\Windows\PolicyDefinitions
Then open Group Policy Management.
Navigate to:
Computer Configuration
→ Administrative Templates
→ LAPS
Step 4: Configure LAPS Policies
At minimum, configure:
- Enable local admin password management
- Password length: 14–20 characters
- Password complexity: Enabled
- Password age: 30 days (or less)
- Administrator account name:
- Rename default Administrator wherever possible
From experience, renaming the default local admin account adds another hurdle for attackers and is worth doing.
Step 5: Apply and Test
Link the GPO to your workstation or server OU.
Force policy update:
gpupdate /force
Verify password storage:
Get-AdmPwdPassword -ComputerName PC-01
If permissions are correct, the password will be returned.
Retrieving LAPS Passwords Securely
Password retrieval should be:
- Logged
- Role-based
- Controlled
PowerShell example:
Import-Module AdmPwd.PS
Get-AdmPwdPassword -ComputerName PC-01
In mature environments, I’ve seen this integrated into:
- ServiceNow
- Secure internal portals
- Privileged access workflows
Never expose LAPS passwords in plain-text dashboards.
Recommended LAPS Configuration (Best Practice)
| Setting | Recommendation |
|---|---|
| Password length | 16–20 characters |
| Rotation interval | 30 days or less |
| Admin account name | Custom (not “Administrator”) |
| Read access | Least privilege |
| Auditing | Enabled on password reads |
Common LAPS Mistakes (That I See Often)
- Granting too many users read access
- Forgetting to delegate computer self-write permissions
- Applying GPOs to the wrong OU
- Using LAPS but still sharing passwords verbally
- Treating LAPS as a “set and forget” tool
LAPS works best when paired with monitoring and auditing.
LAPS Is Not Optional in Modern Security
In almost every ransomware or internal breach investigation I’ve been involved in, local admin password reuse played a role.
LAPS:
- Stops credential spraying internally
- Limits blast radius
- Makes attackers work much harder
- Improves auditability
And it does all of this with minimal operational overhead.
Final Thoughts: LAPS Is a Security Baseline, Not an Extra
If you’re running Active Directory and still using shared local admin passwords, you’re taking an unnecessary risk.
LAPS is free, mature, and proven. It’s one of those rare security controls that:
- Is easy to deploy
- Improves security immediately
- Makes life easier for IT teams
From real-world experience: enabling LAPS is one of the fastest ways to raise your security baseline across the entire domain.

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.
