Local Admin Password Solution (LAPS): Securing Local Accounts in a Windows Environment

In the world of Windows administration, local administrator accounts have long been a significant security liability. When an organization builds a standard server or workstation image, it is common practice to include a local administrator account for emergency access or maintenance tasks that do not require domain connectivity. Historically, many organizations set a single, static password for this account across every machine in the fleet. While this was convenient for IT staff, it created a massive security hole. If an attacker compromised just one machine and extracted that local administrator password, they effectively gained administrative access to every other machine sharing that same password. This technique, known as lateral movement, is a cornerstone of modern cyberattacks and ransomware deployment.

The Local Admin Password Solution (LAPS) was created to solve this specific problem. Originally released as a separate download (Legacy LAPS), it has since been integrated directly into the Windows operating system (Windows LAPS). LAPS automates the process of managing local administrator passwords by generating a unique, complex password for each computer and storing it securely in Active Directory or Azure Active Directory (Entra ID). Because the passwords are randomized and rotated on a schedule, the risk of a single password compromise leading to a domain-wide breach is virtually eliminated.

In this lesson, we will explore the architecture of LAPS, the differences between the legacy and modern versions, and provide a step-by-step guide on how to deploy and manage it in a production environment. We will also cover the security considerations necessary to ensure that your password storage remains protected from unauthorized eyes.

The Problem: Static Passwords and Lateral Movement

To understand why LAPS is necessary, we must first look at how attackers move through a network. Imagine a scenario where a help desk technician sets the local administrator password to Company2024! on a master image. This image is deployed to 500 workstations and 50 servers. An attacker sends a phishing email to a user, gains a foothold on their workstation, and uses a tool like Mimikatz or a simple hash-dumping script to extract the local administrator credentials from the local security authority (LSA).

Armed with these credentials, the attacker doesn't need to find a new vulnerability for the next machine. They can simply use the stolen password to log into any other machine on the network. This is the essence of lateral movement. By the time the security team notices the breach, the attacker might have already gained administrative control over a domain controller or a sensitive file server. LAPS breaks this chain by ensuring that the password for Workstation-01 is completely different from the password for Workstation-02, and that both are updated automatically every 30 days without human intervention.

Callout: Pass-the-Hash (PtH) Attacks Even if you use a complex password, Windows often stores a "hash" of that password in memory. Attackers can steal this hash and use it to authenticate to other machines without ever knowing the actual clear-text password. Because LAPS ensures every machine has a unique password, a stolen hash from one machine is useless against another, effectively neutralizing the lateral movement potential of local accounts.

Evolution of the Tool: Legacy LAPS vs. Windows LAPS

For many years, LAPS was an MSI package that administrators had to manually install on every client and server. This is now referred to as "Legacy LAPS." In April 2023, Microsoft introduced "Windows LAPS," which is built directly into the Windows operating system via monthly updates. It is important to understand the differences between these two versions, as the configuration steps and features have changed significantly.

Legacy LAPS

Legacy LAPS relied on a Client-Side Extension (CSE) that was installed as an application. It stored the password in a clear-text attribute in Active Directory named ms-Mcs-AdmPwd. While access to this attribute could be restricted using Access Control Lists (ACLs), the password itself was not encrypted within the directory database. It only supported on-premises Active Directory and was limited to managing a single local account.

Windows LAPS (The Modern Version)

The modern Windows LAPS is natively integrated into Windows 10 (20H2 and later), Windows 11, and Windows Server 2019/2022. It offers several major improvements:

• Encryption: Passwords can be encrypted in Active Directory using the domain controller's public key, meaning even if someone has read access to the attribute, they cannot see the password without the proper decryption rights.
• Azure AD (Entra ID) Support: Windows LAPS can store passwords directly in the cloud, making it ideal for remote or hybrid workers who rarely connect to the corporate office.
• Multiple Account Support: It can manage the built-in administrator account or a custom local account.
• Automatic Rotation: It can trigger a password rotation immediately after the account is used, ensuring that even if a technician uses the password, it is changed as soon as they log off.

Preparing Active Directory for LAPS

