The Technology

You probably already heard about Windows LAPS? Right? Not the great OG Cloud Laps from Nickolaj Andersen, but its successor, the Official Microsoft version to manage cloud devices’ local admin accounts and help you protect against pass-the-hash and lateral-traversal attacks. If you haven’t you are missing out. Please read its documentation (linked above) and come back after you are done.

The options

When deploying LAPS you can choose to manage the built-in administrator account or a custom-created one. I think there are pros and cons for both approaches, which I’ll quickly go over.

Built-in account Pros

• Its built-in, you do not need to deploy extra configurations to create it
• Until recently, the built-in administrator could not be blocked and that would allow for Brute force attacks. That seems to have been mitigated now as Windows 10 and 11 22H2 have the option to lock out the administrator built-in account turned on by default.

Built-in account Cons

• In multi-language environments, if you don’t rename the account, the account name will be localised to the Operating System.
• In another life (well in 2019) Windows 10 1809 upgrade was mistakenly disabling the built-in account for some unknown reason.

Custom account Pros

• The account is the same across all languages (if you only deploy one policy to manage LAPS and create the account)
• Microsoft won’t disable that account by mistake (let’s hope so :D)
• Since the accounts do not share the same SID you can’t create alerts on account enumeration in case someone tries to enumerate members of “Administrators” groups.

Custom account Cons

• The account needs to be created, so you need to pass a password as a parameter if using the Accounts CSP. In a world where OEMs deliver devices with really old Operating System bases builds that pose a threat that while the Operating System is not up to date with a minimum build that supports Windows Laps the account will be created and its password won’t be changed. Hopefully, that will stop being a problem soon when you can configure Autopilot to natively track Windows Updates (another one for the hope list).

The problem

Recently, when migrating one of my customers to Windows LAPS I noticed something unusual. When deploying a fully up-to-date Windows 11 (Who does that right?) the account would be marked as User must change password at next logon whereas most of the other devices would not have the same problem despite having the same policies.

It’s well-known and documented (second blue box) that “When password length and complexity rules are applied, all the local user and administrator accounts are marked to change their password at the next sign in to ensure complexity requirements are met.”. I had this same issue when my (OG) LAPS account creation script would run before the Password Policies got deployed. But on that occasion, I could interactively log in with the local admin account and change the password.

Note: Keep in mind that Intune Security Baseline for Windows 10 and later deploy those settings, so, you might run into the same issue when manually deploying DeviceLock CSP or using the baselines.

To my surprise, when I tried to do the same on my new Windows LAPS device I got this error

“The account is controlled by external policy and cannot be modified.”

When checking LAPS Event logs (Applications and Services Logs > Microsoft > Windows > LAPS) I saw the 10031 event (LAPS blocked an external request that tried to modify the password of the current managed account.). So, when the account is managed by Windows LAPS, Windows LAPS is the only thing that can change the account.

The solution(s)

Manually Rotate

Quick and dirty, if you need to do it for a small amount (or even one) device go with manually rotate the local admin password.

Quicker Self Fix

If you have configured PostAuthenticationResetDelay on your LAPS policy to anything different than 0 (so between 1 and 24 hours), the simple fact any flag was changed into that account (like when the User must change password at next logon) will trigger an authentication event (10041), forcing the account to change its password after that period has lapsed.

Slow Self Fix

In case you, for some reason, set the PostAuthenticationResetDelay to 0 (in which case disables this account after authentication), your password will only be reset based on the PasswordAgeDays, which is default to every 30 days or whatever value you set between 7 and 365 days (for Azure AD Backup).

Note 1: If at any point after deploying Windows LAPS you need to append password length or complexity policies on your environment, you need to plan for batch-rotating every single managed device's local admin password or relying on the above policies."

Note 2: If you are deploying new devices where the base build is April 2023 and later you might also have the same issue if you have both a password policy and an account creation / LAPS policy assigned to devices and the account creation happens before the password policy.

Thanks for reading and I hope that helps you understand why suddenly people will call saying the LAPS managed account is complaining the password must be changed.