Windows LAPS: More than just a policy

Being able to elevate permissions on Windows clients and servers in a secure and controlled way can be a struggle. Pass-the-Hash (PtH) must always be considered, rendering environments where an admin has signed on with domain credentials vulnerable.

Using local administrator accounts has been used for a long time and we have seen solutions such as:

• Same local administrator password for all devices: Sharing the same password is an obvious risk.
• Local Administrator Password Solution (LAPS): The “Local Administrator Password Solution” (LAPS) provides management of local account passwords of domain joined computers. Passwords are stored in Active Directory (AD) and protected by ACL, so only eligible users can read it or request its reset.
• CloudLAPS: Basically same functionality as LAPS but for Azure AD-joined devices. Works really well but as it is community driven, some organizations tend to not use it.

Expectations

For the rest of this post we will touch down on important considerations before Windows LAPS can be successfully implemented. This is going to be a long one but try to hang as it will help you on your WLAPS journey.

Windows LAPS: Added value

From MS Learn: “Windows Local Administrator Password Solution (Windows LAPS) is a Windows feature that automatically manages and backs up the password of a local administrator account on your Azure Active Directory-joined or Windows Server Active Directory-joined devices. You also can use Windows LAPS to automatically manage and back up the Directory Services Restore Mode (DSRM) account password on your Windows Server Active Directory domain controllers. An authorized administrator can retrieve the DSRM password and use it.”

💡Choose from managing Windows LAPS with Group policies or Intune.

Windows LAPS: Licensing

Windows LAPS is built-in to Windows:

• ✅No need to install an additional client/agent
• ✅No additional licensing. But remember that an Intune license is needed if you want to manage your devices with Intune.

Windows LAPS: Prerequisites

• Windows 11 22H2 – April 11 2023 Update
• Windows 11 21H2 – April 11 2023 Update
• Windows 10 – April 11 2023 Update
• Windows Server 2022 – April 11 2023 Update
• Windows Server 2019 – April 11 2023 Update

Device join state restrictions (password backup possibilities):

• Azure AD joined device: Backup to Azure AD only
• On-prem AD joined device: Backup to on-prem AD-only
• Hybrid joined device: Backup to either Azure AD or on-prem AD. It is not supported to have the same device upload its password to both AAD and AD at the same time.

Windows LAPS: Event 10059

❗Do not forget to enable local administrator settings (this is still required even though it is no longer in preview)

1. Open: entra.microsoft.com -> Devices -> All devices -> Device settings
2. Enable: Enable Microsoft Entra Local Administrator Password Solution (LAPS)

Optional (but recommended): Windows LAPS: Manage the local administrators group

A lot of changes could happen to the local admins group over time. Creative users could use LAPS to add themselves, Shift+F10 during autopilot is a risk, badly put together GPOs could have done some changes and the enrolled by-user could have been added as admin during Autopilot provisioning.. so taking control of the local administrators group is crucial. In short; We need to find the sweet spot were we actually know what is going on 🛡️

Here is an example of what it could look like (somewhat exaggerated):

In this case we want to get rid of below four members/personas as they have no business being local admin.

1. Hacker added me here
2. I quit 2 years ago
3. Random User
4. What is local admin?

In my strategy I want to keep:

• Administrator
• Global administrator
• Azure AD Joined Device Local Administrator

As you can see, we have two SID objects (S-1-12-1-xxxx…) without user names. This is an Azure AD-joined device which has no additions from a local AD. Let’s have a look at how to translate these SIDs to something more friendly for us to read, to make sure we know what they are an can decide upon to keep them or not.

1. Oliver Kieselbach has created two scripts to translate SIDs to Azure AD ObjectIDs and vice versa. Go check his blog post out to learn more: PowerShell Helpers to convert Azure AD Object IDs and SIDs (oliverkieselbach.com)
2. I have slightly modified one of Olivers script and my version is found here NicklasAhlberg/WindowsLAPS (github.com)
   • Go a head and download the latest release, from the “releases part”
   • The script we want to run right now is found in the “Translate SID to objectID” directory
3. Make sure that the Azure AD PowerShell module is installed, if not install it by running: Install-Module AzureAD
4. Now open the script and add the SIDs to translate to line 32. This is an array so it is possible to add multiple SIDs as follows: “SID1″,”SID2,”SID3”
5. Run: the script
   
   
6. OK, so the SIDs translates to “Global Administrator” and “Azure AD Joined Device Local Administrator” and this is according to our strategy which is great.
   💡Now we know these two members should be kept as members of the local administrators group.

Let’s have a look at how to use Intune to take back control of the local administrators group once and for all. In this case we want to remove the four unwanted accounts and keep Administrator and the two SIDs as mentioned above.

1. Open: intune.microsoft.com -> Endpoint security -> Account protection
2. Click: +Create policy
   
3. Platform: Windows 10 and later
4. Profile: Local user group membership
5. Click: Create
6. Name: W10/11 – Local administrators group
7. Local group: Administrators
8. Group and user action: Add (Update)
9. User selection type: Manual
   
10. Selected users/groups: Here we must add the members we want to keep. I will keep the built-in local administrator account and the two Azure AD objects mentioned above.
    
