Microsoft’s Local Administrator Password Solution (LAPS) is a legacy Windows tool that IT admins can use to manage account passwords of domain-joined computers. The company has finally updated LAPS this year and plans to bring it natively into Windows in 2023. In this article, I’ll explain how this new native version of LAPS works and how you can use it to manage local admin account passwords in your Active Directory and Azure Active Directory environments.
As of this writing, the new native version of Windows LAPS is available for Windows Insiders running the Dev Channel build 25145 or newer. It’s also available in the Windows Server vNext Insider build 25151 or newer.
Microsoft’s Local Administration Password Solution (LAPS) is shipped several years ago as an MSI installer package, and the add-on solution has been heavily adopted by Microsoft enterprise customers. If the current version of LAPS lets IT pros manage local account passwords of domain-joined computers, it’s starting to show its age. If passwords are stored in Active Directory (AD) and protected by an access control list (ACL), the current version of LAPS has no support for password storage in Azure.
The new version of LAPS that Microsoft is baking into Windows 11 will include support for managing your on-premises Active Directory member servers, your Azure Active Directory-joined servers, and even Directory Services Repair Mode (DSRM) passwords on your domain controllers. Every password will be stored securely and managed centrally in your Active Directory or Azure Active Directory.
You can use Windows LAPS to rotate and manage your local administrator account passwords and be rewarded with these benefits:
Let’s describe some common scenarios where Windows LAPS will help secure your environment and boost efficiency for your systems engineers when you need to administer your server environment, regardless of where the servers reside:
This section will describe the basic steps for using Windows LAPS to back up passwords to your Active Directory and how to access them securely.
First, you will need to update the AD schema prior to using Windows LAPS. You can run the following PowerShell command to do that:
You can also use the -Verbose parameter to see more detailed info on what the cmdlet does.
Next, your managed device needs to be granted permission to update its password. You need to set inheritable permissions on the organizational unit (OU). Use this PowerShell cmdlet to accomplish the task.
Set-LapsADComputerSelfPermission -Identity NewLAPS
Your output will look similar to this:
It is possible to discover users or groups that already have Extended Rights permissions on your OUs. This can be an issue because it grants said users or groups access to confidential attributes, including the LAPS-stored passwords. You can check if this is the case by running the following command:
Find-LapsADExtendedRights -Identity newlaps
There are no problems here as only SYSTEM and Domain Admins have the privilege. No other remediation is required.
First, you’ll choose a policy deployment mechanism. Most customers will use the Windows LAPS Group Policy to deploy the required settings to their AD-joined devices.
If you have hybrid-joined devices to Azure Active Directory, you can deploy your policies by using Microsoft Endpoint Manager with the Windows LAPS configuration service provider (CSP).
To touch on the specific policies, you will, at a minimum, configure the BackupDirectory setting to a value of 2. This backs up the passwords to Windows Server Active Directory.
If you haven’t renamed the default ‘Administrator’ account, Windows LAPS will manage it by default. The built-in account is identified by the well-known relative identifier (RID) and should never be listed by name.
If you want to configure a custom local administrator account (good idea!), you can configure the AdministratorAccountName setting with the name of your choosing.
Every hour (by default), Windows LAPS processes your current policy and responds to Group Policy change notifications. You can verify your administrator password was updated by opening Event Viewer and checking the LAPS->Operational log for Event ID 10018.
By now, I imagine you’d like to know how to see the password so you can log into your server? Piece of cake. Use this PowerShell cmdlet to do the trick:
Get-LapsADPassword -Identity lapsAD2 -AsPlainText
According to the default policy, the local administrator account password will last for 30 days before being changed by the hourly policy running. However, after a security breach or attack, you may want to rotate a password safely and securely right away. Run the following command to do so:
This is very straightforward, and you don’t have to do anything else. It’s updated and stored securely in your Active Directory. You can also use the command below to set the scheduled password expiration time stored in AD:
Set-LapsADPasswordExpirationTime -Identity lapsAD2
The next time Windows LAPS runs, it will notice the new expiration time and rotate the password.
Next, we’ll go through the necessary steps to store your administrator account passwords in Azure Active Directory and how to access them.
First, as with Active Directory, we need to choose a policy deployment mechanism. The preferred option is again to use Microsoft Endpoint Manager with the Windows LAPS configuration service provider (CSP). If your devices are hybrid-joined to on-premises AD, you can deploy device policies by using Windows LAPS Group Policy.
The following subset of settings are applicable when backing up passwords to Azure Active Directory:
Similar to AD, at a minimum, you must configure the BackupDirectory setting to 1 (backup passwords to Azure AD).
The use of a custom AdministratorAccountName is the same as with Windows Server AD. You can also configure other settings, like PasswordComplexity, as needed by your organization’s security and compliance requirements.
The behavior here is similar to Windows Active Directory. In the Event Viewer, you can open the LAPS -> Operational log on your Azure member servers and search for Event ID 10029.
In order to retrieve Windows LAPS passwords stored in Azure AD, you will be using the Get-LapsAADPassword cmdlet, which leverages the Microsoft Graph PowerShell library. Windows LAPS doesn’t offer any user interface options for Azure AD password retrieval.
First, run this command in PowerShell to install the library:
Install-Module Microsoft.Graph -Scope AllUsers
There are additional steps needed including creating an Azure Active Directory registered app that is beyond the scope of this article. You can reference this post for additional information: Creating an AAD registered app.
We’re almost there. First, sign in to Microsoft Graph. Then, use Get-LapsAADPassword cmdlet to retrieve the password:
Get-LapsAADPassword -DeviceIds myAzureDevice
The previous command requires the DeviceLocalCredential.Read.Basic permission. You need the DeviceLocalCredential.Read.All permission to run the following command:
Get-LapsAADPassword -DeviceIds myAzureDevice -IncludePasswords
For testing purposes only, you can request the SecureString to be populated as plain text using this command:
Get-LapsAADPassword -DeviceIds myAzureDevice -IncludePasswords -AsPlainText
Quick, forget you ever saw this! But really, you want to be careful when using these commands.
Windows LAPS remembers when the last stored password expires – it automatically rotates the password when it expires. In some scenarios, you might need to rotate it right away. You can do so with these commands.
Reset-LapsPassword Get-LapsAADPassword -DeviceIds myAzureDevice -IncludePasswords -AsPlainText
Just a side note, it may take a few centuries to crack THAT password. Well done!
LAPS was introduced on May 1, 2015. However, it hasn’t been updated in a few years, so Microsoft determined it needed some TLC. Thanks to a team of engineers and developers, they’re bringing it natively into Windows client releases (Windows 11 and hopefully, Windows 10) starting in the first quarter of 2023. Hopefully, this article gave you a good crash course in how it works and how you’ll be able to implement it into your Active Directory and Azure Active Directory environments.
Please leave a comment below if you have any questions!