LAPS rotates passwords, but the help desk has excessive access

Local administrator passwords change reliably. Yet a longstanding support group can access far more devices than its responsibilities require. Alternatively, a newly delegated group can read the LAPS attribute but cannot obtain a usable password. Both problems arise when LAPS is introduced purely as a rotation mechanism.

This article covers password access in Windows LAPS with backup to AD DS. The initial deployment is complete; the next step is to verify permissions, encryption and evidence. Microsoft Entra roles and legacy Microsoft LAPS use different access paths and need separate assessments.

Delegate three capabilities separately

The target model distinguishes who may read password attributes, decrypt encrypted passwords and change the expiration time. AD ACLs control attribute access. Encrypted storage adds an authorized decryption principal. Permission to request earlier expiration does not grant password retrieval and does not replace successful rotation on the device.

Define device scopes and responsible groups: for example, standard clients, sensitive workstations and member servers. Keep Tier 0 systems separate. Each group needs a business owner, an explicit device scope and an approval process. Also check who can modify its membership; that delegation forms part of password access.

These two access layers do not automatically provide dual approval. Anyone satisfying both requirements can retrieve the password. An approval workflow needs its own technical or organizational implementation.

Inventory existing permissions without retrieving passwords

Start on an administrative workstation with the ActiveDirectory and LAPS modules. Use an account with the necessary read permissions. This example reads only domain information and permissions; it does not retrieve passwords. Replace the example OU and DC with the approved pilot scope.

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
Import-Module ActiveDirectory
Import-Module LAPS

$pilotOu = 'OU=LAPS-Pilot,OU=Clients,DC=example,DC=com'
$dc = 'dc01.example.com'

Get-ADDomain -Server $dc |
    Select-Object DNSRoot, DomainMode

Find-LapsADExtendedRights -Identity $pilotOu `
    -DomainController $dc -IncludeComputers |
    Select-Object ObjectDN, ExtendedRightHolders

-IncludeComputers includes computer objects in the check. The results are a starting point, not complete proof of effective permissions. Also review nested groups, explicit ACEs, blocked inheritance and permissions to change ACLs or groups. Broad extended rights and full control deserve particular attention.

Record each unexpected principal, the origin of its rights, its owner and the required decision. Do not remove ACEs indiscriminately: other delegated tasks may depend on them. Cleanup requires a protected record of the original ACLs, a bounded change and subsequent functional tests.

Delegate read access within the pilot scope

Assign permissions to managed security groups at the intended OU, rather than preemptively at the domain root. A preview for one specific scope looks like this:

Set-LapsADReadPasswordPermission `
    -Identity 'OU=LAPS-Pilot,OU=Clients,DC=example,DC=com' `
    -AllowedPrincipals 'EXAMPLE\LAPS-Client-Recovery' `
    -WhatIf

-WhatIf changes nothing and does not prove that access works. Verify the group, target and inheritance scope, then execute the approved change without -WhatIf and with -Confirm. Inspect the ACLs again afterward. This command is not a cleanup of previous delegation: existing excessive permissions require a separate review.

A group that only needs to request rotation should receive the appropriate delegation through Set-LapsADResetPasswordPermission. Setting an expiration time does not immediately change the local password. Processing by the reachable device and successful backup complete the operation.

Restrict decryption to the same device scope

Encrypted storage requires at least the Windows Server 2016 domain functional level. Under Computer Configuration > Policies > Administrative Templates > System > LAPS, configure AD DS as the backup destination, enable password encryption and select the intended authorized decryptor for the pilot scope. The corresponding settings are BackupDirectory, ADPasswordEncryptionEnabled and ADPasswordEncryptionPrincipal.

Windows LAPS uses a single user or group for this purpose. If no decryption principal is explicitly configured, it defaults to the Domain Admins group. Use a dedicated security group; where several roles require access, it can contain carefully managed groups. Check effective membership and responsibilities before devices encrypt against it.