11. Here is the result, nice and clean
    
12. ❗Remember to configure this as per your specific need and test it thoroughly.

The first thing we want to do is make sure that creations of new local accounts is monitored. We can accomplish this by following below steps.

1. Open: intune.microsoft.com -> Devices -> Configuration profiles
2. Click: +Create profile
3. Platform: Windows 10 and later
4. Profile type: Settings catalog
5. Click: Create
6. Name: W10/11 – Audit Local account creations (or a name of your choice)
7. Click: Next
8. Click: +Add settings
9. Click: Auditing
10. Find: Audit User Account Management
11. Audit User Account Management: Success+Failure
12. Go ahead and assign the policy as per your need and create the policy
13. New local account creations will generate an event:
    Event Viewer -> Security -> Event ID 4720
    
14. Account name: Will be the logon name for the newly created local account
15. Account domain: Will be the same as the name of the device (hostname) to indicate it is a local account
16. Good to know: You could use gpedit.msc to test this out on a single device

Now we are able to monitor newly created local accounts. But these event are generated and stored locally and we would need to connect to each device to see what is going on.

In the next step we will create a scheduled task with event 4720 as a trigger to be used by Proactive Remediations to monitor our devices centrally.

Windows LAPS: Monitoring – Audit user account management Part 2

I have put together a ZIP-file with the files needed for the next part. Let’s start of by downloading the latest release over at: NicklasAhlberg/WindowsLAPS (github.com)

1. Download and extract the latest release from: NicklasAhlberg/WindowsLAPS (github.com)
2. Open: Local Account Monitoring Package -> Deploy-Application.ps1 in your favorite PowerShell editor, I am using VS Code for this.
3. Scroll through the script to see what is going on. The most interesting part is found between lines 193-198.
4. Optional: Edit line 111 as per your need. This will be the name of the registry hive created by the scheduled task. ❗Remember to change the Win32App detection rule accordingly if you change it.
5. Close and save the PowerShell editor (if you made any changes).
6. We will now wrap this package and deploy it as an Intune Win32 app. Use a Win32 Content Prep tool to wrap the content into an .intunewin-file, I will use the Rock Enroll Tool to get the job done.
7. Open: intune.microsoft.com -> Apps -> Windows -> +Add
8. App type: Windows app (Win32)
9. Select file: Select the .intunewin-file found in the _intune folder
10. Click: OK
11. Name: W10/11 – Local Account Monitoring
12. Description: All info is found here: https://www.rockenroll.tech/2023/05/15/windows-laps-more-than-just-a-policy/
13. Publisher: Rockenroll.tech
14. App version: 1.0.0.1
15. Click: Next
16. Install command: Deploy-Application.exe -DeploymentType Install
17. Uninstall command: Deploy-Application.exe -DeploymentType Uninstall
18. Click: Next
19. Requirements: As per your need
20. Click: Next
21. Rules format: Manually configure detection rules
22. Click: +Add
23. Rule type: Registry
24. Key path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Rockenroll.tech\Detection\Local Account Monitoring – Scheduled task ❗Change this accordingly if you changed line 111 on step 4
25. Value name: Version
26. Detection method: Version comparison
27. Operator: Greater than or equal to
28. Value: 1.0.0.1
29. Click: OK
30. Click: Next (three times)
31. Assign the app as per your need
32. Click: Next
33. Click: Create

Windows LAPS: Monitoring – Audit user account management Part 3

So far we have enabled auditing of local user account creations and deployed an Intune Win32 app to create a scheduled task with 4720 as the trigger.

Let’s go ahead and configure Proactive Remediation as the last step.

1. Edit: Remediation.ps1 -> Line 24
2. Add all your allowed local accounts line 24. Defined accounts will be kept and not removed by the remediation script
   • 💡Remember to add the builtin account, especially if you have renamed it
   • 💡In Windows 365 the builtin account is renamed to BuiltInAdmin
   • 💡If you disable the builtin account you must add the new account created by you
3. Open: intune.microsoft.com -> Devices -> Remediations
4. Click: Create script package
5. Name: W10/11 – Local Account Monitoring – Remediation
6. Description: All info is found here: https://www.rockenroll.tech/2023/05/15/windows-laps-more-than-just-a-policy/
7. Click: Next
8. Detection script file: Detection.ps1 included in the ZIP-file we downloaded before
9. Remediation script file: Remediation.ps1 included in the ZIP-file we downloaded before
10. Run script in 64-bit PowerShell: Yes
11. Click: Next (twice)
12. Assign and set a schedule according to your need. I will begin with a test group and have it scheduled to run on a daily basis
    
13. Click: Next
14. Click: Create
15. Logon to a targeted device and make sure that the task has been created accordingly
16. That’s it for monitoring and taking control of what local accounts are created in your Windows environment.
    
    Again, here is what we have set up:
    1, Local account is created. 2, An event is created. 3, A task is triggered by the event and creates a registry value. 4, Proactive remediations detects the registry value. 5, The remediation script removes all unallowed accounts ✅

Windows LAPS: Intune policy

