Windows LAPS on Windows Server 2025: Active Directory Deployment Guide

In short

Windows LAPS (Windows Local Administrator Password Solution) is built into Windows Server 2025. It automatically rotates the password of a local administrator account and backs that password up to either Windows Server Active Directory or Microsoft Entra ID. For an Active Directory deployment, the clean sequence is:

Verify supported Windows versions
→ extend the AD schema once
→ place managed computers in a dedicated OU
→ grant computer self-permission
→ delegate password read/reset permissions
→ create and link a Windows LAPS GPO
→ back up passwords to Active Directory
→ force policy processing
→ verify Event ID 10018
→ retrieve the password with Get-LapsADPassword
→ test password rotation

This guide focuses on Windows LAPS with Windows Server Active Directory and Windows Server 2025. It does not use the deprecated legacy Microsoft LAPS MSI package.

If you still need the domain itself, start with Promote a Windows VPS to an Active Directory Domain Controller. If Group Policy is new to you, read Active Directory Group Policy Setup from Scratch first.

What is Windows LAPS?

Windows LAPS is Microsoft's current local administrator password-management feature for Windows. It regularly changes the password of a managed local administrator account and stores the password in a protected directory location where authorized administrators can retrieve it.

Microsoft documents Windows LAPS for:

• Windows Server 2025;
• Windows Server 2022 with supported updates;
• Windows Server 2019 with supported updates;
• supported Windows 11 and Windows 10 releases.

Windows LAPS can back passwords up to:

• Windows Server Active Directory for domain-joined devices;
• Microsoft Entra ID for Microsoft Entra-joined devices.

A hybrid-joined device can use either destination, but Windows LAPS does not back the same managed password up to both directories at the same time.

Windows LAPS vs legacy Microsoft LAPS

The old product is commonly called Microsoft LAPS or legacy LAPS. Windows LAPS is the newer implementation built directly into supported Windows versions.

Microsoft has deprecated the legacy Microsoft LAPS product on newer Windows versions. For Windows Server 2025, use Windows LAPS, not the old MSI.

Do you need to download Windows LAPS?

No separate Windows LAPS download is required on Windows Server 2025. The feature and LAPS PowerShell module are part of Windows.

That distinction matters because search results and older tutorials may still point administrators toward the legacy LAPS.x64.msi package. Do not install the legacy MSI on a new Windows Server 2025 deployment simply because an older guide tells you to.

How Windows LAPS works with Active Directory

A normal Active Directory deployment looks like this:

Managed Windows Server or workstation
        |
        | Windows LAPS policy
        v
Local administrator password rotated
        |
        | encrypted before directory backup when configured
        v
Active Directory computer object
        |
        +--> authorized password readers
        +--> authorized password reset operators

The managed computer performs the password rotation locally. It then writes the password information to its own Active Directory computer object, assuming the OU permissions and LAPS policy are configured correctly.

Password access is controlled in two layers:

1. Active Directory ACLs decide who can query the LAPS password attributes.
2. Password encryption can further limit who can decrypt an encrypted password.

For encrypted passwords in Active Directory, Microsoft requires a Windows Server 2016 domain functional level or later.

Prerequisites

Before deploying Windows LAPS, verify:

• Active Directory is healthy.
• DNS works correctly for domain members.
• Managed devices are domain-joined.
• The managed OS supports Windows LAPS.
• Windows updates are current enough for Windows LAPS on Server 2019/2022 devices.
• You have rights to extend the Active Directory schema.
• You have a dedicated OU or a clear OU scope for managed devices.
• You have decided who may retrieve local administrator passwords.
• You have a test computer before applying policy broadly.
• Your domain functional level is Windows Server 2016 or later if you want encrypted AD passwords.

For production, do not test the first LAPS policy on every server in the domain. Start with one OU and one non-critical system.

Step 1 — Verify the Windows LAPS PowerShell module

On Windows Server 2025, open PowerShell as Administrator and run:

Get-Module -ListAvailable LAPS

Then list the available cmdlets:

Get-Command -Module LAPS

Important Windows LAPS cmdlets include:

If the LAPS module is missing from a Windows Server 2025 system, verify the OS image and patch state before downloading random third-party packages.

Step 2 — Update the Active Directory schema

Before Windows LAPS can store password information in Active Directory, extend the schema.

Run this once per forest:

Update-LapsADSchema -Verbose

Microsoft documents this as a one-time forest operation.

You can run it on a supported domain controller or another supported server that has access to the LAPS PowerShell module and the required directory permissions.