Before you can start managing passwords, you must prepare your Active Directory environment. Since LAPS stores passwords in computer object attributes, those attributes must exist in your schema, and the computer objects must have the permission to write to them.

Step 1: Extending the Schema

If you are moving from Legacy LAPS to Windows LAPS, your schema may already be extended. However, Windows LAPS introduces new attributes for encryption and history. To extend the schema, you must be a member of the Schema Admins group.

Open PowerShell on a machine with the Active Directory Administrative Tools installed and run:

# Import the LAPS module (included in modern Windows)
Import-Module LAPS

# Update the AD Schema for Windows LAPS
Update-LapsADSchema

This command adds several attributes to the computer object class, including msLAPS-Password, msLAPS-PasswordHistory, and msLAPS-EncryptedPassword.

Step 2: Granting Computer Permissions

By default, computer objects do not have permission to update their own password attributes in Active Directory. You must grant the "Self" principal the right to write to these attributes for the Organizational Units (OUs) containing your servers and workstations.

# Grant computers in a specific OU the right to update their own LAPS password
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=contoso,DC=com"

Warning: Do not run this command at the root of the domain unless absolutely necessary. It is a best practice to target specific OUs to maintain a granular security posture.

Step 3: Controlling Read Access

This is the most critical step in the setup process. By default, "All Extended Rights" might allow more users than intended to read the password attributes. You must ensure that only authorized users (like Domain Admins or a specific Help Desk group) can read the passwords.

You can check who currently has permission to read LAPS attributes with this command:

Find-LapsADExtendedRights -Identity "OU=Workstations,DC=contoso,DC=com"

If you see groups like "Authenticated Users" or "Everyone" in the list, you must remove those permissions immediately.

Configuring LAPS via Group Policy

Once the environment is prepared, you use Group Policy (GPO) to tell the Windows clients how to behave. For Windows LAPS, the settings are located under: Computer Configuration > Administrative Templates > System > LAPS

Key Policy Settings

1. Configure password backup directory: This is the most important setting. You must choose whether the password should be backed up to "Active Directory" or "Azure AD". If you choose Active Directory, you can also decide if you want the password to be encrypted.
2. Password Settings: Here you define the complexity, length, and age of the password. Industry standards typically recommend a minimum of 14-16 characters and a rotation period of 30 days.
3. Name of administrator account to manage: By default, LAPS manages the built-in administrator account (SID -500). If you have renamed this account or want to manage a different local admin account, specify the name here.
4. Post-authentication actions: This is a powerful new feature in Windows LAPS. You can configure the system to automatically rotate the password and/or log off the account after a specified grace period once the password has been used.

Note: If you are still using Legacy LAPS, the GPO path is different (Computer Configuration > Administrative Templates > LAPS). Note that Windows LAPS can coexist with Legacy LAPS, but it is highly recommended to migrate to the modern version to take advantage of encryption.

Practical Example: Deploying Windows LAPS with Encryption

Let's walk through a practical scenario. You want to secure the local administrator accounts on all Windows Server 2022 file servers. You want the passwords to be 20 characters long, rotated every 14 days, and encrypted in Active Directory so that only the "Server Admins" group can read them.

1. Prepare the OU

Ensure all file servers are moved into an OU named OU=FileServers,DC=contoso,DC=com.

2. Set Permissions

Run the following PowerShell commands to allow computers to write their passwords and allow the Server Admins group to read them:

# Allow computers to write their own password attributes
Set-LapsADComputerSelfPermission -Identity "OU=FileServers,DC=contoso,DC=com"

# Allow Server Admins to read the encrypted passwords
Set-LapsADReadPasswordPermission -Identity "OU=FileServers,DC=contoso,DC=com" -AllowedPrincipals "CONTOSO\Server Admins"

3. Create the GPO

1. Open Group Policy Management (gpmc.msc).
2. Create a new GPO named "LAPS - File Server Security" and link it to the FileServers OU.
3. Edit the GPO and navigate to Computer Configuration > Administrative Templates > System > LAPS.
4. Enable Configure password backup directory and set it to Active Directory.
5. Enable Enable password encryption and set it to Enabled.
6. Enable Password Settings. Set length to 20 and age to 14.
7. Enable Post-authentication actions. Set the grace period to 2 hours and the action to Logoff the interactive account and terminate all remaining processes.