OK, so now that we have control of the local administrators group, let’s have a look at how to use Intune to configure Windows LAPS. We will use an Intune account protection policy to get going.

1. Open: intune.microsoft.com -> Endpoint security -> Account protection
2. Click: +Create policy
   
3. Platform: Windows 10 and later
4. Profile: Local admin password solution (Windows LAPS)
5. Click: Create
6. Name: W10/11 – Windows LAPS
7. Click: Next
8. Here is an example policy, configure it as per your need, note that I will backup the password to Azure AD only
9. Click: Next twice
10. Assign the policy as per your need. I recommend to always test it first.
11. Click: Next
12. Click: Create

Windows LAPS: Event viewer

Let’s have a quick look at the event viewer on a device targeted by our new Windows LAPS policy.

1. Open: Event viewer
2. Click: Applications and Services Logs -> Microsoft -> Windows -> LAPS
3. Before the policy is targeted:
   
4. When the policy has been targeted and received by the device:
5. 💡It is common that the built-in Administrator account is disabled. This doesn’t stop Windows LAPS from takning control, but the account must be enabled before it can be used:
6. Success:
   

Optional: Windows LAPS: Enable local administrator account

As stated above, it is common to have the built-in local administrator account disabled. It is actually disabled out-of-the-box after Windows Autopilot provisioning, but it is easy to enable it.

Let’s have a look at how to enable the account to make sure we can use it with Windows LAPS.

1. Open: intune.microsoft.com
2. Click: Devices -> Configuration profiles -> +Create profile
3. Platform: Windows 10 and later
4. Profile type: Settings catalog
5. Click: Create
6. Name: W10/11 – Enable builtin local administrator
7. Click: Next
8. Click: +Add settings
9. Click: Local Policies Security Options
10. Select: Accounts Enable Administrator Account Status
11. Enable the setting
    

Windows LAPS: Local password policy

So, what if we have devices being (or have been) targeted by a local password policy? What will happen when the Windows LAPS and local password policy collide? Let’s find out!

Scenario 1: Windows LAPS is applied before password policy

In the first test we will have Windows LAPS policy apply before the password policy. We will intentionally configure both policies differently to see the outcome.

Below Windows LAPS policy is configured and applied to the device before the password policy is assigned.

Below password policy is applied after the Windows LAPS policy is successfully applied

As you can see both the password complexity and minimum password length differs between both policies.

Here is the result after both policies has been applied to the device


Summary: The password length setting is successfully applied but the password complexity doesn’t change.

Bonus test: Let’s try to rotate the Windows LAPS password now that the password length requirements have changed.

As demonstrated above, a new Windows LAPS password cannot be created as the password complexity requirements overrides our Windows LAPS policy.

💡We must start off by sorting our existing policies out and to test accordingly.
Remember: Windows LAPS is more than just a policy!

Scenario 2: Password policy is applied before Windows LAPS

Let’s do it the other way around and have the password policy applied before Windows LAPS. This will be the most common scenario for most organizations as the password policy has been around for a long time. 💡Remember that hybrid Azure AD-joined devices could be hit by a GPO.

The Password policy was successfully applied:

The Windows LAPS policy was successfully applied (according to Intune anyway) but nothing happened on my device for about three hours.

After about three hours this showed up in the event viewer:

⛔No local administrator password on the device object

❓The Windows LAPS policy was clearly successfully applied, so this is getting weird…

I left the computer on for a good four hours and the policy tried to re-run every 60 minutes but still didn’t succeed. This is kind of inconsistent with the success codes from Intune, isn’t it?

💡Do not completely rely on the Intune success codes for Windows LAPS. We must check this ourselves to determine whether Windows LAPS has been successfully implemented or not.

Scenario 3: Windows LAPS policy is applied before 2023-04 quality update

As Windows LAPS requires 2023-04 quality update to be installed, any non-updated devices will be unable to apply the policy

Scenarion 4: Password complexity policy was used before, but not anymore

In this scenario we used to have the password policy assigned, but with the new Windows LAPS policy in place we decided to unassign the password policy from our devices.
The password policy was configured to require a minimum device password length of 16 characters before the policy was unassigned. And the Windows LAPS policy is set to 15 characters, meaning that the password policy used to be more restrictive.

I went ahead and tried to rotate the Windows LAPS password from the Intune portal with below result. It clearly states that the rotation was completed, right?

BUT, as I were unable to find the new password from the Local admin password list in Intune, I went a head and had a look at the event viewer once again and this is what I found.

❗So… once again we run into a completed or successful state when something actually didn’t work in the background.

As the password policy most likely has been targeted at our devices at some point before Windows LAPS, there are some things to consider.

💡The password policy tattoos the settings to our devices, meaning that we will not revert any changes by unassigning the policy.

💡If you have had the password policy assigned at some point it is important to have the Windows LAPS policy set to be at least as restrictive.

💡If you run into issues similar to above, my recommendation is to re-assign the password policy to match the Windows LAPS policy.

This has been a long post! If you have come this far (to the end) you have hopefully enjoyed reading it. Let me know what you think and share your experience with Windows LAPS in the comments!