One of the best ways to defend your network is to assume that you won’t be able to fully defend your network and that at some point it will be hacked by attackers: this “assume a breach” approach forces you to protect assets. on your network, especially high-value targets such as domain servers.
In an ideal world, you would still use domain accounts to log into servers when you need to perform administrative tasks that require elevation of privileges, because then you can manage them with password rules. But it doesn’t work for troubleshooting machines that have lost their network or domain connection, and in practice even domain-joined machines often have a local administrator account. To make things easier for busy IT teams, the password for these accounts is often the same for all these machines, but it’s often a weaker password that’s easy to remember and never changes.
SEE: Password Breach: Why Pop Culture and Passwords Don’t Mix (Free PDF) (TechRepublic)
This is because changing passwords has to be done manually and individually, and you also have to find a way to keep everyone up to date with the latest unique strong password for each server without saving those passwords somewhere an attacker can also find them, such as a PASSWORDS Spreadsheet .XLS.
The Local Administrator Password Solution is a tool offered by Microsoft since 2015 that addresses exactly this problem. It generates unique and strong passwords for the local administrator account on each computer in your domain using your password complexity policy, stores them in your Active Directory and automatically replaces them with new passwords, always in using your password age policy. The default password is 14 characters that change every 30 days, but you can choose longer passwords with specific rules like numbers, uppercase letters, and special characters, a different schedule for changes, and you can force a change for an individual system without logging in. .
As long as they’re part of the correct security group in AD, IT staff can use a PowerShell command or the LAPS GUI tool to retrieve the password they need to perform administrative tasks, but because passwords are protected by attribute access lists, ordinary users cannot see these details. Even if an attacker manages to access a server protected by LAPS, he cannot get his administrator password from AD even if he runs the LAPS tool or something like Remote Server Administration Tools, let alone the reading passwords for other systems.
LAPS is built-in and ready
As useful as LAPS is, it still had to be installed on each machine, along with the client-side extension for Group Policy and the PowerShell module, and you had to add the ADMX template which extends your AD schema with new attributes to store the password and the password expiration timestamp for each computer. This could lead inexperienced admins to think they have LAPS deployed on all machines when in reality they are only protecting the admin account.
Now, Microsoft is finally integrating LAPS into Windows 11 and the next version of Windows Server: Preview is part of Windows 11 Insider Preview Build 25145 and Windows Server Preview Build 25151.
However, you will no longer see the LAPS application on managed PCs: you now work with it through PowerShell (and the Group Policy Editor). This is probably a good thing, because the application’s rather old-fashioned font can make it hard to distinguish between an uppercase I and a lowercase l, and many administrators regularly copy the password and paste it into Notepad. If you’re already used to using LAPS with PowerShell, some commands have new names.
You still need to update your AD schema, but you can do so by running the Update-LapsADSchema cmdlet in the new LAPS PowerShell module that was previously Update-AdmPwdADSchema. You must also configure permissions for these attributes to allow authorized users and groups to access View Stored Passwords, run the Set-LapsADComputerSelfPermission cmdlet on the computers you will manage, and create the group policy with the desired settings for password management.
You can find all the settings in the Group Policy Editor under Computer Configuration > Administrative Templates > System > LAPS. Start by adding a new LAPS GPO, 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 save a new password, which you can retrieve with command Get – LapsADPassword cmdlet.
You will see in the event log when the password was stored. This new event logging is an improvement over the previous rather noisy logging and auditing approach which often required workarounds like sending events to a store.
New LAPS feature
There are some handy new options in LAPS, like the ability to reset the admin password, restart the computer, or log out of 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 going offline or rebooting 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 have to worry about teleworkers who regularly use the local administrator account losing access if they are not logged in when LAPS is configured to cycle their password: the password will not be changed only if the PC can reach the domain controller.
You can also set the name of the local administrator account that you want LAPS to manage.
Microsoft originally decided not to encrypt LAPS administrative passwords stored in AD due to the complexity for administrators to manage the encryption scheme and due to the assumption that AD is generally sufficiently secure to protect passwords. If you’re looking for defense-in-depth, you can now choose to encrypt those passwords and choose which users and groups can decrypt them.
For this to work, you must have a domain controller with Windows Server 2016 functionality to get the necessary privileged access management, although it can run a later version of Windows Server). If you enable the Enable Password Encryption Group Policy with an older domain controller configuration that cannot handle encryption, it will not log them at all.
With the added protection of encryption, you can now use LAPS to manage other types of account passwords as well as the local administrator – specifically, the Directory Services Restore Mode administrator password that you allows you to start a domain controller in a special mode where you can repair or restore Active Directory. You set the DSRM password when you first promote a server to a domain controller, and it’s both very powerful and rarely used, making it a credential you probably won’t think about until you won’t have an emergency.
Since Windows Server 2008, you can synchronize the DSRM administrator password with a domain user account, but you have to do it manually with the NTDSUTIL command. LAPS can both store the password and rotate it periodically when you set the Enable Password Safeguard Group Policy for DSRM accounts, but you must enable encryption.
Another useful new option that requires encryption lets you choose how many previous passwords will be stored in AD for each computer. If you were to restore a machine using a backup made before LAPS rotated the password, you could not recover the old AD admin password if it had been updated since , unless you also had an AD backup from the same period. In this case, you needed a tool like Microsoft Diagnostics and Recovery Toolset to recover the computer. You can now use Configure Encrypted Password History Size to match the number of old passwords you keep to your backup policy: If you keep six months or one year of backups for computers, you can make sure you store as many passwords as well.
But the biggest change to LAPS is that you’ll no longer be limited to using on-premises AD to store passwords. If you’re using Azure AD, you’ll be able to set it as the backup store for passwords, although this is currently only available to a small number of organizations in the Windows Insiders Program.