Local administrator passwords and Windows LAPS: A different problem from a domain account

1. Core mechanism

The subject of LAPS is the credential lifecycle of the local Administrator account; It is a separate problem from domain accounts. The password is generated on the machine itself, stored in AD on the computer object's LAPS attributes, and its access is protected by ACL (optional encryption). The boundary of the course is 'storage/ACL/encryption separation and its proof': domain password policy remains at 08.02, computer account ID remains at 08.03, service accounts remain at 08.04. The focus here is on how the local admin password of a single machine (ws-a7) is stored, who can read it and where it leaves a trace.

Interfaces and specifications

• msLAPS-Password: Unicode string; carries the cleartext password as JSON with encryption off ({"n":account, "t":UTC update time hex, "p":password}); SearchFlags 904 (including fCONFIDENTIAL).
• msLAPS-EncryptedPassword: byte string; encrypted password blob; SearchFlags 904; AttributeSecurityGuid ms-LAPS-Encrypted-Password-Attributes (f3531ec6-6330-4f8e-8d39-7a671fbac605).
• msLAPS-PasswordExpirationTime: 64-bit integer, UTC expiration time of the password; SearchFlags 0 — not confidential.
• msLAPS-EncryptedPasswordHistory / msLAPS-EncryptedDSRMPassword: history and DSRM password for DCs; only when encryption is on; SearchFlags 904.
• ms-LAPS-Encrypted-Password-Attributes: extended right / property set; Rights GUID f3531ec6-6330-4f8e-8d39-7a671fbac605; valid accesses 48 (RIGHT_DS_READ_PROPERTY | RIGHT_DS_WRITE_PROPERTY). RP/WP property-set scope does not remove the confidential attribute’s additional RIGHT_DS_CONTROL_ACCESS requirement.
• Storage location: password is stored in the computer object; access is protected by ACLs (and optional AES-256/CNG DPAPI encryption).
• Windows LAPS Operational channel: events under Applications and Services > Microsoft > Windows > LAPS > Operational; It's not on the Security channel.
• Background task: runs once an hour, hard-coded and non-configurable; Unlike Microsoft LAPS, legacy is not a GPO CSE.

Different problem: why local admin password is private

The passwords of domain accounts are managed centrally; But every Windows machine also has a local Administrator account, and this account is independent of the domain. A common mistake for a long time was to give all machines the same local admin password. This means that if one machine is compromised, that password (or its hash) works on all other machines: the classic lateral movement / pass-the-hash backdrop.

LAPS solves this repetition problem. Each machine generates its own local admin password, returns it regularly and stores it in the directory; passwords are unique from machine to machine. This way, the disclosure of a password on one machine does not automatically spread to neighboring machines. Attention: LAPS is not a domain account solution; What it solves is the uniqueness of local credentials.

But this solution does not destroy trust, it maintains it. The question is no longer 'who knows the same password', but 'who can read this unique password stored in the directory'. The rest of the lesson explores this new surface—storage, ACL, and encryption. We will follow the WS-A7 machine as an example.

Storage: which attribute holds what

Windows LAPS stores the password in the computer object of the managed device. If encryption is off, the cleartext is written to the msLAPS-Password attribute; it is a JSON string and carries three fields: "n" the name of the managed local account, "t" the UTC password update time (64-bit hex), "p" the cleartext password. This attribute has a SearchFlags value of 904; This value consists of the fRODCFilteredAttribute, fNEVERVALUEAUDIT, fCONFIDENTIAL, and fPRESERVEONDELETE bits — meaning the attribute is confidential.

If encryption is on, the password is written to msLAPS-EncryptedPassword as a byte string; msLAPS-EncryptedPasswordHistory holds the history, and msLAPS-EncryptedDSRMPassword holds the DSRM account on DCs. These encrypted attributes are bound to the ms-LAPS-Encrypted-Password-Attributes property set (f3531ec6-6330-4f8e-8d39-7a671fbac605) as AttributeSecurityGuid. Property-set membership defines RP/WP scope; it does not replace the additional control-access requirement for confidential reads.

