While playing around with Windows LAPS with an insider Windows canary build, I noticed that some improvements were made to Post Authentication Actions (PAA). These improvements also seem to have created an additional bug, which I will discuss in this blog.
1. Introduction
While I was playing around with the latest Windows Insider canary build and using Windows LAPS to kick off a process as admin because the Endpoint Privilege Management Agent wasn’t getting installed, I noticed some funny behavior.
First, let me show you the LAPS config I had in my tenant. I configured the PAA reset delay with 8 hours in my LAPS Intune policy configuration.
So that would mean that after 8 hours, the Post Authentication Actions would be triggered. 
As shown above, in my case, the password would be reset, and the managed device would be immediately rebooted.
When I was trying to find out what was the root cause of the missing EPM agent, I elevated myself and used the managed account. LAPS will detect the successful authentication and a background task (which isn’t a scheduled task) will be scheduled.
After trying to find the root cause of the missing EPM agent, I rebooted the device to try to enroll the device into the declared configuration service. From there on it started to get weird
2. The Bug
After I rebooted my device, I checked if it was getting enrolled into MMP-C Declared Configuration service, but…. it wasn’t. I continued my troubleshooting, but out of nowhere, my device rebooted again. Okay, that was not expected behavior.
After the reboot, I opened the event logs and tried to find out what happened. After spending some minutes at the event log, I quickly noticed that LAPS rebooted my device.
As shown above, it mentioned that the amount of time allowed for the user of the LAPS account credentials has expired and the machine will now be rebooted. I was like huh? Sometimes I lose track of time but this time but not for 8 hours.
So our device reboots because LAPS thinks it needs to? Let’s find out what happened, shall we?
3. What happened?
When taking a closer look at what happened in the LAPS event log (which has been improved a lot with the latest build), we will find something interesting. After the reboot, the device mentions that a post-authentication reset timer has been rescheduled for a reboot
This message corresponds to the function that does the hard work in the LAPS.Dll named: ReschedulePostAuthResetOperationifNecessary
But somehow this time seems to be cleared after the reboot. With this timer being flushed? the PAA will now be executed. In my configuration, it will start rotating the password and rebooting the device.
From there on LAPS would start updating the password on the server side first.
If that one fails, it will NOT update the local password. And that’s exactly what happened! Because the device was not 100% ready at that point in time, when LAPS.DLL was loaded. It showed me that the Azure discovery failed because we did not have a network connection. 0x800706BA AKA (RPC server is unavailable)
With the latest LAPS version, LAPS will retry this operation (a kind of fail-safe for scenarios when the device did not have a proper network connection)
After exactly 30 minutes, LAPS will retry the configured PAA operation again.
This time we do have a proper internet connection and with it, LAPS could successfully update the Azure Ad (entra?) with the newly generated password.
After the password is updated on the server side, LAPS will execute the PAA action for the target account…. Which is rebooting the device.
4. The Flow
5. What to do with the bug?
It’s obvious that before publishing this blog, I reached out to the “father” of LAPS and explained what I noticed. I showed him the flow and explained it in detail.
After a couple of hours, he replied to me and mentioned: “Bug confirmed”. Cool, so that means, I guess I am not going crazy, but I am not done yet! In that same sentence, he was telling me that he also created a fix and would start the backporting process.
Okay? Looking back at the time frame… damn…within a couple of hours after I reached out, the bug was confirmed, and a fix was coded…
So hopefully we will get that fix released quickly but looking at another issue that I told Jay about: MaxPwdAge and the devicelock policy that I also showed at WP Ninjas, should be fixed with the 2023-10 update!!!!
So I will assume that the fix for the PAA reboot issue will also be delivered quickly…. Ow wait here it is!!!!
January 23, 2024—KB5034203 (OS Build 19045.3996) Preview – Microsoft Support
Conclusion
Having your device rebooted because of some PAA bug could give a bad user experience, which we don’t want! Luckily Microsoft (Jay) fixed this issue pretty fast !!