Do not repeatedly run schema updates as part of normal workstation or server onboarding.

After the command completes, continue with OU permissions.

Step 3 — Put managed devices in a dedicated OU

A dedicated OU makes LAPS policy and delegation easier to understand.

Example:

contoso.com
  └── Servers
      └── LAPS-Managed-Servers

You can create one with PowerShell:

New-ADOrganizationalUnit `
  -Name 'LAPS-Managed-Servers' `
  -Path 'OU=Servers,DC=contoso,DC=com'

Move one test computer into the OU before applying policy broadly.

Example target:

SERVER01

For an MSP, separate OUs by customer or administrative boundary rather than giving one support group unrestricted LAPS access to unrelated client systems.

Step 4 — Allow managed computers to update their own LAPS password

Each managed computer needs permission to update its LAPS password information on its own Active Directory computer object.

Grant the required inheritable permission on the target OU:

Set-LapsADComputerSelfPermission `
  -Identity 'OU=LAPS-Managed-Servers,OU=Servers,DC=contoso,DC=com'

Microsoft also allows simpler OU names when they resolve uniquely, but the distinguished name is clearer in production documentation.

Verify the returned object matches the OU you intended to modify.

Do not grant this permission at the domain root unless you deliberately want that scope.

Step 5 — Create a dedicated LAPS password-readers group

Avoid making every help-desk administrator a Domain Admin just so they can retrieve a local password.

Create a dedicated security group:

New-ADGroup `
  -Name 'LAPS-Password-Readers' `
  -SamAccountName 'LAPS-Password-Readers' `
  -GroupScope Global `
  -GroupCategory Security `
  -Path 'OU=Groups,DC=contoso,DC=com'

Then add only the administrators who actually need local-password recovery access.

Example:

Add-ADGroupMember `
  -Identity 'LAPS-Password-Readers' `
  -Members 'helpdesk.admin'

Use a separate group for password-reset/expiration rights when duties should be separated.

Step 6 — Delegate password-read permission

Grant the dedicated group permission to query LAPS passwords for computer objects inside the managed OU:

Set-LapsADReadPasswordPermission `
  -Identity 'OU=LAPS-Managed-Servers,OU=Servers,DC=contoso,DC=com' `
  -AllowedPrincipals 'CONTOSO\LAPS-Password-Readers'

Members of Domain Admins already have password-query permissions by default, but a dedicated group is easier to audit and follows least privilege more closely.

Important: permission to read the LAPS attributes is not automatically permission to decrypt an encrypted password. If you use password encryption and specify a custom ADPasswordEncryptionPrincipal, that principal must also be able to decrypt the stored value.

Step 7 — Delegate password-reset permission separately

Windows LAPS can let selected administrators force an earlier password rotation by updating the password expiration timestamp in Active Directory.

Create a group such as:

LAPS-Password-Resetters

Then delegate expiration/reset permission:

Set-LapsADResetPasswordPermission `
  -Identity 'OU=LAPS-Managed-Servers,OU=Servers,DC=contoso,DC=com' `
  -AllowedPrincipals 'CONTOSO\LAPS-Password-Resetters'

This permission does not directly set a chosen password. It allows authorized operators to modify the LAPS password expiration time so the managed device rotates the password during policy processing.

Step 8 — Audit who has LAPS rights before rollout

Before storing privileged local passwords in Active Directory, inspect who has extended rights on the OU.

Run:

