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!