[Bug] - CRITICAL: Device Lockout risk - LAPS v3.6 config missing 'WLapsAdmin' name causes Group Membership v3.7 failure

[zdenda-balcar-clevertify]

Baseline Info (please complete the following information):

• OS: Windows 11 (24H2+)
• Version: v3.6 (LAPS) & v3.7 (Local Group Membership)

Describe the bug
A critical configuration mismatch exists between the LAPS v3.6 policy and the Local Group Membership v3.7 policy in the repository. When these JSON files are imported manually, the LAPS policy fails to create the managed admin account because the account name is undefined (empty string). However, the Group Membership policy (v3.7) runs a Replace action expecting this account to exist. This results in the removal of all existing administrators (including the current user and Entra Admins) without adding the new one, causing a complete device lockout.

To Reproduce
Steps to reproduce the behaviour:

1. Import the JSON policy Win - OIB - ES - Windows LAPS - D - LAPS Configuration (24H2+) - v3.6.json into Intune.
2. Import the JSON policy Win - OIB - ES - Local Group Membership - D - Local Administrators - v3.7.json into Intune.
3. Assign both policies to a fresh Windows 11 (24H2+) device.
4. Sync the device and wait for policy application.
5. See error: The device local Administrators group is empty (except for the built-in disabled Administrator). In Intune, the "Local Group Membership" profile reports Error 65000 (Failed).

Expected behaviour
The LAPS configuration JSON (v3.6) should explicitly define the account name as WLapsAdmin in the automaticaccountmanagementnameorprefix setting by default. This would ensure the account is created, matching the hardcoded dependency in the Group Membership (v3.7) policy and preventing the lockout.

Screenshots
N/A (Intune reports Error 65000; Local net localgroup administrators returns an empty list).

Additional context
Root cause analysis based on the JSON files:

• In Win - OIB - ES - Windows LAPS - D - LAPS Configuration (24H2+) - v3.6.json, the setting for Automatic Account Management Name is initialized with an empty string:

  "simpleSettingValue": {
     "value": ""
  }

• In Win - OIB - ES - Local Group Membership - D - Local Administrators - v3.7.json, the policy is configured with Group and User Action: Replace and explicitly attempts to add the user "WLapsAdmin".

Because the account is not created (due to the empty value in LAPS config), the Group Membership policy fails to find the user but successfully executes the "Replace" action, wiping all other admins.

[itkama]

As far as I know this isn't really a problem. The LAPS Automatic Account Management ensures in the background that the account has the necessary rights. Have you actually tried if created LAPS user works regardless? I would assume it does.
This however is probably still a bug, as that user should either exist or the Local Group Membershop Policy should be ammended.

[zdenda-balcar-clevertify]

Thanks for the reply @itkama. I understand how LAPS manages rights in the background, but here is exactly what happened in my deployment which caused the lockout:

1. I imported the policies as they are in the repo.
2. The LAPS policy has an empty string "" for the Account Name. As a result, the specific user WLapsAdmin was NOT created on the device.
3. The Local Group Membership policy (v3.7) is set to Replace. It successfully removed all existing administrators (including my management account) but FAILED to add WLapsAdmin because the user does not exist.
4. Intune reported Error 65000 for the Group Membership profile.
5. The device was left with an empty Administrators group (except the built-in disabled Administrator).

So the issue is that the v3.7 Group Membership policy strictly requires the WLapsAdmin account to exist (by name), but the v3.6 LAPS policy doesn't configure that name by default in the JSON.

[itkama]

But does it actually show no LAPS password/user in Entra or Intune for affected devices?

[zdenda-balcar-clevertify]

Thanks for the reply @itkama .

I checked the "Local administrator password recovery" blade in the Entra Admin Center as requested. It explicitly states:

"No local administrator passwords found"

This confirms that the Managed Account was never created/registered by the LAPS CSP. The AutomaticAccountManagementNameOrPrefix is set to an empty string "" in the v3.6 JSON, so the account creation simply doesn't trigger. Consequently, the v3.7 Group Membership policy (Action: Replace) wiped existing admins but failed to add the missing LAPS account, causing the lockout.

Defining "WLapsAdmin" in the v3.6 LAPS JSON seems to be the required fix to prevent this.

What do you propose as the best way to handle this?

[Michael-eit]

import how? But regardless of that fix the policy re sync the device and it should figure itself out.

