Trials of a Network Admin

As in a lot of environments, we sync our on-prem AD to Azure AD, and as such, on-prem security groups are used to grant access to various cloud resources. For us, this includes shared calendars in Exchange 365.

We received a ticket that a few users were not getting the proper level of access to a shared calendar, and my initial investigation did not turn up anything that would explain the problem. Permissions were granted to a sync’d AD group, which itself contained two nested AD groups. Group nesting has always been a bit quirky in M365, so that was the obvious place to check, but users in the first nested group had the proper access. Only users in the second group were missing permissions.

I checked Azure AD and was able to confirm that all members of both groups were properly being placed in the parent group, so clearly the nesting itself was not the issue and there had to be something else going on. I started looking at the differences between the two nested groups and found that the working group was a mail-enabled security group, while the non-working group was not mail-enabled. Turns out that was the problem.

Evidently, Exchange 365 ignores group membership unless the relevant group is mail-enabled. It’s been a while since we had on-premise Exchange but I do not recall this being the case there. In any event, I added an e-mail address and proxy address to the problem group (in AD), and once things sync’d up to the cloud, the users had the proper permissions.

I was not able to find any documentation for this. Hopefully this post saves someone else the trouble of figuring it out on their own. If it does, or you have anything else to add, I’d love to hear from you.