Last Updated on October 7, 2023 by rudyooms
LAPS everywhere!!!! This time I am deep-diving into the wonders of the Post Authentication Actions (PAA) and what is actually happening (or maybe not happening) when you try to authenticate yourself with the managed account.
I am going to divide this blog into multiple parts
1. Introduction
Some weeks ago I put on my swimming goggles and started diving into the wonders of Windows LAPS and how clicking on the magic password reset button in Intune triggered the password reset on the device itself
Windows Laps | Password Rotation | Threadpool | LRPC (call4cloud.nl)
This blog was focused on the Password rotation and not so much on the Post Authentication Actions (PAA) even when I slightly touched that subject
As shown above, I noticed that even when the authentication is NOT successful when trying to run a process as admin with the managed account, a background queue will still be scheduled to reset the password
Which is odd, right? Exactly that part (odd) caught my attention. I wanted to know why the PAA was queued even though it shouldn’t. So I decided to open the IDA tool and just start looking
(Lucikly, the issue I am describing above is now fixed…)
2. PAA
After opening IDA and spending some time looking at LAPS.dll and LAPScsp.dll and looking through all the code I felt that I was missing something. Let me explain why I had that feeling!
I knew where to start digging because I already found some interesting stuff. In the Windows LAPS password reset blog, I showed you what was happening when a task was queued in the background.
As shown below, the magic word is the “SubmitDelayedSerialOperation” Function inside LAPS.DLL
So I already knew that something, somewhere, somehow was calling this function. After looping back through what was using this function I stumbled upon another function called “NotifyLocalAccountAuthentication”
When taking a closer look, the SAM_LOGON_STATISTICS was shouting at me. When taking a closer look at which functions LAPS imports, I noticed (of course….) SAMSRV being mentioned
But as shown above, nothing that indicates something called Logon_Statistics. I couldn’t care less so I just opened the SAMSRV.DLL and started searching and digging my way around it. After removing the _ between the 2 words I got a nice hit
I was like, okay that’s nice but ow my…. how the f… could that flow fit my screen? Here is the SamIUpdateLogonStatistics Function flow …
Yeah…!! exactly that!! Now you know that it will take a lot of time to get to know the code! Luckily this time the first search was successful! I just decided to start searching for LAPS…. Guess what functions it showed me!
If we just click on one of them, it brings us to the proper place in the disassembly code
So, first of all, it starts checking if the LAPS feature is enabled by calling upon this function (Feature_service_Laps_private_isEnabled)
For your information, this type of function has been used a lot lately. When you spend some time on the internet and reading things you like, you could have stumbled upon this MSDoc named Known Issue Rollback AKA KIR
Inside this doc, this part is mentioned “at the code level”
Mmm, that certainly looks a lot like this code in the SAMSRV.DLL right?
Microsoft implemented KIR to make sure they can roll back easily without breaking existing deployments.. So assuming the LAPS feature is enabled on our device, this next step will be to execute the SampLAPSNotifyLocalAccountAuthentication Function.
It’s like opening a magic box that’s full of functions as from there it will call upon the LAPS.DLL function that we noticed earlier
This function is a “delayed” import from the ext-ms-win-laps-l1-1-0.dll. This is an API not a DLL….
With this API being used, the LAPS.DLL will be called upon. With the LAPS being loaded, it will execute the PAA. But….. I did NOT notice any “catch” in it when the authentication failed because a wrong password is entered. It just calls upon the LAPS.DLL and LAPS would just queue the post-authentication action. Let me show you the flow so you can decide for yourself!
3. PAA FLOW
If you have read the information above, this is what you will get. It’s not as big as the first LAPS password reset flow but it makes a great addition to it!
As always, just click on it to get the BMP version you can save to get a better picture
I will recommend reading my other Windows LAPS blog about the threadpools because without it it could be difficult to understand it all (but that’s just my piece of advice)
4. PAA Flow Improved
Part1: LAPS PAA Detection
Part2: LAPS Background schedule
Conclusion
So now we know how the local password is reset when we press the magic button in Intune and we also know how the PAA is triggered when authenticating with the managed account…. But how does the device block a local password reset for the managed account?
That’s something we will learn in a next blog post