Beyond RBAC: Delegating the ‘Mail-enable Public Folders’ right


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.

 

 

 


Comments (0)

Skip to main content