In a Federated Sharing scenario, the Client Access servers in each organization should be able to establish an authenticated and secure connection with each other to enable the exchange of availability information or to enable calendar sharing. The Client Access servers use the federated trust that you configure with the Federation Gateway to verify the other organization’s Client Access servers and to encrypt all traffic sent between the organizations.
In Exchange Server 2010, you use the Microsoft Federation Gateway to establish the federation trust. The Microsoft Federation Gateway is an identity service that runs over the Internet and works as a trust broker for Federated Sharing. To enable Federated Sharing, the organization must register with the Microsoft Federation Gateway, and then configure a federated sharing relationship with another organization that also registers with the Federation Gateway.
When you enable Federation Sharing, all communications between organizations is sent through the organization’s Exchange Server 2010 servers. This communication is transparent to the messaging clients. This means that the feature works with any client that can connect to Exchange Server 2010, including Outlook Web Access, Outlook 2003, and Outlook 2007.
When configuring a sharing relationship is to enable users from one organization to view availability information for another organization’s users. The following steps describe the communication flow when you configure this option, and a user in one organization invites another organization’s user to a meeting.
- A user in the ABC.com organization invites a user in the XYZ.com organization to a meeting. This meeting request is sent to the Exchange Web Service on the Client Access server at ABC.
- The ABC Client Access server checks with a ABC.com domain controller to verify that the user has permission to utilize the sharing relationship to request availability information, and that a sharing relationship is configured with XYZ.com. If both verifications succeed, the Client Access server continues with the next step.
- The ABC Client Access server connects to the Microsoft Federation Gateway and requests a security token for the ABC user. Because you configure ABC.com in the organization identifier, the Federation Gateway issues the token.
- The ABC Client Access server sends a request for the availability information for the user to the A. Datum Client Access server. The ABC Client Access server includes the security token with the request.
- The A. Datum Client Access server validates the security token and then checks with a domain controller in the XYZ.com domain to verify that the organization has a sharing relationship with ABC.com.
- The A. Datum Client Access server retrieves the user’s availability information from the user’s Mailbox server.
- The A. Datum Client Access server sends the availability information to the ABC Client Access server.
- The ABC Client Access server provides the availability information to the ABC user.
Before you can configure a sharing relationship with another organization, both organizations must configure a federation trust with the Microsoft Federation Gateway.
Before configuring the federation trust, you must ensure that your organization meets the following prerequisites:
- Obtain a trusted certificate. Setting up a federation trust with the Federation Gateway requires a certificate from a public certificate authority (CA) that the Federation Gateway server trusts. The certificate requires a private/public key pair that is both a client and server certificate, and requires a Subject Key Identifier. This certificate must be deployed on all Exchange Server 2010 Client Access servers. The associated name of the certificate is not relevant to federation, so you can reuse an existing certificate on the Client Access server if the certificate is trusted. The private/ public key pair associated with the certificate signs and decrypts delegation tokens that the Federation Gateway issues.
- Configure the authoritative domains. You must configure all SMTP domain names that you want to use for Federated Sharing as authoritative accepted domains in Exchange.
- Configure external DNS records. To enable Federated Sharing, you need to ensure that servers from other organizations can resolve your server’s names on the Internet. Additionally, you need to configure DNS with a text (TXT) resource record that provides proof-of-ownership for your domain name. The Federation Gateway uses the proof-of-ownership record to ensure that your servers are authoritative for the domain name that you provide. To create this proof-of-ownership record, you need to:
- Obtain the application identifier that is created when you create a federation trust. You can obtain this identifier by running the Get-FederationTrust –Identity ‘FederationTrustName’ | fl ApplicationIdentifier cmdlet.
- Create a new TXT record on the DNS server that is accessible from the Internet. The TXT record should include the following information:domainname IN TXT AppID=ApplicationIdentifier.
Setting Up the Federation Trust with Microsoft Federation Gateway
You can set up and manage the federation trust by using the Exchange Management Console or the Exchange Management Shell. On the machine where you run these tasks, you should deploy the certificates that federation should use. The machine also needs to have Internet connectivity to reach Microsoft Federation Gateway.
If you are using the Exchange Management Console, click the Organization Configuration node, and then click New Federation Trust to start the New Federation Trust wizard. When you run the wizard, you must configure a certificate that will validate the trust. When you use the Exchange Management Console to create the federation trust, it receives the name “Microsoft Federation Gateway” automatically.
If you are using the Exchange Management Shell, run the New-FederationTrust –Name TrustName -Thumbprint <org-cert-thumbprint> cmdlet.