Skip to content

Migrating Cloud LAPS to the New Windows LAPS

Join me as I delve into the alternative approaches to migrate the renowned Cloud LAPS Community edition to the latest Windows LAPS by Microsoft.

Table of Contents

The Background

Microsoft LAPS, which stands for Local Administrator Password Solution, was a password management tool developed by Microsoft. It was introduced to address security concerns related to local administrator accounts on Windows operating systems. The tool provided a solution for automatically generating and managing unique passwords for these accounts across Active Directory joined computers. By regularly randomizing passwords and securely storing them, LAPS helped prevent unauthorized access and enhance overall system security.

Admin Rights are not Human Rights
Sami Laiho

As organizations transitioned to modern endpoint management with Azure AD and Microsoft Intune, they faced a loss of functionality with the Microsoft LAPS service. This gap opened up opportunities for community-driven solutions, and one standout solution emerged: The Cloud LAPS Community Edition from MSendpointMGR by MVP Nickolaj Andersen, MVP Thomas Kurth, MVP Maurice Daly, and Simon Wåhlin. Their CloudLAPS solution offers a comprehensive approach, enabling access and retrieval of local administrator passwords through a user-friendly web portal. Native Azure AD enterprise application management supports delegated access to the portal, while password retrievals are automatically logged in a Log Analytics workspace for thorough auditing.

Microsoft has recently released its Windows LAPS, offering support for modern endpoint management with Azure AD and Microsoft Intune for modern Windows operating systems holding the April 2023 update. While not as feature-rich as the MSEndpointMGR solution, the availability of a native Microsoft option suggests that further development of the community versions may cease. This presents an opportune moment to migrate to the built-in Windows LAPS solution provided by Microsoft.

Different Approaches Migration Cloud LAPS to Windows LAPS

Dedicated Admin Account, or not?

The Cloud LAPS Community edition did create a separate local admin account on each device, leaving the built-in local administrator account disabled. This is in line with best practices. Microsoft’s new Windows LAPS routine does not fancy this and will rely on the built-in Administrator account. Is this good enough, or will creating a dedicated local Administrator be feasible?

Rename Existing Administrator

Most attacks against the directory begin as attacks against individual hosts, and the local Administrator account is a well-known target.

An example from a computer found recently with RDP (Ransomware Deployment Protocol) open to the internet.
Several logons are attempted each second toward the Administrator account.

There really is someone out there trying to guess your passwords!
– Law #6, Ten Immutable Laws of Security Administration

There are options to rename the local built-in Administrator account. This will make it a bit more challenging to guess the account to attack. Enabling and renaming the Local Administrator account can be done by use of the following settings from the Settings Catalog:

Cloud LAPS to the New Windows LAPS

Some discussions are going on in the community related to this.

  • Should we use the local Administrator account?
  • Is it worth the effort to rename the local Administrator account since it will have the same well-known SID after the rename?
  • The local Administrator account will not have a lockout threshold for brute force attacks.
    (Changes are arriving with KB5020282 making account lockout available for built-in local administrators. There are some caveats related to the Windows version the machine was installed with, configured policies, if the account is accessed through the network or console, etc.)

Create a Dedicated Administrator

Creating a dedicated local Administrator will make it harder for externals to find the account to attack since it will have an unknown name, and the SID will be unknown. This account will also have a lockout threshold, which the built-in Admin account lacks.

Using a dedicated local administrator will be a better approach if the account is created with some smartness regarding the password.

A computer is only as secure as the administrator is trustworthy
– Law #6, Immutable Laws of Security v2

We can create a new local Admin account using a custom policy with OMA-URI settings. As MVP Joost Gelijsteen discusses in his blog post, LAPS around Intune (joostgelijsteen.com), this can be a bad idea since the accounts created with OMA-URI will have an identical identity and password across all devices before Windows LAPS takes effect.

An alternative approach for creating a new local Admin account is using device remediations in Microsoft Intune. The remediation script can have a routine for setting a randomized password upon creating the account. This will make the account unique per device.

