Microsoft Changed the Way the Search-UnifiedAuditLog Cmdlet Works Without Telling Anyone

[Tony Redmond]

Microsoft changed the way that the Search-UnifiedAuditLog cmdlet works without saying anything to Microsoft 365 customers. The results is that some scripts don't work and others won't return the expected results. This article explains what's happened and offers a workaround. Microsoft's actions are unexplainable, but it's the norm in this area where audit log changes happen without communication all the time.

https://practical365.com/search-unifiedauditlog-cmdlet-changes/

[#2]

Whats insane to me is when I had to track down who was creating accounts and users in our tenant. The UnifiedAuditLogs still can't provide any detail on who created accounts when its being done by "Microsoft Substrate System". Worse I have not found any audit program/system that can pull these specific logs out. You actually have to go in AzureAD, find that app, and check the app's audit logs to figure out the culprit. Just another entry in my list of massive security failures with O365. It turned out in our case, the problem was with MS new "Bookings" feature, where by default it lets literally any user create an account in your tenant with any name they can think of.

[#3]

A way is needed to allow non-privileged actors to create new accounts. That mechanism is the substrate... and it's what creates the accounts used for Bookings. The 'Microsoft Substrate Management' is an Entra ID app that holds the permissions necessary to perform all sorts of operations, like the dual-writes to keep EXODS and Entra ID in sync (Vasil has a lot to say on this topic in https://www.michev.info/blog/post/4264/dual-write-glitch-allows-exchange-online-cmdlets-to-be-execut...). I agree that things could be better and will raise the problem with Microsoft.