Exchange Server 2010 : Configuring Federated Sharing (part 1) - Implementing Federated Sharing

1. Implementing Federated Sharing

With federated sharing, you can use federation technologies to establish trusted relationships and hence enable secure Internet communications between organizations. This requires that you use Microsoft Federation Gateway as a trust broker, that each participating organization establish and manage its trust, and that federated sharing is supported for all messaging clients. To establish a federation trust, organizations exchange security certificates with public keys with each other or with a trusted third party and use those certificates to authenticate and secure all interorganizational communications.

1.1. The Microsoft Federation Gateway

The Microsoft Federation Gateway is an identity service that runs over the Internet and functions as a trust broker for federated sharing. It provides a broker service to establish the communication between the organizations but does not authenticate individual users or store any user account information from either organization.

To enable federated sharing, you need to register your organization with the Federation Gateway and then configure a federated sharing relationship with another organization that also registers with the Federation Gateway. The Federation Gateway then acts as a hub for all connections that the organizations make with each other, For example, Client Access servers in each organization connect through the Federation Gateway to exchange availability information and enable calendar sharing. These Client Access servers use the federated trust that you configure with the Federation Gateway to verify you partner’s Client Access servers and to encrypt traffic sent between the organizations. Users can also send encrypted and authenticated email messages between the organizations.

In federated sharing, each organization needs only to manage its trust relationship with the Federation Gateway and its own user accounts. After an organization establishes a trust relationship with the Federation Gateway, you can identify other trusted organizations and the types of information you want to share with them. When you enable federation sharing, all interorganizational communication is sent through your organization’s Exchange Server 2010 servers. This traffic is transparent to the messaging clients so that federated sharing works with any client that can connect to Exchange Server 2010, including Microsoft Outlook Web Access, Outlook 2003, Outlook 2007, and Outlook 2010.

To implement federated sharing, you need to establish and configure the following components in Exchange Server 2010:

• A federation trust A federation trust configures the Federation Gateway as a federation partner with the Exchange Server organization, which enables Exchange Server 2010 Web Services on the Client Access servers to validate all Federation Gateway authentication requests. You establish a federation trust by submitting your organization’s public key and a valid X.509 certificate issued by a Certificate Authority (CA) trusted by Windows Live Domain Services to the Federation Gateway and downloading the Federation Gateway public key and certificate.

• An organization identifier An organization identifier defines what authoritative domains in an Exchange organization are available for federation. If your organization supports multiple SMTP domains, you can include one or all of your domain names in your organization identifier. Users can participate in Federated Sharing only if they have email addresses in the domains that you configure with the organization identifier. The first domain you specify with the organization identifier is known as the account namespace. Federation Gateway creates federated user identifiers within this namespace when the Client Access server requests a delegation token for a user. This process is transparent to the Exchange Server organization.

  ---

  Note:

  OBTAINING THE ORGANIZATION IDENTIFIER OF AN EXTERNAL ORGANIZATION

  The organization identifier of your own organization consists of the authoritative domains that you specify when configuring federated sharing. To obtain the organization identifier of the external organization in a federation partnership, you use the Get-FederationInformation EMS cmdlet. This is discussed later in this lesson.

  ---

• Sharing relationships with the organizations with which your organization shares data In your Exchange Server organization, you configure a sharing relationship that defines a partnership for federated sharing with an external Exchange organization. You specify the target domains configured as the organization identifier in the external Exchange organization. When you configure a sharing relationship, you can define what information your users can share with external users and which users can participate in the relationship.

Note:

THE FEDERATION GATEWAY AND MICROSOFT WINDOWS LIVE

Although the Federation Gateway uses Windows Live as the authentication mechanism, it does not share any user accounts with Windows Live.

1.3. Accessing Availability Information

You can configure a sharing relationship that enables users from one organization to view availability information for users in another organization. Suppose, for example, that a User in Blue Sky Airlines wants to set up a meeting with a user at Consolidated Messenger and issues a meeting request. The following occurs:

1.4. Federated Message Delivery

When you configure a sharing relationship, you can enable federated message delivery. This permits users from one organization to send encrypted, authenticated email messages to users in another organization. When, for example, a user in Blue Sky Airlines sends such an email message to a user in Consolidated Messenger, the following occurs (note that the first three steps are the same as those in the previous procedure):

Note:

USERS DO NOT NEED TO CHOOSE THE OUTLOOK OPTION TO SEND ENCRYPTED EMAIL

When you configure a sharing relationship with another organization and enable Federated Delivery, all messages sent by users who have permission to use the sharing relationship are automatically encrypted. Users do not require locally installed certificates and do not need to choose the Outlook option to send encrypted email.

1.5. Configuring a Federation Trust

