Exchange federation trust – part 1.

I need to configure federation trust between two organizations, but what is federation trust? It is secure trusted connection of separate organizations, which need to share their internal data (From Exchange point of view it is Calendar,Free/busy and contact information and others (see Set-OrganizationRelationship) without a need of establishing special Forests/Domains trusts, VPN connections or buying expensive synchronization servers.

Federation trust works based on free Microsoft cloud service Microsoft Federation Gateway. Microsoft Federation Gateway acts like middle authority, with which all Exchange organizations need to establish one time trust before those will be able to communicate with each-other. After one time trust is established, Microsoft Federation Gateway issues SAML tokens for users, which requests to get information about users from federated Exchange organization. These tokens are then trusted by fedetated partners and contain info about user e-mail address, immutable (constant) number and action to which token is issued for.
If we imagine the description above, all Exchange organizations will be trusted with Microsoft Federation Gateway, but it will not allow it to communicate with each-other, before 1:1 trust relationship “Organization Relationship” is not established between 2 Exchange organizations. Organization Relationship connects 2 Exchange organizations and allow them to share data defined by Sharing policies.

In first part of article I will go through prerequisites, you need to start configuring Federation trust, actual configuration of Federation trust with Microsoft Federation Gateway, Configuring of Organization identifier. Preparation for configuration of Organization relationship will be part 2 of this series. Reason is simple. I don´t have DNS records in place during the time writing this article.

For full technology description please visit MS Technet


  • Autodiscover and EWS virtual directories must be published to internet (or in case internal connection exists between your organizations, these must be accessible in both directions)
  • Federation trust needs to have WSSecurity authentication in place on EWS and Autodiscover virtual directories

Run the following commands to check if all of these are in place:

Get-ClientAccessServer | Get-WebServicesVirtualDirectory |select *auth*

CertificateAuthentication     :
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
LiveIdNegotiateAuthentication :
WSSecurityAuthentication      : True
LiveIdBasicAuthentication     : False
BasicAuthentication           : False
DigestAuthentication          : False
WindowsAuthentication         : True
OAuthAuthentication           : True
AdfsAuthentication            : False

Get-ClientAccessServer | Get-AutodiscoverVirtualDirectory |select *auth*

InternalAuthenticationMethods : {Basic, OAuth}
ExternalAuthenticationMethods : {Basic, OAuth}
LiveIdNegotiateAuthentication : False
WSSecurityAuthentication      : False
LiveIdBasicAuthentication     : False
BasicAuthentication           : True
DigestAuthentication          : False
WindowsAuthentication         : False
OAuthAuthentication           : True
AdfsAuthentication            : False

As you can see in the result, AutoDiscover virtual directory doesn´t have WSSecurity authentication enabled. To enable it use the command below followed by IIS reset.

Get-ClientAccessServer | Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication $true

After these are ready, we can continue configuring Federation trust.

Federation trust

  • To get Federation trust working we need to generate self-signed certificate with unique Subject Key Identifier. This certificate will be used to sign and encrypt delegation tokens  (3rd party sign certificate can be used too, but why if we can use free self-signed one with longer validity period).

First command generates unique SKI, second generates the certificate

$ski = [System.Guid]::NewGuid().ToString("N")
New-ExchangeCertificate -FriendlyName "Exchange Federated Sharing" -DomainName "" -Services Federation -KeySize 2048 -PrivateKeyExportable $true -SubjectKeyIdentifier $ski

Next command creates Federation trust, but we are not able to communicate with MFG yet.

Get-ExchangeCertificate | ?{$_.friendlyname -eq "Exchange Federated Sharing"} | New-FederationTrust -Name "Microsoft Federation Gateway"

To be able to communicate with MFG we must proove, that domains , which will be defined in Federation Organization Identifier are owned by us. This is accomplished by adding HASHES as TXT records to our DNS.
Hashes can be gathered by the following commands. Domain is used to create namespace for communication between organizations and to be honest I am not sure if this hash needs to be in place, but I put it there to be sure it works.

Get-FederatedDomainProof -DomainName

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
DomainName :
Name       : OrgPrivCertificate
Thumbprint : 82E68E80B61290475025A0E9737FECE922D4E8C3
Proof      : EmJKFNW+frdgGM+fkDZyKE+nbJzdRaouCKM2NHNzIjgVPB6TuwlEmWdqxCa1BWuxfTth+Do2R+fLLbbahTWmLg==
DnsRecord  : TXT IN 

Get-FederatedDomainProof -DomainName

The format of DNS records is as follows: TXT IN <hash>

And live example is TXT IN iE64T7bsM8auQUYoAD/Dc/+sEAieDjG6gJFkGvZRIvyb+5FiwjCQY8BiIrrwafVUr7r3VdyAOXm9F/eb0R8kuA==

After hashes are in external DNS, we can set Federated Organization Identifier. It defines which domains of our organizations will be enabled for federation and what federation trust it will use.
Before setting of Federation identifier we get the following results


RunspaceId          : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
AccountNamespace    : missing
Domains             : missing
DefaultDomain       : missing
Enabled             : False
OrganizationContact : 
DelegationTrustLink : 
Identity            : Federation
IsValid             : True
ExchangeVersion     : 0.10 (
Name                : Federation
DistinguishedName   : CN=Federation,CN=SalonoviMail,CN=Microsoft 
Guid                : 3a69e332-7156-4251-856c-f3cc17853e39
ObjectCategory      :
ObjectClass         : {top, msExchFedOrgId}
WhenChanged         : 1/7/2013 7:18:04 PM
WhenCreated         : 11/29/2011 9:21:30 PM
WhenChangedUTC      : 1/7/2013 6:18:04 PM
WhenCreatedUTC      : 11/29/2011 8:21:30 PM
OrganizationId      : 
OriginatingServer   :
ObjectState         : Unchanged

Get-FederationInformation -DomainName
Federation information could not be received from the external organization.
    + CategoryInfo          : NotSpecified: (:) [Get-FederationInformation], GetFederationInformationFailedException
    + FullyQualifiedErrorId : D04C5818,Microsoft.Exchange.Management.SystemConfigurationTasks.GetFederationInformation
    + PSComputerName        :

Federated Organization Identifier

Set-FederatedOrganizationIdentifier -Enabled $true -DefaultDomain -AccountNamespace -DelegationFederationTrust "Microsoft Federation Gateway"

Final step is to test if Federation Trust is working. I use verbose parameter to troubleshoot but in this example I was lucky and all worked as expected at first glance.

Test-FederationTrust -UserIdentity

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : FederationTrustConfiguration
Type       : Success
Message    : FederationTrust object in ActiveDirectory is valid.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : FederationMetadata
Type       : Success
Message    : The federation trust contains the same certificates published by the security token service in its 
             federation metadata.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : StsCertificate
Type       : Success
Message    : Valid certificate referenced by property TokenIssuerCertificate in the FederationTrust object.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : StsPreviousCertificate
Type       : Success
Message    : Valid certificate referenced by property TokenIssuerPrevCertificate in the FederationTrust object.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : OrganizationCertificate
Type       : Success
Message    : Valid certificate referenced by property OrgPrivCertificate in the FederationTrust object.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : TokenRequest
Type       : Success
Message    : Request for delegation token succeeded.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : TokenValidation
Type       : Success
Message    : Requested delegation token is valid.

Next part comes soon (tomorrow) continuing with setting 1:1 relationships.


10 thoughts on “Exchange federation trust – part 1.

  1. Pingback: Exchnage 2010 SP3 and Exchange 2013 RTM coexistence issue | FICILITY.NET

    • Hi Jason, thanks for your comment. I plan to do second part of article till the end of next week. I have some issues, because my lab is under NDA (coexistence between Exchange 2010 and 2013) and due to coexistence I have some minor issues to make it work correctly.

  2. Hello zbycha
    Thanks alot
    I have configured and shared calender using microsoft federation gateway. I can share the calender between different domain. On the recipient side he can view the calender, but calender is blank , no events at all . I tried to configure by changing the sharing policy but same result.
    any help would be appreciated

    • Hello,

      thanks for comment. Please send me your sharing policy config output and some printscreens to my mail Quicky thinking I believe you should set authenticated user level of access on the site, which is sharing calendar to level FreeBusy.

      Regards Zbynek

      • Hello,

        first of all, great Blog. I have the Same Problems like “Anoop Ravi”. How did you solve the errors from him/her

      • Hello,

        Thanks for your comment. I appreciate that. in Anoop´s case it was setting authenticated user level of access on the site, which is sharing calendar to level FreeBusy. Please send me your Sharing policy to my email (same as in Anoop´s case and let me check).

        Regards Zbynek

  3. Finally somebody writes a good Federation explanation in plain easy to read English language instead of that stupid Microsoft-Technet articles language that looks like the Star Trek Klingons wrote it and (normal) humans have difficulty to understand. Thank you from Vancouver Canada.

Leave a Reply

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

You are commenting using your 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