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.
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.
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.
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:
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.