Friday, 08 June 2018 10:10

Force LAPS Password Reset during MDT OSD

Written by
Rate this item
(3 votes)

image

My customers often send me exciting cases. This particular one is especially interesting because it is common in infrastructures that use "Local Administrator Password Solution" (LAPS) for password management. LAPS, which I can't recommend highly enough, provides management of common local administrator account by setting a different, random password on every managed domain-joined computer. The case opened when a customer contacted me a few weeks ago reporting that they experienced issues when re-installing computers using Microsoft Deployment Toolkit: after OS deployment, LAPS didn't update the local administrator password which in turn significantly increased the risk of lateral escalation (Pass-the-Hash (PtH)) that results when the same administrative local account and password combination is used. Given the importance of the customer, I immediately sat down to investigate.

In this case, the fact that stood out was that all the systems on which the problem had occurred kept their computer name and re-used computer’s corresponding Active Directory object. LAPS stores the password for each computer’s local administrator account in a confidential ms-Mcs-AdmPwd attribute in the AD, while the expiration date is written into the ms-Mcs-AdmPwdExpirationTime attribute. Re-using the computer's AD account is not a supported scenario: when MDT installs LAPS client-side extension (CSE), after the next startup or background group policy refresh (whichever comes first), the LAPS agent determines that the expiration date of the local administrator password set by the previous computer that used the AD object is within the defined threshold and does not reset password. Only when the expiration time is reached, will LAPS CSE replace local admin password.

Note: same issue occurs on non-persistent virtual computers.

Now that the problem was understood, I needed a way to force the LAPS client to change the password right after OSD ends. Jiri Formacek published a script back in 2015 which clears the ms-Mcs-AdmPwdExpirationTime attribute, telling LAPS client-side extension that it needs to change local administrator account password upon next group policy refresh.

The only caveat with the script is that it needs to run as NT AUTHORITY\SYSTEM because each machine is allowed to update its own password data in Active Directory. Microsoft System Center Configuration Manager runs command lines in task sequences with Local System account permissions on managed computers. Microsoft Deployment Toolkit runs task sequences with the local administrator account credentials.

To overcome this issue, I wrote a small PowerShell ResetLapsPasswordWrapper.ps1 script that relies on Microsoft Sysinternals PSexec tool to execute Jiri Formacek's script with local system account permissions. Confident I solved the issue, I copied both scripts as well as PSexec.exe (for 32-bit systems) and PSexec64.exe (for 64-bit machines) to the Windows 10 deployment share, added ResetLapsPasswordWrapper.ps1 to the Windows 10, version 1803 task sequence, ran a couple of deployments and confirmed that the script forced password reset of the Administrator account, effectively mitigating PtH attacks that rely on identical local account passwords.

Case closed!

Read 2763 times
  1. Comments (1)

  2. Add yours

Comments (1)

This comment was minimized by the moderator on the site

You could use the module that comes with LAPS. Create a package with the module in it and run following:

Import-Module -Name .\AdmPwd.PS
Reset-AdmPwdPassword $env:COMPUTERNAME

Regards,
Claus

There are no comments posted here yet

Leave your comments

  1. Posting comment as a guest.
0 Characters
Attachments (0 / 3)
Share Your Location

Recent Posts