Before you can configure a sharing relationship with another organization, both organizations must configure a federation trust with the Federation Gateway. You need to obtain an X.509 certificate from an external CA that is trusted by Windows Live Domain Services and hence by the Federation Gateway server. This certificate requires a private and public key pair that can act as both a client and a server certificate and that can sign and decrypt delegation tokens issued by the Federation Gateway. The certificate requires a Subject Key Identifier, and it must be deployed on all Exchange Server 2010 Client Access servers. If you want to, you can reuse an existing trusted certificate already installed on the Client Access server.

You next need to configure all SMTP domain names you want to use for federated sharing as authoritative accepted domains in your Exchange organization.

Federated sharing requires that servers from other organizations can resolve your servers’ names on the Internet. You also 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 you provide.

To create this proof-of-ownership record, you need to obtain the application identifier created when you configure a federation trust. You can obtain this identifier by using the Get-FederationTrust cmdlet in the EMS. For example, the following command retrieves properties (including identifiers) of federation trusts configured for the organization:

Get-FederationTrust | FL

To create a new TXT record on a DNS server, you use the DNS Microsoft Management Console snap-in. Figure 1 shows the dialog box that enables you to create a text record. The DNS server also needs to have Internet connectivity to reach the Federation Gateway.

To use the EMC to create a federation trust, click Organization Configuration in the Console tree and then click New Federation Trust in the Action pane. This starts the New Federation Trust Wizard, shown in Figure 2. The EMC does not permit you to specify a name for the trust. The trust receives the name “Microsoft Federation Gateway” by default. You can browse for the thumbprint of a trusted third-party certificate that can validate the trust. A thumbprint is the digest of the certificate data and uniquely identifies a certificate. Click New to create the trust. Click Finish on the Completion page to close the wizard.

You can create a federation trust in the EMS by using the New-FederationTrust cmdlet. However, you must first obtain the thumbprint of a valid certificate. You can use the Get-ExchangeCertificate EMS cmdlet to obtain the certificate thumbprint. Figure 3 shows two certificate thumbprints on the VAN-EX1 server. It is a good idea to redirect the output of this command to a text file so that you can paste the thumbprint into the command to create a new federation trust. Note also that the certificate whose thumbprint you choose must be exportable. You need to obtain such a certificate from a trusted third-party CA. A locally generated self-signed certificate cannot be used for this purpose.

To create a federation trust named Microsoft Federation Gateway using the thumbprint of an exportable certificate, you enter the following command:

New-FederationTrust -Name "Microsoft Federation Gateway" -Thumbprint <thumbprint>

					  

Note:

INTERNET ACCESS

Your Exchange Server 2010 Client Access server requires Internet access to create a federation trust. The domain used for establishing a federation trust must be resolvable from the Internet.

1.6. Adding a Domain to a Federation Trust and Modifying the Trust Properties

If you need to configure a secondary domain with a federated organization identifier—in effect, to add it to the federated trust—the domain must exist as an accepted domain in the Exchange organization. If this condition is met, you can use the Add-FederatedDomain cmdlet in the EMS to add a specified domain to an existing federation trust. For example, the following command adds the domain mail.adatum.com:

Add-FederatedDomain -DomainName mail.adatum.com

As well as adding a domain to an existing federated trust, you can configure the properties of the trust using the Set-FederationTrust EMS cmdlet. For example, you might choose to change the certificate that you use to verify the trust, possibly because the current certificate is due to expire.

This is a multistage process. First, you use the Thumbprint parameter to specify the thumbprint of the X.509 certificate to be configured as the next certificate to be used to verify the federation trust. After the certificate is deployed on all Hub Transport and Client Access servers in the Exchange organization, you use the PublishFederationCertificate switch to configure the trust to use this certificate.

The following command configures the federation trust named Microsoft Federation Gateway to use the certificate with the thumbprint AC00F12CBA8358253F412FD0984B5CCAF2AF4F27 as the next certificate:

Set-FederationTrust -Identity "Microsoft Federation Gateway" -Thumbprint
AC00F12CBA8358253F412FD0984B5CCAF2AF4F27

You next need to verify that the certificate is available on all Hub Transport and Client Access servers. On each of these servers, you enter the Test-FederationTrust EMS cmdlet without parameters. The cmdlet confirms that connection to the Federation Gateway is established and that communication between the local Client Access or Hub Transport server and the Federation Gateway is working correctly. It checks that certificates, including the next certificate, are valid and can be used with the Federation Gateway, and it requests a security token from the Federation Gateway and ensures that the token can be properly retrieved and used.

Your final step is to configure the trust to use the next certificate as the current certificate. For example, to configure the federation trust Microsoft Federation Gateway to use the certificate configured as the next certificate as its current certificate, you enter the following command:

Set-FederationTrust -Identity "Microsoft Federation Gateway"
-PublishFederationCertificate


1.7. Configuring Organizational Relationships