MVP Jannik Reinhardt has a GitHub repository holding a remediation package for creating a new local Administrator account. I have created a variation of that remediation script to have the password randomized.

<#
Version: 1.0
Author: 
- Joey Verlinden (joeyverlinden.com)
- Andrew Taylor (andrewstaylor.com)
- Florian Slazmann (scloud.work)
- Jannik Reinhard (jannikreinhard.com)
- Simon Skotheimsvik (skotheimsvik.no)
Script: Create-LocalAdmin
Description: Add a local admin with randomized password, ensuring that we do not have an account with a static password across all devices before Windows LAPS takes effect.
Hint: This is a community script. There is no guarantee for this. Please check thoroughly before running.
Version 1.1: Init
Run as: Admin
Context: 64 Bit
#> 

$localAdminName = "LAPS Admin"
$password = -join ((65..90) + (97..122) + (48..57) + (35..38) + (40..47) | Get-Random -Count 35 | ForEach-Object {[char]$_}) | ConvertTo-SecureString -AsPlainText -Force

New-LocalUser "$localAdminName" -Password $password -FullName "$localAdminName" -Description "LAPS account"
Add-LocalGroupMember -Group "Administrators" -Member "$localAdminName"
PowerShell

This way, I will have a unique account per device regarding SID and Password. This will avoid lateral movements between devices where the Windows LAPS service has not changed the initial password.

Reuse Cloud LAPS Admin, or not?

I find it best to use a dedicated local administrator account for Windows LAPS, avoiding the built-in Administrator account on Windows devices.

If you have used the Cloud LAPS Community tool, your devices will have a dedicated local Admin already. Migrating to Windows LAPS, you should decide if this account should be reused or if you will create a new local Admin account.

Reuse Cloud LAPS Admin

If you decide to reuse the local Administrator from Cloud LAPS Community, you should follow this path to implementation:

  1. Remove/disable the device remediation routine from the Cloud LAPS Community tool to ensure it no longer updates the passwords.
  2. Add the new device remediation routine to create the local admin account on devices missing the account.
  3. Implement Windows LAPS targeting the defined local admin account.
  4. Ensure Windows LAPS rotates the passwords and you have access.
  5. Remove the Cloud LAPS Community solution.

Create New Windows LAPS Admin

If you decide to create a new local Administrator for Windows LAPS, you should follow this path to implementation:

  1. Add a device remediation routine to create the new local admin account on devices missing the account.
  2. Implement Windows LAPS using the new local admin account.
  3. Ensure Windows LAPS rotates the passwords and you have access.
  4. Remove the device remediation routine from the Cloud LAPS Community tool.
  5. Add a device remediation routine to delete the Cloud LAPS admin account.
  6. Remove the Cloud LAPS Community solution.

The Migration from Cloud LAPS to the New Windows LAPS

I need to migrate an environment from Cloud LAPS to Windows LAPS, and I want to use the same administrator account that was used in the Cloud LAPS Community tool. Below, I’ll explain the detailed process for this.

Remove Cloud LAPS Remediation

Navigate to the Intune Admin Center – Devices – Remediations, and locate your Cloud LAPS remediation script.

Take note of the local administrator name used in the proactive remediation. As discussed above, this account will be reused in the new Windows LAPS solution.

Delete the remediation script (or change targeting to disarm it).

This will stop the password rotation at the endpoints. The existing valid passwords will remain available through the Cloud LAPS web portal.

Add Windows LAPS Account Remediation

I want to continue using the same admin account with the new Windows Laps routine. This means I need a way to create an account on new devices onboarded to the tenant. I am using a new proactive remediation for this.

A name and description are provided for the remediation routine.

I will use my modified version of the remediation package (Create-LocalAdminLAPSDetection.ps1 and Create-LocalAdminLAPSRemediation.ps1 ) from the mentioned GitHub repository. My local admin name is added to the detection and remediation script.

The remediation package is now assigned to run daily, ensuring new devices have the account created with randomized passwords.

Enable Windows LAPS in the Tenant

Navigate to the Entra Portal – Azure Active Directory – Devices – All devices – Device settings and enable Azure AD Local Administrator Password Solution.

