New Windows LAPS - Unusable Auditing?
Posted by Iaskquestions-32@reddit | sysadmin | View on Reddit | 8 comments
To put it bluntly, unless I'm missing something, Windows LAPS auditing is unusable / non-existent.
(Auditing password viewing/decryption/activity events)
From what I've gathered from Microsoft documentation, the only relevant event ID for Windows LAPS auditing is Event 4662, which is the generic "4662(S, F): An operation was performed on an object". These event details obfuscated with the schemaIDGUID, which must be translated to see if a LAPS related attribute was involved.
Most unfortunately, 4662 "Object Access" Events, occur literally any time any user opens a Computer object in ADUC, whether or not they actually looked at a LAPS password or not. This is because the LAPS attributes are all eager loaded into the ADUC attribute editor window in the background. This means there is no possible way to audit who is or is not viewing or decrypting Windows LAPS passwords.
Anyone have specific advice or recommendations based not their own solutions or implementations?
Thank you
One_Ad5568@reddit
I will look into this a bit. ManageEngine ADAudit Plus has “new LAPS” auditing, and I think it works fine. I don’t know if the product does anything special on the server side to make the logs more readable.
-manageengine-@reddit
Hey u/One_Ad5568 , you’re right—ADAudit Plus does support LAPS auditing, and to your point about server-side improvements for log readability, hopefully this helps clarify things. u/Iaskquestions-32 , totally hear you—auditing LAPS access isn’t exactly straightforward.
That said, ADAudit Plus does quite a bit on the server side to make those logs easier to work with. It translates raw Windows events into clear, human-readable reports—so instead of digging through schemaIDGUIDs or vague entries, you get specific details on who did what, when, and where. For LAPS, that includes identifying access to the ms-Mcs-AdmPwd attribute and alerting on it if needed.
It also helps track who has permission to read those attributes, and flags any changes in group membership or access rights that could allow someone to get to that data. It’s not a perfect fix, but we’ve seen it make a big difference in cutting down blind spot. Happy to help you set this up if you're exploring options!
Iaskquestions-32@reddit (OP)
Appreciate the reply and information. What you’ve mentioned about ADAudit Plus capabilities makes sense. It would certainly help provide easy, out of the box readability improvements to the obfuscated logging that is available, however still tracks with my original issue and question about how there really isn’t any actual effective auditing due to Microsoft’s Implementation of the event logging.
I’d agree using a solution like ADAudit Plus could save hours of manual custom solutioning to make the logs readable, and for some, maybe that’s good enough. Unfortunately , in at least my environment, even if the logs are readable, it seems they are rendered unusable for true audit purposes.
Forgery@reddit
https://4sysops.com/archives/part-2-faqs-for-microsoft-local-administrator-password-solution-laps/
Forgery@reddit
I think if you want the kind of auditing you're asking for (i.e. Did someone actually see the password?), you would need to look at a real PAM solution.
Iaskquestions-32@reddit (OP)
thank for the answer, I do realize that we need to map schemaIDGUIDs to basically make the logs human readable, but still doesn't actually make the logs usable from what I mentioned. If a "password read" event is generated every time someone looks at an ad object (without looking at the password), it makes the auditing null & void.
Thus far, I concur with your thoughts that you'd need some different more robust PAM solution.
ZAFJB@reddit
Not a direct answer to your question, but you might find this useful:
https://int64software.com/overlaps/docs/
imnotaero@reddit
I think you have the gist of it. PIM is available from Microsoft and the expectation is that you have to pay for E5 to get it.
But! You can use Intune to put a policy in place that disables the local administrator account. Disabling local admin is a Microsoft recommendation and something that'll give you Microsoft Security Happy Points(tm), or whatever they're called.
We have a group that is exempted by this policy, so if you want to use the LAPS password a M365 admin has to add the device to this group. That step of adding the computer to the group is absolutely logged, and we use it as a cheap-butt proxy for using the LAPS password.