Once the GPO refreshes on the file servers (you can run gpupdate /force to speed this up), the LAPS engine will trigger. It will generate a new 20-character password, update the local administrator account, and then send the encrypted password back to Active Directory.

Retrieving Passwords

When a technician needs to log into a server locally, they must retrieve the current password from Active Directory. There are several ways to do this.

Using the LAPS GUI

Microsoft provides a simple graphical tool (installed via the RSAT or the LAPS MSI) where you simply type in the computer name, and it displays the current password and expiration date. In the modern Windows LAPS, this tool is updated to handle decryption automatically if the user has the correct permissions.

Using PowerShell

For automation or quick retrieval, PowerShell is the preferred method. The Get-LapsADPassword cmdlet is used for this purpose.

# Retrieve the password for a specific server
Get-LapsADPassword -Identity "FS01"

If the password is encrypted, the cmdlet will attempt to decrypt it using your current user context. If you don't have the "Read Password" permission granted via Set-LapsADReadPasswordPermission, the command will return an error or a blank result.

Using the Entra ID Portal (Azure AD)

If you have configured LAPS to back up passwords to Azure AD, you can find them in the Microsoft Entra admin center:

1. Navigate to Devices > All Devices.
2. Select the specific device.
3. Under the Monitor section, click on Local administrator password.
4. Click Show local administrator password. This action is logged in the Azure audit logs, providing a clear trail of who accessed the credentials.

Callout: Auditing and Accountability One of the greatest benefits of LAPS is the audit trail. Because passwords are restricted to specific groups and stored in a central directory, every time a password is "viewed," it can be logged. In Azure AD, this is automatic. In on-premises AD, you should enable "Directory Service Access" auditing to track who reads the msLAPS-Password attribute. This prevents "ghost" admins from using local accounts without a record.

LAPS in a Hybrid Environment (Entra ID)

Many organizations are moving away from traditional domain joins toward Entra ID Join (formerly Azure AD Join). Windows LAPS fully supports these modern endpoints. When a device is Entra ID joined, there is no "Domain Controller" to talk to via LDAP. Instead, the Windows LAPS client uses the Microsoft Graph API to communicate with Entra ID.

Configuration via Intune

In a cloud-native or hybrid environment, you don't use Group Policy. Instead, you use Microsoft Intune (Endpoint Manager).

1. Go to Endpoint security > Account protection.
2. Create a new policy and select Local admin password solution (LAPS) as the profile type.
3. Configure the settings (Backup directory: Azure AD, Password complexity, etc.).
4. Assign the policy to a group of devices.

This allows you to manage local admin passwords for laptops that may never connect to the corporate VPN, as long as they have an internet connection to reach Azure services.

Common Pitfalls and Troubleshooting

While LAPS is generally a "set it and forget it" tool, there are several common mistakes that can lead to deployment failures or security gaps.

1. Forgetting the Schema Update

If you configure the GPO but haven't updated the Active Directory schema, the clients will have nowhere to store the password. You will see errors in the Event Viewer (Event ID 10007) stating that the computer was unable to write the password to the directory. Always verify schema versioning before wide-scale deployment.

2. Conflicting GPOs

If you have Legacy LAPS and Windows LAPS policies both targeting the same machine, Windows LAPS will generally take precedence if it is configured. However, having both can lead to confusion and unpredictable rotation schedules. When migrating, disable the Legacy LAPS GPO settings as you enable the Windows LAPS settings.

3. Permission Bloat

The most dangerous mistake is leaving the "Read" permission open to "Authenticated Users." Since every user who logs into the domain is an "Authenticated User," this effectively makes every employee a local administrator on every machine. Use the Find-LapsADExtendedRights cmdlet regularly to audit who has access.

4. The "Disabled Account" Trap

LAPS manages the password of an account, but it does not necessarily enable the account. If the built-in administrator account is disabled by another GPO or security policy, LAPS will still rotate the password, but you won't be able to use it to log in. Ensure your "Local Account" policies allow the specific LAPS-managed account to be enabled if you intend to use it for emergency access.

