Let me first start this off with I’m 99% sure you aren’t being compromised, but read on to see what I mean.
I first ran into this when I was running Maester and I saw that it said my test failed for having Unified Audit Log enabled. I then went to my Purview Portal and saw that it was enabled. Next I ran the command:
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled
And received this output:
UnifiedAuditLogIngestionEnabled : False
It got me worried, as why is the PowerShell version saying it failed, but the GUI isn’t. Honestly, I usually trust the PowerShell output before the GUI. Then I run the PowerShell command to set it to “True.”
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
And received this output:
WARNING: The command completed successfully but no settings of 'Admin Audit Log Settings' have been modified.
Are you scratching your head like I was? I thought, maybe it’s because on the portal it shows it’s enabled, it is seeing it there and not changing it. Why not put that in the warning message though?
I did a little research and found Audit Log Enable Disable | MSFT which is where this little gem is located
Important
Be sure to run the previous command in Exchange Online PowerShell. Although the Get-AdminAuditLogConfig cmdlet is also available in Security & Compliance PowerShell, the UnifiedAuditLogIngestionEnabled property is always
False, even when auditing is turned on.
And that is when it clicks, I connect to ExchangeOnlineManagement first then IPPSSession which must be causing the issue! I then disconnect with “Disconnect-ExhangeOnline”, and reconnect using “Connect-ExchangeOnline.” Now for the moment of truth:
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled
UnifiedAuditLogIngestionEnabled : True
Success! But now the “why does this happen and why haven’t more people reported this?” I asked my buddy Sam Erde, had he seen this before? And he was perplexed as I was. Then he started digging a bit, and saw that you couldn’t use -NoClobber as it is from the same module.
The crazy part is, if you export both versions, they are the exact same code! What could it be? Is it how the IPPSSession connects to the API? If so, why not put a message saying you are connecting with IPPSSession, please disconnect and use connect-exchangeonline?
The mystery still continues, but I know Sam is working on a fix to handle this more consistently and hopefully have a fix shortly!
Have you been burned by this before?
Cliff notes version:
- You weren’t compromised (unless you see it being changed in the logs and/or you ensure you are checking it correctly)
- Make sure when checking for AuditLog is enabled through PS that your not using IPPSSession for the command
- Sam Erde is working on a fix for Maester
Hope this saves you some headaches and have a great day!