One critical distinction: msLAPS-PasswordExpirationTime is a 64-bit integer that holds the UTC expiration time of the password, and SearchFlags has a value of 0 — so it's not confidential. This is the basis for the three-layer permission model going forward: reading the expiration time is not reading the password. These attributes are added to the forest with Update-LapsADSchema and entered into the mayContain list of the computer class.

Access: three layers of permissions and encryption

There are three separate permission questions. Reading/writing msLAPS-PasswordExpirationTime can affect the remaining time to the next expected rotation, shortening or extending it; the device reads that value during its next policy-processing cycle. This right does not grant password-attribute read, decryption or authority to choose/write the password. Reading confidential password attributes requires both the applicable RIGHT_DS_READ_PROPERTY and RIGHT_DS_CONTROL_ACCESS conditions. If the value is encrypted, decryption also depends on that value’s encryption principal.

Encryption requires Windows Server 2016 Domain Functional Level and above. The password is encrypted on the managed device itself before being sent to the directory. The underlying CNG is DPAPI and LAPS encrypts the password with AES-256 against a single AD security principal (user or group) only. Which principal can decrypt is determined by ADPasswordEncryptionPrincipal; If not specified, the Domain Admins group of the device's own domain is used. For an already encrypted password value, the principal specified by that encryption remains fixed. ADPasswordEncryptionPrincipal is still configurable: the effective policy determines the principal for a later password encryption and successful backup. Changing the setting does not re-encrypt the stored value or its history. The principal can be a group, whose membership and access permissions must be considered separately.

The single RP ACE in the artifact is one Read Property permission limb for the ms-LAPS-Encrypted-Password-Attributes property set. Both plaintext and encrypted password attributes are confidential: both require applicable RIGHT_DS_CONTROL_ACCESS in addition to RP. Do not interpret a single RP ACE as an effective password-read grant; evaluate the security context, other ACEs and control-access scope separately. Reading ciphertext also does not replace decryption permission.

Suppose the stored password for ws-a7 was encrypted for the fictional LAPS-Readers-A group. The policy is then changed to LAPS-Readers-B. The stored value does not become a B-encrypted value just because the policy now names B. Only a later password encrypted and successfully backed up under the new effective policy uses B. Reading the attribute and being able to decrypt that particular value remain different checks.

ws-a7 / symbolic example

Stored value C_A : encryption principal = LAPS-Readers-A
Current policy  : ADPasswordEncryptionPrincipal = LAPS-Readers-B

Policy change   : C_A remains C_A
Later successful encrypted backup under policy B:
New value C_B   : encryption principal = LAPS-Readers-B

C_A / C_B are labels, not ciphertext or real passwords.

Evidence: LAPS speaks on its own channel

The evidence left by LAPS is not in the Security channel; is in a separate Windows LAPS Operational channel (Applications and Services Logs > Microsoft > Windows > LAPS > Operational). This distinction is important: searching for LAPS events among Security events results in not finding them at all. The background task runs once an hour; this cycle is hard-coded and non-configurable, and unlike Microsoft LAPS, legacy is not a Group Policy CSE (and therefore does not depend on the GP refresh cycle).

Events describe each local policy-processing cycle: 10003 marks its start, followed by 10004 for success or 10005 for failure with an error code. Event 10018 records a successful password backup to AD; 10021/10022/10023 record the effective policy settings. The channel belongs to the machine running Windows LAPS. On a domain controller, it concerns management of that DC’s local DSRM account, if enabled; it does not record password rotation on domain-joined workstations.

A special case is tampering protection. When managing an account, LAPS rejects any attempt by an actor outside of LAPS to change that account's password, blocking it with the error STATUS_POLICY_CONTROLLED_ACCOUNT (0xC000A08B) / ERROR_POLICY_CONTROLLED_ACCOUNT (0x21CE); logs each rejection as event 10031. In the Artifact section, we will read the envelope of this 10031 event.

