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.

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:

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 a 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
$Localadmingroupname = $((Get-LocalGroup -SID "S-1-5-32-544").Name)

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

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.

My colleague MVP Sandy Zeng has a better script from her GitHub repository. This script will support multilanguage environments in a better way. The script will find the builtin local Administrator account regardless of the local naming of it. The account will be renamed to Administrator to have it uniform on all devices before setting a random password and disabling the account. The script will then create a local LAPS admin account with a random password before adding the user to the local Administrators group regardless of the local name of the group. Sandy has this remediation package available at her GitHub repository: MSIntune/Intune-PowerShell/WindowsLAPS at master · sandytsang/MSIntune (github.com)

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 already have a dedicated local Admin. 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 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.

Scheduled Task Instead of Remediation?

On some rare occasions, cloud LAPS might have a different implementation on the endpoints. Customers not eligible to use remediation scripts might have implemented the Cloud Laps solution using a scheduled task installed on the endpoints using a platform script.

This script would create a protected folder on the endpoint holding a script called from a scheduled task to reset and upload the password.

When migrating from Cloud LAPS, this script should be unassigned from the devices to prevent it from spreading to new endpoints.

A new script will clean these devices’ old Cloud LAPS accounts and task scheduler routines. This script will delete the scheduled task, remove the folder holding the script that did the password rotation, and finally, delete the local Administrator account used in the Cloud LAPS routine.

The script is available from my GitHub repository: CloudLAPS_SchTask_Uninstall_1_0_0.ps1

    <#
.SYNOPSIS
    Script to uninstall CloudLAPS solution for environments not licensed for Proactive Remediations where the solution has been added as a Scheduled task.

.DESCRIPTION
    This script will check if the scheduled task exists and then delete it. The script will also remove the folder holding the script for the scheduled
    task and delete the old local cloudlaps administrator account.
    
.NOTES
    FileName:    Uninstall-CloudLAPS_SchTask.ps1
    Author:      Simon Skotheimsvik
    Contact:     @SSkotheimsvik
    Created:     2024.01.09
    Updated:     2024.01.09

    Version history:
    1.0.0 - (2024.01.09) Script created
 
    #>

#region Variables
$scheduledTaskName = "CloudLAPS Rotation"
$folderPath = "C:\ProgramData\CloudLAPS Client"
$userAccount = "LocalAdmin"
#endregion Variables

#region Scheduled Task
$scheduledTask = Get-ScheduledTask -TaskName $scheduledTaskName -ErrorAction SilentlyContinue

if ($scheduledTask -ne $null) {
    # Delete the scheduled task
    Unregister-ScheduledTask -TaskName $scheduledTaskName -Confirm:$false
    Write-Host "Scheduled task '$scheduledTaskName' deleted."
} else {
    Write-Host "Scheduled task '$scheduledTaskName' not found."
}
#endregion Scheduled Task


#region Script and folder
if (Test-Path $folderPath -PathType Container) {
    Remove-Item -Path $folderPath -Recurse -Force
    Write-Host "Folder '$folderPath' deleted."
} else {
    Write-Host "Folder '$folderPath' not found."
}
#endregion Script and folder


#region Local Administrator account
$userExists = Get-LocalUser -Name $userAccount -ErrorAction SilentlyContinue

if ($userExists -ne $null) {
    Remove-LocalUser -Name $userAccount -Confirm:$false
    Write-Host "User account '$userAccount' deleted."
} else {
    Write-Host "User account '$userAccount' not found."
}
#endregion Local Administrator account

This script must be adapted to your environment and tested before being implemented in your production!

Here, I assign the script to a group of pilot devices before assigning it to all devices. The script should not run using the logged-on credentials.

Remove EventLog

The Cloud LAPS client has been logging its events to Event Viewer, and some in the Community have asked if this can be removed from the devices as well. These logs are located at the following place in Event Viewer:

We can also list this log with the command Get-EventLog – List giving the following result:

Based on this, I have created a PowerShell script available on my GitHub: Community-By-SSkotheimsvik/Microsoft/Intune/CloudLAPS_EventLog_Removal_1_0_0.ps1 at main · SimonSkotheimsvik/Community-By-SSkotheimsvik (github.com)

    <#
.SYNOPSIS
    Script to remove CloudLAPS EventLog.

.DESCRIPTION
    This script will check if the Event Log named "CloudLAPS-Client" exists and then delete it.
    
.NOTES
    FileName:    CloudLAPS_EventLog_Remocal.ps1
    Author:      Simon Skotheimsvik
    Contact:     @SSkotheimsvik
    Info:        https://skotheimsvik.no/migrating-cloud-laps-to-the-new-windows-laps
    Created:     2024.01.11
    Updated:     2024.01.11

    Version history:
    1.0.0 - (2024.01.11) Script created
 
    #>

#region Variables
$eventLogName = "CloudLAPS-Client"
#endregion Variables

#region EventLog
if (Get-EventLog -LogName $eventLogName -ErrorAction SilentlyContinue) {
    # If it exists, delete the EventLog
    Remove-EventLog -LogName $eventLogName
    Write-Host "EventLog '$eventLogName' has been deleted."
} else {
    Write-Host "EventLog '$eventLogName' does not exist."
}
#endregion EventLog

This script can be assigned as script or remediation to the Endpoints from Intune.

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 has 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", "DeviceLocalCredential.ReadBasic.All"
Get-LapsAADPassword -DeviceIds PCName123
Get-LapsAADPassword -DeviceIds PCName123 -IncludePasswords

A complete shift for all devices from Cloud LAPS Community edition to Windows LAPS can take some time, depending 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.1
    Author:         Simon Skotheimsvik
    Info:           https://skotheimsvik.no/migrating-cloud-laps-to-the-new-windows-laps       
    Creation Date:  09.06.2023
    Version history:
    1.0 - (09.06.2023) Script released
    1.1 - (24.10.2023) Least privilege (Thanks  to Sandy Zeng)

#>

#region connect
Connect-MgGraph -Scopes "Device.Read.All", "DeviceLocalCredential.ReadBasic.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

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.

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

Remove Cloud LAPS Administrators

If you created a new local administrator account when moving from Cloud LAPS to Windows LAPS, you should clean out the local Administrator account used by Cloud LAPS.

Use the script described earlier in the chapter “Scheduled Task Instead of Remediation?” to remove the local Administrator account from each device.

Use an account protection policy to take control of the local Administrators group and remove the old Cloud LAPS account. This is done using an “Add (Replace)” rule, which could look like the following.

This way, the old cloud LAPS admin account is removed from the device.

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.