Microsoft LAPS (Local Administrator Password Solution) is solution for managing the automatic rotation and storage of local administrator account passwords for Windows endpoints joined to a Windows Server Active Directory domain. It’s main limitation up to this point has been that the solution only supports Windows Server AD joined Windows endpoints. For organizations that are or have migrated to Azure Active Directory joined clients, legacy LAPS is not available as an option. Why does this matter? Shouldn’t we take the route of disabling all local administrator accounts on Azure AD joined devices and rely on Azure AD accounts that have delegated rights to perform local admin tasks?
Many organizations like to have a local administrator account on their Windows endpoints as a “break glass” or emergency account that can be leveraged by IT in the event of an issues where logging into the device with an Azure AD account that has local admin privileges is not an option. Consider an issue with the devices network connectivity, perhaps. In this scenario, we cannot log into the device with an Azure AD account that has been delegated local admin rights so without a local admin account we are unable to triage and troubleshoot.
Microsoft recently released Windows LAPS, which is not simply an update to the legacy Microsoft LAPS solution, but a total rebuild of LAPS that’s now baked into the Windows 10/11 operating system. The new Windows LAPS solution supports storing and rotating passwords on Azure Active Directory joined devices as well as several other new configuration options like triggering an automatic password rotation when the managed account is used to authenticate to the managed device. While legacy LAPS is still available, Microsoft strongly recommends Customers migrate to Windows LAPS due to the new security features and improved product servicing.
If you are brand new to Windows LAPS, I’d highly encourage you to read through the Microsoft doc’s articles here: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview as I won’t be covering all the in’s and out’s in this article. I created this guide for the hybrid enterprises who may already have a Microsoft LAPS (legacy) deployment and need to migrate to Windows LAPS. I’ll also address how to leverage Azure AD for stored passwords (currently in public preview), where feasible with hybrid-joined and Azure AD joined endpoints.
My Lab Environment
- I have four Windows 10/11 devices both AD joined and hybrid-joined to Azure AD:
| Name | Directory Join | Management Platform | Operating System |
| WKSADSV01 | Hybrid Joined | Configuration Manager Only | Windows 11 |
| WKSADSV02 | Hybrid Joined | Co-Managed | Windows 11 |
| WKSADSV03 | Hybrid Joined | Co-Managed | Windows 10 |
| WKSADSV04 | Hybrid Joined | Intune Only | Windows 11 |
- I also have four Windows 10/11 devices joined to Azure AD only:
| Name | Directory Join | Management Platform | Operating System |
| WKSAADV01 | Azure Active Directory | Co-Managed | Windows 11 |
| WKSAADV02 | Azure Active Directory | Intune Only | Windows 10 |
| WKSAADV03 | Azure Active Directory | Intune Only | Windows 11 |
| WKSAADV04 | Azure Active Directory | Intune Only | Windows 11 Insider Preview |
As you can see from the tables, the devices are in various states of device management.
- In addition to the clients, I have half a dozen Windows Servers that mostly Windows Server 2019 and are all Active Directory joined.
- Microsoft LAPS (legacy) is currently deployed and configured via group policy for all Windows Server AD joined/Hybrid joined workstations and servers.
- Windows LAPS is not yet configured for any of the native Azure AD joined devices.
- I have a two existing group policy objects created for Microsoft LAPS (legacy). One policy pushes the LAPS agent while the other configures the LAPS agent with the following settings:
Microsoft LAPS (legacy) Group Policy Settings:
- Enable local admin password management: Enabled
- Password Settings: Enabled
- Password Complexity: Large letters + small letters + numbers + specials
- Password Length: 14
- Password Age (Days): 30
Running the Microsoft LAPS (legacy) UI and providing one of my Windows Server AD joined endpoints shows passwords have been created for the local administrator accounts:
Prerequisites for Migration
To migrate to Windows LAPS, your Windows devices must meet the following prerequisites:
- Windows 10 clients running the April 11, 2023 updates or later
- Windows 11 22H2/22H1 clients running the April 11, 2023 updates or later
- Windows Server 2019/2022 with April 11, 2023 updates or later
I would suggest leveraging your endpoint management solution to run the necessary reports to validate which clients are ready for Windows LAPS migration and which devices will need to perform OS upgrade first.
To Leverage Windows Server AD for Password Escrow:
- I highly recommend using the new password encryption solution for Windows LAPS which will require that your domain functional level is Windows Server 2016 or higher. Azure AD provides additional security and built-in encryption to address this without any requirements.
To Leverage Azure AD for Password Escrow:
- Azure AD Joined or Hybrid-joined Windows 10/11 devices that meet the minimum requirements for Windows LAPS
While it’s not a requirement for migration, it’s preferred to leverage Microsoft Intune to deploy your Windows LAPS policies. Group policy can still be used in the cases where Windows Server AD joined clients are in play without Intune management (Windows Servers). We will be utilizing both management tools in this guide as servers cannot be managed by Intune and I want to continue running LAPS on my servers.
Migration Planning
Microsoft LAPS (legacy) and Windows LAPS are two different, independent solutions for managing local admin passwords. As such, a coordinated effort to switch solutions is necessary as both solutions cannot be operational on the same devices at the same time, or the solutions will work against each other and lead to inconsistent passwords. for local admin accounts.
There are two main methodologies for migrating from Microsoft LAPS (legacy) to Windows LAPS. The first approach is more of an immediate transition that involves switching between solutions and policies as quickly as possible. More of a “cutover” migration, if you will. Option number two involves a more methodical migration but requires a coexistence state where multiple local admin accounts exist on clients (so the two solutions do not compete with each other) which adds attack surface and complexity for IT, in my opinion.
I will be using the more immediate transition in my environment as I do not want multiple local admin accounts on my endpoints, and I want to continue to leverage the built-in local admin account as the only local admin account.
My environment includes endpoints that are not hybrid-joined or native Azure AD joined (mainly servers). I will be migrating to Windows LAPS with Windows Server AD password escrow (for the servers) as well as Windows LAPS with Azure AD password escrow (for the clients). This makes the transition a bit more involved as multiple Windows LAPS configuration tools will be utilized, but I think is a great example of how many enterprise environments may be setup today with both servers and clients as LAPS endpoints.
Here’s a visual depiction of how the various endpoints will fall under Windows LAPS management, based on the directory they are bound to and how they are managed:
Another important note about coexistence is that if a device that meets the minimum requirements for Windows LAPS (operating system build) is joined to a domain or Azure AD environment where a legacy LAPS policy is in place, the client device will automatically go into LAPS emulation mode and begin honoring legacy LAPS policies. So, even before you deploy Windows LAPS, you can eliminate the deployment of the Microsoft LAPS (legacy) agent and allow the built-in Windows LAPS software to run in emulation mode until such time that you are ready to upgrade to Windows LAPS policies. Removing the legacy LAPS client-side extension (agent) is part of the migration process so by stopping legacy LAPS agent deployments now, you are saving yourself additional efforts in the future.
In planning a Windows LAPS migration you will want to define, at a minimum, the following values prior to implementation so you are ready with the appropriate variables during the deployment process. If the default values meet your organizations requirements, you only need to enable the password backup directory
Windows Server Active Directory Password Escrow Planning Questions
- What Windows Server AD groups should be allowed to view client properties for Windows LAPS but not retrieve passwords?
- What Windows Server AD groups should be allowed to view client properties for Windows LAPS AND retrieve passwords?
- What local admin account password complexity requirements will you require?
- Large Letters
- Large Letters + small letters
- Large letters + small letters + numbers
- Large letters + small letters + numbers + special characters (default)
- What local admin account password length will you require? (14 characters is the default)
- How often should local admin account passwords rotate? (30 days is the default)
- Identify all organization units (OU’s) in Windows Server AD that contain computer objects where Windows LAPS will be in use.
- What is the name of the local admin account? (If changed from the default, Administrator)
Answer the following additional, optional Windows LAPS configurations, as necessary:
- Do you wish to enable the password backup for domain controllers directory services restore mode passwords? (This will require a LAPS policy targeting domain controllers)
- Will you use the new AD password encryption functionality of Windows LAPS? (recommended)
- If so, what Windows Server AD groups, beyond domain admins, should have the rights to decrypt and read passwords?
- Do you want to store encrypted password history? (Allows the retrieval of up to 12 previous local admin passwords)
Azure Active Directory Password Escrow Planning Questions
- What Azure AD groups should be allowed to view client properties for Windows LAPS but not retrieve passwords?
- What Azure AD groups should be allowed to view client properties for Windows LAPS AND retrieve passwords?
- What local admin account password complexity requirements will you require?
- Large Letters
- Large Letters + small letters
- Large letters + small letters + numbers
- Large letters + small letters + numbers + special characters (default)
- What local admin account password length will you require? (14 characters is the default)
- How often should local admin account passwords rotate? (30 days is the default)
- What is the name of the local admin account? (If changed from the default, Administrator)
Now that we’ve properly planned for our WIndows LAPS migration, we can start migrating the Windows Server AD backed clients first which is covered in Part 2 of my migration guide.
Did you find this particular article extra helpful? Please consider donating to help me offset the costs of maintaining this site. Your support is greatly appreciated!
Mike Shellenberger's Blog 
Leave a comment