The scenario: provisioning linked mailboxes in an Exchange resource forest (with the FIM Synchronization Service, Identity Lifecycle Manager, or Identity Integration Server).
The error: “This security ID may not be assigned as the owner of this object.”
The problem: It would appear that the issue is writing the msExchMasterAccountSid attribute however in reality it is as a result of the ExchangeUtils.CreateMailbox method actually updating the msExchMailboxSecurityDescriptor and nTSecurityDescriptor attributes.
The resolution: grant the management agent (MA) account performing the creation SeRestorePrivilege (Restore files and directories) on the domain controllers.
Modifying msExchMailboxSecurityDescriptor and nTSecurityDescriptor is evidently a security sensitive operation, and the underlying API requires SeRestorePrivilege –Restore files and directories in the GPEDIT.MSC tool. The account running the AD MA that creates the mailbox requires SeRestorePrivilege (Restore files and directories) on Domain Controllers. The reason the privilege is required on domain controllers and not the member servers hosting the mailbox databases is because the ACLs that are being written are against the AD user object.
ExchangeUtils::CreateMailbox(ConnectedMA, ReferenceValue, String, String, Byte) and ExchangeUtils::CreateMailbox(ConnectedMA, ReferenceValue, String, String, long, long, long, Byte, Boolean) actually updates the following attributes in addition to those you define against the connector (CSEntry) object:
You will likely be setting the following values:
- mDBUseDefaults (or mDBOverHardQuotaLimit, mDBOverQuotaLimit and mDBStorageQuota)
In addition to the usual distinguishedName, sAMAccountName, userPrincipalName, etc.
Either method needs to update the nTSecurityDescriptor such that the actual user (in the trusted domain) has access to the mailbox. Replacing this value during export requires SeRestorePrivilege.