One of the silent risks I see most often in enterprise environments: the same local admin password (or an account cloned from the same image) lives on tens or hundreds of machines. At some point a single device gets compromised, the password leaks, and the attacker walks sideways with “the same key.”
LAPS (Local Administrator Password Solution) is a very practical defense for this: each machine gets a unique and time-bounded local admin password, while access itself is governed by delegation plus audit.
Target design: Run LAPS as “secure operations”
Components of a successful rollout:
- Ring rollout: pilot OU → gradual expansion
- Read permission: not “all of helpdesk/ops,” but role-based groups
- Lifetime: 7–30 days (shorter on critical servers)
- Audit: who read the password, when, against which ticket?
- Break-glass: keep “emergency access” as a separate model when LAPS isn’t an option
1) Preparation for AD-based LAPS (Windows LAPS)
Separate the two worlds in your organization:
- Workstation LAPS: end-user devices (rotated more often)
- Server LAPS: servers (change blast radius is bigger; ring is more controlled)
Permission model (recommended)
- Group that can read passwords:
GRP-LAPS-READ-SERVERS/GRP-LAPS-READ-WKS - Group that can reset passwords (ops):
GRP-LAPS-RESET - GPO management:
GRP-GPO-ADMINS
2) Enabling via GPO (pilot)
Start your pilot OU with these principles:
- Target only one specific local admin account (your organization’s standard)
- Standardize password length and complexity
- Rotation interval: e.g. 14 days (pilot), then 7/30 days
To avoid breaking clients early on:
- exclude non-domain-joined devices from scope
- identify any critical automation accounts (legacy scripts) you might break
3) Delegation: “who can see the password?”
The biggest mistake: saying “the helpdesk group can see them” and exposing reads to hundreds of people.
Practical approach:
- Helpdesk only sees workstation LAPS (not servers)
- Server LAPS reads go only to L3 ops / incident commander / platform team
- Always tie a read to a ticket (procedure + audit)
4) Audit and operational discipline
Minimum audit goals:
- LAPS password read events flow into your central log
- When a “password read” event fires, link it to the relevant ticket/incident
- Suspicious case: same person reads many machines’ passwords in a short window → alarm
5) Entra/Intune side (organizations with device management)
If you manage end-user devices through MDM:
- Distribute the LAPS policy via Intune
- Restrict password access with role-based scopes
- For the “device lost / stolen” scenario, separate the password read and reset processes
Runbook: “Emergency local admin access needed on a server”
This is the most critical moment in production. The flow I lean on in the field:
- Open a ticket/incident (owner + duration)
- Read the LAPS password (the read log lands in SIEM)
- Access happens, the work gets done
- As soon as work ends, rotate immediately (don’t wait for the timer)
- Post-action: write a short “why was local admin needed?” root-cause note
Closing
With Windows LAPS, the local admin password stops being a “shared secret” at enterprise scale and becomes a time-bounded, auditable access component. With the right rollout, the right delegation, and solid auditing, LAPS becomes a low-cost security baseline that meaningfully reduces lateral movement risk, especially after ransomware events or identity leaks.