Exchange Server 2010 Cross Forest Delegation

This has been an interesting bit of work for me.  I have been working with a customer who really needed to provide their users with the ability to manage calendars across different Exchange organisations.  When they initially presented this requirement to me, my first thought was that we would be able to provide cross-forest availability sharing but that cross-forest delegation was not going to be possible…

So, as with most projects like this I began by asking my colleagues and quickly discovered that some thought it was possible and some thought it wasn't.  This at least gave me the incentive to dig a little deeper to determine what we could and couldn't achieve.  This digging discovered a few articles about ILM FP1 SP1 and FIM that showed a check box called “support cross-forest delegation (Exchange 2007 or 2010 only)”…

A little more research suggested that given a few pre-requisites it should be possible to achieve cross-forest delegation for Outlook users.  This article will briefly go through the required steps and link to further information to assist with configuration…

Prerequisite requirements

To get cross-forest delegation to work the following prerequisites must be met…

• Forest Trust between Forests
• Cross-Forest Availability Configured
• GALSYNC configured with either ILM FP1 SP1 or FIM 2010 (or manual cross-forest mail contacts created)
• Exchange Server 2007 SP1+
• Outlook 2007 SP1+

 

Forest Trust

Before we continue we need to establish a forest trust between the forests…

• https://technet.microsoft.com/en-us/library/cc780479(WS.10).aspx 

Cross-Forest Availability

The next step is to establish cross-forest availability.  This provides users availability data between exchange organisations.

Note: The documentation in TechNet regarding cross-forest availability is particularly difficult to follow. Where the examples contain reference to the “Client Access Servers” group you must either create this group and add in your CAS servers or simply use “Exchange Servers” instead. Additionally the steps assume that your CAS servers are using public certificates that are trusted – if you are using an internal PKI CA you must ensure that all of your CAS servers trust the root CA.

• https://technet.microsoft.com/en-us/library/bb125182.aspx

Here is my short-cut version of that guidance…

Run In the source forest

• Add-AvailabilityAddressSpace -ForestName "TargetSMTPnamespace.com" -AccessMethod PerUserFB -UseServiceAccount $true

Run In the target forest

• Get-ClientAccessServer | Add-AdPermission -AccessRights ExtendedRight -ExtendedRights "ms-exch-epi-token-serialization" -User "Source Forest\Exchange Servers"

Note: You must perform these steps in both forests for a 2-way configuration

Configuring cross-forest Autodiscover

• $a = Get-Credential <Enter Administrator credentials in the remote forest when prompted>
• Export-AutoDiscoverConfig -DomainController <Local GC> -TargetForestDomainController <Target GC> -TargetForestCredential $a -MultipleExchangeDeployments $true

So, by the time we get here it should be possible to lookup availability data for a user in the other forest.

GALSYNC

This is where the secret sauce happens for cross-forest delegation.  Basically we are going to use FIM in this example to read in mailbox objects from each forest and create contacts in the target forest to build a common GAL for both Exchange Organisations. 

The official guidance for configuring this is available here, however I have included my steps as well below

• https://technet.microsoft.com/en-us/library/aa998597.aspx

The steps I follow are as follows…

Note: I generally create an OU in each forest called Contacts to receive contacts from FIM. These steps assume that you have created this OU already.

1. Open Synchronisation Service Manager (FIM)
2. Click on Management Agents
3. On the Actions Menu, click Create
4. Select Active Directory global address list (GAL) from the Management Agent drop down
5. Enter a name for this MA and click Next
6. Enter the forest name and credentials that this MA will retrieve information for and click next
7. In Select directory partitions enable the checkbox for the root of the forest
8. Click on Containers
9. Deselect all OU’s and manually select OU’s that contain mailboxes + ensure that the Contacts OU is checked and click ok
10. Click Next
11. Click Target, Click Container and Check the Contacts OU and click Ok
12. Click Source, Add Containers and check all OU’s that contain mailboxes, then click OK
13. Under Exchange configuration, click Edit, Add in the SMTP namespace you want the contacts to use that are created for this forest, click Add and finally OK
14. Check Route mail through this forest for all contacts created from contacts in this forest
15. Check Support cross-forest delegation (Exchange 2007 or 2010 only)
16. Click Next
17. Click Next until the Configure Extensions page is displayed
18. In the Exchange 2010 RPS URI: Enter https://<CAS Server>/Powershell
19. Click Finish

Repeat these steps for all forests.

Note: By default ILM and FIM have provisioning disabled, to enable provisioning click on Tools, Options and check the Enable Provisioning Rules Extension checkbox.

Once all MA’s have been created run the following profiles (Right click on the MA, select RUN)

1. Full Import (Staging Only)
2. Full Synchronization
3. Export
4. Delta Import

Finally check the contacts OU in each forest to ensure that FIM has populated it with contacts from the remote organisation.  If there are problems, the first thing to do is check the event logs on the FIM server to begin troubleshooting…