Changing the principal does not rewrite existing encrypted passwords. Plan controlled rotation and successful backup under the new policy. Existing password history remains associated with the principal used when each password was encrypted. Former authorized users may still know previously retrieved passwords, which is another reason to include rotation when withdrawing access.

DSRM is a special case: for backup on domain controllers, the Domain Admins group of the respective domain is the authorized decryptor. A different ADPasswordEncryptionPrincipal is ignored there. Do not extend the client help desk model to DCs.

Run positive and negative tests without plaintext logging

Test retrieval against one approved pilot device in separate sessions: authorized support, an unauthorized user and support responsible for a different device scope. After group changes, use a renewed sign-in context for the tests.

Get-LapsADPassword -Identity 'LAPS-PILOT-01' `
    -DomainController 'dc01.example.com' -ErrorAction Stop |
    Select-Object ComputerName, Source, DecryptionStatus,
        AuthorizedDecryptor, PasswordUpdateTime

This command actually attempts password retrieval and, where applicable, decryption. Run it on a trusted administrative workstation. Without -AsPlainText, the password is returned as a SecureString; the selection displays only verification metadata. Never export the complete result into tickets or logs.

For an authorized test with encrypted storage, expect Source: EncryptedPassword and DecryptionStatus: Success. Also match AuthorizedDecryptor against the approved target group and check PasswordUpdateTime to confirm that the planned rotation has occurred. Negative tests must not make a usable password available. Distinguish denied attribute access, denied decryption and technical failures. Broken connectivity to a DC does not demonstrate effective access restrictions.

Verify auditing on the responsible DC

Configure LAPS-related SACLs specifically on the pilot scope using Set-LapsADAuditing. Cover both legitimate retrievals and the unauthorized access attempts you need to observe. On the responsible DCs, enable the Audit Directory Service Access subcategory for the intended success and failure cases.

Use the test accounts to validate event 4662 and its forwarding. Correlate identity, object, access type and timestamp. A 4662 event for reading an encrypted attribute does not prove successful decryption. Decryption denied after the read does not necessarily appear as a failed AD read operation either.

Define specific alerts: retrievals for many devices in a short period, access outside the assigned scope and changes to authorization groups. Password values belong in neither the SIEM nor support tickets.

Advantages of separate access controls

  • Support permissions can match the devices each team actually manages.
  • Encryption adds a control alongside the AD ACL.
  • Rotation can be delegated without also permitting password retrieval.
  • Repeatable access tests reveal whether the role model still works after OU or group changes.

Disadvantages and operational limits

  • Two access layers increase troubleshooting and maintenance effort; selecting the wrong decryptor can block recovery.
  • Group membership changes cannot make someone forget a password they already know.
  • LAPS does not replace protected administrative workstations or secure group and GPO management. It does not create an independent security boundary against compromised domain administration.
  • AD-based retrieval may be unavailable during a widespread directory outage. The emergency process must explicitly address that dependency.

Common pitfalls before acceptance

Correct OU delegation offers little protection when an old support group inherits full control from above. Other significant problems include moving devices without reassessing access, using stale sign-in tokens for negative tests and confusing directory read auditing with password use. Successfully querying metadata also does not prove that an emergency local sign-in works.

Rehearse that sign-in separately on an isolated pilot device, with controlled password display and no recording of the secret. Verify rotation and renewed backup afterward. Outages affecting AD or the usual administrative workstation require a separately protected and rehearsed recovery path; blanket password exports are not an operational model.

Project checklist for approval

  • [ ] Device scopes, group owners and membership change permissions documented.
  • [ ] OU and object permissions checked, including inheritance.
  • [ ] Read access, authorized decryptor and rotation delegation defined separately.
  • [ ] Effective policy, rotation and backup verified on the pilot device.
  • [ ] Authorized retrieval, cross-scope access and unauthorized access tested.
  • [ ] Password history and former authorized users considered during transitions.
  • [ ] DC auditing, event forwarding and alerts validated in practice.
  • [ ] Emergency sign-in, subsequent rotation and an AD outage scenario rehearsed.
  • [ ] Reassessment agreed for OU, group and GPO changes.