Entra ID Audit Captures Some But Not All Updates of User Account Properties

Audit User Account Changes – But Not For All Properties

In a Twitter (X) discussion about Microsoft Entra ID logging, one of the participants commented that “On the small end, just being able to see who changed a user account property like UsageLocation” would be a good thing. The point here is that changing the usage location of a user account can have licensing implications.

The complaint is that the Entra ID audit log doesn’t disclose who updated a user account and changes the usage location. And as it turns out, the statement is true, as a quick test reveals. Update a user account and change several properties, including the usage location. Wait for a few minutes and check what the Entra ID audit log reports. It should show something like Figure 1. The changes made to all other properties are there, but there’s no trace of the change made to move the account’s usage location (in this case, from Ireland to France).

Later on in the conversation, the original complainant stated that they had “opened a case last year on the UsageLocation issue. I was told that the missing data is ‘by design’ and it was closed.” That response seems strange. Why would Entra ID consider that not logging changes made to account user locations is a design feature? After all, their documentation emphasizes that “you must specify the Usage location for all members.”

How the Audit Log Stores Details of User Account Updates

Entries from the Entra ID audit log flow through to the unified audit log (now holding 180 days of audit data for Office 365 E3 accounts). Perhaps the data ingested by the unified audit log would hold the missing usage location information. It’s always worth checking.

Many workloads pump information to the unified audit log, and it’s a great source of who-did-what knowledge covering situations like permission consent grants, usage of sensitivity labels, and keeping an eye on membership changes in Microsoft 365 groups. Knowing how to extract information from the audit log is a skill that every Microsoft 365 enterprise tenant administrator should have.

Unfortunately, while some fields are standard, the bulk of the interesting audit information is in the AuditData property. Workloads can stick whatever they like into AuditData, and some workloads take free liberty to do their own thing. The result is that interpreting the content of audit events is always “interesting” and takes more time than it should.

In this case, the action we want to check is “update user.” (with or without the full stop). Not all of the events logged for this action are interesting because some originate from background processes. Checking a bunch of events revealed that the ones which hold relevant data have an entry in the ModifiedProperties property called “Included Updated Properties.” For instance, the Entra ID audit record shown in Figure 1 includes this data when ingested into the unified audit log:

$Auditdata.ModifiedProperties | fl

Name     : City
NewValue : [
             "Flayosc"
           ]
OldValue : [
             "Dublin"
           ]

Name     : Country
NewValue : [
             "France"
           ]
OldValue : [
             "Ireland"
           ]

Name     : TelephoneNumber
NewValue : [
             "+33 4 9242554"
           ]
OldValue : [
             "01-2070807"
           ]

Name     : StreetAddress
NewValue : [
             "24 Chemin de Floriege"
           ]
OldValue : [
             "15 Fairways"
           ]

Name     : State
NewValue : [
             "Var"
           ]
OldValue : [
             "Dublin"
           ]

Name     : PostalCode
NewValue : [
             "83780"
           ]
OldValue : [
             "D18A6R4"
           ]

Name     : Included Updated Properties
NewValue : City, Country, TelephoneNumber, StreetAddress, State, PostalCode
OldValue :

Six properties are described in the Included Updated Properties property, but there’s no trace of UsageLocation. So no joy there…

Writing a Script to Report Changed Properties

After discovering how audit records hold details about updated properties, it didn’t take too long to create a script to report changed properties for user accounts. The biggest problem is extracting data in a reportable format from the AuditData property. With some trial and error and some persistence, it’s possible to generate a reasonable report. Figure 2 shows the script output.

You can download the script from GitHub. It is very much an example to illustrate the principal of extracting this information and can be improved. For instance, detailing the exact changes made to licenses assigned to an account.

The Hassle of Dealing with Non-Standard Audit Events

The unified audit log is a huge benefit for enterprise tenants. It’s just a pity that the Microsoft development groups make it so difficult for administrators to extract information from the audit log because of some quixotic approaches to how they format data written in log events. It would be nice if all groups used a standard method to format audit entries, but I guess that’s not going to happen. But it would be nice if Entra ID logged changes to the usage location property.

---

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.