Auditing removal of group members in Entra ID

By | January 25, 2024

I came across something quite surprising (to me at least) the other day, so I thought I would share it here in case others come across the same behaviour. What I found is that that the Entra ID audit log doesn’t always show an entry for removal of a member from a group. Specifically, if the member is soft-deleted there is no corresponding “Remove member from group” audit event associated with the group object.

Let’s take a look at a couple of examples.

In the first example, you have a dynamic group and you modify the attributes of one of the members so that it no longer meets the rule criteria for group membership. In this scenario you will not only see the member dropped from the group, you will also see an audit event showing the details of the removal.

In the second example, you also have a dynamic group but in this case you soft delete one of the members. Again, you’ll see the member dropped from the group but (and this is what I have a problem with) you won’t see a corresponding “Remove member from group” audit entry.

Having spoken to Microsoft Support, the absence of a “Remove member from group” audit event appears to be behaviour by design. The member has effectively been soft deleted from the tenant and no longer exists, so it hasn’t been directly “removed” from the group as such. Except that is has – at least from my perspective. How do I keep track of changes to a group’s membership if I don’t have the corresponding audit events?

When I discovered this behaviour, the problem I was trying to solve was whether an Access Review for a dynamic group containing all Guest users was working as expected. The Access Review was configured to block inactive guests from sign-in and then remove them from the tenant after a further 30 days. I was hoping to see from the audit logs that the inactive Guest users were being removed in the expected time frame. From what I now know, looking at the audit events associated with the group object was not going to help me, but I was able to work around the problem by running a KQL query to find deleted Guest accounts. Here’s what I used.

| where TargetResources[0].userPrincipalName contains "#EXT#"
| where OperationName == "Delete user" 
| project ActivityDateTime, OperationName, InitiatedBy.user.userPrincipalName, TargetResources[0].userPrincipalName, TargetResources[0].id

I hope that sometime in the furture Microsoft will change the way in which group membership changes are audited to make the information more consistent and discoverable. In the meantime, you might need to find a workaround for what you are trying to achieve.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.