In the past, a company-specific standard was usually always used for local administrator passwords. But what do you do if an employee who knows the default password leaves the company?
Right, it should be changed. In the past, Group Policies (GPO) were often used for this, even if the password was in clear text in SysVol. This was fortunately stopped by Microsoft. What other solutions are available? In practice I have seen VBS or PowerShell scripts, the good ones have random passwords, the bad ones only a standard.
But isn’t there a well designed solution from Microsoft? Yes, there is, Local Administrator Password Solution (LAPS).
Why the effort?
Some customers I’ve been to before used default passwords for local admin accounts because it’s easy. Once stored in the image, done. But when can this become a problem? Here is my personal top-3 why this is a bad idea:
- Employees leave the company and know these passwords…
- If all passwords are the same, a lateral pass-to-hash attack is simplified in case of infection or attack.
- If you have to give a password to the user (yes, shouldn’t happen, but it can happen), then the user only knows that for his computer (And changing it can be triggered prematurely via PowerShell).
Other reasons and requirements (e.g. German Federal Office for Information Security (IT-Grundschutz)) are sufficient. Mostly local administrator passwords are not changed because it is too much work. This also changes with LAPS.
How does it work?
LAPS is a service that is installed on the respective computers. This service writes its information to 2 attributes of the computer object. These attributes must be installed with a schema extension and are automatically protected by ADDS-ACL. The extension is done by a provided PowerShell script.
The client / service is delivered as MSI package and can be done via command line or with a software distribution.
The administration is done with an own PowerShell module or an installable GUI. The control over the clients is done via group policies. The GPO can then also be used to set the policies for Local Admin passwords, for example password length or maximum age.
To monitor the whole thing, the log behavior and the audit function can be adjusted. The corresponding events are logged in the Event Log.
Which systems are supported?
I always talk about a client, but for which systems can the LAPS client be used? Quite simply, more than you might think, any x86 or x64 Windows currently supported by Microsoft that is a member of a Windows domain. The Active Directory requirement is similarly low, the domain controllers must be running Windows Server 2003 SP1 or higher. The functional level of the domain should also be 2003.
How do I install it now?
During a normal installation of the MSI, the management tools can be selected. Normally they are not installed. This includes the PowerShell scripts for the propagation of AD.
The installation of the management tools is very easy.
After the installation, the PowerShell must be used to prepare the AD. To do this, start the PowerShell with a user that is included in the Schema Admins group and run the following commands
Import-Module AdmPwd.PS Update-AdmPwdADSchema
If necessary, the permissions on the attributes can also be adjusted manually, for example to give the help desk access only to the passwords of the client computers. See the LAPS documentation for details.
In order for the LAPS client to be able to enter the new passwords when using the GPO, they must also be authorized. Without these rights, the passwords will not be changed. To do this, execute the command and replace with the corresponding OU name.
In order to be able to control the whole thing via group policy, the ADMX and the ADML file must be copied, preferably to the central storage for group policies. If you don’t have a Central Store for GPO’s yet, it’s high time. The files you need to copy can be found after installation under “%SystemRoot%\PolicyDefinitions” the file name is “AdmPwd.admx” or “en-US\AdmPwd.adml”.
You can then configure LAPS via Group Policy.
Installation of the LAPS client
For LAPS to work, the appropriate MSI package must be installed in addition to the policy. If you don’t have a software distribution, you can also do this via a scheduled task using group policies. Or classic via a command line command, e.g:
msiexec /i \\server\Freigabe\LAPS.x64.msi /quiet
If you would like the LAPS not to be listed under “Programs and Functions”, you can also distribute and register the DLL. See the LAPS documentation for details.
After the next GPUpdate the Admin Password will be changed accordingly.
How can I view the password?
Simply start the GUI and select the computer name.
Alternatively the PowerShell command can be used, here a placeholder also works.
Get-AdmPwdPassword -ComputerName Win10Ent
Appropriately, the article “Using and auditing PowerShell scripts with Local Administrator Password Solution (LAPS)” was published on June 4, 2019. The translation of this article was published on the 25th July 2019 at LinkedIn. Please read the article on LinkedIn.
This article first appeared on Infrastrukturhelden.de in German.
This article is a translation of the Infrastrukturhelden.de article “Local Administrator Password Solution (LAPS)” (Published – 2017-04-19). Links may refer to other Infrastrukturhelden.de articles, these may also be available in English language.