Share via

Beyond RBAC: Delegating the 'Mail-enable Public Folders' right

  • Article

In the RBAC world, it should be possible to create a new management role, based on the built-in role "Mail-enable public folders." The built-in role allows delegates/members to run the enable-mailpublicfolder cmdlet. When you add users to the built-in role, they can execute assigned duties without incident. However, when you create a new management role, or attempt to add the built-in role to a non-built-in role assignement, the cmdlet fails. It fails with the following access denied error.

MapiExceptionNoAccess: Unable to set properties on object. (hr=0x80070005, ec=-2147024891)

You may also see several lines of diagnostic context.  It is my opinion that this is caused by a failure of the RBAC delegation model to adequately apply the necessary permissions in Active Directory to make the delegation work.  As evidence, I submit the following cmdlets that seem to validate a certain suite of permissions are necessary and granted to the built-in group "Public Folder Management."  We can look at the permissions on the store:

 

Get-PublicFolderAdministrativePermission "\" | where {$_.user -like 'root\public folder management'} | select accessrights

AccessRights
------------
{ViewInformationStore}
{AdministerInformationStore}
{ModifyPublicFolderACL}
{MailEnablePublicFolder}
{ModifyPublicFolderQuotas}
{ModifyPublicFolderAdminACL}
{ModifyPublicFolderExpiry}
{ModifyPublicFolderReplicaList}
{ModifyPublicFolderDeletedItemRetention}

and the complementary permissions in Active Directory appear to correspond.

Get-ADPermission -Identity "CN=ORG,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=root,DC=gov" | ?{$_.user -like "root\public folder management"}

AccessRights ExtendedRights
-------------- --------------
{GenericRead}
{ExtendedRight} {ms-Exch-Store-Create-Named-Properties}
{ExtendedRight} {ms-Exch-Store-Admin}
{ExtendedRight} {ms-Exch-Store-Visible}
{ExtendedRight} {ms-Exch-Create-Top-Level-Public-Folder}
{ExtendedRight} {ms-Exch-Modify-Public-Folder-Deleted-Item-Retention}
{ExtendedRight} {ms-Exch-Modify-Public-Folder-Replica-List}
{ExtendedRight} {ms-Exch-Modify-Public-Folder-Expiry}
{ExtendedRight} {ms-Exch-Modify-Public-Folder-Quotas}
{ExtendedRight} {ms-Exch-Modify-PF-ACL}
{ExtendedRight} {ms-Exch-Create-Public-Folder}
{ExtendedRight} {ms-Exch-Mail-Enabled-Public-Folder}
{ExtendedRight} {ms-Exch-Modify-PF-Admin-ACL}

To test my theory, I granted the same permissions (highlighted above in red) to my newly created delegate group using the following cmdlets.

Add-ADPermission "CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=root,DC=com" -user "root\Delegated Messaging Admins" -AccessRights GenericRead

Add-ADPermission "CN=OrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=root,DC=com" -user "root\Delegated Messaging Admins" -ExtendedRights ms-Exch-Mail-Enabled-Public-Folder

Logging off and back on, the delegation took and appears to be consistently working. I have been unable to get a confirmed answer on whether this practice is supported but given the ease with which it's implemented, and the consistency with which it works, I am okay with taking the risk that it may require additional modifications in future versions or service packs. 

This document is based on Exchange 2010 SP1.