This step-by-step guide demonstrates the integration of LAPS in an Active Directory environment. The user passwords of Active Directory users are stored central on all Domain Controllers. But what about the local account of the administrator? Many use the same password on all computers. A nightmare in terms of security. LAPS can store and change local administrator passwords centrally.
Downloading the LAPS Installer
LAPS should be installed on a management server (in my case, a Windows Server 2016 domain controller). First, we have to download the LAPS Installer: https://www.microsoft.com/en-us/download/details.aspx?id=46899
Installing LAPS on the Management-Server
During setup, it’s important to select all features, otherwise only the client-side extensions (which are also required for the clients) will be installed.
Modifying the Active Directory Schema
Two attributes must be added to the computer objects:
- msMcsAdmPwd
- msMcsAdmPwdExpirationTime
Both attributes can be created by using LAPS commands in PowerShell. The user must be a member of the Active Directory Schema Admins group. Open Windows PowerShell and run
Import-Module AdmPwd.PS Update-AdmPwdADSchema
Configuring Permissions
Domain computers must have write permissions to renew the password of the local administrator. In my case, I grant access for all computers of the organizational unit “Workstations”.
Set-AdmPwdComputerSelfPermission -Identity Workstations
Now we have to configure group permissions. All group members of this group will be able to read the local password of each computer centrally. I grant “read password permission” for the domain admins group.
Set-AdmPwdReadPasswordPermission -OrgUnit Workstations -AllowedPrincipals "Domain-Admins"
Next we configure the right to reset the password of the local administrator account. As before, I allow it for all Domain Admins.
Set-AdmPwdResetPasswordPermission -OrgUnit Workstations -AllowedPrincipals "Domain-Admins"
Installing LAPS on the Client Computers manually
In order to use LAPS, the AdmPwd GPO Extensions must be installed on all client computers. This can be done either manually or via GPO. In my case, I manually install the previously used tool on a Windows 10 system. All you need to do is to install only the client-side extensions.
Installing LAPS on the Client Computers by using Group Policy Software Installation (Bulk)
Well, it’s boring to install LAPS on hundred or thousand computers manually. In a production environment you can install the software by using group policy. This now takes some time. Are you ready? 😉
Create a shared folder
First, we have to create a shared folder and put the installation files in it. All we need is PowerShell and the installation package. For creating a shared folder on the management server open Windows PowerShell and run
New-Item -Itemtype Directory -Name LAPS -Path C:\
Once the folder is created, activate sharing.
New-SmbShare -Name LAPS -Path C:\LAPS\
Now copy the installation package into the folder.
Configure a GPO for Software Installation
On a domain controller, open the group management console (gpmc.msc). Create a new GPO by following my screenshots.
Provide a name for the GPO.
Click on Edit.
Navigate to Computer Configuration – Policies – Software Settings. Right click Software Installation and select New – Package.
Pay attention to the path. You have to provide the UNC Path of the previously configured shared folder. Do not start browsing your computer to find the package! Enter the path to the folder manually by using the format \\ServerName\SharedFolderName\LAPS.x64.msi and click Open.
Next, select Assigned.
Review your work.
Finally, link the GPO to an organizational unit. Make sure, that you link it to the OU of your client computers.
For testing, run gpupdate /force on one of your client computers. Then restart the computer. After restarting check Programs and Features.
Let’s move on configuring the final steps.
Enabling LAPS on all Client Computers
The last step is to create a GPO for LAPS. On a domain controller, open the group policy management console (gpmc.msc) and create a new GPO named LAPS. Open the GPO and navigate to Computer Configuration – Policies – Administrative Templates – LAPS. Enable “Enable local admin password mangement”.
Then link the GPO to the Organizational Unit.
Run gpupdate /force on all Client Computers. You can do this remotely: PowerShell: Force gpupdate on all Domain Computers
Showing Local Administrator Passwords
On the management server open LAPS.
Enter the computer name of one of your clients.
As an alternative, open Windows PowerShell and run
Import-Module AdmPwd.PS Get-AdmPwdPassword -ComputerName ComputerName | Format-List
Advanced Settings
Changing Password Policies
With LAPS you can enforce local administrator password policies. Open the previously created GPO and configure the appropriate settings.
Renaming the Local Administrator Account
Furthermore, it’s possible to rename the administrator account.
Have fun with LAPS!
More Informations about LAPS here: Technet: “Local Administrator Password Solution”.
Categories: Cyber Security, Windows Server
Hello, we are used LAPS 6.2.0 with Win 7 without problems but with WIn 10 1703, the local admin password is not changed. any idea?
LikeLike
Hi Alberto, unfortunately I have no experience with 1703. Do the client computers get the GPO?
LikeLike
I followed your guide for a 2008R2 DC environment and also a 2012R2 DC environment – Workstations are pulling the LAPS GPO installation and I can confirm the admin dll file is present on those clients but I am not able to read the password in either AD Attribute Editor, LAPS GUI using ‘Run as Administrator’, or in a PowerShell session. I triple checked Effective Access permissions on the Workstations OU and can confirm Domain Admins has rights to Write/Read msAdminPWD and msAdminExpiration. Any guidance on what I could be missing here?
LikeLike
Do you get an error message? I haven’t tried it in a Windows Server 2008R2 environment.
LikeLike
I did exactly as explained but I can’t find LAPS policies at Computer Configuration – Policies – Administrative Templates at all. Any idea for the reason or how to fix that please?
LikeLike
Where are u looking for it? On the management server or on the client machine? First check if the software was installed correctly.
LikeLike
I am checking on the management server. And the software was installed successfully on the client.
LikeLike
I would recommend reinstalling LAPS on the management server. Make sure you select all the components (in particular GPO Editor Templates).
LikeLike
Same issue. By the way I am using a central store. Does this have any effect?
LikeLike
Central ADMX Store? Yes, then you have to install (copy?) the templates manually in your SYSVOL Folder.
LikeLike
It worked! Thanks a lot.
LikeLike
So how are you doing this when 30% of your endpoints are remote users that only connect to the domain 4 times a year?
LikeLike
This one is tested with computers that logged in on a regular basis.
LikeLike
is there any way to reset the local admin password for every 4 hours?
LikeLike
Hi Jeff, I guess this is only possible by using a script. I heard of some guys playing with local administrator accounts without using LAPS. Regards, P
LikeLike
i think using below script can reset in 4 hours.
Set-ADComputer –Identity “Client01” –Replace @{“ms-Mcs-AdmPwdExpirationTime”=14400}
However, i have no idea about repeat this script every 4 hours.
LikeLike
Ah, now I got you. Then make a Scheduled Task as I’ve described here and pay attention to $trigger:
https://sid-500.com/2017/09/16/powershell-how-to-automatically-restart-applications-when-they-are-closed/
LikeLike
hi pewa2303,
I used another stupid method to solve the problem.
LAPS need to extend schema (ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime).
Do you know the ID for those schema in server 2012 r2?
Thanks,
Jeff
LikeLike
Hi Jeff,
My article is based on Windows Server 2016. This might help you:
https://blogs.technet.microsoft.com/heyscriptingguy/2013/07/24/exploring-active-directory-data-types-with-powershell/
Regards, P
LikeLike
Very goodbye thanks for sharing.
LikeLiked by 1 person