State and data flow

1. Policy: the managed device identifies the local account and backup target. This example follows AD backup.
2. Generation: the device prepares a new password locally; P_A is only a label in this model.
3. Preparation: in encrypted mode, the device protects P_A for the record’s chosen principal, producing C_A. Plaintext mode stores P_A without that protection.
4. Backup: after the assumed successful write, the computer object holds C_A in msLAPS-EncryptedPassword or P_A in msLAPS-Password in plaintext mode.
5. Read decision: the confidential attribute requires both RP and applicable control access. Expiration-write authority does not replace either.
6. Decryption decision: encrypted records require separate decryption access for the principal chosen when the record was created. A later policy change does not change that existing record’s principal.
7. Outcome: the password is recovered only when the required decisions allow it. This model does not run rotation. 10018 represents the assumed successful AD backup in this fixture only.

2. Exploitation

Broken trust assumption

Reliable assumption: 'With LAPS installed, local admin passwords are secure; Now that each machine has received a unique password, it's done.' Where it breaks: LAPS makes the password unique but stores it in a readable location (computer object); If the right to read the password (and decrypt it if encrypted) is granted too broadly, a single authorized principal can legitimately collect the local admin password of many machines, introducing a new risk of reuse.

Technical prerequisites

• A principal controlled by the attacker has the right to read LAPS password attributes on target computer objects (yellow layer).
• If encryption is on, the same principal must also have decrypt permission (red layer: ms-LAPS-Encrypted-Password-Attributes / ADPasswordEncryptionPrincipal).
• This read right is granted inherited to a large OU (many machines); or the attacker can force rotation with expiration time write rights (green layer).
• Without these conditions, the password cannot be read: the confidential attribute requires access beyond plain read, and the encrypted password is useless without decrypt permission.

Exploitation mechanism

LAPS password compromise is often not a 'vulnerability' but rather an overly broad read/decrypt permission. If a principal computer can read LAPS password attributes on objects, the cleartext msLAPS-Password (or decrypted msLAPS-EncryptedPassword) comes to it via the directory; this is the local Administrator password for that machine. If the authority is given broadly at an OU level, the same principal can collect the local admin passwords of dozens of machines and make lateral movement — the repetition problem that LAPS solved returns, this time in the form of 'one reader, many passwords'. Alternatively, an actor with only expiration-time write rights (green layer) can non-destructively force the password to return early. The impact is limited to the set of readable machines; Password cannot be retrieved without confidential read and decrypt permissions.

Wide reading rights: the illusion of uniqueness

Just because LAPS generates unique passwords does not mean that those passwords remain secret. If a help desk group is granted permission to read LAPS passwords across the entire workstation OU, anyone in that group can read the local admin password of each workstation. Uniqueness does not provide security here; The only protection is that the right to read is kept narrow.

Encryption adds a second door to this table: encrypted attributes are only opened to the principal with decrypt authority. But if the decrypt principal is a large group (or the default is Domain Admins), the protection is weakened. Keeping the red layer narrow is just as important as the yellow layer.

Boundary and inhibitory control

Scope limit: LAPS password is a machine's LOCAL admin; It does not provide domain management on its own, but if it is read widely, it opens up to mass lateral movement. Password cannot be retrieved without Confidential read and (if encrypted) decrypt permissions; This keeps out the arbitrary reader.

Blocking controls: grant password read and decrypt permissions to the narrowest group and narrowest OU scope possible; Separate security layers based on the sensitivity of the machines (unlocking administrator laptops and frontline devices to the same group). Enable encryption (WS2016 DFL+) so that 'read right' alone does not yield cleartext. Prevent force-rotate abuse by also limiting expiration-time writes (green layer).

3. Defense & Detection

Telemetry scope