[zdenda-balcar-clevertify]

Hi @Michael-eit,

Regarding the import method: I used the IntuneManagement tool to import the JSONs.

I have applied the fix (manually setting the account name to "WLapsAdmin" in the policy) and forced a sync. Unfortunately, the device did not recover and remains locked out.

Diagnostics:
I managed to run Get-LocalUser on the affected device with restricted permissions. The output reveals why a simple resync isn't working—there are dozens of WLapsPendingXXXXXX accounts present (zombie accounts).

Likely Root Cause:
It appears that deploying the policy with an empty name "" forced the LAPS CSP into a failure loop:

1. CSP creates a temporary WLapsPending account.
2. CSP attempts to rename it to the target name.
3. The rename FAILS because the target name is an empty string "".
4. The process aborts, leaving the pending account disabled.
5. On the next cycle/reboot, it repeats the process, accumulating these stale accounts.

At this point, the LAPS processing seems stuck due to these stale accounts, and I suspect a full Wipe is now the only way to resolve this.

Do you have any other suggestions on how to recover from this state without a wipe?

[Michael-eit]

If you have an RMM just add a local user using the system account (we have datto, you can create or just give a current one local admin). Or you could try turning off the LAPs policy adjust the grouping manually with a seperate account. Thats what I would try before nuking the device.

[zdenda-balcar-clevertify]

Thanks for the suggestion regarding RMM. Unfortunately, we are a pure Intune environment (no Datto or other agents installed), so I don't have any alternative remote access to bypass the login.

@Michael-eit Update on the situation:
I performed a full Device Wipe to clear the corrupted state (the dozens of zombie/pending accounts). I verified that the LAPS policy in Intune was updated with the fixed name ("WLapsAdmin") and let the device re-enroll.

Surprisingly, the result ended up being the same: The device is locked out again.
It seems that the Managed Account is still not being created correctly before the Group Membership policy kicks in and restricts the administrators.

Question for the community:
Has anyone else actually successfully deployed this specific combination of v3.6 LAPS (configured with a name) and v3.7 Group Membership policies on a fresh Windows 11 24H2 device?

I am trying to rule out if this is a specific conflict in my tenant or if the baseline combination itself is currently broken for new enrollments.

[incedIT]

Question for the community: Has anyone else actually successfully deployed this specific combination of v3.6 LAPS (configured with a name) and v3.7 Group Membership policies on a fresh Windows 11 24H2 device?

I am trying to rule out if this is a specific conflict in my tenant or if the baseline combination itself is currently broken for new enrollments.

I have those policies in my tenant, the v3.6 LAPS policy has successfully applied to all my devices, the v3.7 Group Membership successfully applied to all but one device. I connected to that device this morning and when running anything as admin, the UAC prompt only shows a 'No'/'Cancel' option, no option to enter the LAPS password or select any other account/enter a username. On my other devices I get the WLapsAdmin account selected by default and I can enter the LAPS password.

All my devices are Thinkpads, the one that has the issue is a really old one just used to test some configs. It is on Windows 11 but the CPU doesn't officially support it (due to age), in case that makes any difference.

[zdenda-balcar-clevertify]

Thanks for the insight @incedIT ! It is really helpful to know that it works for you on most devices.

To clarify my hardware situation: I am deploying this on a brand new Surface Pro (ARM processor), so performance or device age shouldn't be the bottleneck in my case.

Could I ask you a few details about your setup to compare?

1. Configuration: Are you using the JSON policies exactly as they are in the repository (stock), or have you made any modifications to them?
2. OS & License: I am running Windows 11 Pro with a Microsoft 365 Business Premium license. What version and license are you using? I am wondering if this could be related to a feature difference between Pro and Enterprise (E3/E5).

Also, I did not deploy the entire baseline suite, as I excluded some policies that didn't fit my needs. Could the absence of one of these policies potentially cause the conflict (e.g., a missing dependency)?

Policies I did NOT deploy:

• Win - OIB - SC - Windows User Experience - U - Copilot - v3.6
• Win - OIB - ES - Attack Surface Reduction - D - ASR Rules (Audit Mode) - v3.1
• Win - OIB - ES - Defender Antivirus Updates - Ring 1 - Pilot - v3.4
• Win - OIB - ES - Defender Antivirus Updates - Ring 3 - Production - v3.
• Win - OIB - ES - Windows LAPS - D - LAPS Configuration - v3.1 (I used v3.6 instead)
• Win - OIB - SC - Device Security - D - Local Security Policies - v3.0
• Win - OIB - SC - Microsoft Store - U - Configuration - v3.3
• Win - OIB - SC - Windows Apps - D - In-Box App Removal - v3.7
• Win - OIB - SC - Windows Hello for Business - D - Cloud Kerberos Trust - v3.5

