Many environments I’ve worked in fall into the same habit. They set the same local administrator password on all client systems across the domain and rarely, if ever, reset it. When you consider the number of ex-employees that have that password and knowledge of the fact that all non-servers sometimes use it, coupled with the potential for Pass-The-Hash attacks, you see quickly why Microsoft created the Local Administrator Password Solution. It’s really easy to implement. Easy enough that the documentation alone will probably get you there. Regardless, here’s my guide for implementation. As usual, your mileage may vary.
On your system, you’ll need to install the LAPS package with the management tools component to have the appropriate PS cmdlets and GPO template.
Download LAPS here: https://www.microsoft.com/en-us/download/details.aspx?id=46899
Choose to install management tools (and GPO extension if you intend to apply LAPS to the system you’re working from)
We need to accomplish 5 things to successfully deploy LAPS. Adjust paths as necessary, mine used as an example. I would suggest going through all of the motions with a test OU and a couple of test systems before deploying to a broad range of systems.
1. Extend the AD schema. This is a forest level change and cannot be reversed.
[code language=”powershell”]Import-Module AdmPwd.PS
Update-AdmPwdADSchema[/code]
2. Allow computers in target OU(s) to update their password fields.
[code language=”powershell”]Set-AdmPwdComputerSelfPermission -OrgUnit “OU=Computers,DC=sccmchris,DC=com”[/code]
3. Allow specific users to retrieve the content of password fields for computers in target OU(s). Here, let’s assume we have a group called “Desktop Support Staff” and we’d like members of that group to be able to retrieve local admin passwords for any system within the Computers OU.
[code language=”powershell”]Set-AdmPwdReadPasswordPermission -OrgUnit “OU=Computers,DC=sccmchris,DC=com” -AllowedPrincipals “Desktop Support Staff”[/code]
4. Configure GPO and link to appropriate OU. Below is my configuration. Note: Until you enable the setting “Enable local admin password management”, regardless of extension install or GPO application, nothing will be changed in re: to local admin password. If you leave “Name of admin account to manage” not configured, it will manage the default Administrator account. This is nice because you can roll the client MSI in advance of actually enabling LAPS.
5. Deploy LAPS CSE (client side extension) on target systems. This is the same MSI that you used to install the management tools. If you run this MSI with the silent switch, it will install only the GPO extension for the client (no management tools). This makes it incredibly easy to deploy in SCCM or you can even script it on non-SCCM clients.
Only once a client has the GPO extension installed, the GPO applied, and the “enable local admin password management” setting enabled, the management will begin.
That’s it. You’ve deployed LAPS. Of course, you’ll want to do some auditing to ensure systems are successfully submitting their passwords. Options for reading back local passwords:
1. The MSI’s management tools component includes a LAPS UI for retrieving local admin passwords and forcing resets.
2. I use a LAPS Password plugin for SCCM. Find it here: https://gallery.technet.microsoft.com/LAPS-Extension-for-SCCM-e8bd35b1
3. PowerShell option:
[code language=”powershell”]Get-AdmPwdPassword -ComputerName W10L1234[/code]
4. You can retrieve the passwords for *all* computers in an OU (assuming you were granted Read). This is especially useful for your initial test deployment and verifying passwords are being submitted (accurately):
[code language=”powershell”]Get-ADComputer -Filter * -SearchBase “OU=Computers,DC=sccmchris,DC=com” | Get-AdmPwdPassword -ComputerName {$_.Name}[/code]
I had very few issues with this deployment. If I could give you one piece of advice it’d be to use options #4 to generate a list of systems that have submitted a password and compare it to a list of computers that have supposedly installed the client side extension already. Troubleshoot the delta. The few systems I had trouble with were generally experiencing group policy application issues. I had two systems (out of 1,000) that required manual reinstalling of the CSE.
