SharedMailbox SendOnBehalf Permission Failure

We have setup AzureAD Connector with EXO Management enabled in IIQ 8.4 for managing Shared Mailboxes. We are able to aggregate/provision Shared Mailboxes with FullAccess and SendAs Permissions successfully. However, this is not working with SendOnBehalf Permission. Any ideas how we can provision/aggregate this SendOnBehalf permission from IIQ. Below is the provisioning error for this permission:

Cannot process argument transformation on parameter ‘AccessRights’. Cannot convert value “System.Collections.Generic.List`1[System.String]” to type “Microsoft.Exchange.Management.RecipientTasks.MailboxRights”. Error: “Unable to match the identifier name SendOnBehalf to a valid enumerator name. Specify one of the following enumerator names and try again: FullAccess, SendAs, ExternalAccount, DeleteItem, ReadPermission, ChangePermission, ChangeOwner”

Hi @jai_l Just throwing this out there, because I’m not sure I can remember the specifics, but if EXO is like On-Prem, the Send On Behalf Of permission is actually on the User object associated with the Mailbox not the Mailbox itself (as the delegate doesn’t need to access the actual Mailbox). Don’t know if that helps, but maybe could point you in the right direction.

@jai_l AFAIK SendOnBehalf is a multi valued user attribute. Have you tried adding it at account schema?

Hi, I have the same question. I’ve tried to add an new attribute to the schema called “SendOnBehalf” with the same configurations as the “sharedMailbox” but it doesn’t aggregate any attribute.

Thank you

Hi @ancardoso try using “sendOnBehalf”; I believe it is case-sensitive.

Hi @jai_l can you post the provisioning plan that is failing?

Hi @paul_hilchey I’ve updated the application as suggested, but unfortunately no success.
Here is an print of the application schema:

@ancardoso Is it possible for you to share the complete app xml ?

HI All. As I said above, SendOnBehalf is not a permission like FullAccess or SendAs, it is based on Delegate functionality. I believe you could provision it via PowerShell, but I’m not aware you can aggregate it using IIQ.

SendOnBehalf appears to be supported for on-premise AD, but not for Azure AD. :frowning:

Thank you for all the replies. I’ve contacted Sailpoint directly and indeed the SendOnBehalf entitlements will not be created on the account aggregation.

As referenced in the documentation the entitlements created during the aggregation are:

  • Recipient: SendAs

  • Mailbox: ChangeOwner, ChangePermission, DeleteItem, ExternalAccount, FullAccess, ReadPermission

Hello everyone,

thanks for your responses/analysis/efforts on this issue. Yes, although SailPoint confirms that SendOnBehalf is not supported by connector, we have found that entra id connector do support this feature but through a dedicated attribute called EXO_GrantSendOnBehalfTo and not with “sharedMailbox” attribute, which FullAccess and SendAs is currently using. We were able to successfully provision/aggregate SendOnBehalf permission through connector itself without any customizations.

We handle it by adding the new schema attribute with EXO_GrantSendOnBehalfTo .
We tried provisioning it in AttributeRequest (Add/Remove with user ObjectIds), and also verified at exchange center, the members are getting added to SendOnBehalf.

The account request for SendOnBehalf provisioning looks like below:

accReq.setNativeIdentity(“00267f67-xyz-4aab-xxxx-39dc0cf3e47e”); → this is native identity (entra id objectId of the shared mailbox )

accReq.add(new AttributeRequest(“EXO_GrantSendOnBehalfTo”, ProvisioningPlan.Operation.Add, “00294848-xxxx-xyz-xx-98d0f7b9aa62”));

00294848-xxxx-xyz-xx-98d0f7b9aa62 → belongs to the entra id objectId of the Identity for whom SendOnBehalf access is needed.

you can find more details and snapshots here at → https://ideas.sailpoint.com/ideas/IIQ-I-1629

We can also mark this attribute managed, entitlement to have entitlement created in the catalog.

Thanks for your time and I hope this workaround helps.