TL;DR if you use ADUC/RSAT to pull LAPS data you run the risk of a MITM.
Microsoft’s Local Admin Password Solution (LAPS) is a method of securely randomizing the local admin password on domain workstations. This solves the issue of a user discovering the local admin password, writing it down, sharing it with their buddies, and the inevitable installation of Trojan horse malware that looked like a useful program. It also mitigates against pass-the-hash. There are plenty of great guides out there on why you should use LAPS and how to set it up, so I won’t re-invent the wheel here. I used this one personally: https://medium.com/@mestacey/why-arent-you-using-microsoft-s-local-administrator-password-solution-laps-yet-66a8a2987a65
There is however an important note on LAPS that I have not seen all over Google. This is not specific to just LAPS, it’s a function of the Active Directory Users & Computers (ADUC) tool in the Remote Server Administration Tools (RSAT). It just happens to affect LAPS. By default ADUC uses LDAP and sends the attributes of an AD object in plain text.
This is relevant to LAPS as it stores the local admin password in plain text in an attribute. This attribute is confidential, in other words domain users cannot view it. Only Domain Admins can by default. To check who can view LAPS passwords run the query in PowerShell:
Find-AdmPwdExtendedRights –Identity <workstation OU> | % {_.ExtendedRightHolders}Or simply:
Find-AdmPwdExtendedrights -Identity <workstation OU>
Helpdesk was given read access as part of a lab testing out how to prevent credential theft by utilizing LAPS.
It is important to remember that the Lightweight Directory Access Protocol (LDAP) transmits in plain text. Since ADUC uses LDAP by default, this means that if the helpdesk personnel get in the bad habit of using ADUC to view workstation attributes then the LAPS passwords will be transmitted in plaintext across the network.
The domain workstation’s FQDN and location in AD are in the same TCP Stream, so an attacker would not have an issue locating the system.
Administrators should be logged in under their normal user account obviously, so a better practice for pulling a LAPS password when necessary is to run PowerShell as their privileged account, then either:
Get-AdmPwdPassword -ComputerName <ComputerName>or
Get-ADComputer -Identity <ComputerName> -Properties ms-Mcs-AdmPwd
WinRM is encrypted by default, so this method is preferred. A MITM will only see encrypted gibberish when PowerShell is in use.
Next, since we just publicly posted the local admin password to one of our VMs, go ahead and get Windows to generate a new random password and apply it to the workstation. This can be done either from the workstation:
Or from a management system:
Please note that to successfully execute an ‘Invoke-GPUpdate’ or do the same task from the GUI via GPMC by right clicking the OU and selecting ‘Group Policy Update’ the domain clients will need to allow Remote Scheduled Task Management through Windows Firewall. This can be centrally managed by a GPO for an inbound rule under Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Inbound Rules. Then simply apply the GPO to the OU containing the domain workstations.
Conclusion
In summary LAPS is an easy to implement and easy to use method of handling local admin passwords in a Windows domain. Just ensure that administrators are following best practices whenever they need to pull the LAPS password from AD.
References:
https://adsecurity.org/?p=1790
https://foxdeploy.com/2017/02/08/is-winrm-secure-or-do-i-need-https/
https://docs.microsoft.com/en-us/powershell/module/grouppolicy/invoke-gpupdate?view=win10-ps
