This chapter provides an overview and description of federation in Office Communications Server 2007. The chapter covers the setup and administration of servers, managing users in a Federated environment, understanding Domain Name System (DNS) servers and certificates and their importance, and understanding the technical details behind message flow in a federation.
Federation, in its most basic view, is a trust relationship between two entities. If two companies that are separate enterprises need to communicate, they might federate to allow easy access to common data.
Note
This method is not the same as Active Directory Federation Services, but it serves the same purpose—that is, allowing 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 the manufacturing company might federate their enterprises to allow for easy collaboration and access to common applications. Access can be managed in much the same way that access is managed today, because users and groups can be populated with instant messaging (IM) contacts from either enterprise as well. The difference is that there is no common Address Book that contains all the names as the other enterprise. 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.
In Office Communications Server 2007, the purpose for federation of IM is to enable collaboration between users. Given our example of the manufacturing and the raw materials companies, 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, and Bob notes that Alice's presence indicates that she is Available—that is, on line. Bob initiates an IM session with Alice. They both need to review the details in the contract, and Bob initiates a Live Meeting session to share the contract and hash out the final details. Both companies have used federation to enable Bob and Alice to accomplish more and be more productive in their jobs.
A federated user is defined as an external user (not a member of your enterprise) who possesses valid credentials and can authenticate to his or her enterprise. Once users authenticate, they are treated very much as if they are a part of your enterprise as far as Office Communications Server 2007 services are concerned. Of course, the behavior can be managed and modified by policies and configuration settings in Office Communications Server 2007.
In this chapter, we will discuss at length and in depth the following federation topologies.
Direct Federation Direct Federation refers to the one-to-one agreement, or trust, that is established between two entities that decide that they want their users to be able to communicate in a common and collaborative way, but not in a fully open and less controlled manner—over the Internet, for example.
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. If you are familiar with SRV records in DNS and have used them in Active Directory, you already have an idea as to how this will play out. Please review the section Understanding Federated Partner Discovery later in this chapter for more information on SRV records.
Federation with Public IM Providers Federation with public IM providers (Yahoo!, MSN, AOL) will be discussed in this section. We will not go into depth on what public IM is, but we will discuss the technical elements that allow public IM federation to occur between Office Communications Server 2007 and the three public providers mentioned. If you are looking for detail on how public IM works, how to establish it, and how to administer it, you will find those topics covered in Chapter 8.
We will also talk about the user and administrative scenarios and the steps that must be taken to accomplish them.
Administration of federation requires mainly the following prerequisites:
The use of Public Certification Authority certificates for a common or mutual trust
Enabling the user for federation
Applying settings on Access Edge Servers to Allow the Session Initiation Protocol (SIP) domain of the partner
The fully qualified domain name (FQDN) of the federated partner's Access Edge Server (the Edge Server resides at the perimeter of your enterprise and receives incoming / sends outgoing messages)
Direct Federation implies that two enterprises are establishing an explicit trust between each other (see Figure 7-1). This trust says that the enterprises have entered into an agreement in which they will directly share contacts and presence information related to those contacts. This makes it easier for the staff within each of the enterprises to communicate and to determine when a given person is available. Presence information is reflected in applications that are presence aware and comply with the requirements of Office Communications Server 2007, and that a federation-enabled user has installed on their desktop. Examples of these are Office Communicator 1.0 (and newer), Microsoft Office Outlook 2003 (and newer), and Microsoft SharePoint 2003 (and newer).
The trust element is established by certificates that ensure that either partner can absolutely confirm that the other end of the established trust is who they say they are, as well as ensuring 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 in the section Understanding the Requirements for and Use of Certificates in Federation later in this chapter. Also, the options for federation settings will be defined as well.
Figure 7-1. Direct Federation—Defined by the FQDN and IP to specific Office Communications Server 2007 enterprises
Of the three types of federation, Direct Federation has the most straightforward and simple implementation because there are very few moving parts. That being said, it is, at the same time, the most administratively intensive.
A majority of the work in a Direct Federation model takes place at the Access Edge Server. (The Access Edge Server role provides the same level of functionality as the Access Proxy from Live Communications Server, and more.) It provides a separate, distinct role for incoming communications to be received, and it is an outgoing portal for communications bound for external destinations. As with all roles in Office Communications Server 2007, certificates play an important role in establishing a level of security, trust, and confidentiality. And, as with all roles in Office Communications Server 2007, if you experience any problem with federation, suspect certificates, certificate naming, and DNS as the initial cause—then expand your search for other less relevant causes of difficulty.
A Director is a recommended, but not a mandatory, server role that sits logically between your edge servers and the pool. The role of the Director is to pre-authenticate inbound traffic destined for your internal SIP domains. It's important to differentiate pre-authenticate from the type of authentication you are more familiar with—ensuring that a given user's principal and password match that of a known value.
In the case of the Director process, pre-authentication determines whether the SIP domain and/or the user is known to the Director. Using the example shown in Figure 7-1, users in the Contoso.com domain can be pre-authenticated by the Director, but users of Fabrikam.com cannot. Simply, there is a one-way replication from Active Directory to the Director and with only mandatory attributes necessary to pre-authenticate. The Director at this point is authenticating only that the Fabrikam domain is allowed and that the users are recognized and belong to the Fabrikam domain—nothing more. The role of the internal servers is a minor part in federation. The servers, and the way that they operate and support users, still play their roles, but those roles are no different than they would be if the federation did not exist. So they will not be dealt with in this section.
It should be noted that Direct Federation becomes administratively more complex as additional partners are added. The administrative work to manage up to 10 partners can be reasonable, defining the access edges servers and managing certificates for each partner. However, managing much more than this becomes difficult and potentially error prone. And the errors might result in one or both of the following issues:
Users will not be able to connect with partner users.
Security problems and issues might arise because of poor configuration.
You can also 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. Your Access Edge Server can still discover federated partners other than the ones listed on the Allow list, but specific rules are applied to those partners not on the Allow list. Those rules are discussed in the upcoming Administering Federated Partner Access section.
Adding a Trusted Federated Partner Domain
To add a trusted federated partner domain and optionally the FQDN of its Access Edge Server, do the following.
Log on to the Access Edge Server as a member of the Administrators group or a group with equivalent user rights.
Open Computer Management. Click Start, click All Programs, click Administrative Tools, and then click Computer Management.
On the Allow tab, click Add.
In the Add Federated Partner dialog box, do the following:
In the Federated Partner Domain Name box, type the domain of each federated partner domain.
In the Federated Partner Access Edge Server box, optionally type the FQDN of each Access Edge Server that you want to add to your Allow list. Remember if you configure the FQDN of a partner's Access Edge Server and the FQDN changes, you must manually update your configuration for this partner.
Repeat this procedure for each federated partner you want to add to your Allow list, and then click OK.
SRV records play a very important role in Federated Partner Discovery. Compared to Direct Federation, where the path and IP address or fully qualified domain name 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 (see Figure 7-2).
SRV records are a special type of DNS record that define 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 of you who are familiar with Active Directory, you might recall that SRV records are used to define what domain controllers offer to LDAP, Kerberos, Global Catalog, and so on. In our case, the 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
SRV records are defined by the Internet Engineering Task Force (IETF) Request for Comment (RFC) Document 2782, which you can access at http://www.ietf.org/rfc/rfc2782.txt.
There is also an A, or Host, record that ties the SRV record's entry for Host Offering This Service to the actual Access Edge Server—in this case, access.fabrikam.com (see Figure 7-3). 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-3. DNS SRV records—The A records pointed to by SRV records define names for Office Communications Server 2007 services
The key point in this section is that if we ask DNS for SRV records, it returns records to us that can provide the services of Office Communications Server 2007 federation. This is a very critical step—knowing which servers can provide the necessary services to establish a federated partnership. Once there is clarity as to what is going on with one server, we can then bring in the concept that when an Access Edge Server is configured to look and do a search for other potential federated partners, DNS does most of the work.
The Access Edge Server asks for all the SRV records meeting our 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 (see Figure 7-4). It's up to the Access Edge Servers to negotiate a partnership, which we will discuss shortly. The final setup involves heavy use of certificates, allow and deny settings, and DNS configuration. Any of these can complicate the process of troubleshooting, and creating documentation as you go is highly recommended.
Figure 7-4. Access Edge Server—Finds other Office Communications Server 2007–capable servers through a query to DNS and A record resolution
Note that there are three ways in which Federated Partner Discovery is evaluated and controlled:
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 with equivalent user rights.
Open Computer Management. 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, and then click Properties.
On the Access Methods tab, select the Allow Discovery Of Federated Partners check box, as shown in the following screen shot:
Establishing an instant messaging relationship with another enterprise might sound familiar. If you have used the MSN, AOL, or Yahoo! IM client, you've done just this. Office Communications Server 2007 allows establishing what would be seen as a federation 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 allows you to do this. This chapter won't spend any more time on public IM specifically, but it is important to understand that this chapter is the foundation of how the relationship with public IM providers is established.