[incedIT]

I imported the policies using IntuneManagement, I then edited the Local Group Membership policy to switch from Add (Replace) --> Add (Update). I do not do this on my client tenants, but on my tenant I was testing something.

Using Windows 11 Pro and M365 Business Premium.

I deployed all the policies, LAPS 3.1 is unassigned as all my devices are on the current Win 11 build. I don't think those policies would have a dependency, James has done a great job at categorising the policies and making them as self-contained as possible.

[zdenda-balcar-clevertify]

Aha! That is the key detail—thank you @incedIT !

You changed the action from Replace to Update. That explains exactly why you aren't seeing the lockout.

• Update: Adds the LAPS account but keeps existing admins (failsafe).
• Replace (Repo Default): Wipes all existing admins immediately.

Since I want to stick to the strict Replace action (to ensure only the LAPS admin exists), I am hitting a race condition where the cleanup happens before the LAPS account is fully created.

My plan to fix this:
I intend to use a staged deployment:

1. Deploy only the fixed LAPS policy (v3.6) first.
2. Wait for the WLapsAdmin account to be created.
3. Only then assign the Group Membership policy (v3.7) to "Replace" the admins.

Do you agree that this phased approach should resolve the race condition on a fresh device?

[incedIT]

Aha! That is the key detail—thank you @incedIT !

You changed the action from Replace to Update. That explains exactly why you aren't seeing the lockout.

• Update: Adds the LAPS account but keeps existing admins (failsafe).
• Replace (Repo Default): Wipes all existing admins immediately.

Since I want to stick to the strict Replace action (to ensure only the LAPS admin exists), I am hitting a race condition where the cleanup happens before the LAPS account is fully created.

My plan to fix this: I intend to use a staged deployment:

1. Deploy only the fixed LAPS policy (v3.6) first.
2. Wait for the WLapsAdmin account to be created.
3. Only then assign the Group Membership policy (v3.7) to "Replace" the admins.

Do you agree that this phased approach should resolve the race condition on a fresh device?

I am seeing the lockout on one device which is strange, and I have just under 20 tenants I manage using the policy as-is (Group Memberships left on 'replace') and none of those have any errors or issues. These are devices that were already onboarded to Intune using a previous set of OIB policies and I then updated Intune to add/remove/replace so they are on the current v3.7 set.

The tenants I referenced jumped from v3.3 to v3.7 as I have them on an annual review, so they were not upgraded to v3.6 first and then to v3.7.

[zdenda-balcar-clevertify]

Hi everyone,

I think I might have finally found the root cause in my tenant setup! 🤦‍♂️

I discovered that the global tenant-level setting Enable Microsoft Entra Local Administrator Password Solution (LAPS) (located in Entra Admin Center > Devices > Overview > Device settings) was set to No.

This would explain the fatal chain of events:

Since LAPS was globally disabled, the device likely ignored the v3.6 LAPS policy during enrollment, so the managed account was never processed or created.

Immediately after, the v3.7 Group Membership policy executed the Replace action.

Since no LAPS account existed, the policy wiped all existing local admins (including the one created during OOBE).

Result: Device Lockout.

I have now enabled this setting in Entra. I am going to re-test the deployment on a fresh device using the stock v3.6 LAPS configuration (as-is, with the empty name string) to confirm if this was indeed the only missing piece.

If this confirms to be the issue, it might be worth adding a distinct warning about this Entra prerequisite to the documentation or the policy description to prevent others from accidental lockouts during fresh deployments.

I will report back with the results shortly!

[incedIT]

I discovered that the global tenant-level setting Enable Microsoft Entra Local Administrator Password Solution (LAPS) (located in Entra Admin Center > Devices > Overview > Device settings) was set to No.

That setting is a ridiculous one, such an important setting hidden in the Entra portal in a weird location. Glad you found it and resolved, I have that set to 'Yes' on my tenants. They really should either move the setting to somewhere more prominent, or have some sort of banner somewhere when it detects a LAPS policy is enabled in Intune.