The service is now enabled in the tenant.

Configure Windows LAPS Policy

Navigate to Intune Admin Center – Endpoint Security – Account Protection and create a new policy.

Set a name and a description for the policy.

Set the policy settings according to your prerequisites. The policy below backs up the password to Azure AD only. The password age is set to a minimum of 7 days for Azure AD. The custom administrator account is defined. The password complexity includes large letters + small letters + numbers + special characters. Password length has been set to 32 characters, and post-authentication actions are set to reset the password and log off the managed account after 7 hours.

The script should now be assigned and created.

Verify Windows LAPS functionality

The Cloud LAPS Community edition will hold the LAPS passwords until the new Windows LAPS has applied a new password on the devices. Before removing the Cloud LAPS Community edition, we should verify the new Windows LAPS functionality.

Verify the Local Admin Account

Once created, we can see the local Administrator accounts directly on the devices.

We can have an overview of the local administrator accounts created by the remediation routine by looking at the statistics on the job.

Damien Van Robaeys have created a nice blog post showing how to use Intune reporting with Power BI to list local admin accounts on your devices and who added them. This could be an interesting approach to use related to Windows LAPS.

The LAPS configuration policy will also give insights into which devices have been managed by LAPS and have their passwords reset.

This report will give device insights related to each setting in the policy.

Verify the Password Rotation

We can verify if the password has been set and captured by checking up on a device. This can be done in the Intune Admin Center, Entra Portal, or Powershell Graph API.

This information is available for Cloud Device Administrators, Intune Administrators, and Global Administrators.

The following shows a device where the Windows LAPS password has not been set yet.

The following screenshots show a device where Windows LAPS has managed to rotate the password.

Here is the PowerShell command for checking the device LAPS password through Graph API:

Connect-MgGraph -Scopes "Device.Read.All", "DeviceManagementManagedDevices.Read.All", "DeviceLocalCredential.Read.All"
Get-LapsAADPassword -DeviceIds PCName123
Get-LapsAADPassword -DeviceIds PCName123 -IncludePasswords
PowerShell

A complete shift for all devices from Cloud LAPS Community edition to Windows LAPS can take some time, dependent on the settings implemented in the LAPS environments. A Powershell command measuring the number of devices in Windows LAPS would be excellent, but I haven’t found this available yet.

The following script could help count devices where Windows LAPS has been applied:

<#
.SYNOPSIS
  Script to find devices with LAPS passwords.
.DESCRIPTION
    This script will find all devices with a LAPS password set. Use this to find the prevalence of LAPS in your environment.
    
.NOTES
    Version:        1.0
    Author:         Simon Skotheimsvik
    Info:           https://skotheimsvik.no        
    Creation Date:  09.06.2023
    Version history:
    1.0 - (09.06.2023) Script released

#>

#region connect
Connect-MgGraph -Scopes "Device.Read.All", "DeviceManagementManagedDevices.Read.All", "DeviceLocalCredential.Read.All"
#region connect

#region variables
$devices = get-mgdevice -Filter "OperatingSystem eq 'Windows'" -All
$NumberOfDevices = $devices.count
$NumberOfDevicesWithLaps = 0
$Counter = 1
#endregion variables

#region find devices with LAPS passwords
foreach ($device in $devices) {
    if (Get-LapsAADPassword -DeviceIds $device.DisplayName -erroraction 'silentlycontinue') {$NumberOfDevicesWithLaps++}
    Write-Progress -Activity "Searching device $Counter : $NumberOfDevices for LAPS" -PercentComplete (($Counter / $NumberOfDevices) * 100)
    $Counter++
}
#endregion 

#region write result
Write-Host "$NumberOfDevicesWithLaps of $NumberOfDevices Windows devices have Windows LAPS password."
#end region
PowerShell

Running the script can take time, depending on the number of devices. The progress bar will indicate the progress before giving you information on the number of devices with a Windows LAPS password registered in Azure AD.

The script is available on my GitHub.

You can get an overview of all the devices which have been enrolled to Windows LAPS from the Microsoft Entra Portal by navigating to Azure Active Directory – Devices – Local administrator password recovery.

