Version: 1.0

Date: 2025-04-04

Audience: Active Directory Administrators


TABLE OF CONTENTS


Introduction

This document provides guidance for Active Directory administrators on configuring and deploying the modern Windows Local Administrator Password Solution (LAPS) integrated with Active Directory. Windows LAPS replaces the legacy LAPS solution (based on a separate MSI install) and offers enhanced security features, including password encryption, password history, and integration with standard Windows management tools.

The primary goal of Windows LAPS is to mitigate the risk associated with using a common, static local administrator password across multiple endpoints by automatically managing unique, complex passwords for the specified local administrator account on each managed Windows device and storing them securely within Active Directory.

This guide covers the necessary steps for preparing Active Directory, configuring LAPS policies via Group Policy, setting appropriate permissions, and considerations for rollout and monitoring.


Note: This guide assumes you are implementing Windows LAPS integrated with Active Directory Domain Services (AD DS). Configuration for Entra ID (formerly Azure AD) joined devices involves different steps using Intune or other MDM solutions and is not covered by this guide.


Prerequisites

Before proceeding with the Windows LAPS configuration, ensure the following prerequisites are met:

  • Domain Functional Level (DFL) / Forest Functional Level (FFL): While Windows LAPS can function with older levels after schema updates, Windows Server 2016 DFL/FFL or higher is recommended for native support of certain features like password encryption.
  • Schema Update Permissions: The administrator performing the schema update requires Schema Admins group membership. Membership in Enterprise Admins is typically required to replicate schema changes forest-wide.
  • Domain Controller OS & Updates: All Domain Controllers (DCs) must have the necessary Windows Updates installed that include the Windows LAPS feature. Refer to Microsoft documentation for specific KB numbers relevant to your DC operating systems (Windows Server 2016/2019/2022).
  • Client OS & Updates: Target client devices (Windows 10/11 Pro, Enterprise, Education) must have the appropriate Windows Updates installed that include the Windows LAPS client components.
  • LAPS Management Tools: The administrator workstation used for configuration should have the LAPS PowerShell module installed. This is included with the latest RSAT: Active Directory Domain Services and Lightweight Directory Services Tools (See Section 4 in the Helpdesk guide for installation).
  • Backup: Perform a System State backup of at least one Domain Controller holding the Schema Master FSMO role before making any schema modifications.

Active Directory Preparation

3.1. Update Active Directory Schema

Windows LAPS requires specific attributes in the AD schema. Even if you used legacy LAPS previously, running the update cmdlet for Windows LAPS is necessary to add new attributes (like password encryption attributes) and default ACEs.

  1. Logon: Log onto a Domain Controller holding the Schema Master role (or any DC in the forest root domain if using Windows Server 2012 R2 or later DCs, provided Schema Admins membership) with an account that is a member of the Schema Admins and Enterprise Admins groups.
  2. Open PowerShell: Open an elevated PowerShell prompt.
  3. Run Schema Update Cmdlet:Execute the following command:
    Update-LapsADSchema -Verbose

  4. Verify: Monitor the verbose output for successful completion across all domains. Schema updates can take time to replicate throughout the forest.

3.2. Grant Computer Self-Update Permission

Computer accounts need permission to update their own LAPS password attribute in Active Directory.

  1. Open PowerShell: Open an elevated PowerShell prompt on a machine with the LAPS PowerShell module installed (e.g., a DC or admin workstation).
  2. Target OU: Identify the Organizational Unit(s) (OUs) containing the computer accounts you intend to manage with LAPS. Do not target the domain root or the default 'Computers' container unless absolutely necessary and intended. It's best practice to apply this permission granularly.
  3. Run Permission Cmdlet:Execute the following command for each target OU, replacing "OU=ManagedComputers,DC=dktire,DC=com" with the distinguished name of your target OU:
    Set-LapsADComputerSelfPermission -Identity "OU=ManagedComputers,DC=dktire,DC=com"


    • You can use the -Verbose switch for more detailed output.
    • This command grants the SELF principal the necessary write permissions on the LAPS password attributes for computer objects within that OU.

Configuration via Group Policy

Windows LAPS settings are configured using Group Policy Objects (GPOs).

  1. Create/Edit GPO: Open the Group Policy Management Console (gpmc.msc). Create a new GPO or edit an existing one that is linked to the OU(s) containing the target computer accounts. Link the GPO to the OUs where you granted self-permission in step 3.2.
  2. Navigate to LAPS Settings: In the Group Policy Management Editor, go to:
     Computer Configuration -> Policies -> Administrative Templates -> System -> LAPS
  3. Configure Key Settings:
    • Configure LAPS: Set to Enabled. This is the master switch to turn on LAPS processing on clients.
      • Directory type: Select Active Directory.
    • Password Settings:Enabled. Configure the desired password complexity, length, and maximum age. Ensure these meet your organization's security standards.
      • Recommendation: Use a mix of character types, a length of 15 characters or more, and a reasonable password age (e.g., 30-90 days).
    • Name of administrator account to manage:Enabled. Specify the exact name of the local administrator account whose password LAPS should manage (e.g., Administrator). If you have renamed the built-in administrator account, specify that name here. Do not leave this blank.
    • Configure password backup directory:Enabled. Ensure Active Directory is selected. This confirms passwords will be backed up to AD DS.
    • (Optional) Enable password encryption:Enabled. Requires Windows Server 2016 DFL or higher. Allows DCs to encrypt the password using Kerberos. Configure an authorized decryptor group (e.g., Domain Admins) if needed, although standard AD permissions often suffice for authorized viewers. Note: This setting primarily affects how the password is treated on the DC side during storage/retrieval, not the client-side encryption.
    • (Optional) Configure password history size:Enabled. Specify the number of previous passwords to retain in AD (e.g., 5 or 12). This is useful for scenarios like restoring machines from snapshots, as documented for Helpdesk. Requires sufficient AD attribute storage.
    • (Optional) Configure post-authentication actions:Enabled. Define actions (like logging off the managed account) and a grace period after the LAPS password is used and the machine authenticates to a DC.

Configure Permissions for Password Viewing/Reset

Grant specific groups (e.g., Helpdesk) the necessary permissions to view or reset LAPS passwords. Apply the principle of least privilege.

  1. Open PowerShell: Use an elevated PowerShell prompt on a machine with the LAPS module.
  2. Identify Target OU(s): Use the same OU distinguished name(s) as in step 3.2.
  3. Identify Authorized Group(s): Determine the security group(s) that require access (e.g., CORP\HelpdeskGroup).
  4. Grant Read Permission:Execute this command for each group and target OU:
    Set-LapsADReadPasswordPermission -Identity "OU=ManagedComputers,DC=dktire,DC=com" -AllowedPrincipal "CORP\LAPS_Password_Readers"

  5. (Optional) Grant Reset Permission:If a group needs the ability to force an immediate password reset (e.g., Tier 2/3 Support), grant reset permission:
    Set-LapsADResetPasswordPermission -Identity "OU=ManagedComputers,DC=dktire,DC=com" -AllowedPrincipal "CORP\Password Administrators"

     

Deployment Strategy

  • Phased Rollout:Deploy LAPS gradually.
    1. Pilot Group: Apply the LAPS GPO to a small OU containing test machines and IT workstations first. Verify functionality thoroughly.
    2. Broader Deployment: Gradually link the GPO to more OUs containing workstations and servers. Monitor closely during each phase.
  • Communication: Inform Helpdesk and other relevant IT teams about the rollout schedule, the purpose of LAPS, and how to use the viewing tools (referencing their documentation).
  • Exclusions: Carefully consider any systems that should not have their local administrator password managed by LAPS (e.g., specific critical servers, domain controllers themselves) and ensure they are not in scope of the LAPS GPO or use GPO filtering.

Verification and Monitoring

  • Client Event Logs:On target clients, check the LAPS event log for successful policy application and password updates:
    • Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> LAPS -> Operational
    • Look for Event ID 10018 (Password successfully updated in AD) or other relevant informational/error events.
  • AD Attributes: Use Active Directory Users and Computers (with the LAPS tab enabled via RSAT) or PowerShell (Get-LapsADPassword -Identity "ComputerName") to verify that passwords are being stored and updated for computers in the pilot/deployment groups. Check the msLAPS-PasswordExpirationTime attribute.
  • GPO Application: Use gpresult /r or gpresult /h report.html on client machines to confirm the LAPS GPO is being applied correctly.

Troubleshooting

  • Schema Update Fails: Verify permissions (Schema Admins, Enterprise Admins), check DC health and replication (repadmin /showrepl, dcdiag). Ensure you are running PowerShell elevated on the correct DC.
  • GPO Not Applying: Standard GPO troubleshooting (check OU linking, security filtering, WMI filters, gpupdate /force, gpresult). Ensure clients have the necessary LAPS updates installed.
  • Clients Not Updating Password: Check client event logs for errors. Verify client can reach a DC. Confirm Set-LapsADComputerSelfPermission was run correctly on the client's OU. Ensure the LAPS service is running on the client.
  • Permission Errors (Viewing/Resetting): Double-check the output of Set-LapsADReadPasswordPermission or Set-LapsADResetPasswordPermission. Verify group memberships and OU targeting. Remember permissions can take time to replicate or require a fresh user logon token.

Migrating from Legacy LAPS

  • Schema: Windows LAPS uses some different AD attributes than legacy LAPS. Running Update-LapsADSchema is still required.
  • Client: The legacy LAPS client (MSI) needs to be uninstalled. The Windows LAPS client is built into updated Windows versions.
  • Coexistence: Legacy LAPs and Windows LAPs can co-exist though it is preferable to uninstall the MSI client from all endpoints as soon as possible.

Support

For issues encountered during the configuration or rollout, consult Microsoft's official Windows LAPS documentation.



Current LAPs Configuration

  • Password Settings: Enabled, 8 characters, complex password
  • Name of administrator account to manage: Enabled, "laps_admin"
  • Configure password backup directory: Enabled
  • (Optional) Enable password encryption: Enabled
  • (Optional) Configure password history size:Enabled, 3
  • (Optional) Configure post-authentication actions: Not Configured