• LAPS events are in the separate Windows LAPS Operational channel, not in the Security channel; This channel should be covered separately when collecting telemetry.
• Loop events: 10003 (started), 10004 (success), 10005 (fail, with error code); 10018 Password writing success to AD; 10020 local accounts updated.
• Policy proof: Events 10021/10022/10023 record the active policy (backup directory, password age, length, encryption).
• Tampering: Non-LAPS password change is rejected with STATUS_POLICY_CONTROLLED_ACCOUNT (0xC000A08B) and logged as 10031.
• A domain controller's LAPS channel contains only events related to the DSRM account; It does not include domain-joined client behavior.

Events and relevant fields

• 10003 / 10004 / 10005 — start / success / failure of the policy processing cycle (with error code).
• 10018 — LAPS successfully wrote the password to Active Directory.
• 10021 / 10022 / 10023 — details of the active LAPS policy (AD / Entra / legacy source).
• 10031 — LAPS blocked the external request to change the managed account's password (tampering protection).
• 10041 / 10042 / 10043 / 10044 — post-authentication grace/rotation events.

The right event on the right channel

The first rule of LAPS detection is the channel: events are in the Windows LAPS Operational channel, not in Security. If a SIEM collects only the Security channel, meaningful signals such as 10031 (tampering) or 10005 (loop failure) will not appear at all. So the first 'tightening' is actually a telemetry decision: collecting the LAPS channel.

The second point is which machine the events belong to. A DC's LAPS channel is relevant only to its DSRM account; It does not include the LAPS behavior of domain-joined clients. So looking for client password events in the DC would be misleading; The event is on the client machines' own channel.

Read policy and consent proof together

A good authentication combines two sources of evidence: policy events (10021/10022/10023) show active settings — backup directory, password age, encryption turned on; ACL control shows who has password/decrypt permissions on computer objects. Whether the policy says 'encryption is on' or whether the permissions are narrow should be verified separately; one does not guarantee the other.

Post-hardening verification should be reversible and gradual: first tighten read rights in a pilot OU, followed by 10018 (successful typing) and read control, then expand. A spike of 10031 could also indicate a legitimate imaging/automation change; Evaluate the alarm with context.

Detection logic · KQL

// Windows LAPS Operational kanalindan 10031 (tampering) olaylarini daraltir.
// Varsayim: LAPS Operational kanali AMA/DCR ile Log Analytics 'Event' tablosuna
// ingest ediliyor; klasik Security ingesti bu olaylari GETIRMEZ.
Event
| where TimeGenerated > ago(24h)
| where EventLog == 'Microsoft-Windows-LAPS/Operational'
| where EventID == 10031
| summarize count(), min(TimeGenerated), max(TimeGenerated) by Computer
| where count_ > 1
| order by count_ desc

Query assumptions

• Product/table: Azure Monitor / Sentinel 'Event' table; The LAPS Operational channel is collected with AMA + DCR (the classic Security agent does not fetch this channel).
• Join key/grouping: Computer field; The time window is the last 24 hours (ago(24h)).
• The EventLog field must bear the channel name ('Microsoft-Windows-LAPS/Operational'); field mapping is required in different ingest schema (e.g. 'Channel' for modern channel).
• Missing field behavior: if the channel is not collected at all, the result returns null (the alarm silently never occurs) — this is coverage gap, not cleanup.

False positives

• Misconfigured third-party tools (password managers, imaging scripts) may attempt to modify the LAPS-managed account and produce benign 10031.
• A single 10031 on a machine is most of the time harmless; The rule focuses on a recurring (count_ > 1) pattern, however context is required.
• If the channel is only collected on some machines, tampering on uncovered machines will not appear at all (missing telemetry false-negative).

Hardening

• Grant LAPS password read permission (yellow layer) to the narrowest group and narrowest OU scope; Remove extensive inherited read rights.
• Enable encryption (WS2016 DFL+) and keep the decrypt principal (red layer / ADPasswordEncryptionPrincipal) tight; Choose the default Domain Admins consciously.
• Restrict expiration-time write authority; it can shorten or extend the remaining time to the next expected rotation. Observe the device’s next policy-processing outcome separately; do not confuse it with password read/decrypt authority.
• Include LAPS Operational channel in telemetry; Monitor events 10031 (tampering) and 10005 (failure) and establish a baseline.
• Separate security layers based on machine sensitivity; Removes admin/executive devices from help desk scope.
• When changing the encryption principal, check the effective device policy separately from the principal associated with the stored value and any retained history. Do not treat the new policy as proof that an old value was re-encrypted; keep read permission, decryption authorization and successful new backup distinct.