GET https://graph.microsoft.com/beta/deviceLocalCredentials?$count=true

This kind of overview is not available from the Intune admin center.

Remove the Cloud LAPS Community solution

Once you are confident that Windows LAPS is working, you can continue to remove the rest of the Cloud LAPS components.

Remove Resource Group

The Cloud LAPS remediation script has already been removed. Removing the resource group holding the Azure resources involved in Cloud LAPS will effectively remove all associated resources.

Be aware!
Removing the rest of the Cloud LAPS solution, will remove the key vault holding the LAPS passwords applied using the community solution!

Navigate to the resource group in the Microsoft Azure portal, click on Delete Resource Group, verify the name, and click the Delete button before confirming that you will do the deletion. There are many confirmations to ensure this doesn’t happen by accident!

This process might take some minutes to complete.

Remove App Registration

The Azure App registration for the Cloud LAPS portal can now be deleted from AAD.

This will finish within seconds. The Azure Enterprise application for the Cloud LAPS portal should also have been removed now, and by this, the Cloud LAPS Community Edition should be history in this tenant.

Troubleshooting Windows LAPS

The migration has been completed. This chapter will cover some tools to troubleshoot and verify Windows LAPS is working as expected in your environment.

Event Viewer

To view Windows LAPS events on the endpoint, Start Event Viewer and navigate to Applications and Services Logs – Microsoft – Windows – LAPS – Operational.

Here is an example of logging for a manual password rotation.

  • Event ID 10000: LAPS loads and initializes.
  • Event ID 10003: LAPS processing starts
  • Event ID 10022: Gives insight into the current policy applied
  • Event ID 10010: Informs where the password will be backed up
  • Event ID 10050: Informs of Azure-initiated password rotation
  • Event ID 10030: Informs of message exchange during password rotation
  • Event ID 10029: Informs of successful password update in AAD
  • Event ID 10020: Informs of successful password rotation
  • Event ID 10004: LAPS processing ends

Microsoft has good information related to the events on the following page: Windows LAPS troubleshooting guidance – Windows Server | Microsoft Learn

Manually Rotate Local Admin Password

The minimum age for a password is seven days. You can manually rotate the password. This can be a necessary operation related to troubleshooting. The following screenshot shows this operation on a device in Intune admin center.

Once the endpoint reboots, the password should be changed. If you want a super deep timelapse view of what’s going on behind the scenes when rotating the password, I recommend you to look into Rudy Ooms‘s blog post, where he dives into the wonders of Windows LAPS and what happens when you remotely perform a password rotation from Intune.

Audit Logs

By looking at the Audit Logs found in the Microsoft Entra Portal under Azure Active Directory – Monitoring & Health – Audit Logs, I found some information on the LAPS actions performed in the environment.

Filtering on the Device Registration Service gives an insight into the LAPS actions running.

Wrapping Up

The Windows LAPS service is still in preview and does a pretty good job. If the environment has Azure AD P1 licenses, we can use Azure functionality like administrative units to scope access to cloud device admins from that business unit to read the local admin passwords, as demonstrated by John Savill.

I think Windows LAPS still lacks some functionality related to the excellent community edition from MSEndpointMGR. Some of the things I am missing are:

  • The possibility of having shorter password age than seven days.
  • Rotating revealed passwords not used within a set time.
  • Having good reports of Windows LAPS. The workbook from the community edition is sorely missed.

I believe some of these missing functionalities will be available from Microsoft in future version releases, and maybe the community will fill some of the holes. Either way, LAPS is a crucial service for controlling local admin access on the endpoints, as mentioned in my previous post, Five Approaches For Local Admin Access On The Azure AD Joined PC. It is free to use. Do not allow perfection to hinder progress – each step taken on the security ladder will make it harder for attackers to access resources.

Don’t be the hacker’s dream customer!

If running the community edition, you should consider migrating to the new Windows LAPS solution from Microsoft. If you are not using LAPS at all, you should look into Microsofts solution today, available for both AD and AAD.

Published inAzureIntuneWindows

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: