Federation is a trust relationship between two entities. If two companies that are separate enterprises need to communicate, they federate to enable easy access to common data.
Note
Federation is not the same as Active Directory Federation Services, but it serves the same purpose: enabling two enterprises that do not share a common authentication base to interact with each other.
For example, a manufacturing company and a supply chain partner that sells raw goods to that company might federate their enterprises to enable collaboration and access to common applications. Access can be managed in much the same way that access is managed in separate organizations, within a single entity, because users and groups can be populated with IM contacts from either enterprise. The difference is that there is no common address book that contains all the names from both enterprises. Similar to e-mail, you have to find and enter the name of the target person you are trying to contact into Office Communicator 2007 R2. The difference between e-mail and federated contacts is that you have control over who can contact you, whereas e-mail does not offer such specific controls (short of spam filters).
In Office Communications Server 2007 R2, the purpose of federation is to enable collaboration between users in completely separate enterprises. Using our example of the manufacturing and the raw materials companies, suppose Bob (an employee of the manufacturing company) needs to confirm details with Alice (an employee of the supply company) of an upcoming contract. Both have Office Communicator, so Bob can check Alice’s presence. When he sees that her presence indicates that she is available, Bob initiates an IM session with Alice. In addition, they both need to review the details in the contract, so Bob starts a Live Meeting session to share the contract where they can both work on the document and the final details. Both companies have used federation to enable Bob and Alice to be more productive in their jobs.
A user does not need to belong to any of the companies in a federation to be able to communicate within a federation. Instead, they can access these resources as a federated user, that is, an external user (not a member of your enterprise) who possesses valid credentials and can authenticate to his enterprise. Once federated users authenticate, they are treated as if they are a part of your enterprise as far as Office Communications Server 2007 R2 services are concerned. Policies and configuration settings in Office Communications Server 2007 R2 can manage and modify the access that each user has.
Now that we’ve provided a short explanation of what a federation is and how it can help users within different enterprises, we can talk about the various federation topologies. In the sections that follow, we will discuss these federation topologies:
Direct federation. Direct federation refers to the one-to-one agreement, or trust, that is established between two entities. Direct federation requires specific entries on the Access Edge Server and the DNS Server.
Enhanced federation. Federated partner discovery (the process by which enhanced federation is accomplished) is similar to direct federation, but it requires much less administrative effort to establish and maintain. SRV records are used in the DNS to identify the federation. For more information about which SRV records are required, see the section titled "Understanding Federated Partner Discovery" later in this chapter.
Federation with public IM providers. Federation with public IM providers, such as Yahoo!, MSN, and AOL, is briefly discussed in this section. For more information about how public IM works, how to establish it, and how to administer it, see Chapter 8.
This chapter will also discuss user and administrator scenarios and the steps that must be taken to accomplish those scenarios.
Administration of federation requires the following prerequisites:
Use public CA certificates.
Enable users for federation.
Apply settings on Access Edge Servers to allow the SIP domain of the partner organization.
Obtain the fully qualified domain name (FQDN) of the federated partner’s Access Edge Server.
Direct federation implies that two enterprises are establishing an explicit trust between each other, as shown in Figure 7-10. This trust says that the enterprises have entered into an agreement in which they will directly share contacts and presence information that is related to those contacts. This makes it easier for users within each enterprise to communicate and to determine when a person is available. Presence information is reflected in applications that are presence aware, that comply with the requirements of Office Communications Server 2007 R2, and that are installed on a federation-enabled user’s computer. Examples of these are Microsoft Office Communicator 1.0 (and later), Microsoft Office Outlook 2003 (and later), and Microsoft Office SharePoint 2003 (and later).
Figure 7-10. Direct federation that is defined by the FQDN and IP to specific Office Communications Server 2007 R2 enterprises
The trust element is established by certificates that ensure that either partner can absolutely confirm that person on the other end of the established trust is who they say they are, as well as ensure that the trusted partner domain name is entered on the Allowed tab of the Access Edge Server. We will discuss certificate types that can be used to accomplish this task in the section titled "Understanding the Requirements for and Use of Certificates in Federation" later in this chapter. Options for federation settings will be defined as well.
Of the three types of federation, direct federation is the simplest to implement. However, it requires more administrative resources.
Most of the work in a direct federation model takes place on the Access Edge Server. It provides a separate, distinct role for incoming communications to be received, and it is an outgoing portal for communications that are bound for external destinations. As with all roles in Office Communications Server 2007 R2, certificates play an important role in establishing a level of security, trust, and confidentiality. Certificates and DNS record-naming inconsistencies between the host name and the certificate subject name or subject alternate name are a common cause of error in the configuration and setup of Office Communications Server 2007 R2.
A Director server is a recommended, but not mandatory, server role that sits logically between your Edge Servers and the pool. The role of the Director is to pre-authenticate and pre-authorize incoming traffic that is destined for your internal SIP domains. In the case of the Director process, pre-authentication determines whether the SIP domain, the user, or both are known to the Director. Earlier, in Figure 7-10, you saw that users in the Litwareinc.com domain can be pre-authenticated by the Director, but users of Fabrikam.com cannot. There is a one-way replication from Active Directory to the Director, and only mandatory attributes are necessary to pre-authenticate and pre-authorize. The director is authenticating only that the Fabrikam domain is allowed and that the users are recognized and belong to the Fabrikam domain. The role of the internal servers is a minor part in federation. The internal servers, along with the way that they operate and support users, are no different than they would be if the federation did not exist.
Direct federation becomes administratively more complex as additional partners are added. Ten is manageable. The administrative overhead involves defining the Access Edge Servers and managing certificates for each partner. The administrative effort in managing additional partner federations becomes increasingly difficult and potentially error prone as the administrator manages the addition or removal of entries on the Allow tab of the Access Edge Server as well as the attainment or removal of certificates from federated partners.
To maintain a reasonable level of administrative overhead, the recommended maximum number of partners is 10.
You can enable discovery of federation partners and add federated partners to the Allow list. Adding specific partners to the Allow list gives them a higher level of trust. The Access Edge Server can still discover federated partners other than the ones on the Allow list, but specific rules are applied to those partners who are not on the Allow list. To enable federation in an enterprise, perform the following steps in the Office Communications Server 2007 R2 administrative tool on a Standard Edition Server or Enterprise pool front-end server:
Click Start, click Administrative Tools, and then click Open Office Communications Server 2007 R2 MMC.
Select the Forest,<domain name> node.
Right click Global Policy Properties.
A dialog box will open (as shown in Figure 7-11).
Click the Federation tab.
Select the Enable Federation And Public IM Connectivity check box.
Specify the FQDN of the next-hop server Director, load balancer, or Access Edge Server.
To add a trusted federated partner domain and the FQDN of its Access Edge Server, do the following:
Log on to each of the Access Edge Servers as a member of the Administrators group or a group that has equivalent user rights.
Click Start, click All Programs, click Administrative Tools, and then click Computer Management.
In the console tree, expand Services And Applications, right-click Microsoft Office Communications Server 2007 R2, and then click Properties.
On the Allow tab, click Add, as shown in Figure 7-12.
Figure 7-12. Define the Allow property for a federated SIP domain and the Access Edge Server of the partner.
The benefit of defining global properties is that doing so is much easier to manage than defining multiple separate options. This configuration affects all default routes for all pools. If you need an exception, you can define it locally.
In the Add Federated Partner dialog box, do the following:
In the Federated Partner Domain Name text box, type the domain of the federated partner domain.
In the Federated Partner Access Edge Server (Optional) text box, type the FQDN of each Access Edge Server that you want to add to your Allow list. If the FQDN of a partner’s Access Edge Server changes, you must manually update your configuration for this partner, as shown in Figure 7-13.
Click OK.
Repeat this procedure for each federated partner that you want to add to your Allow list and then click OK.
SRV records play an important role in federated partner discovery. Unlike direct federation, where the path and FQDN of the destination federated partner is defined, the Access Edge Server parses the DNS server for any existing SRV records that define potential federated locations, as shown in Figure 7-14.
Figure 7-14. Federated partner discovery in which the Access Edge Server queries DNS for SRV records.
SRV records are a special type of DNS record that defines a service that a server offers. The SRV record defines the name of the server, the protocol, and a port that can be used. For those familiar with Active Directory, SRV records are used to define which domain controllers offer LDAP, Kerberos, GC, and other services. For Office Communications Server 2007 R2 federation, SRV records define what servers are available to offer federated services. The format of the record is as follows:
Service : _sipfederationtls Protocol: _tcp Priority: <variable> Weight: <variable> Port: 5061 Target: access.fabrikam.com
Note
For more information about how SRV records are defined, see the IETF RFC Document 2782 at http://go.microsoft.com/fwlink/?LinkID=133684.
There is also an A, or host, record that connects the SRV record’s entry to the actual Access Edge Server. In this example, consider the host access.fabrikam.com, shown in Figure 7-15. Recall that this is the external interface of the Edge Server, which should have two interfaces. One interface is for the internal communication, and the other is for the perimeter communication.
Figure 7-15. In these DNS SRV records, the A records that SRV points to define names for Office Communications Server R2 services.
The important thing to remember is that if you ask the DNS for SRV records, it returns records that can provide the services of Office Communications Server 2007 R2 federation. (These are the results of the query for SRV records and then the subsequent query for the A record of the server named in the SRV record.) This is a critical step in the process to determine which servers can provide the necessary services to establish a federated partnership. Access Edge Servers can query the DNS for SRV records that meet the correct criteria and return results for any other Access Edge Server that offers federation.
The Access Edge Server queries for all the SRV records that meet the federation SRV record criteria, and the DNS server complies with a list of A records for other Edge Servers that advertise the federation SIP service, as shown in Figure 7-16. It is the Access Edge Servers that negotiate a partnership, which will be discussed later in this chapter. The final setup involves the use of certificates, allow and deny settings, and DNS configuration. Any of these can complicate the process of troubleshooting; therefore, creating documentation as you go is highly recommended.
Figure 7-16. Access Edge Server finds other Office Communications Server R2–capable servers through a query to the DNS and A record resolution.
Note that federated partner discovery is evaluated and controlled in three ways:
Allow automatic discovery of all federated partners.
Allow discovery of partners, but assign trust levels by using the Allow tab.
Do not allow partner discovery; instead, allow access only to partners or Edge Servers that are specifically defined. (This is the direct federation method discussed earlier in this chapter.)
To enable discovery of federated partners, do the following:
Log on to the Access Edge Server as a member of the Administrators group or a group that has equivalent user rights.
Click Start, click All Programs, click Administrative Tools, and then click Computer Management.
In the console tree, expand Services And Applications, right-click Microsoft Office Communications Server 2007 R2, and then click Properties.
On the Access Methods tab, select the Allow Discovery Of Federation Partners check box, as shown in Figure 7-17.
Establishing an IM relationship with another enterprise might sound familiar. If you have used the MSN, AOL, or Yahoo! IM clients, you have done this. Office Communications Server 2007 R2 enables you to establish a federation relationship between your enterprise environment and one, two, or all three of these IM providers.
Chapter 8 deals specifically with the process and technology of how Office Communications Server 2007 R2 enables you to do this. However, it is important to understand that this chapter is the foundation of how the relationship with public IM providers is established.