I’d love to see current global stats comparing use of Exchange on-prem vs cloud. Surely given the number of recent security disasters, any notion of physical ownership of mailboxes equating to their safety has been well and truly dispelled and only the bravest or most prodigiously-resourced organisations would attempt hosting it themselves.
Exchange Online is doubtless the most popular version and would most often be deployed alongside an on-prem Active Directory, yet as soon as AD is in the mix the assumption is that Exchange is on-prem or hybrid. Even though all of my mailboxes and groups are in EXO, I still have to manage them with legacy directory extensions manipulated via Powershell or ADSIedit rather than having access to settings in EXO. Worse, those settings aren’t always well-documented or transparent and with a mix of cloud and synced entities in a single tenant, management becomes a headache. This little tale is a perfect case in point.
I have my org’s Azure AD Sync set up based on security groups; these determine who gets synced, what their roles and license assignments are and so on. To make life easy I have mail-enabled them as well, since this gives me a guaranteed-accurate membership list rather than using a DL that gets updated separately. I need to ensure that only staff can send messages to student groups in order to maintain control and avoid bothersome reply storms.
Since all of these groups are AAD Synced, it’s not possible to update them from the EXO side; the system throws this warning if I try:
The operation on Identity "StudentGroup" failed because it's out of the current user's write scope. The action 'Set-DistributionGroup', 'AcceptMessagesOnlyFromSendersOrMembers,RequireSenderAuthenticationEnabled', can't be performed on the object 'StudentGroup' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.
There’s no official documentation that I can find or to which Microsoft has been able to refer me when it comes to enforcing delivery management restrictions on AAD synced groups. Through research, trial and error I have found that it is controlled by the following attributes on the on-prem AD object.
- AuthOrig – Mailboxes only allowed to send
- UnauthOrig – Mailboxes only blocked from send
- dlMemSubmitPerms – Groups only allowed to send
- dlMemRejectPerms – Groups only blocked from send
I had assumed the latter two related only to distribution lists (since they start with DL) and would not apply to my mail-enabled security groups. Indeed when I raised a ticket, Microsoft support incorrectly informed me that this was the case and had me waste hours attempting to get a result from adding a group to the AuthOrig attribute. When I finally discovered my error I was able to apply the DL restriction to my security group through the following Powershell command in on-prem AD referencing the distinguished names of the groups and this worked successfully:
Set-ADObject "CN=StudentGroup,OU=Azure AD Sync Groups,OU=[...]" -replace @{dlMemSubmitPerms="CN=StaffGroup,OU=Azure AD Sync Groups,OU=[...]"}
For multiple groups, use the -add switch instead:
Set-ADObject "CN=StudentGroup,OU=Azure AD Sync Groups,OU=[...]" -add @{dlMemSubmitPerms="CN=AnotherGroup,OU=Azure AD Sync Groups,OU=[...]"}
You’d think that Microsoft’s own support staff would know this but apparently not! Needless to say I requested an escalation for this to be documented but ultimately I’d like a solution. We have writeback capabilities in Azure AD to sync cloud changes back to on-prem, so why not the same for EXO? Or even a toggle somewhere that says ‘manage synced objects in EXO’ and once enabled it shifts the locus of control from AD to Exchange after it pulls in the basics of an object. This would be a boon to those with a mix of cloud and synced objects in their EXO tenant who struggle to apply settings equally across all of them.
A final word of warning from my own recent experience; if the groups are renamed, their distinguished names will change and the link will be broken. Remember to run the commands again if that happens.