Windows LAPS Overview
Windows Local Administrator Password Solution (Windows LAPS) is a Windows feature that can automatically manage and backup the password of a local administrator account on either a Microsoft Entra joined or Active Directory joined device Windows device. This is a great feature, as administrators do not want to provide local admin rights for users as this poses a security risk but it's also important that admins retain some form of local admin access on devices for troubleshooting purposes or elevation and having a solution that does not open an organization up to lateral movement in the event of a compromise is key.
Worth noting is that for Windows Server 2019/2022, Windows LAPS can also automatically manage and backup the Directory Services Restore Mode (DSRM) account password on your Active Directory domain controllers, pretty neat.
Table of Contents
6. Conclusion
An intro to LAPS
This is actually, the first time I've delved into LAPS (we had a custom solution at my previous place of employment) and I did so following Daniel Bradley's excellent guide on how to configure the new LAPS settings for automatic account creation, which you can find here: How to Enable Automatic Account Creation for LAPS in Intune (ourcloudnetwork.com), highly suggest you read that and bookmark his blog.
What I am going to highlight in this post is how you can pair these new settings with the Local user group membership policy to have full control over which user accounts are local administrators. Why? You may still be in the process of removing local admin from your users and looking to implement LAPS at the same time in which case, this is a great way forward as we can boot those users out while ensuring we still have local admin access, without the use of third-party solutions, such as an RMM or script.
NOTE: Prior to releasing this blog, I have seen that Microsoft have added some new functionality in Entra ID which allows you to manage the addition of the Global Admins group as well as who (if any) should be allowed to be added to the local Administrator group after joining an Entra device, nice! Thanks again to Daniel Bradley for posting about this. You can find his blog about this new feature here: Limit local administrators on Microsoft Entra joined devices (ourcloudnetwork.com)
Setting Up LAPS on Windows 11
Quick heads-up for those diving into the LAPS setup on Windows 11—I learned that the fresh account creation CSP settings are currently only supported on Windows 11 Insider Preview Build 26040 and newer. For my own experiments, I went with the Windows 11 Insider Preview Enterprise (Dev Channel) Build 26080. Just to mix things up and see what happens on the other side of the fence, I also ran some tests on another machine sporting Windows 11 Enterprise 22631. This was to get a taste of what we're dealing with when it comes to older builds.
Now, the new policy settings include the following CSP settings.
Before we dive deep, there's a crucial bit you need to know for our proposed solution to hit the mark. We need the power to specify the username for the account we're adding to the Administrators group. This means we can't just roll with the AutomaticAccountManagementRandomizeName CSP—nope, we need to dial in the exact name using the AutomaticAccountManagementNameOrPrefix CSP.
So, what’s the look of our LAPS policy shaping up to be? Since these settings haven’t made their grand entrance into the Settings Catalog just yet, we're going down the bespoke route with a custom OMA-URI settings profile. A bit of a workaround, but hey, it gets the job done.
The settings used are as follows:
Name: AutomaticAccountManagementEnableAccount
Description: Use this setting to enable or disable the automatically managed account.
OMA-URI: ./Device/Vendor/MSFT/LAPS/Policies/AutomaticAccountManagementEnableAccount
Data Type: Boolean
Value: True
Name: AutomaticAccountManagementEnabled
Description: Use this setting to enable automatic account management.
OMA-URI: ./Device/Vendor/MSFT/LAPS/Policies/AutomaticAccountManagementEnabled
Data Type: Boolean
Value: True
Name: AutomaticAccountManagementNameOrPrefix
Description: Use this setting to specify the name or the name prefix of the automatically managed account.
OMA-URI: ./Device/Vendor/MSFT/LAPS/Policies/AutomaticAccountManagementNameOrPrefix
Data Type: String
Value: TSL-LapsAdmin
Name: AutomaticAccountManagementRandomizeName
Description: Use this setting to enable randomization of the name of the automatically managed account.
OMA-URI: ./Device/Vendor/MSFT/LAPS/Policies/AutomaticAccountManagementRandomizeName
Data Type: Boolean
Value: False
Name: PasswordComplexity
Description: Use this setting to configure the required password complexity of the managed local administrator account, or to specify that a passphrase is created.
OMA-URI: ./Device/Vendor/MSFT/LAPS/Policies/PasswordComplexity
Data Type: Integer
Value: 7
Name: BackupDirectory
Description: Enables password backup to Entra ID.
OMA-URI: ./Device/Vendor/MSFT/LAPS/Policies/BackupDirectory
Data Type: Integer
Value: 1
Name: PasswordAgeDays
Description: Configure the maximum password age of the managed local administrator account.
OMA-URI: ./Device/Vendor/MSFT/LAPS/Policies/PasswordAgeDays
Data Type: Integer
Value: 7
Name: PostAuthenticationActions
Description: This setting specifies the actions to take upon expiration of the configured grace period.
OMA-URI: ./Device/Vendor/MSFT/LAPS/Policies/PostAuthenticationActions
Data Type: Integer
Value: 3
Name: PostAuthenticationResetDelay
Description: This setting specifies the amount of time (in hours) to wait after an authentication before executing the specified post-authentication actions.
OMA-URI: ./Device/Vendor/MSFT/LAPS/Policies/PostAuthenticationResetDelay
Data Type: Integer
Value: 1
Name: AutomaticAccountManagementTarget
Description: Use this setting to configure which account is automatically managed.
OMA-URI: ./Device/Vendor/MSFT/LAPS/Policies/AutomaticAccountManagementTarget
Data Type: Integer
Value: 1
With the above settings deployed to an Insider version of Windows we will end up with a newly created LAPS admin account called 'TSL-LapsAdmin' with a password complexity that equates to a Passphrase using short words that is rotated every 7 days, is backed up to Entra ID and will reset the password and logoff the managed account upon expiry of the grace period which is set to 1 hour. The highlighted CSP settings are the new ones that currently require the Insider version of Windows.
Now if we deploy that to both VMs, let's see what we get!
Down the rabbit hole
On the Windows 11 22631 build we can see that we get the Event ID 404 or in other words 'Catastrophic failure' 😂 - this is because the CSP settings are not supported on this build.
And we can confirm this by checking in the registry where we can see that only the supported settings have applied.
Now let's check our insider VM.
Here we can see that all the expected registry keys have been created, so now we need to check local users to see if the account was created.
Voila! Account created and the account was added to the local Administrators group. We can also grab the password for the account directly from the device in Intune.
But notice how we have a user account called LocalAdmin? In my case, this is the initial account created when I spun the VM up which subsequently became the first local admin account (other than the built-in Administrator). In a real scenario this could easily be the Entra ID user that enrolled the device to Entra or just legacy local admins that were used previously. So how can we take this one step further and remove all local admins from the built-in Administrators group except our LAPS admin?
This is where the Local user and group membership profiles come in!
Remove those users!
We can create a profile from Endpoint Security > Account Protection > Local user and group membership.
By setting up our LAPS account with a specific username, we've ensured it remains a fixed member of the local Administrators group. With the "Add (Replace)" action in our toolkit, we can now meticulously control who makes the cut into this group. This means we can wave goodbye to any unwanted accounts, like LocalAdmin, ensuring a clean slate. This is also why we did not want to use the AutomaticAccountManagementRandomizeName CSP setting as the LAPS account would get a different username each time it was created.
Now, we understand the necessity of adding our LAPS administrator account 'TSL-LapsAdmin'. However, what about other accounts? You may not be aware, but by default, all devices joined to Entra ID include two group object SIDs that are automatically added to the local Administrators group. These groups are associated with the tenant's Global Admins and the Entra Joined Device Local Administrator role. You can verify this by checking the Administrators group on a reference device. The SIDs linked to these groups are unique to your tenant. Assuming you wish to maintain this default setup (though you might choose not to), it is necessary to add the corresponding SIDs to your Local User and Group Membership profile. Furthermore, following Microsoft's guidance here: LocalUsersAndGroups Policy CSP - Windows Client Management | Microsoft Learn, when utilizing the 'Replace' option to configure the built-in Administrators group, it's crucial to always include the administrator account as a member, along with any other custom members.
So, our policy will look like the below which we can then assign to our device group.
Let's see how that looks on our Insider VM first.
Sure enough, we can see that the policy applied and has successfully replaced the users in the local Administrators group with the ones specified in the policy.
And we can confirm this by checking the group membership.
Now let's check our Windows 11 22631 build.
Error, error, error.
Let's take a look…
Following through the details we can see that the issue is stated towards the bottom.
No mapping between account names and security IDs was done.
We have confirmed the correctness of the SIDs for the Global Admins and the Device Local Administrator role, and since the Administrator account is a built-in account, it must exist. This narrows down the issue to the LAPS admin account 'TSL-LapsAdmin', which we know has not been created or does not exist. This is due to the new CSP settings requiring the Insider Preview of Windows. Therefore, let's address this.
To resolve this issue on the standard Windows 11 build, we need to exclude 'TSL-LapsAdmin' from the original Local User and Group Membership policy. This can be achieved through group exclusion or applying a filter (I opted for a filter). Subsequently, we need to establish a new policy that omits the LAPS admin. What I ended up with was…
And for the CLIENT-2 policy (our Windows 11 22631 build)
Once that policy had applied, it applied correctly.
Managing the LAPS account before the new settings arrive
So, at this point you could revert to the current method for deploying LAPS using a custom OMA-URI to create the account and set the initial password and if required, add the account to the Local user and group membership policy.
I added "01" to the username to identify it was separate to our other policy.
Used in conjunction with its own Local user and group membership policy we get the same outcome without the new account management controls.
Conclusion
I'm honestly surprised this was my first real dive into LAPS, but now that I've gotten my hands dirty, I have to say—it’s a solid tool for admins aiming to keep their local administrator account in check. I am excitedly awaiting the rollout of the new CSP settings in the Settings Catalog and their distribution via Windows update. It’s clear this is going to make life a lot easier for many of us.
Comments