One of the best ways to defend your network is to assume that you won’t actually be able to fully defend your network, and at some point, it will be breached by attackers: That “assume breach” approach forces you to protect the assets on your network — especially the high value targets like domain servers.
In an ideal world, you’d always use domain accounts to log in to servers when you need to run administrative tasks that require privilege escalation, because then you can manage them with password rules. But that doesn’t work for troubleshooting machines that have lost their connection to the network or domain, and in practice, even domain-joined computers often have a local admin account. To make it simpler for busy IT teams, the password for those accounts is often the same for all those machines, but it’s often a weaker password that’s easy to remember and never gets changed.
SEE: Password breach: Why pop culture and passwords don’t mix (free PDF) (TechRepublic)
That’s because changing the passwords has to be done manually and individually, plus you have to find a way to keep everyone up to date on the unique latest strong password for each server without saving those passwords somewhere an attacker can also find them, like a PASSWORDS.XLS spreadsheet.
The Local Administrator Password Solution is a tool Microsoft has offered since 2015 that deals with exactly that problem. It generates unique, strong passwords for the local admin account on every computer in your domain using your policy for password complexity, stores them in your Active Directory and automatically replaces them with new passwords, again using your password age policy. The default is 14 character passwords that change every 30 days, but you can choose longer passwords with specific rules like numbers, capital letters and special characters, a different schedule for changes and you can force a change for an individual system without needing to log in.
As long as they’re part of the right security group in AD, IT staff can use a PowerShell command or the LAPS GUI tool to retrieve the password they need to run admin tasks, but because the passwords are protected by per-attribute Access Lists, ordinary users can’t see those details. Even if an attacker does manage to get onto a server that’s protected by LAPS, they can’t get its admin password from AD even if they run the LAPS tool or something like Remote Server Administration Tools, let alone read passwords for other systems.
LAPS is built in and ready
Useful as LAPS is, it always had to be installed on each computer, along with the client-side extension for Group Policy and the PowerShell module, plus you needed to add the ADMX template that extends your AD schema with new attributes to store the password and password expiry timestamp for each computer. That could result in inexperienced admins thinking they had deployed LAPS to all machines when in truth they would only be protecting the admin account.
Now Microsoft is finally integrating LAPS into both Windows 11 and the next version of Windows Server: The preview is part of Windows 11 Insider Preview Build 25145 and Windows Server Preview Build 25151.
You won’t see the LAPS app on managed PCs any more though: You now work with it through PowerShell (and the Group Policy Editor). That’s probably a good thing, as the font in the rather elderly app could make it hard to distinguish an uppercase I from a lowercase l, and many admins routinely copied out the password and pasted it into Notepad. If you’re already used to using LAPS with PowerShell, some of the commands have new names.
You still need to update your AD schema, but you can do that by running the Update-LapsADSchema cmdlet in the new LAPS PowerShell module that used to be Update-AdmPwdADSchema. You also have to configure permissions for those attributes to give authorized users and groups access to view stored passwords, run the Set-LapsADComputerSelfPermission cmdlet on the computers you’re going to manage and create the group policy with the settings you want for password management.
You’ll find all the settings in the Group Policy Editor under Computer Configuration > Administrative Templates > System > LAPS. Start by adding a new LAPS Group Policy object, enabling the Configure password backup directory setting and making the backup store Active Directory.
If you don’t want to wait for the usual GPO refresh interval you can run the gpupdate /target:computer /force command or use the Invoke-LapsPolicyProcessing PowerShell cmdlet to generate and back up a new password, which you can retrieve with the Get-LapsADPassword cmdlet.
You’ll see in the event log when the password has been stored. This new event logging is an improvement on the previous, rather noisy logging and audit approach which often needed workarounds like sending the events to a store.
New LAPS functionality
There are some handy new options in LAPS, like being able to reset the admin password, reboot the computer or log off the admin account after an admin has logged in and made changes — but not immediately. You don’t want to leave a computer running with elevated credentials in case it gets infected, so the post-authentication actions policy automates the cleanup. You also don’t want the machine you’re working on log you off or restart when you’re in the middle of troubleshooting, so you can set a grace period that cleans up after a few hours.
You don’t need to worry about remote workers who use the local admin account regularly losing access if they’re not connected when LAPS is set to cycle their password: The password will only be changed if the PC can reach the domain controller.
You can also now set the name of the local admin account you want LAPS to manage.
Originally, Microsoft decided not to encrypt the admin passwords LAPS stores in AD because of the complexity for admins in managing the encryption scheme and because of the assumption that AD is usually secured well enough to protect the passwords. If you’re looking for defence in depth, you can now choose to encrypt those passwords and choose which users and groups can decrypt them.
For this to work, you need to have a domain controller with Windows Server 2016 functionality to get the necessary privileged access management, although it can be running a later version of Windows Server). If you turn on the Enable Password Encryption group policy with an older domain controller setup that can’t handle the encryption, it won’t save them at all.
With the extra protection of encryption, you can now use LAPS to handle other kinds of account passwords as well as local admin — in particular, the Directory Services Restore Mode administrator password that lets you boot a domain controller into a special mode where you can repair or restore Active Directory. You set the DSRM password when you first promote a server to domain controller, and it’s both very powerful and rarely used, making it a credential you probably won’t think about it until you have an emergency.
Since Windows Server 2008, you’ve been able to synchronise the DSRM admin password to a domain user account, but you have to do that manually with the NTDSUTIL command. LAPS can both store the password and rotate it regularly when you set the Enable Password Backup For DSRM Accounts group policy, but you need to have encryption enabled.
Another useful new option that requires encryption lets you choose how many previous passwords will be stored in AD for each computer. If you needed to roll back a machine using a backup taken before LAPS rotated the password, you were unable to retrieve the old admin password from AD if it’d been updated since then unless you also had an AD backup from the same period. In that case, you needed a tool like the Microsoft Diagnostics and Recovery Toolset to recover the computer. Now you can use Configure Size Of Encrypted Password History to match the number of older passwords you keep to your backup policy: If you keep six months or a year’s worth of backups for computers, you can make sure you store that many passwords as well.
But the biggest change to LAPS is that you’ll no longer be restricted to using on-premises AD to store passwords. If you’re using Azure AD, you’ll be able to set that as the backup store for passwords, though that’s currently only available to a small number of organizations in the Windows Insiders program.
