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 R2 environment. This section will also look briefly at how to manage multiple accounts and how to block external domains.
You can explicitly manage users 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, do the following:
If you have configured support for federated partners, including an Audio Conferencing Provider (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 trying to access your Access Edge Servers, domains that have not made an attempt for a while will roll off the list. 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 that you specifically will accept; all others will be blocked. For increased security, explicitly specify the FQDN of a federated partner’s Access Edge Server.
When a domain is configured on the Allow list, communications with this domain are assumed to be legitimate. The Access Edge Server does not provide any means of traffic control over connections for these domains. In the case of DNS-based discovery of federated domains that are not on the Allow tab, connections are not fully trusted, and the Access Edge Server actively monitors these connections and limits the allowed throughput.
Two situations may cause the limit of 1,000 URIs to be met: one situation is problematic, and one is 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 because the Access Edge Server will have already blocked further connections.
Probable and expected. Valid traffic between the local and federated domains exceeds the limit of 1,000 URIs in a second.
Further traffic from this domain will be dropped. If an administrator knows that the message rate from a given domain will exceed the 1,000 URI limit, the sending domain should be added to the Allow list; otherwise, messages beyond the 1,000 URI limit will not be accepted.
The information that the Access Edge Server acts on can be viewed by an administrator in the Office Communications Server 2007 R2 MMC on the Access Edge Server. Clicking the Open Federation tab reveals information about Allowed and Open Federated partners, as shown in Figure 7-18.
It is also possible to manage a large number of accounts by doing the following:
Open Active Directory Users and Computers.
Select an organizational unit, group, or collection of users.
Right-click and then select Configure Users.
Click Next on the first page of the Configure Office Communications Server Users Wizard.
On the Configure User Settings page, select Federation, ensure that the Enable radio button is set, and then click Next, as shown in Figure 7-19.
Figure 7-19. Configuration of user settings through the Configure Office Communications Server Users Wizard
Note also in Figure 7-19 that there are six sections to this dialog box. Two of them refer to archiving, which is discussed in Chapter 3, and in Chapter 16. Discussion of the functions that a user gains when Public IM Connectivity is checked and enabled is located in Chapter 8. The features that a user gains when Enhanced Presence is checked and enabled are located in 22, "Routing and Authentication." Two of these are germane to our topic of remote access Place Figure 7-19 after this paragraph.
In the previous procedure, Office Communications Server–enabled users were given the permission (that is, they were enabled) to communicate with federated partner users. The Remote User Access check box allows the same control over enabled users, yet they need to access the infrastructure remotely using Office Communicator. Selecting Enable allows Remote User Access action, and selecting Disable denies the remote access privilege to the currently selected collection of users, groups, or organizational units.
However, these settings cannot take effect unless the global policy settings defined under the Forest - <domain name> node are set at the Federation tab. It is necessary to access the global properties OR the Global Properties dialog box by using the Office Communications Server 2007 R2 MMC on the front-end server or the Standard Edition Server.
You can access these global policies by doing the following (refer to Figure 7-22):
Click Start, click Administrative Tools, and then click Open Office Communications Server 2007 R2 MMC.
Click the Forest - <domain name> node.
Right-click, select Properties, and select Global Properties.
Select the Federation tab.
Note the Enable Federation And Public IM Connectivity check box. Once this check box is selected, the FQDN and Port text boxes will also be available. The FQDN of the server that you should input here is the server that will provide your outbound route for all SIP traffic destined for outside your infrastructure. The FQDN could be one of the following:
Single Director
Internal interface of load-balanced array of Directors
Internal-facing interface of the single Access Edge Server
Internal-facing interface of the hardware load balancer for an array of Access Edge Servers
When managing user accounts, you also need to keep anonymous users in mind. Anonymous (nonauthenticated) users are a reality that you must consider in an environment where you are accommodating users from domains with which there might be a casual relationship. You will need to decide whether to allow anonymous users into your environment and then decide whether they can access Live Meetings or A/V conferences. Anonymous users can be unsettling to some administrators and IT security staff, but Office Communications Server 2007 R2 has a number of safeguards for anonymous users.
First, users are not completely anonymous. You have to send them an invitation before they can access the conference or meeting. Second, they are accessing the Edge Servers, not your internal environment. Third, they have authenticated to their environment and their Active Directory in the case of a federated relationship. This is similar to allowing a user to access your Web server, except that these services are using streaming protocols instead of HTTP. Administrative control determines the options that dictate which anonymous users can be invited and in what manner.
Global properties enable 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 R2 management console and right-clicking the Forest node. As shown in Figure 7-20, a menu enables you to select Properties and then Global Properties.
Figure 7-20. By selecting Global Properties, you can set properties that will be applied to the entire forest.
After you open the Global Properties dialog box, select the Meetings tab, as shown in Figure 7-21. You can select from three settings:
Allow users to invite anonymous participants. This option enables 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 invitations 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 client, and this can be controlled administratively as well. Just because users have the ability to send invitations does not necessarily mean that they are allowed to do so.
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 set whether a user can allow an anonymous user on a per-user basis. Although 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.
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.
It is sometimes necessary to explicitly block a specific domain because of continued unsolicited instant messages (SPIM) or attempts to compromise security. This is accomplished much like an Allow. Use the same beginning dialog box, but click the Block tab instead of the Allow tab.
Log on to the Access Edge Server as a member of the Administrators group or a group with equivalent user rights.
On the Access Edge Server, open Computer Management.
In the console tree, expand Services And Applications, right-click Office Communications Server 2007 R2, and then click Properties.
On the Block tab, click Add.
In the Add Blocked SIP Domain dialog box, in the SIP Domain text box, type the name of the domain to be added to the list of blocked SIP domains as shown in Figure 7-22. This name should be unique and should not already exist on the Block list for this Access Edge Server. The name cannot exceed 256 characters in length. Click OK.
