Wednesday 22 April 2020

LAPS not working after computer rebuilds

Many of my customers use the Microsoft Local Administrator Password Solution (LAPS) to manage local account passwords of domain joined computers. Recently I created a Windows 10 v1909 task sequence solution with ConfigMgr for one of these customers. Everything looked good in testing but after a few days I got a report to say that LAPS wasn't working. Admins couldn't sign into the devices uing the local administrator password.

I figured that was unusual so I reinstalled W10 v1909 on a test laptop and LAPS worked perfectly. That was a bit odd. What was the difference between my test and the customers test?

You have to delve a little deeper into how LAPS works to be able to answer that question. This Microsoft blog post explains what happens to LAPS during machine reinstalls.

“LAPS uses the attribute ms-MCS-AdmPwdExpirationTime on the computer object to remember the expiration time of local administrator password. It works pretty well during lifetime of computer. But what happens when computer is reinstalled? LAPS design expects that in this case, computer account is deleted and created again. But what if you decide to reuse computer account?

In this case, when you install the computer and then install LAPS CSE on it, during first GPO refresh after install, CSE looks to computer account and sees that it is not time to reset password yet: ms-MCS-AdmPwdExpirationTime attribute still has value populated by previous computer that used this computer account. This means that the password that is on local administrator account after setup may be there until the password expiration time set by previous computer expires: up to 30 days by default”.

That explained to me why my test computer worked and none of the others did. I ALWAYS delete the computer object from ConfigMgr and Active Directory before I re-image. The customer verified that they didn't do this for any of their tests.

The customer wondered why this not happen before. I explained that it did occur but they didn't notice as they didn’t test LAPS immediately. The solution corrects itself after the password expiration date.


It's easy to verify that this is happening:


I generated the password on 10th Feb but it was set to expire on 12th Feb. That was my first clue. The password should have been valid for 30 days.

I hope this helps you to explain the anomaly if you encounter it. It's expected behaviour. 

Until next time....

Note: several people have pointed out to me that it's better to automatically expire the existing password during the rebuild by including this script in the task sequence.


No comments:

Post a Comment