PAA 'Reset the password and reboot' fails when device is manually rebooted before PAA is executed
We are currently using the following PAA option within the LAPS policy:
"Reset the password and reboot: upon expiry of the grace period, the managed account password will be reset and the managed device will be immediately rebooted."
When you login as the LAPS admin on the device the following event will be generated:
##############################
10042
The post-authentication grace period has expired per policy. The configured post-authentication actions will now be executed.
##############################
When you now reboot the device manually before PAA execute LAPS will follow up with the following events:
##############################
10047
A pending post-authentication reset timer has been rescheduled after a reboot.
10051
LAPS is updating the managed account password in response to a post-authentication action.
10030
LAPS is sending a message to the following endpoint.
https://enterpriseregistration.windows.net/XXXXXXX
10025
Azure discovery failed.
10005
LAPS policy processing failed with the error code below.
Error code: 0x800706BA
##############################
This results in the LAPS password not being updated in AzureAD which means the password can be used again and again untill the 'next password rotation' kicks in which is makes this solution unsecure.
The Microsoft docs tells us the following for eventid 10025:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/windows-laps-troubleshooting-guidance#event-id-10025
1) Verify that you can connect successfully to the registration endpoint (https://enterpriseregistration.windows.net). If you open Microsoft Edge or Google Chrome and connect to the registration endpoint (https://enterpriseregistration.windows.net), you get a message "Endpoint not found". This message means you can connect to the Enterprise Registration Endpoint.
2) If you're using a proxy server, verify that your proxy is configured under the system context. You can open an elevated command prompt and run the netsh winhttp show proxy command to display the proxy.
We've tested this and visting https://enterpriseregistration.windows.net gives us the expected response ("Endpoint not found").
Also 10 minutes after the 10025 event it starts the processing the LAPS policy again which it does succesfully, but does not update the password as part of the PAA:
##############################
10016
The managed account password does not need to be updated at this time.
10004
LAPS policy processing succeeded.
##############################
This also shows there is no problem reaching https://enterpriseregistration.windows.net. We've tested this both on Windows 10 and Windows 11 with latest updates.
11 Comments
- JaySimmons
Microsoft
Status changed:Working on ittoCompleted - JaySimmons
Microsoft
Awesome, thank you Atitej for confirming the fix is working as expected - much appreciated.
>>The best solution for this would be when the LAPS admin is used and the device
>>is manually rebooted, the PAA will be executed immediately without the reboot.
I assume what you meant was "the PAA will be executed immediately after the reboot"? If so I agree with you that that is one possible minor optimization, but I'm not making any further PAA changes in this regard.
Consider that there are numerous environmental reasons why PAA might not be able to complete the expected password rotation - untimely reboots are just one such issue, also consider network availability, network line-of-sight timing, etc. These issues are outside of the control of the PAA feature, which is why I explicitly kept the retry behavior as simple as possible, using a basic retry-every-30-minutes mechanism. I don't see the current behavior as confusing nor do I see it as a limitation. The goal of the PAA feature is to update the managed account password after the PAA expiry period, but we do not (and cannot) make any hard SLA guarantees as to when that will happen.
If you are still not satisfied with the current behavior, one option you can consider would be to manually force a pwd rotation after use, either via a remote PSH session calling the Reset-LapsPassword cmdlet, or (for Intune-managed) devices via the remote Intune pwd-reset feature.
Jay
- AtitejCopper Contributor
JaySimmons I've managed to get the preview build installed (19045.3271) and did some testing:
Process run as LAPS admin: PAA execute after an hour like configured
Login as LAPS admin: PAA execute after an hour like configured
Process run as LAPS admin and manually reboot: PAA executes after 30 minutes after the device is booted up
Login as LAPS admin and manually reboot: PAA executes 30 minutes after the device is booted up
So the original problem was that if you would login as the LAPS admin and manually reboot, it would not execute the PAA and therefore not reboot and change the LAPS password like it's configured in Intune.
Now it does seem to execute the PAA after a manual reboot, but only after 30 minutes.. I can see the following in the LAPS event log when the device is manually rebooted:
#################################Eventid: 10025
Azure discovery failed.
Error code: 0x800706BA
See https://go.microsoft.com/fwlink/?linkid=2220550 for more information.Eventid: 10043
LAPS failed to reset the password for the currently managed account. The password is considered expired due to an authentication event. LAPS will continue retrying the password reset operation until it succeeds.
Account name: <Account Name>
Account RID: 0x3E9
Password reset retry count: 0
Error code: 0x800706BA#################################
And after 30 minutes it will execute the PAA:
#################################
Eventid: 10042
The post-authentication grace period has expired per policy. The configured post-authentication actions will now be executed.
Account name: <Account Name>
Account RID: 0x3E9#################################
I'm assuming this will cause confusion among our users who will be using the LAPS admin as they don't know exactly when the device will restart again.
The best solution for this would be when the LAPS admin is used and the device is manually rebooted, the PAA will be executed immediately without the reboot. As the user already rebooted the device which is part of the PAA, there is no point in waiting another 30 minutes for the device to restart itself again. This would mean as soon as the device reboots, the LAPS password will be updated and there will be no scheduled reboot.
I hope I made sense. Is this something which can be implemented? Or will we be running into limitations of LAPS?
- JaySimmons
Microsoft
Atitej - the patch is a Windows-side patch only - no changes are necessary on the Intune side,. If you run Windows Update on a repro machine, the July preview patch should be offered to you. Or if you want, you can just wait a few more days for the next Windows Patch Tuesday update coming on August 8th.
The fix is being shipped on all Windows LAPS-supported platforms - it is not restricted to Windows Insider builds.
Hope that helps?
Jay
- AtitejCopper Contributor
JaySimmons Sorry for not getting back to you earlier. Can you tell me which update settings are required within Intune to receive the preview patch? Does this require to be part of the Insider Program?
- AtitejCopper Contributor
JaySimmons Thank you for the update. Sadly the earliest I'm able to test is monday. When I do test I'll make sure to give you an update with the results.
- JaySimmons
Microsoft
Atitej - the July 25th preview patch ship date has been slightly delayed by one day - current ETA is Wednesday July 26th. Fyi - Jay
- AtitejCopper Contributor
Hello JaySimmons - Thank you for the fast response. Sure thing! I'll update this post as soon as I got the results.
- JaySimmons
Microsoft
Status changed:NewtoWorking on it - JaySimmons
Microsoft
Hi Atitej - there is a reboot-related PAA fix shipping next week in the July 25th preview patch which I think will fix this issue. Would you please take one of your repro machines, install the July 25th preview patch next week, re-test, and lmk the results?
thx.
Jay