This section covers how to configure edge servers and user accounts for federation and how to manage federated partner access in an Office Communications Server 2007 environment. We'll also look briefly at how to manage multiple accounts and how to block external domains.
Once the edge servers are set up in the environment, your next step is to configure your organization for federation. The assumption to this point is the edge servers are functioning within the organization and remote access is working. To reach the conclusion that this is happening, you must verify that remote users can contact the edge servers and edge servers can contact the internal Office Communications Server 2007 servers.
Federation provides the organization with the ability to communicate with other organizations' Access Edge Server to share IM and presence. You can also federate and control federation with an audio conferencing provider by using either of the following methods. The process of configuring federation with an organization or an audio conferencing provider is identical.
Allow automatic discovery of federated partners This is the default option during initial configuration of an Access Edge Server because it balances security with ease of configuration and management. For example, when you enable automatic discovery of federated partners on your Access Edge Server, Office Communications Server 2007 automatically evaluates incoming traffic from federation partners and limits or blocks that traffic based on trust level, amount of traffic, and administrator settings.
Allow discovery of federated partners Grant a higher level of trust to specific domains or Access Edge Servers that you specify on the Allow list. For example, if you want to grant a higher level of trust to partners using the SIP domain contoso.com and fabrikam.com, you add these two domains on the Allow tab. Restricting discovery in this way establishes a higher level of trust for connections with the domains or Access Edge Servers that you add to your Allow list, but it still provides the ease of management that is possible by discovering other federation partners that are not listed on the Allow tab.
Do not allow discovery of federation partners Limit access of federated partners to only the domains or Access Edge Servers for which you want to enable connections. Connections with federated partners are then allowed only with the specific domains or Access Edge Servers you add to the Allow tab. This method offers the highest level of security, but it does not offer ease of management. For example, if an FQDN of an Access Edge Server changes, you must manually change the FQDN of the server in the Allow list.
You can explicitly manage the user by overriding the Global Settings (in the Office Communications Server snap-in at the Forest node level) or you can manage users as individuals. To configure a user object for federation, the following procedure should be used:
Open the Office Communications Server 2007 management console.
Expand to pools (Enterprise or Standard).
Expand Users, and locate the user.
Right-click, select properties, and click the Configure button.
Enable federation by selecting the Enable Federation check box.
If you have configured support for federated partners, including an ACP that is providing telephony integration, it is required that you actively manage the lists of external domains that can communicate with the servers in your organization.
The administrator can view a list of the federated domains that have most recently made at least one connection to your Access Edge Server. This list is not all-inclusive, and if numerous domains are hitting your Access Edge Servers, domains that haven't been seen in a while will roll off. To best use this feature, it is highly recommended that DNS-based discovery (via the SRV records) of Access Edge Servers be implemented as the federation configuration method of choice. You can also use Federated Partner Discovery in conjunction with the Allow tab to control domains you specifically will accept; all others will be dropped. (Note the stipulations discussed next that further clarify the rules.) For increased security, explicitly specify the FQDN of a federated partner's Access Edge Server.
When a domain is configured in the Allow list, communications with this domain are assumed to be legitimate. The Access Edge Server does not throttle connections for these domains. In case of DNS-based discovery of federated domains that are not on the Allow tab, connections are not fully trusted and Access Edge Server actively monitors these connections and limits the allowed throughput.
The Access Edge Server marks a connection for monitoring in one of two situations:
Suspicious traffic is detected on the connection. To detect suspicious activity, the server monitors the percentage of specific types of error messages on the connection. A high percentage can indicate attempted requests to invalid users, such as a SPIM (SPAM attack over Instant Messaging) attack. In this case, the connection is placed on a watch list, and the administrator can then take action to explicitly block the offending domain. Also, this type of traffic is throttled to one message per second, as it is much less predictable (in terms of which domain is sending it). Partners are also limited to 20 messages per second unless they are added to the Allow list.
Federated party has sent requests to more than 1000 URIs. When this many URIs are received, they could be valid or invalid, as the sheer volume could be an indication of potential attacks. Again, the domain is placed on a Watch list. Additional requests within a specific time period cause the offending domain to be blocked at the Access Edge Server.
Two situations may cause the limit of 1000 URIs to be met–one problematic, one probable and expected:
Problematic The remote party is attempting a directory attack on the local domains.
If the traffic from this partner is deemed to be legitimate, the sending domain must be added to the Allow tab, as the Access Edge Server has already blocked further connections.
Probable and expected Valid traffic between the local and federated domains exceeds the limit of 1000 URIs.
Further traffic from this domain will be dropped. If an administrator knows that the message rate from a given domain will exceed the 1000 URI limit, the sending domain should be added to the Allow list; otherwise, messages beyond the 1000-URI limit will not be accepted.
The information that the Access Edge Server acts on can be viewed administratively in the Office Communications Server 2007 Microsoft Management Console (MMC) on the Access Edge Server. Selecting the Open Federation tab reveals information on Allowed and Open Federated partners (see Figure 7-5).
It is also possible to manage a large number of accounts as follows:
Anonymous (non-authenticated) users are a reality that needs to be considered in an environment where you are accommodating users from domains that there might be a casual relationship with. Whether you will allow anonymous users into your environment, then access to Live Meetings or Audio/Video conferences is a decision that you will need to make. The very concept of anonymous users is unsettling to some administrators and IT security staff, but Office Communications Server 2007 handles the situation with a number of safeguards.
First, users are not completely anonymous. You have to send them an invite for them to access the conference or meeting. Second, they are accessing the edge servers, not your internal environment. In essence, this is little different than allowing a user to access your Web server, except these services are using streaming protocols instead of HTTP. The selections possible for who and how anonymous users can be invited are determined by administrative control, too.
Global properties allow you to set a policy that defines whether the Anonymous User settings are global or per user. Access the global properties by opening the Office Communications Server 2007 management console and right-clicking the Forest node. As shown in Figure 7-6 a fly-out menu allows you to select Properties and then Global Properties.
At this point, you are presented with a number of tabs in a dialog box. Select the Meetings tab. (See Figure 7-7.) You have three settings to select from:
Allow users to invite anonymous participants This option allows your users to invite users who are not members of your domain to attend anonymous meetings. Your users will be able to schedule and send invites on behalf of nonmembers, and they can create ad-hoc meetings. Of course, some of the abilities and settings are dependent on the Office Communicator 2.0 client, and this can be controlled administratively as well. Just because users have the ability to send invites does not necessarily mean that they are allowed to.
Disallow users from inviting anonymous participants This option prevents users from inviting users who are not members of your domain (that is, who do not have authentication credentials to your domain—and this includes federated users) to meetings.
Enforce per user This option leaves the administrative capacity to setting if a user can allow an anonymous user at a per-user basis. Though it might seem overly intensive, you can set this option if you intend to grant this ability to only a few people. For example, you can grant this ability to administrative assistants who are responsible for setting up meetings and are generally accountable for sending out external meeting notices—whether they are notices for meetings in your department or notices that the CEO is holding a shareholders' meeting.
Figure 7-7. User object—Properties of a user in the Office Communications Server 2007 management console
To re-emphasize: Anonymous access still requires specific meeting keys, a URL/URI, and other identifying elements. Anonymous users are anonymous only because they do not have authentication credentials for your domain.
Sometimes, because of continued unsolicited instant messages (also known as SPIM) or attempts to compromise security, it's necessary to explicitly block a specific domain. This is accomplished much like an Allow. We use the same beginning dialog box, but we choose the Block tab instead of the Allow tab, as follows:
Log on to the Access Edge Server as a member of the Administrators group or a group with equivalent user rights.
On an Access Edge Server, open Computer Management.
In the console tree, expand Services And Applications, right-click Office Communications Server 2007, and then click Properties.
On the Block tab, click Add.
In the Add Blocked SIP Domains dialog box, in the SIP Domain box, type the name of the domain to be added to the list of blocked SIP domains. This name should be unique and should not already exist in the Block list for this Access Edge Server. The name cannot exceed 256 characters in length. Click OK.
