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

Advertisements

About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in FIM, FIM 2010, FIM 2010 R2 and tagged , , , , , , , , , , . Bookmark the permalink.

4 Responses to Exchange recipient administration overkill in ILM and FIM

  1. Pingback: Delegating the minimum set of permissions for mailbox-enabled user and linked mailbox provisioning | Yet another identity management blog

  2. Ossian says:

    Great post – exactly what I was looking for, however we are still using exchange 2007. Could this work in a mixed environment?

  3. I pinged an Exchange SME colleague in the hope of providing you an accurate yes or no answer but he’s currently ignoring me. 🙂

    I’m not in a position to test but would guess that the answer is yes, this will work. However there are going to be some caveats. For example, http://technet.microsoft.com/en-us/library/dd335157.aspx, tells us that “Exchange 2010 permission assignments are separate from Exchange 2007 permission assignments. This is true even if both versions of Exchange are installed in the same forest. Without additional configuration, Exchange 2010 administrators don’t have the required permissions to manage Exchange 2007-based servers, and Exchange 2007 administrators don’t have the required permissions to manage Exchange 2010-based servers.”

    But we’re not managing servers we’re managing recipients.

    If you have a mixture of Exchange 2007 and 2010 servers you can define Exchange 2010 provisioning and point FIM to the remote PowerShell interface on your e2k10 CAS array and forget about the Exchange 2007 servers.

    If you have a mixture of Exchange 2003, 2007 and/or 2010 then you can choose to not use Exchange provisioning at all and instead let the e2k3 RUS handle the process.

    If my colleague replies with a sensible answer I will post another comment. I can’t commit to testing a mixed mode Exchange implementation as I’m a FIM, AD FS and AD DS guy and I would burn time building out a mixed mode Exchange topology.

  4. Pingback: Note-to-self: Exchange recipient administration rights in ILM/FIM/MIM | Identity Underground

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s