Microsoft LAPS

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

BenefitWhy It Matters
Unique passwords per devicePrevents lateral movement
Automatic rotationEliminates stale credentials
Centralised storageNo spreadsheets or guesswork
AD-based access controlFull auditability
No persistent agentUses native Windows components
Helpdesk-friendlyPasswords 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 AdmPwd PowerShell 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 password
  • ms-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.admx
  • AdmPwd.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)

SettingRecommendation
Password length16–20 characters
Rotation interval30 days or less
Admin account nameCustom (not “Administrator”)
Read accessLeast privilege
AuditingEnabled 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.

Leave a Reply

Your email address will not be published. Required fields are marked *