5. Time Synchronization

LAPS relies on timestamps to determine when a password should expire. If a client's clock is significantly out of sync with the Domain Controller or Azure AD, password rotation may fail or happen prematurely. Ensure NTP (Network Time Protocol) is functioning correctly across the fleet.

Troubleshooting with Event Logs

When LAPS isn't working, the first place to look is the Event Viewer on the client machine.

• Path: Applications and Services Logs > Microsoft > Windows > LAPS > Operational
• Event ID 10001: Success. The password was updated and backed up.
• Event ID 10017: Failure. This often indicates a permission issue where the computer cannot write to its own object in AD.
• Event ID 10025: Encryption failure. This usually means the client cannot reach a Domain Controller to retrieve the public key needed for encryption.

Best Practices for Secure Implementation

To get the most out of LAPS, follow these industry-standard best practices:

• Use Encryption: If you are using Windows LAPS with on-premises AD, always enable encryption. Storing passwords in clear-text attributes is an unnecessary risk.
• Enforce Long Passwords: There is no reason to use short passwords for LAPS. Since humans don't have to remember them (they retrieve them from the tool), set the length to at least 20 characters with all character sets enabled.
• Short Rotation Cycles: Set the rotation to 30 days or fewer. If a password is leaked, the window of opportunity for the attacker is limited.
• Enable Post-Authentication Actions: Set LAPS to rotate the password immediately after it is used. This ensures that a technician's temporary access doesn't leave a "stale" password on the machine for weeks.
• Rename the Admin Account: While LAPS can find the account by SID, renaming the built-in administrator account adds a small layer of "security through obscurity" that can frustrate basic automated scripts.
• Monitor Password Access: Treat the LAPS password retrieval as a high-privilege event. Use a SIEM (like Microsoft Sentinel or Splunk) to alert whenever someone reads a LAPS password from the directory.
• Backup the Managed Account: Ensure that your disaster recovery plan doesn't rely solely on LAPS. If Active Directory is completely offline, you might not be able to retrieve the passwords. Keep a "Break Glass" account password in a secure, physical vault or a separate offline password manager.

Comparison: LAPS vs. PAM/PIM

It is important to distinguish LAPS from Privileged Access Management (PAM) or Privileged Identity Management (PIM) solutions.

Callout: LAPS vs. Full PAM Solutions LAPS is a "point solution" designed specifically for local accounts. It does not manage domain admin accounts, service accounts, or database credentials. A full PAM solution (like CyberArk or BeyondTrust) provides broader features like session recording, "just-in-time" access for domain accounts, and credential injection. LAPS is often used alongside these tools to cover the local account gap that larger PAM tools sometimes overlook or find too expensive to license for every single workstation.

Summary and Key Takeaways

The Local Admin Password Solution is one of the most effective, low-cost security controls you can implement in a Windows environment. By automating the management of local credentials, you eliminate a primary vector for lateral movement and significantly harden your infrastructure against internal and external threats.

Key Takeaways:

1. Eliminates Lateral Movement: LAPS ensures every computer has a unique local administrator password, preventing an attacker from using one compromised machine to access others.
2. Native Integration: Windows LAPS is now built into modern Windows versions, removing the need for manual MSI installations and providing better support for encryption and Azure AD.
3. Secure Storage: Passwords can be encrypted in Active Directory using AES-256, ensuring that only authorized administrators can view them.
4. Automation: LAPS handles the generation, rotation, and reporting of passwords automatically based on Group Policy or Intune settings.
5. Auditability: Every time a password is retrieved, it can be logged and audited, providing accountability for administrative actions.
6. Flexible Deployment: LAPS works for on-premises servers via GPO and for remote, cloud-joined laptops via Microsoft Intune.
7. Post-Use Security: Modern LAPS can automatically change a password and log off a user immediately after the local admin account has been used, minimizing the time a password remains valid.

By following the steps outlined in this lesson—preparing the schema, setting strict permissions, and configuring robust GPO/Intune policies—you can transform the local administrator account from a major security liability into a well-managed, secure emergency access mechanism.