A couple of weeks ago, I wrote on Petri about using Microsoft LAPS (Local Administrator Password Solution) to manage local administrator accounts for remote administration instead of domain accounts. While domain accounts for remote management don’t need to be privileged in the domain, i.e. members of Domain Admins or other privileged AD groups, they could be used to compromise every workstation. If a helpdesk user wants to remotely access a workstation, it is more secure to retrieve a LAPS-managed local administrator account password from Active Directory (AD), limiting damage to the device if the password is compromised. And furthermore, some remote access tools expose credentials.
While there are clearly some security benefits to this approach, as I noted in the previous article, there are also drawbacks. One is that it requires more administrative effort for helpdesk staff to retrieve local admin passwords from AD every time they need to log in to a remote system, as opposed to logging in directly with a domain account. Secondly, using an unnamed account to log in means there is no record of who accessed the device with administrative privileges. But as I’ll show you in this article, you can work around these limitations by enabling auditing of access to LAPS passwords in AD and resetting passwords after each use with the PowerShell Set-AdmPwdAuditing and Reset-AdmPwdPassword cmdlets.
Before running the commands in this article, make sure that LAPS is set up properly in your domain. Installing LAPS involves several steps, including extending the Active Directory schema and setting permissions in Active Directory. The LAPS PowerShell module can be installed using the LAPS installer.
By default, LAPS doesn’t audit who accesses LAPS passwords stored in Active Directory. But using the LAPS PowerShell module, you can enable auditing using the Set-AdmPwdAuditing cmdlet. The command below records all accounts that access passwords stored for computer accounts in the Clients Organizational Unit (OU).
Set-AdmPwdAuditing -Identity:Clients -AuditedPrincipals:Everyone
Once auditing is enabled, any user accessing the ms-Mcs-AdmPwd attribute in Active Directory will have their activity logged in the Windows Security Event Log. Event 4662 logs the user’s name and the name of the object they tried to access, which will be the computer account of the LAPS-managed local admin password. For example, if Joe1 tries to access the LAPS password for a computer in the Clients OU called Client131, an event will be logged that shows the username (Joe1), the object (Client131), other details such as the object’s full distinguished name (DN), and the time and date.
If you want more control over how LAPS passwords are accessed and managed, you could set up a process that only allows specific users to read the passwords in AD and then assign the passwords as requested by support staff. This would allow you to keep a record of who is using the accounts and when; and reset a password after use to ensure access is blocked until the password is reissued. A process like this involves more effort but does make it easier to trace who had access to devices without needing to search through the event log. It also gives you a better idea of precisely how long a user was accessing a device.
When you set up LAPS in your domain, you can control who has read access to the passwords using the Set-AdmPwdReadPasswordPermission cmdlet. See Secure Local Administrator Accounts with the Local Administrator Password Solution (LAPS) Tool on Petri to learn how to secure access to LAPS passwords in AD.
Resetting a password is easy using the Reset-AdmPwdPassword cmdlet. The command below resets the LAPS-managed local admin password in AD for Client131.
Reset-AdmPwdPassword -ComputerName Client131
Remember that this system isn’t ideal. When you reset a password using Reset-AdmPwdPassword, you must wait for Group Policy to refresh on the device before the password is applied to the local computer. See Forcing a Remote Group Policy Update with GPMC on Petri to learn how to remotely refresh Group Policy.