User Experience

By this point you should now have a common global address list amongst your Exchange Organisations and if you look into the Contacts OU it should be populated with contacts from the remote organisations.  If you look in the Exchange Management Console you should see that the contacts have been created as a Recipient Type of Cross-forest mail contact.  This recipient type means that you can use this contact to assign delegate permissions.

In my lab I have two Exchange Organisations in two Forests

• org4.lab (org4user1)
• org5.lab (org5user1)

As a test I am going to delegate calendar editor permissions over org4user1’s to remote user org5user1.  I did this simply by opening the delegates tab on org4user1’s mailbox and tagged in the contact for Org5user1. 

I then logged on to the org5user1’s mailbox and attempted to open org4user1’s calendar.  This worked as expected, so I then attempted to make changes to the shared calendar, again which worked as expected! result

Manually Creating a cross-forest mail contact

So this is an interesting exercise (interesting is relative here obviously, but lets go with it for now!).  My current customer does not have FIM or ILM deployed to synchronise contacts between forests, however they wanted to enable cross forest delegation for a few users.  We have a project planned to deploy FIM to solve this issue strategically but due to the importance of some of the users affected they really pushed me to come up with a temporary solution for cross-forest delegation.

My solution to this was to perform all of the configuration for cross-forest availability and then to manually create the cross-forest mail contacts in the target forest.  The challenge of course was how to create a cross-forest mail contact!

After some investigation the following attributes looked to be of interest…

• mAPIRecipient = TRUE
• msExchMasterAccountSID = objectSID from Mailbox
• msExchOriginatingForest = Target Forest FQDN
• msExchRecipientDisplayType = –1073741818
• msExchRecipientTypeDetails = 32768
• proxyAddresses = X500: + LegacyExchangeDN from Mailbox; existing addresses

Here is an example…

Source Mailbox Attributes for Org4User1@org4.lab

• legacyExchangeDN: /o=Org4/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Org 4 User 1;
• mail: Org4User1@org4.lab ;
• mailNickname: Org4User1;
• objectSid: S-1-5-21-1575148580-663765585-2685387708-1129;

Cross-forest mail contact attributes for Org4User1@org4.lab

• legacyExchangeDN: /o=Org5/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Org 4 User 1;
• mail: Org4User1@org4.lab ;
• mailNickname: Org4User1;
• mAPIRecipient: TRUE;
• msExchMasterAccountSid: S-1-5-21-1575148580-663765585-2685387708-1129;
• msExchOriginatingForest: org4.lab;
• msExchRecipientDisplayType: -1073741818;
• msExchRecipientTypeDetails: 32768;
• proxyAddresses (2): X500:/o=Org4/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Org 4 User 1; SMTP:Org4User1@org4.lab;
• targetAddress: SMTP:Org4User1@org4.lab;

 

Conclusion for Cross Forest Delegation in Exchange Server

I must admit that I did feel like I had missed a day at school when I first started this.  For me this is a huge feature area that is pretty poorly documented and even the fact that you can do cross-forest delegation is relegated to a one liner in TechNet under the cross forest implementation section.

However, the user experience is absolutely great once this is configured and in fact it is difficult to tell which organisation a user is from simply by the features you have enabled, i.e it doesn't really matter to a user where the people are that they are collaborating with, everything just works.

Update: Quite a few people have asked me about licensing for FIM when used only for GALSYNC. My understanding here is that the GALSYNC MA is free of charge and so the only thing you need to purchase is the FIM Server License (no CAL’s are required) + Server + SQL licenses.

This functionality was first made available in ILM FP1 SP1 and works with Exchange 2007 SP1 and Exchange 2010.  The clients need to be Outlook 2007 or above.

Comments

• Anonymous
  January 01, 2003
  Well done, thanks for clarifying this obscure feature set... :) Following this I created a new cmdlet(-like script named Enable-CrossForestMailContact USAGE: Enable-CrossForestMailContact.ps1 -Identity john.doe@tailspintoys.com -LinkedUser TAILSPINjohn.doe -LinkedForest tailspintoys.net I'll share it as soon as I think it passed some qualification tests for a customer who need this Quick notes: I don't believe syncing the legacyDN as proxy is really needed in that case (i'm thinking it may be needed eg: when needing to reply to a mail in a cross-delegated mailbox ...)

• Anonymous
  January 01, 2003
  Good one !

• Anonymous
  February 01, 2012
  Thanks for this great article.  Do you know if its possible to have the GAL sync objects be mail enabled users, rather than mail contacts?  I already have mail enabled users for the remote users who need delegated access for different use case.  So, I can't create a contact with the same SMTP address.  All of the availability steps are working, and I can assign delegate permissions, but the remote user can only read the calendar, not write (despite having Owner permissions).  Thanks.