Exchange RBAC might be more granular than you think
Most Exchange admins probably know (or should know ) the permission model since Exchange 2010 is Role Based Access Control, RBAC for short. With it, you can regulate quite granularly what admins and end-user are able to do, without the hassles of Access Control Lists (ACLs).
However, it recently became clear that it might be more granular than you think. You can allow only certain types of PowerShell Cmdlets, have only change rights on a certain Organizational Unit (OU)or types of users etc. etc. But did you know you can also control access to certain parameters of Cmdlets instead of allowing or blocking a whole Cmdlet?
Consider the scenario that you want to give a certain servicedesk employee rights to edit mailboxes with Set-Mailbox, but for whatever reason you don’t want them to edit quota settings?
Here’s how you do it:
We start off by making a new ManagementRole based on the default created “Mail Recipients” role with the New-ManagementRole Cmdlet. You could make a brand new ManagementRole and add in all the required Cmdlets, but the default is close enough for this situation:
New-ManagementRole -Name “Mail Recipients No Quota” -Parent “Mail Recipients”
So, now we have a new ManagementRole, but we have to edit what it’s members are allowed to do with the Set-Mailbox Cmdlet. We want to remove any parameter related to quotas and we can do that with Set-ManagementRoleEntry and its -RemoveParameter option:
Set-ManagementRoleEntry -identity “Mail Recipients No Quota\Set-Mailbox” -Parameters IssueWarningQuota, ProhibitSendQuota, ProhibitSendReceiveQuota, UseDatabaseQuotaDefaults -RemoveParameter
Isn’t RBAC great?
#Edit 2013.11.11: I’ve noticed (after writing and publishing this one) that I already wrote a post about customizing RBAC almost two years ago, in which I even used the same example . The focus was a bit different, so it’s still a good additional read: Handing out only Send-as permissions with Exchange 2010 RBAC