Microsoft 365: Why is Mail.Send permission required?

[positron]

The Microsoft 365 integration setup instructs to grant the Mail.Send application permission in the Azure Application, which is defined as "Allows the app to send mail as any user without a signed-in user."

From a least-privilege security perspective, this seems overly broad, and I am unable to identify any element of the integration for SSO or other features which engage in sending e-mail as a user. Also, this is the only permission requested which is not just a "Read" permission.

Can you help me understand the need for this permission to be assigned?

 

[NickD_3CX]

If you go to Settings --> Email, you will see this:

 

[positron]

So, if a different SMTP setting is configured, can the Mail.Send permission be removed from the Azure application?

 

[NickD_3CX]

As far as I am aware this permission is only used for this, so I would say yes, but, if you run into any problems, add it back and recheck.

 

[positron]

Ok, I removed/revoked Mail.Send and it seems ok.

 

[CodeTwo]

In that case you can use this: https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access to limit Mail.Send permission to specific mailbox.

 

[positron]

In that case you can use this: https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access to limit Mail.Send permission to specific mailbox.

Unfortunately, I don't think that will work with the rest of the 3CX integration. The Azure application needs permissions to read user info, calendar and contact data for users synchronized to 3CX, but the Mail.Send process is about selecting the identity used to originate messages. The application restrictions are not granular to specific data sets or methods, so it would not be possible to restrict just Mail.Send to a specific mailbox used by 3CX to send messages without also blocking access to all the other mailboxes for sync purposes.

 

[CodeTwo]

Unfortunately, I don't think that will work with the rest of the 3CX integration. The Azure application needs permissions to read user info, calendar and contact data for users synchronized to 3CX, but the Mail.Send process is about selecting the identity used to originate messages. The application restrictions are not granular to specific data sets or methods, so it would not be possible to restrict just Mail.Send to a specific mailbox used by 3CX to send messages without also blocking access to all the other mailboxes for sync purposes.

I did this in my infrastructure and it works pretty well without any issue. I only restrict access for Mail.Send permission to specific mailbox, all others permission are not limited.

 

[positron]

I did this in my infrastructure and it works pretty well without any issue. I only restrict access for Mail.Send permission to specific mailbox, all others permission are not limited.

Maybe I'm missing something in my read of New-ApplicationAccessPolicy. I only see where it applies to the application ID as a whole; I don't see options to apply granular permissions to just Mail.Send without applying the same restrictions to the full scope of the application.

 

[CodeTwo]

I forgot to mansion that I`m not using calendar and contact synchronization, this is why I`m not seeing any issue. But there is alternative method to limit application permission which I believe could be solution: Role Based Access Control for Applications in Exchange Online (Preview) | Microsoft Learn