Find-LapsADExtendedRights `
  -Identity 'OU=LAPS-Managed-Servers,OU=Servers,DC=contoso,DC=com'

Review the output for unexpected users or groups.

This is especially important in old Active Directory environments where delegated rights may have accumulated over years.

Do not assume a dedicated LAPS readers group is the only principal with access simply because you just created it.

Step 9 — Create and link a Windows LAPS Group Policy

Open Group Policy Management:

gpmc.msc

Create a new GPO, for example:

Servers - Windows LAPS

Link it only to the managed server OU first.

Edit the GPO and go to:

Computer Configuration
→ Policies
→ Administrative Templates
→ System
→ LAPS

Windows includes the Windows LAPS administrative template at:

%windir%\PolicyDefinitions\LAPS.admx

If your environment uses a Group Policy Central Store, Microsoft notes that Windows Update does not automatically copy the LAPS ADMX/ADML files into that Central Store. Copy the current template files deliberately and keep the Central Store maintained.

Step 10 — Configure the minimum Windows LAPS policy

For an Active Directory deployment, the minimum critical setting is the backup destination.

Configure:

Configure password backup directory

Set the backup directory to:

Active Directory

At the policy-data level, Microsoft documents this as:

BackupDirectory = 2

If BackupDirectory remains disabled, the other LAPS settings are ignored.

Administrator account to manage

If you leave AdministratorAccountName unconfigured, Windows LAPS manages the built-in local Administrator account by its well-known RID.

That means Windows can still identify the built-in Administrator account even if it was renamed.

Do not enter the visible localized account name just to target the built-in Administrator account.

If you want Windows LAPS to manage a custom local administrator account in manual account-management mode, set AdministratorAccountName to that custom account and make sure the account already exists.

Password settings

Windows LAPS has defaults when you do not configure every value. Microsoft currently documents defaults including:

You can define stricter values if your organization requires them, but do not create extreme rotation schedules that cause operational problems without adding meaningful security.

Step 11 — Enable Active Directory password encryption

For Windows Server Active Directory, Windows LAPS supports encrypting the password before it is written to the directory.

Microsoft requires a Windows Server 2016 domain functional level or later for this feature.

The relevant policy is:

ADPasswordEncryptionEnabled

When enabled, the device encrypts the password before storing it in Active Directory.

If you do not configure a custom decryptor, Microsoft documents the default decryptor as the Domain Admins group.

For least privilege, consider using a dedicated group such as:

CONTOSO\LAPS-Password-Readers

as the configured ADPasswordEncryptionPrincipal, provided your operational model requires those users to decrypt the password.

Remember that AD ACL read permission and encryption/decryption permission are separate controls.

Step 12 — Apply Group Policy to the test computer

On the managed server, run:

gpupdate /force

Then confirm the GPO is applied:

gpresult /r

For a detailed report:

gpresult /h C:\Temp\LAPS-GPResult.html

Look for:

Servers - Windows LAPS

under the applied computer policies.

If the GPO is missing, fix the OU, link, filtering, replication, or DNS problem before troubleshooting Windows LAPS itself.

Step 13 — Force Windows LAPS policy processing

Windows LAPS processes policy in the background and responds to Group Policy changes. Microsoft also documents an hourly active-policy processing cycle.

To avoid waiting during a controlled test, run on the managed computer:

Invoke-LapsPolicyProcessing

This triggers Windows LAPS to process the current policy immediately.

The cmdlet does not provide a detailed success report. Use the Windows LAPS event log to verify the outcome.

Step 14 — Verify Event ID 10018

Microsoft documents Event ID 10018 as the event showing that a Windows LAPS password was successfully updated in Active Directory.

Open Event Viewer and navigate to the Windows LAPS operational log, or query relevant events with PowerShell.

A practical approach is to inspect recent events from the LAPS operational channel after invoking policy processing.

If you do not see a successful password update, check:

• the GPO applied;
• BackupDirectory points to Active Directory;
• the computer object is inside the OU where self-permission was configured;
• AD replication and DNS are healthy;
• the computer can contact a supported domain controller;
• the managed local account exists;
• no conflicting LAPS policy source is overriding the GPO.

Step 15 — Retrieve the local administrator password

From an authorized administrative system with the LAPS PowerShell module, retrieve the stored password:

Get-LapsADPassword `
  -Identity 'SERVER01' `
  -AsPlainText

Microsoft's output can include fields such as:

• ComputerName;
• Account;
• Password;
• PasswordUpdateTime;
• ExpirationTimestamp;
• Source;
• DecryptionStatus;
• AuthorizedDecryptor.

If password encryption is enabled, a successful result should show that the password came from an encrypted source and that decryption succeeded for the authorized identity.

Security warning for -AsPlainText

-AsPlainText intentionally displays the credential in clear text. Use it only when an administrator genuinely needs the password.

Do not:

• paste the output into tickets;
• record it in screenshots;
• send it over chat;
• store it in scripts;
• redirect it to ordinary log files.

The whole value of Windows LAPS is reducing shared and long-lived local administrator credentials. Do not recreate the same problem by copying rotated passwords into permanent documentation.

Step 16 — Test an early password rotation

There are two useful rotation methods.

From Active Directory

An authorized administrator can expire the stored password:

Set-LapsADPasswordExpirationTime -Identity 'SERVER01'

At the next policy-processing cycle, the managed computer sees the expired timestamp and rotates the password.

To process immediately on the managed server:

Invoke-LapsPolicyProcessing

Locally on the managed computer

For exceptional cases where an immediate local rotation is required:

Reset-LapsPassword

Microsoft recommends Reset-LapsPassword for uncommon situations such as incident response rather than as a high-frequency automation mechanism.

After rotation, retrieve the password again and confirm the update timestamp and password changed.

Step 17 — Consider Windows Server 2025 automatic account management

Windows Server 2025 adds an important Windows LAPS capability: automatic account management.

Manual mode remains the default. In manual mode:

• leave AdministratorAccountName empty to manage the built-in Administrator account;
• or specify a custom local account that you create separately.

Automatic account-management mode can manage more of the account lifecycle itself, including:

• targeting the built-in Administrator or a custom managed account;
• creating/deleting a custom managed account as required;
• choosing the account name or prefix;
• enabling or disabling the account;
• randomizing the account name.

Microsoft documents automatic account management for Windows Server 2025 and later and Windows 11 24H2 and later.

For a first deployment, keep the architecture simple. Prove password backup, retrieval, delegation, and rotation first. Then evaluate automatic account management as a separate policy decision.

Windows LAPS for domain controller DSRM passwords

Windows LAPS can also manage and back up Directory Services Restore Mode (DSRM) account passwords on Active Directory domain controllers.

That is a different scenario from managing the local Administrator password on member servers or workstations.

Use DSRM password management only after you understand:

• domain functional-level requirements;
• recovery procedures;
• who can retrieve the DSRM password;
• how the password is encrypted;
• how domain-controller backup and recovery are documented.

Do not enable DSRM management simply because the setting exists. Treat it as part of your domain-controller recovery design.

Windows LAPS security best practices

Use a dedicated OU first

Start with one test OU. Do not make a new LAPS policy domain-wide before validating it.

Use dedicated reader and resetter groups

Avoid assigning broad Domain Admin rights to help-desk staff just to retrieve local passwords.

Audit extended rights

Use:

Find-LapsADExtendedRights

before assuming only your new delegation groups can read passwords.

Prefer encrypted AD passwords

For a Windows Server 2016 or later DFL, enable AD password encryption and deliberately choose who can decrypt the password.

Do not copy passwords into permanent records

LAPS passwords are temporary privileged credentials. Treat clear-text retrieval as a sensitive administrative action.

Keep the local account separate from domain administration

Windows LAPS solves the reusable local-admin-password problem. It does not replace separate domain-admin accounts, privileged access workstations, MFA, Windows Firewall, patching, or logging.

Monitor policy and retrieval behavior

Use Windows LAPS event logs and AD auditing where appropriate. A password-management control is only useful when administrators can detect failures and unexpected access.

For broader host security, use the Windows Server Hardening Checklist.

Recommended MSP rollout model

For MSP-managed Windows environments, use administrative boundaries that match the client boundary.

A simple pattern is:

Client A Servers OU
→ Client A LAPS GPO
→ Client A LAPS Readers group
→ Client A LAPS Resetters group

Client B Servers OU
→ Client B LAPS GPO
→ Client B LAPS Readers group
→ Client B LAPS Resetters group

Avoid one global support group that can retrieve every customer's local administrator password unless that broad access is a deliberate and audited part of the service model.

For each client, document:

• OU scope;
• GPO name;
• managed account mode;
• password backup destination;
• password-read group;
• password-reset group;
• encryption principal;
• test computer;
• last successful retrieval test;
• incident rotation procedure.

Common Windows LAPS deployment mistakes

Installing legacy Microsoft LAPS on Windows Server 2025

Windows LAPS is built into Windows Server 2025. Do not follow an old MSI-based tutorial for a new deployment.

Updating the schema but forgetting OU permissions

Schema extension creates the required directory attributes. It does not automatically let managed computer objects write their LAPS information.

Use Set-LapsADComputerSelfPermission on the correct OU.

Giving read permission but not decryption permission

When AD password encryption is enabled with a custom encryption principal, ACL read permission alone does not guarantee the administrator can decrypt the password.

Setting AdministratorAccountName to the renamed built-in Administrator

Leave the setting empty when you want Windows LAPS to manage the built-in Administrator account. Windows identifies it by RID.

Configuring a custom account that does not exist

In manual account-management mode, Windows LAPS rotates the password but does not create the custom account for you.

Leaving BackupDirectory disabled

If BackupDirectory is disabled, the remaining settings do not create a usable backup workflow.

Linking the GPO to users instead of computers

Windows LAPS policy is computer-side policy. Link the GPO to the OU containing the managed computer objects.

Assuming gpupdate proves LAPS worked

gpupdate /force proves Group Policy was processed. Verify Windows LAPS itself with the LAPS event log and the stored password in Active Directory.

Over-delegating password retrieval

LAPS passwords are privileged credentials. Audit OU rights before and after delegation.

Troubleshooting Windows LAPS

Use this order when the password does not appear in Active Directory.

1. Confirm the device is domain-joined.
2. Confirm the OS supports Windows LAPS.
3. Confirm the LAPS PowerShell module is available.
4. Confirm the schema update completed.
5. Confirm the computer object is in the intended OU.
6. Confirm Set-LapsADComputerSelfPermission was applied to that OU.
7. Confirm the Windows LAPS GPO is linked and enabled.
8. Run gpresult /h and verify the GPO applies to the computer.
9. Confirm BackupDirectory is Active Directory.
10. Run Invoke-LapsPolicyProcessing.
11. Check the Windows LAPS operational event log.
12. Check AD/DNS/replication health.
13. Run Find-LapsADExtendedRights for delegation problems.
14. Retrieve with Get-LapsADPassword from an authorized account.

Do not weaken permissions or disable encryption as the first troubleshooting step.

Where Raff fits

Raff Windows VMs can provide the Windows Server infrastructure for Active Directory domain controllers, member servers, RDS environments, SQL Server, and other Windows workloads where Windows LAPS is useful.

Windows LAPS itself is an operating-system and identity-management control. You still design:

• the Active Directory topology;
• private networking;
• OU structure;
• Group Policy;
• LAPS delegation;
• domain-controller redundancy;
• backups;
• privileged access;
• monitoring and recovery.

For production Active Directory, avoid a single domain controller and avoid exposing AD services directly to the public internet.

Frequently asked questions

Is Windows LAPS built into Windows Server 2025?

Yes. Windows LAPS is native to Windows Server 2025. You do not need the legacy Microsoft LAPS MSI for a new Server 2025 deployment.

What is the difference between Windows LAPS and Microsoft LAPS?

"Microsoft LAPS" often refers to the older standalone product. Windows LAPS is the newer Windows-native implementation with support for Active Directory and Microsoft Entra ID, AD password encryption, DSRM scenarios, and additional management features.

Does Windows LAPS require Active Directory?

No. Windows LAPS can back passwords up to Windows Server Active Directory or Microsoft Entra ID depending on device join state and policy. This guide covers the Active Directory scenario.

Does Windows LAPS create the local administrator account?

In the default manual account-management mode, no. If you specify a custom account, you create that account separately. Windows Server 2025 also supports optional automatic account management, which can manage more of the account lifecycle.

What domain functional level is required for encrypted LAPS passwords?

Microsoft requires Windows Server 2016 domain functional level or later for Windows LAPS password encryption in Active Directory.

How do I retrieve a Windows LAPS password from Active Directory?

Use an authorized account with the LAPS PowerShell module:

Get-LapsADPassword -Identity 'SERVER01' -AsPlainText

Treat the clear-text password as sensitive and avoid copying it into tickets or logs.

How do I force Windows LAPS to process policy now?

On the managed device, run:

Invoke-LapsPolicyProcessing

Microsoft documents Event ID 10018 as evidence that the password was successfully updated in Active Directory.

How do I immediately rotate the managed local password?

On the managed computer, Reset-LapsPassword forces an immediate rotation. Microsoft recommends using it for exceptional situations rather than frequent scheduled rotation.

What's next

• Promote a Windows VPS to an Active Directory Domain Controller
• Active Directory Group Policy Setup from Scratch
• Windows Server Hardening Checklist
• Configure Windows Firewall on a Windows VPS
• Raff Windows VM

Sources

• Microsoft Learn — Windows LAPS overview: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview
• Microsoft Learn — Get started with Windows LAPS and Windows Server Active Directory: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-windows-server-active-directory
• Microsoft Learn — Key concepts in Windows LAPS: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-concepts-overview
• Microsoft Learn — Configure policy settings for Windows LAPS: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-policy-settings
• Microsoft Learn — Windows LAPS account management modes: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-concepts-account-management-modes
• Microsoft Learn — Windows LAPS PowerShell cmdlets: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-powershell
• Microsoft Learn PowerShell — LAPS module: https://learn.microsoft.com/en-us/powershell/module/laps/?view=windowsserver2025-ps
• Sources verified: 2026-08-29