Let's have a tête-à-tête with the new Windows LAPS for Azure AD joined devices

Loooooong awaited and it’s finally here - the new Windows LAPS. With the previous announcement(s) of the integration into the native Windows operating system and support for Azure AD join this was a long-awaited feature. With the recent patch Tuesday the binaries were backed and delivered natively into the current Windows client and Server OS and today they also launched the Azure AD backend that can serve as the backup source for passwords. Within this post, I want to give you a quick impression of what the deployment experience currently looks like and where I needed some adjustments to get the expected result.

Setup

Prerequisites

To deploy LAPS with Azure AD password backup and Intune you need licenses/access to those tools and Windows 10/11 devices with the latest April patches installed. A full list of prerequisites is provided by Microsoft here.

Azure AD enablement

Unlike the on-premises AD LAPS enablement we do not need any schema extensions and can simply enable the following toggle within our Azure AD device settings:

LAPS configuration considerations

The configuration of the LAPS settings can be done with Intune. The settings are available under Endpoint Security > Account protection. When you configure LAPS on Azure AD joined devices we do not have access to all of the settings or better said not all settings are supported as some of them were designed especially for on-premises Active Directory.

An important aspect to understand, similar to the ‘old’ on-premises laps that came with a separate agent, is the fact, that LAPS will not modify or create any accounts nor does it enable any disabled accounts such as the built-in administrator account that is disabled by default.

Microsoft also shares some opinions when it comes to the built-in administrator account:

“The built-in administrator account can’t be locked out, regardless of how many times an attacker might use a bad password. This capability makes the administrator account a popular target for brute-force attacks that attempt to guess passwords….” Microsoft - Administrator account status.

And no - renaming the built-in administrator account does not improve or change the above-stated situation (and I do not believe in this measure as the account can still be easily enumerated due to its well-known SID).

This means when deploying LAPS on Azure AD Joined devices with Intune we can either:

• Enable and use the default built-in Administrator account
  • That might be suitable for a quick test drive in your lab, but for a production deployment I would go for a dedicated account due to the reasons described above
• Creating and using a dedicated local Administrator account for LAPS and leaving the built-in Administrator account untouched

But just for completeness, I will provide you with an example for both scenarios.

A few settings to highlight are:

• BackupDirectory which allows the Password Backup to Azure AD
• PostAuthenticationActions where we can define an action such as forced logoff or reboot after a specific time when the LAPS-managed account signs in to Windows
  • PostAuthenticationResetDelay controls the above scheduling for the action

For the rest and more details of the settings, I will not go into detail, as Microsoft has documented them pretty well.

Intune Profile

To configure the settings create a new Account Protection Profile under endpoint security and select Local admin password solution (Windows LAPS) as the profile type:

Configure the settings according to your needs, I just went with most of the defaults. If you do not want to use a custom admin account you can simply omit the Administrator account name setting by leaving it not configured.

Afterward, I assigned the policy to a dedicated testing group that contains my test device:

Enabling Accounts

To deal with account enablement/creation we have multiple options. As I never made good experiences with the Account CSP (and Michael Niehaus as well) I just created two simple PowerShell proactive remediations, one to enable the built-in Administrator account and one to create a new one.

Enablement of the built-in Administrator account

To avoid any localization issues when it comes to the Administrator account we can use the well-known SID to match the account in both the detection and remediation parts.

The remediation script is just a lazy one-liner performing the enablement (that could of course be improved with logging):

Creation of a dedicated local LAPS Administrator Account

The detection and creation of the dedicated account proactive remediation works similarly, just make sure to align the $username with your LAPS config in Intune.

The creation process consists of creating the account with a random password (that will be overwritten by LAPS as soon as the config is applied) and the group membership of the Administrators group.

Simply create the proactive remediation and make sure to run the scripts in x64 PowerShell environment by enabling the toggle:

Assign to the same test group where you applied your LAPS settings:

LAPS Password Retrieval

Permissions

The LAPS password is stored in Azure Active Directory and can be accessed by the following Azure AD directory roles:

• Helpdesk Administrator
• Cloud Device Administrator
• Security Reader
• Global Reader
• Intune Administrator
• Security Administrator
• Global Administrator

For scoped access, granularity can be achieved with Azure AD organizational units.

Additionally, the following OAuth Scopes grant read access to metadata such as expiration: DeviceLocalCredential.ReadBasic.All or LAPS password access DeviceLocalCredential.Read.All.

AAD / Intune retrieval

The password retrieval is similar to the existing BitLocker key management with Intune. A dedicated tab on the respective device shows the LAPS password metadata:

A click on Show local administrator Password displays then the password details and a button to show or copy the password to the clipboard.

Automated retrieval

Retrieval via automation such as PowerShell can be done with the Microsoft Graph API and the following REST endpoint: https://graph.microsoft.com/beta/deviceLocalCredentials/{Azure AD Device ID}.

To access the password the ?$select=credentials query string parameter is required to access the base64 encoded password hiding within a nested hash table:

Auditing

The password retrieval actions are audited within the Azure AD audit logs and can be queried with KQL if you have sentinel or log analytics in place:

LAPS Windows Event Logs

The LAPS Windows Eventlog Microsoft-Windows-LAPS provides very detailed information about the policy processing and the current setting status of LAPS.

When LAPS did not yet process any new LAPS settings we get the following output:

Once the Intune settings get applied, LAPS detects this:

The update of the password is also logged:

LAPS also warns when the managed account is not yet enabled or present on the device (this happened before my remediation script got invoked):

When you use the LAPS managed account, you also find information about the scheduled post authentication action(s):

 Final words & ressources

Pretty nice that we have now finally access to LAPS on Azure AD Joined devices. The setup- and configuration process went pretty smoothly. Although a production deployment including the appropriate processes such as access to the passwords will probably be a little bit more difficult.

More information:

• https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-event-log

• https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview

• https://techcommunity.microsoft.com/t5/windows-it-pro-blog/by-popular-demand-windows-laps-available-now/ba-p/3788747

Apendix OMA-URI’s

Before the endpoint security settings became available I created a custom OMA-URI profile with the following settings: