1 TLDR;

Microsoft is releasing an Azure AD integrated, built-in LAPS agent to Windows 10 and Windows 11 that can be controlled by Intune.

1.1   Problem Statement

Migrating Windows endpoints to Intune-only management left gaps in controllable settings. An alternative for traditional Local Administrator Password Solution (LAPS) in an on-premises domain has been a primary gap. Third-party tools and DIY solutions existed but introduced complexity and insecurities. Microsoft is now releasing a new version of LAPS that will be built in to the Windows OS, integrates directly with Azure Active Directory (AD) for password escrow, and is configurable natively in Microsoft Endpoint Manager (MEM/Intune).

1.2   Audience

Organizations and teams managing Azure AD joined endpoints looking to remove dependencies of on-premises AD

1.3      Prerequisites

• Azure AD joined or Hybrid joined Windows 10 20H2 or later systems
• A configuration management tool capable of applying CSP or Registry settings

2 Windows LAPS

Microsoft's legacy LAPS tool has long provided a necessary mechanism for maintaining administrative accounts on endpoints. IT and security teams have traditionally deployed and configured this tool by Group Policy to meet numerous security requirements, including:

• Automatically rotating privileged passwords on endpoints
• Maintaining access to endpoints that lose domain membership
• Providing end users temporary privileged access while unreachable by RMM tools
• Performing troubleshooting or IR access to potentially compromised devices

With organizations trending toward a primarily remote workforce, many of the tools and techniques that have depended on local AD have become a significant pain point for IT. Legacy LAPS was no exception, with its dependance on Group Policy for deployment and local AD as the only option for storing device passwords. Later versions of legacy LAPS supported uploading passwords to Azure AD but could still only be deployed and configured by Group Policy. This restriction meant that teams wanting to leverage the Microsoft native solution were forced to keep devices tethered to AD.

Step in, Windows LAPS! In the April cumulative update for Windows, Microsoft has released Windows LAPS. This version is built in to Windows 10 devices running 21H2 or later and can be configured by Configuration Service Provider (CSP), including through Intune. Since it's officially in public preview, let's kick the tires!

2.1      Prerequisites

We need to first enable the preview feature in Azure AD:

Azure AD or Entra > Devices > Device settings > Enable Azure AD Local Administrator Password Solution (LAPS)

While we're here, let's make sure users (and attackers) can't get their own BitLocker keys.

Next, let's get an Intune-managed system updated to the version of Windows that includes Windows LAPS. We'll check for the 2023-04 Cumulative Update (CU) and make sure we're enrolled and synced with Intune.

If the legacy LAPS agent is installed, make sure to remove it at this point to avoid conflict with the new policy.

2.2      Create a Profile

Now we need to set up a policy in Intune. I have been using the Windows LAPS CSP, but there is a new Account Protection policy template for Windows LAPS here:

Intune > Endpoint Security > Account Protection > Create > Windows 10 and later > Windows LAPS

Alternatively, you can still use the CSP in a custom template here:

Intune > Devices > Configuration profiles > Create profile > Windows 10 and later > Templates > Custom

https://endpoint.microsoft.com/?ref=AdminCenter#view/Microsoft_Intune_DeviceSettings/CreatePolicyFullScreenBlade/policyId/00000000-0000-0000-0000-000000000000/policyType/Windows10Custom/policyJourneyState~/0

Many of the settings shown below are default values and do not need to be configured. I prefer to set these settings anyway, to remove any doubt, and so I can verify that the setting was applied through the Per Setting Status later. A description is also optional, but since the value is not directly visible from the profile, I use that to note a friendly value of the setting. There are other settings for devices syncing the LAPS password to on-premises, but you can ignore those settings for Azure AD.

https://learn.microsoft.com/en-us/windows/client-management/mdm/laps-csp

2.3      Create a New Local Account (Optional)

If you configured LAPS to manage the built-in local Administrator account, you can skip this section. LAPS looks up the local Administrator account by well-known Security Identifier (SID), so if even if you're using a renamed Administrator account, you can skip this section.

If you configured LAPS to manage a custom account name, you need to create the new account separately. There is a CSP for creating local accounts, but the documentation isn't quite as clear. The account's username goes directly in the path of the OMA-URI, not as a value. Check out the placement of TrustedSecAdmin in the two (2) settings below to see what I mean. Change the username and initial password to your own. If you configured the LAPS profile above via CSP, you can add these two (2) settings to the same profile.

https://learn.microsoft.com/en-us/windows/client-management/mdm/accounts-csp

2.4      Make it So!

Assign this policy to the test device and force a sync. Wait a few minutes for the profile to pull down and get applied. If you configured LAPS to back up to Azure AD, Windows registers Event ID 10022 to the Microsoft-Windows-LAPS/Operational Log once the profile is successfully applied.

(Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-LAPS/Operational';Id=10022}|Select-Object -First 1).Message

The new profile should trigger LAPS to do a sync and generate Event IDs 10029 and 10020.

If this doesn't happen or you need to adjust the policy and trigger a new LAPS reset attempt, run this command:

Invoke-LapsPolicyProcessing

Check that the device's password is visible in Entra/Azure AD. There is a handy new menu that will show every device with a password uploaded:

And that's it! Now you have a cloud-native, built-in LAPS solution deployed.

If you were pushing local administrators with Azure AD or Intune previously, you can now roll that policy back. Having any account with administrative access to many devices is a bad idea.

Lastly, remember to train support staff with information on what the local administrator username is and where to get the password before deploying the profile to the fleet.