After you create the federated trust, your next step is to configure an organizational relationship. Organizational relationships determine the organizations (or domains) with which you share information and what types of information you share.

To configure organizational relationships in the EMC, carry out the following procedure:

To use the EMS to create an organization relationship, you must use the Get-FederationInformation cmdlet to identify the domain names provided for the external organization. This cmdlet accesses the Federated Organization Identifier (OrgID), which defines which of the authoritative accepted domains configured in the Exchange organization are enabled for federation. You pipe the output from the Get-FederationInformation cmdlet into the New-OrganizationRelationship cmdlet, which attempts to automatically discover configuration information from the external organization and, if successful, creates the organizational relationship as specified.

The following command creates an organization relationship with the Contoso organization, enabling free or busy information and specifying that the requesting organization receives free or busy, subject, and location information from the target organization:

Get-FederationInformation -DomainName Contoso.com | New-OrganizationRelationship -Name
"Contoso" -FreeBusyAccessEnabled $true -FreeBusyAccessLevel -LimitedDetails

					  

When you have created an organizational relationship, you can use the Set-OrganizationRelationship cmdlet to change its settings. For example, the following command disables the organization relationship with Contoso:

Set-OrganizationRelationship -Identity "Contoso" -Enabled $false

You can discover information about an organizational relationship by using the Get-FederatedOrganizationIdentifier EMS cmdlet to retrieve the Microsoft Exchange Server 2010 organization’s federated organization identifier and related details, such as federated domains, organization contact, and status. You can obtain details about the status of federated domains from the Federation Gateway by including the IncludeExtendedDomainInfo parameter, such as the following:

Get-FederatedOrganizationIdentifier -IncludeExtendedDomainInfo

You can use the Set-FederatedOrganizationIdentifier EMS cmdlet to configure federated organization identifiers. You configure a federated organization identifier to create an account namespace for your Exchange organization with the Federation Gateway and enable federation so that you can make use of the facilities that federation provides, such as sharing calendars or contacts and accessing free or busy information.

Typically, an organization’s federated organization identifier is created using the organization’s primary domain name. Additional domain names can be added and removed later by using the Add-FederatedDomain cmdlet (described earlier in this lesson) and the Remove-FederatedDomain cmdlet.

For example, the following command configures and enables a federated organization identifier for the Adatum.com Exchange organization:

Set-FederatedOrganizationIdentifier -DelegationFederationTrust "Microsoft Federation
Gateway" -AccountNamespace "Contoso.com" -Enabled $true

					  

Sharing policies define which users in your organization can use the organizational relationships to share information with other organizations and what types of information those users can share. The default sharing policy is created when you install Exchange Server 2010. This policy enables sharing with all domains but enables only calendar sharing with free or busy information. It is assigned to no mailboxes.

If you want to enable users to participate in federated sharing, you can add their mailboxes to the default sharing policy or create a new sharing policy. When you create a new sharing policy, you configure the domain name for the external domain and the sharing actions that are permitted under the policy. Sharing options include the following:

• Calendar sharing with free or busy information only

• Calendar sharing with free or busy information, subject, and location

• Calendar sharing with free or busy information, subject, location, and body

• Contacts sharing

• Calendar sharing with free or busy information only and contacts sharing

• Calendar sharing with free or busy information, subject, and location and contacts sharing

• Calendar sharing with free or busy information, subject, location, and body and contacts sharing

Configuring a sharing policy requires that a federation trust has been created between your Exchange 2010 organization and the Federation Gateway and that the federated organization identifier is configured. Recipients from an external domain can access your users’ information only if they have an Exchange 2010 organization and their domain is federated. To use the EMC to configure sharing policies, carry out the following procedure:

Note:

CREATING A NEW SHARING POLICY

The settings you specify when creating a new sharing policy are similar to the settings you can edit when configuring a sharing policy. In this case, click Mailbox under Organization Configuration in the Console tree and then click New Sharing Policy in the Result pane.

Note:

APPLYING A SHARING POLICY TO A MAILBOX

You can also apply a sharing policy to a specific mailbox by using the Mailbox Settings tab in the mailbox’s Properties dialog box.

You can use the New-SharingPolicy cmdlet in the EMS to create a sharing policy and the Set-SharingPolicy cmdlet to modify a policy. For example, the following command creates a sharing policy called Blue Sky Airlines for the mail.BlueSkyAirlines.com domain, which is external to your organization. This policy allows users in the mail.BlueSkyAirlines.com domain to see detailed free or busy information and contacts. By default, the policy is enabled:

New-SharingPolicy -Name "Blue Sky Airlines" -Domains 'mail.BlueSkyAirlines.com:
CalendarSharingFreeBusyDetail, ContactsSharing'

					  

The following command modifies a sharing policy named Contoso for the contoso.com domain, which is external to your organization, so that users in the Contoso domain can see your users’ availability (free or busy) information:

Set-SharingPolicy -Identity Contoso -Domains 'contoso.com:
CalendarSharingFreeBusySimple, Contacts'

To get details about a sharing policy, you can use the Get-SharingPolicy EMS cmdlet. For example, the following command displays all the available information for the sharing policy Blue Sky Airlines:

Get-SharingPolicy "Blue Sky Airlines" | FL

If you no longer require a sharing policy, you can remove it using the Remove-SharingPolicy EMS cmdlet. Note that you cannot remove a sharing policy that has mailboxes assigned to it and that you need to assign them to another policy first. The following command removes the sharing policy Blue Sky Airlines and suppresses the requirement that you enter Y to confirm that you want to remove the policy:

Remove-SharingPolicy -Identity "Blue Sky Airlines" -Confirm:$false


1.9. Configuring Mailboxes to Use Sharing Policies

You can configure mailboxes to use sharing policies by using the Get-Mailbox and Set-Mailbox EMS cmdlets. A command based on the Get-Mailbox cmdlet obtains the mailbox or mailboxes to which you want to apply the sharing policy by using the criteria you define (for example, all mailboxes that are associated with the Sales Department). You pipe the output from this command into a command based on the Set-Mailbox cmdlet, which applies the sharing policy.

For example, the following command configures all mailboxes associated with the Marketing Department to use the Adatum Marketing federated sharing policy:

Get-Mailbox -Filter {Department -eq "Marketing"}

You can also use a command based on the Get-Mailbox cmdlet to list the mailboxes that use a specific sharing policy. To give a convenient display, you can pipe the result into the format-table function. For example, the following command returns all the mailboxes in an organization that are provisioned to use the Adatum Marketing sharing policy and lists them as email addresses:

Get-Mailbox | Where {$._SharingPolicy -eq "Adatum Marketing" } | format-table Alias, EmailAddress

					  

The sharing policies you configure determine what your users can share with users from another organization. The mailboxes to which you apply the sharing policy determine which users can share this information.

Suppose, for example, that you create a sharing policy named Fabrikam01 with the external domain fabrikam.com, and this permits your users to share calendar free or busy information, subject, and location. You apply this policy to all the mailboxes belonging to users in the Marketing Department.

Suppose you create a sharing policy named Fabrikam02 with the same external domain, and this permits your users to share calendar free or busy information only and contacts. You apply this policy to all the mailboxes belonging to users in the Sales Department.

Don Hall, a user in the Marketing Department, can now send sharing invitations through his email client to users in the fabrikam.com domain. If these invitations are accepted, Don can share his calendar free and busy information, subject information, and location with these users.

Jeff Hay, a user in the Sales Department, can now send sharing invitations through his email client to users in the fabrikam.com domain. If these invitations are accepted, Jeff can share his calendar free and busy information and his contacts information with these users.

Any of your users who do not have a specific sharing policy assigned to his or her mailbox might still be able to share information with users in a federated domain. This will depend on your organization’s default sharing policy.

The details that the users in the fabrikam.com domain can, in turn, share with your users depend on the sharing policies the Fabrikam administrators have configured and applied to the mailboxes in their domain.

Subject Alternative Name (SAN) Certificates

If you need to protect multiple host names with a single certificate, you can use a SAN certificate. This allows you to specify a list of host names and protect them with a single SSL certificate.

SANs enable you to secure host names on different base domains with one certificate and to host multiple virtual SSL sites using a single IP address. Typically, hosting multiple SSL-enabled sites on a single server requires a unique IP address per site, but a SAN certificate, also known as a Unified Communications SSL certificate, can solve this problem. Both Microsoft Internet Information Services version 6 or later and Apache HTTP server are able to use SAN certificates to host virtual websites.

SAN certificates can secure multiple fully qualified domain names with a single certificate. SAN certificates are used to secure Exchange Server 2010 sites where there is a need to secure multiple domains that resolve to a single IP address (such as in a shared hosting environment). Using a SAN certificate saves the time required to configure multiple IP addresses on an Exchange server and bind each IP address to a different certificate.

When browsers connect to servers using HTTPS, they check to make sure the SSL certificate matches the host name in the address bar. Browsers find a match in one of the following ways:

• The host name in the address bar exactly matches the common name in the certificate’s Subject field.

• The host name matches a wildcard common name. For example, www.contoso.com matches the common name *.contoso.com.

• The host name is listed in the Subject Alternative Name field.

Normally, a browser compares the server name it connects to with the common name in the Server certificate. However, if an SSL certificate has a SAN field, then SSL clients typically ignore the common name value and seek a match in the SAN list.

Microsoft Internet Explorer, Microsoft Windows Mobile 5, Firefox, Opera, Safari, and Netscape all support SAN certificates. However, some mobile devices do not support SAN certificates, although all of them support exact common name matching.