Exchange recipient administration overkill in ILM and FIM

You’ve probably all thought about this but might not have done anything about it.  That was true for me for three years too and then I finally had a customer goal that made me look into it properly (if a customer’s not paying I must confess to struggling to find the time to actually dig deeply into things).  What am I talking about?  Reducing the privilege required to perform Exchange recipient provisioning using the Active Directory Domain Services Management Agent (ADMA).  The default documentation on the subject clearly states that in order to provision mailbox-enabled users or linked mailboxes the ADMA account needs to be a member of the Recipient Administrators role group.  Now, while it’s true membership in that group will allow you to run Update-Recipient and successfully invoke the RUS after creating a user and stamping the mandatory Exchange attributes that same membership also grants you access to perform a multitude of recipient administration tasks that the account doesn’t need to perform.

In fact, if you look at the underlying Exchange Management Role ‘Mail Recipients’ you’ll notice there are 91 Management Role Entry objects associated with the role.  Translated that means that the role has access to 91 cmdlets whereas for the purpose of ILM and FIM provisioning we need one: Update-Recipient.

In order to follow the principal of least privilege it is essential that a custom management role be created that only has one management role entry and a new role group created and assigned to that management role.  After doing this the ADMA account can be removed from the Recipient Administrators role group and added to the custom role group.

Supportability

From a supportability standpoint the Exchange product group support the customisation and delegation of roles.  The FIM product group don’t test such granularity however I’ve raised a bug and Andreas informs me that in the future this will be tested and the documentation updated to reflect this.

Implementation

How to implement?  First we create a new management role.

001 002 003 004

# create a new management role based on the existing Recipient Administrators role New-ManagementRole `        -Name UpdateRecipientAccess `        -Parent “Mail Recipients”;

Figure 1: Create a new management role (New-ManagementRole)

Next we remove all management role entries from the new role except Update-Recipient.

001 002 003 004 005

# Remove all cmdlets from this role except Update-Recipient Get-ManagementRoleEntry `        -Identity UpdateRecipientAccess\* | ? {                $_.Name -ne ‘Update-Recipient’         } | Remove-ManagementRoleEntry;

Figure 2: Remove all cmdlets other than Update-Recipient (Remove-ManagementRoleEntry)

The management role is now configured.  A new management role has been completed and the only cmdlet that can be invoked by a principal that holds this role is Update-Recipient.  Next we create a new role group –an AD DS security group assigned to the management role.

001 002 003 004 005 006 007

# Create a new role group (AD DS SG) and add the AD MA account as the only member. New-RoleGroup `        -Name “Update-Recipient-Access” `        -Roles UpdateRecipientAccess `        -DisplayName “Recipient Update Service Invocation” `        -Description “Members of this role group can use the Update-Recipient cmdlet to invoke the Recipient Update Service (RUS)” `        -Members svcfimadma;

Figure 3: Create a new role group (New-RoleGroup)

Figure three creates a new AD SG called “Update-Recipient-Access” with a single member: an account called SVCFIMADMA.

At this point we’re done.  Remove the ADMA account (SVCFIMADMA in my example) from Recipient Administrators and validate that the ADMA still works.

Wrap-up

In this post I’ve shown you how to create a new role that is only able to use the Update-Recipient cmdlet and create a new role group assigned to that role.  This is one aspect of implementing a policy of least privilege.  Once I’ve deployed into live I will post about the minimum set of permissions required on the AD objects too –this obviously varies depending on what you’re synchronising but I’ll do a couple of posts on this over the next couple of months.

Oh and just in case it wasn’t clear the cmdlets and PowerShell examples above are Exchange 2010 cmdlets.  You have to run them from an Exchange management shell, i.e. you need to create an Exchange session like follows.

001 002 003 004 005 006 007 008 009

# establish an authenticated connection to Exchange using your # default (i.e. current) credentials. $session = New-PSSession `     -ConfigurationName Microsoft.Exchange `     -ConnectionUri http://ms1.corp.contoso.com/PowerShell/ `     -Authentication Kerberos; # import the powershell session into your client session Import-PSSession $session;

Figure 4: Create an Exchange 2010 PowerShell session using default credentials

Or using explicit, i.e. specified, credentials.

001 002 003 004 005 006 007 008 009 010

# establish an authenticated connection to Exchange using an # input (i.e. you are prompted) credential. $session = New-PSSession `     -ConfigurationName Microsoft.Exchange `     -ConnectionUri http://ms1.corp.contoso.com/PowerShell/ `     -Authentication Kerberos `     -Credential (Get-Credential); # import the powershell session into your client session Import-PSSession $session;

Figure 5: Create an Exchange 2010 PowerShell session using explicit credentials