Office 365 Audit Records Truncated for Azure Active Directory Events

A Live Demo Fails

The shifting sands of cloud services caught me out on Monday when I spoke at the UK Evolve conference. My topic was how to use PowerShell to manage Office 365 Groups and Teams (aka “Hacking your way to Happiness” – you can download a PDF of the deck here). During the session, I use several demos to show people how easy PowerShell really is and how quickly it lets you get real work done. All went well and then I came to an example where I look for records in the Office 365 audit log for “add group” events.

To make sure that demos run smoothly I use a cheat sheet of PowerShell code snippets in a Word document. Cutting and pasting known good code is faster and saves the embarrassment of getting code wrong in front of large audiences. I was therefore nonplussed to see an error from code that “used” to work perfectly well and is from an example in Chapter 21 of the Office 365 for IT Pros eBook.

Cannot index into a null array.
At line:1 char:7
+ $ReportLine = [PSCustomObject][Ordered]@{
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : NullArray

Add Group is Truncated

Looking at the code, I found that the problem happened after I used the Search-UnifiedAuditLog cmdlet to search for audit records for the “add group” event. The idea is that you can extract these audit records from the log and then analyze them to figure out who’s creating new Office 365 Groups and Teams. Audit records hold a lot of interesting information in the JSON content held in the AuditData field, so we need to unpack the content to extract information about the name of the newly created groups. The resulting $AuditData variable for an unpacked record contains the data shown below:

ObjectId       : Not Available
UserId         : Tony.Redmond@office365itpros.com
ClientIP       : 
Id             : a6ddc5dc-bfce-4d7c-b39b-775cba7b48ae
RecordType     : 8
CreationTime   : 2018-07-11T14:36:54
Operation      : Add group.
OrganizationId : b662313f-14fc-43a2-9a7a-d2e27f4f3478
UserType       : 0
UserKey        : 1003BFFD805C87B0@office365itpros.com
Workload       : AzureActiveDirectory
ResultStatus   : Success : Record Truncated
Version        : 1

Seeing “Record Truncated” in a status field doesn’t create a feeling of confidence that the audit records are complete. In fact, the data is missing two fields that used to be available called Actor and Target, the latter being the field that the group identifier and group name were available in. When my code tried to access the information in $AuditData with references to $AuditData.Target[0].Id and $AuditData.Target[1].Id, the null array error happened because that array was never populated by the JSON extract.

Something Changed

Something had clearly changed in the audit records generated for “add group” events since I used the same demo code at the European Collaboration Summit in late May.  I looked at all the audit events I could find for “add group” using the Audit log viewer in the Security and Compliance Center and found that every one of the events lack the data.

Office 365 only keeps audit log records for 90 days, so I could only go back to early July.  I found good records on July 5 and bad records after July 11. It therefore seems likely that the format of the audit records captured for Azure Active Directory events ingested into the Office 365 audit log changed sometime between July 5 and 11. I can’t be more definite than that.

Changing Audit Records is a Bad Thing

As it transpires, the problem of truncated information in Office 365 audit records exists for other Azure Active Directory group operations like add and remove user (see below) and group removal and updates. This is a real problem. Customers depend on this information to understand what happens with groups inside their tenant.

Looking at the Azure audit log, the details of the group (name and identifier) are present, so it seems likely that the problem occurs when Office 365 extracts information from Azure Active Directory and normalizes the data before ingestion into the audit log.

Activity
Date : 9/9/2018, 4:45:32 PM
Name : Remove member from group
CorrelationId : 3669b365-5346-4fb7-aeb5-0260a1e64305
Source : AzureAD
Category : Core Directory
Activity Status
Status : Success
Reason :
Initiated By (Actor)
Type : User
Name : Microsoft Teams Services
ObjectId : eff4cd58-1bb8-4899-94de-795f656b4a18
Upn : Tony.Redmond@office365itpros.com
IpAddress :
Target(s)
Target
Type : User
ObjectId : bd8ad08e-c964-41e0-b5e9-456ab487a0c1
Upn : O365-ExchangeConnections2015@office365itpros.onmicrosoft.com
Modified Properties
Name : Group.ObjectID
New Value : "37991751-f6dd-48e5-bc86-1967181a7e53"
Name : Group.DisplayName
New Value : "All R &A Users"
Name : Group.WellKnownObjectName
Target
Type : Group
ObjectId : 37991751-f6dd-48e5-bc86-1967181a7e53
Additional Details

Not a Good Situation

I don’t know why Microsoft decided to change the format of the Azure Active Directory audit records as they were ingested into the Office 365 audit log. I do know that they messed up by removing essential data from the records. Where once it was possible to easily determine the name of a newly created group, now it is not. The same is true when trying to find out who was added or removed from groups, or accounts that are added or removed from the tenant. Losing this information is not good and it doesn’t give you confidence in the testing regime used to validate code changes.

I also don’t like when changes happen to data that might be used for compliance purposes without any warning or documentation. It doesn’t help people who roll their own analysis with PowerShell and it doesn’t help the ISVs who extract audit data on behalf of Office 365 tenants and store that data for longer than the 90-day default retention period.

All the Office 365 for IT Pros writing team can do is to keep checking to make sure that the code examples we include in the book continue to work over time. I’m happy that I found this problem and have been able to report it to Microsoft; it just wasn’t so good to run smack into the issue when doing a live demo.