Share via

Exchange 2010 Federation Part I

  • Article

So we must be talking about Identity Management. Nope.

In this case we are talking about federating calendars between on-premises and cloud services such as Outlook Live and Exchange Online (when our back-end moves to Exchange 2010). This can also be used to share calendars between your school and partners to shared their availability information (free/busy) for scheduling meetings.

In previous editions of Exchange we had to use tools like the inter-org replication tool to provide this type of integration as well as Active Directory Trust in both ways which most times has been undesirable with 3rd parties or even within school systems.

In Ex2007 we were able to change the entire model from system folder (free/busy) to looking at experiences with Exchange Web Services (EWS), availability Services, and the Client Access Server (CAS). So to configure availability services between forest you could do this:

Add-AvailabilityAddressSpace -ForestName "contoso.edu" -AccessMethod PerUserFB -UseServiceAccount $true

More info on this can be found here.

So now we jump to light speed and we now have “Federated Sharing”. So yes it’s federated but no it’s not identity management. This now allows use to enable users to share information with recipients with external federated organizations such as (Outlook Live, Exchange Online). Federating Sharing uses the Microsoft Federation Gateway (MFG), as the trust broker between two federated organizations.

Notes: Exchange Server 2010 uses Microsoft Federation Gateway (MFG), an identity service that runs in the cloud, as the trust broker. The trust allows users authenticated by Active Directory , known as the identity provider (IP), to be issued Security Assertion Markup Language (SAML) delegation tokens by MFG. The delegation tokens allow users from one federated organization to be trusted by another federated organization. With MFG acting as the trust broker, organizations are not required to establish multiple individual trust relationships with other organizations.

The requirements for this with Outlook Live and Exchange Online are the following:

An Exchange 2010 Client Access Server (CAS) exists in the Exchange organization

A Federation Trust has been created

The Federated Organization Identifier (OrgId) has been configured. Domains used for generating users' e-mail addresses have been added to the OrgId.

STEP 1 – Setting up Federation

To setup federation sharing the customer is required to use a public cert with these requirements for integration with the MFG.

Trusted Certification Authority The certificate must be signed by a trusted certification authority (CA). For a list of trusted certification authorities, see Trusted Root Certification Authorities For Federation Trusts [ https://technet.microsoft.com/en-us/library/ee332350(EXCHG.140).aspx ] .

Subject Key Identifier The certificate must have a Subject key Identifier (SKI) field. Most X.509 certificates issued by commercial certification authorities have a SKI.

CryptoAPI CSP The certificate must use a CryptoAPI cryptography service provider (CSP). Certificates that use CryptoAPI Next Generation (CNG) providers are not supported for Federation. If you use Exchange to create a new certificate request, a CryptoAPI provider is used.

RSA signature algorithm The certificate must use RSA as the signature algorithm.

Exportable Private Key The private key used to generate the certificate must be exportable. You can specify that the private key of a certificate be exportable when you create the certificate request using the New Certificate wizard in EMC, or the New-ExchangeCertificate [ https://technet.microsoft.com/en-us/library/aa998327(EXCHG.140).aspx ] cmdlet.

Current certificate The certificate must be current. You can't create a Federation Trust using a certificate that is expired or revoked.

Enhanced Key Usage The certificate must include the Enhanced Key Usage type Client Authentication (1.3.6.1.5.5.7.3.2) . This usage type is inteded for the purpose of proving your identity to a remote computer. If you use Exchange tools to generate the certificate request, this usage type is included by default.

Since the certificate is not used for authentication, it does not have any subject name or subject alternative name requirements. You can use a certificate with a subject name that is the same name as the hostname, the domain name, or any other name. Only one certificate is required for the Federation Trust. Exchange automatically distributes the certificate to other Exchange 2010 servers in the organization.

Now that we have a cert I’ll talk about configuration with gateway in Part II.

Comments

  • Anonymous
    January 15, 2011
    technet.microsoft.com/.../dd335047.aspx indicates that a self-signed certificate is valid: Certificate Requirements for Federation To establish a federation trust with the Microsoft Federation Gateway, either a self-signed certificate or an X.509 certificate signed by a certification authority (CA) must be created and installed on the Exchange 2010 server used to create the trust Can you clarify?