LAPS stands for Local Administrator Password Solution. After a computer is joined to the domain the local administrator account isn’t used often or is disabled and not able to be used at all. This creates a problem, do you keep an admin account with no domain ties enabled or do you disable it and risk losing access to a computer once it loses access to the domain? The solution, so aptly named by Microsoft, is LAPS. Setting up LAPS randomizes the password of an admin account and syncs it with Active Directory. This ensures that an attacker who’s acquired the password doesn’t have unfettered access to a domain. While at the same time provides password strength and password access by approved users.
In PDQ Deploy LAPS can be used to remove the need of a static password for an account that has admin rights to all computers you wish to scan or deploy, as is traditionally done. When LAPS is enabled within PDQ Deploy and PDQ Inventory it will use the password that is only valid for one of the many target computers and not all target computers.
How to set up LAPS
Keep in mind that PDQ Inventory is required to use LAPS in Deploy. Now, the first item to perform to get started is to download LAPS from here and grab both the 32bit and 64bit installers if you have both types of OS to deploy to. The next step is to pick a computer that LAPS will be configured from, we don’t recommend a production server but a management workstation with GPO tools on the domain should suffice. Run the proper installer for the OS bit then click next until you reach the feature selection screen.
Here we recommend you select all the management tools for installation, click them and select install until no more red crosses remain. Now click next and accept the installation confirmation, it shouldn’t take too long.
Now we have a few files to copy from the local computer to the policy store of your domain. You can find the two files at: %SystemRoot%\PolicyDefinitions. You may have multiple files in this location, specifically, we want the AdmPwd.admx and in the en-US folder AdmPwd.adml. You can access the policy store under \\%USERDNSDOMAIN%\sysvol\%USERDNSDOMAIN%\Policies\PolicyDefinitions. Place the AdmPwd.admx at the root of the policy store and the AdmPwd.adml file in the en-US subfolder. Now the Group Policy objects will be accessible to anyone in the domain without needing to log into a single computer for any LAPS GPO changes.
Choosing what computers to apply LAPS policy
Now that the LAPS Group Policy objects are available to the domain, it’s time to choose what computers will get the LAPS policy applied to them. Keep in mind that this will only be the policy until the agent is in place, no changes to the admin account will occur. For our example, we are going to use an OU called Whiskey Computers as the OU to target. We’ve also created an example group called LapsAdmins to determine who will have rights to retrieve a LAPS password. We won’t be able to create the policies quite yet, we’ll need to extend the AD schema with a PowerShell command. First, let’s import the module with the command Import-module AdmPwd.PS and then we’re going to extend the schema. Warning this cannot be undone so please be ready to do this for real. You’ll need Enterprise admin rights to perform the schema upgrade. Run the command Update-AdmPwdADSchema and wait for it to complete. It shouldn’t take too long. Once done, a list of AD schema changes will be listed in the console.
With the foundation laid we can begin to configure the LAPS permissions for our computers, this will allow specific AD accounts to view and/or modify LAPS passwords. To allow computers the permissions to start updating their passwords to use the PowerShell command.
Where “OU HERE” is the distinguished name of an OU. Now any computer in this OU will be able to set the password of a LAPS account. Next would be allowing approved accounts the ability to read the password too. This is also done with a PowerShell command.
Where GROUP HERE is the name of a group to allow read access to the LAPS passwords and OU HERE is the name of the OU to allow access to. If you would also like the same users to reset the LAPS password manually do so with this.
The configuration of the LAPS
Now to set up the configuration of the LAPS with group policy. Open the Group Policy Management console and a new GPO under the GPO section, we don’t want to link it to any OUs yet. Drill down to Computer Configuration > Policies > Administrative Templates > LAPS. If you do not see it the admx and adml files from before may not be in the correct folder or have not replicated through the domain yet. Enable the Password Settings policy to set how parameters are used to generate and when to generate a password, if the account you wish to have updated is different than the default admin set the name of the account to access as well in the Name of administrator account to manage policy (no need to specify administrator here as the LAPS agent will default to that account automatically based on its well known SID), and lastly to enable the rotation, enable the Enable local admin password management policy. Once you link the GPO to an OU it will start to configure the computers for LAPS just as any other GPO would configure its settings.
For the last piece to fully enable LAPS, the LAPS agent will have to be deployed. We’ll be using, as you might imagine, PDQ Deploy to push it out there. Rather than explain it in words you can watch the video here for it in action. After it is installed and the GPO configuration is in place you can pull the LAPS yourself with the LAPS UI program or with the PowerShell cmdlet Get-AdmPwdPassword. Of course, PDQ Deploy will now be able to make use of the LAPS account option as well removing the need for an account with full admins rights to your computers! Security people will be able to breathe a little easier.
With one foot in development and one foot in operations, Dakota has over ten years of experience in information technology and has presented at the PowerShell + DevOps Global Summit. He's an advocate for automating the boring things and collaborating on the stuff that matters. Das ist mir Wurst! Dakota was a PDQ employee.