Using and Auditing PowerShell Scripts with Microsoft Local Administrator Password Solution (LAPS)

This article first appeared in German at Intrastrukturhelden.de. This is the English translation of my article.

You don't know the Administrator Password Solution (LAPS) yet, then read my first article (Update: now also available in English) about LAPS and how to set it up. This article is about using LAPS with PowerShell and how to audit it.

Why use Remote PowerShell with LAPS Protected Administrator Passwords

Since LAPS is often used to prevent vertical attacks after password hash capture, why not go further? There are often PowerShell scripts that need to be executed locally on remote systems. These can be administrative, or simply read data from the Event Viewer. But always use a domain-based service account that leaves a hash? Why not use the Local Administrator? Since the passwords are all different, there is no risk. The password is also changed regularly so that the hash loses its worth.

But the password keeps changing, but you can query it with the PowerShell. So, what could be more logical than writing a PowerShell script that uses the local administrator with the LAPS password for accessing remote systems? The password can be directly reset after use. Then, the hash or even the password is worthless.

The big advantage of auditing, which I will describe later in this article, is that you can see directly who executed the script.

The requirements

The computer that starts the script must have the LAPS PowerShell module installed from the LAPS Installer. Also, the systems that want to use with LAPS to connect must be registered as a Trusted Host. Because Kerberos cannot be used for local passwords, either unencrypted WinRM usage must be allowed, or SSL for WinRM must be used. How to do this the secure way can be found in the article "Windows WinRM over HTTPs" (In German).

It makes sense to limit this to the Trusted Host configuration to the necessary systems. If it should be simple, a "*" also works.

Set trusted hosts by group policy

To enable this via Group Policy, go to Administrative Templates/Windows Components/Windows Remote Management (WinRM)/WinRM Service and select Allow remote server management through WinRM. The IP addresses or subnets are entered here as the value for the trusted hosts.

Set trusted hosts with Power Shell

To define the Trusted Hosts using PowerShell, use the command

Set-Item WSMan:\localhost\Client\TrustedHosts -Value <ComputerName>,[<ComputerName>]

can be used. This overwrites existing entries. If you want to read more about the PowerShell variant, I recommend the article "Add computers to TrustedHosts list using PowerShell" by Dimitris Tonias.

But the group policy wins if both are active. Since the GPO can also be adjusted more easily, I recommend the group policy solution. This also makes possible error analysis easier.

The script

Now to the script that automatically uses the LAPS protected administrator. The LAPS PowerShell module must be installed on the system on which the script is running. The following script is just an example of how to do this. For productive use, you should make it "pretty" accordingly.

Import-Module AdmPwd.PS

$computer = "Win10-1809"

$username = "$computer\Administrator"

$password = (Get-AdmPwdPassword -ComputerName $computer).Password

Write-Output "Found Password: $password"

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username,$($password | ConvertTo-SecureString -asPlainText -Force)

$FQDN= $computer + ".adg.local"

Invoke-Command -ComputerName $FQDN -ScriptBlock { Get-ChildItem C:\ } -credential $cred -UseSSL

Now you could argue that the password is known, or the stored hash on the target could be misused. So we change it.

This is done by adding the following commands to our script:

Reset-AdmPwdPassword -ComputerName $computer

Start-Sleep -Seconds 30

Invoke-GPUpdate -Computer $computer -Target Computer -Force

After the Invoke-GPUpdate it may take 5-10 minutes until the new password is set.

This will reset the password after the script. As a supplement, you could add your own event log entries to the script.

Auditing the use of the receiving of the password

Of course, the risk is that local administrator passwords are used to leave no traces. Since the local administrator is not personalized, it could be anyone who can read the password. Fortunately, the Active Directory can audit here. LAPS bring the command "Set-AdmPwdAuditing" with it. This command makes it easier to set up the audit function. A group to be audited and the OU can be specified. It makes sense to use the same groups that are also used for readout authorization. Alternatively, the group "Everyone" can also be used for the audit. The OU should be selected accordingly. After activation, an entry with Event-ID 4662 appears in the security log of the domain controller. This entry contains the user. My personal recommendation, Trust no one. Here the example for this:

Set-AdmPwdAuditing -Identity Clients -AuditedPrincipals Everyone

Enabling Client Logging for LAPS

Normally, LAPS records anything in the event log on the system that manages it. However, creating entries in the Event Log can be enabled for error analysis or better monitoring. To activate logging, a registry key with the name "ExtensionDebugLevel" must be created under HKLM:SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA}. The value is of type Reg_Dword and has the following values:

0: Silent Mode, no records

1: Only Errors and Warnings

2: Verbose, almost everything

Event IDs für den LAPS Client

The Event-IDs are documented in the LAPS_OperationsGuide, which can be downloaded with LAPS.

Windows Admin Center and LAPS

I had already written about the Windows Admin Center, aka Project Honolulu, in April 2018.

Meanwhile, the Windows Admin Center can also use LAPS to automatically establish connections to the managed systems. So not everyone needs a Personal Admin who is a local administrator everywhere. And there are fewer password hashes and cached credentials left on the systems. This is already a security improvement. For example, in many companies, the personal administrative passwords are either not changed, or the administrative accounts have more rights than required for the actual task.

In combination with the auditing mentioned above, it is also possible to control who had access.

Whether this function makes sense and how much security it provides depends on your procedures.

Code Disclaimer

The code contained here serves as an example. I do not provide any warranty, guarantee or support for the code or its components. Use the code at your own risk.

I always recommend having a close look at the scripts before using them.