Read the examples

O:BAG:BAD:(OA;;RP;f3531ec6-6330-4f8e-8d39-7a671fbac605;;S-1-5-21-1109110911-2202220222-3303330333-6510)

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-LAPS"/><EventID>10031</EventID><Version>0</Version><Level>3</Level><Task>0</Task><Opcode>0</Opcode><Keywords>0x8000000000000000</Keywords><TimeCreated SystemTime="2026-09-29T07:41:03.552108100Z"/><EventRecordID>4471</EventRecordID><Channel>Microsoft-Windows-LAPS/Operational</Channel><Computer>ws-a7.outreason.example</Computer><Security UserID="S-1-5-18"/></System></Event>

Two reality checks

Assumption: Once LAPS is installed, local admin passwords are secure; Because they are unique, no one can access them in bulk.

In fact: LAPS makes passwords unique but stores them in a readable location (computer object). If the right to read the password (and decrypt permission if it is encrypted) is granted to a large OU, a single authorized principal can legitimately read the local admin password of many machines. Security comes not from uniqueness, but from narrowness of read/decrypt permissions.

Assumption: I find LAPS events and password changes in the Windows Security log.

In fact: Windows LAPS has its own separate Operational channel (Microsoft-Windows-LAPS/Operational); Events like 10018 (AD writing), 10031 (tampering) are there, not in the Security channel. Additionally, a DC's LAPS channel is only relevant to the DSRM account, it does not include domain-joined client behavior.

Sources

• Microsoft · Windows LAPS schema and rights extensions
  msLAPS-Password (Syntax 2.5.5.5, SearchFlags 904, JSON n/t/p), msLAPS-EncryptedPassword/History/DSRM (AttributeSecurityGuid f3531ec6-...), msLAPS-PasswordExpirationTime (SearchFlags 0); ms-LAPS-Encrypted-Password-Attributes rights GUID f3531ec6-6330-4f8e-8d39-7a671fbac605, valid accesses 48 (RP|WP); Update-LapsADSchema.
• Microsoft · Windows LAPS architecture (concepts)
  Password on the computer object; ACL + optional encryption; three-layer permission model (expiration/password/decrypt); CNG DPAPI AES-256 single principal, ADPasswordEncryptionPrincipal default Domain Admins, WS2016 DFL; hourly hard-coded loop (not a GPO CSE); tampering 10031 + STATUS_POLICY_CONTROLLED_ACCOUNT 0xC000A08B / ERROR_POLICY_CONTROLLED_ACCOUNT 0x21CE; disabled in safe mode.
• Microsoft · Use Windows LAPS event logs
  Operational channel; 10003/10004/10005 loop, 10018 AD write, 10020 local account, 10021/10022/10023 policy, 10031 tampering, 10041-10044 post-auth; DC channel only DSRM.
• Microsoft · Windows LAPS overview
  Windows LAPS automatically manages the password of the local Administrator account; unique, rotated passwords.
• Microsoft Open Specifications · [MS-ADTS] Control Access Rights
  §5.1.3.2.1: the control access right / property set GUID is carried as ObjectType inside the ACE ACCESS_MASK; if ObjectType is empty, all rights are covered.
• Microsoft · Configure policy settings for Windows LAPS
  ADPasswordEncryptionPrincipal: configurable user/group name or SID, resolvable by device; AD encryption prerequisites.
• [MS-ADTS] Extended Access Checks
  Selected passages reviewed: bounded permission/operation conditions; no runtime validation.
• Microsoft · Windows LAPS AD permissions
  Selected passages reviewed: bounded permission/operation conditions; no runtime validation.