Cross-Forest Management Deployment Guide

Updated: June 3, 2010

Applies To: Forefront Identity Manager 2010

In the “Cross-Forest Management Using Forefront Identity Manager 2010 (FIM 2010)” solution guide, you find instructions for planning and implementing a cross-forest management solution in an enterprise environment using Microsoft® Forefront® Identity Manager (FIM) 2010.

• What This Guide Covers

• Reader Prerequisites

• Intended Audience

• Cross-Forest Object Management

• User Objects in AD DS and FIM 2010

• FSPs Used to Represent Users/Groups

• Group Membership Restrictions

• Limitations

Companion Guides

This guide is the first guide in the following series:

• Steps for Deploying Cross-Forest Management Solution Using Forefront Identity Manager (FIM) 2010

• Verification Checklist for Cross-Forest Management Solution Using Forefront Identity Manager (FIM) 2010

• Test the Deployment of a Cross-Forest Management Solution Using Forefront Identity Manager (FIM) 2010

What This Guide Covers

This guide offers guidance on how to manage objects in Active Directory® Domain Services (AD DS) using FIM 2010. In it, you will find information about implementing and configuring your cross-forest management solution. After you have read this guide and implemented its solution, you will be able to deploy a cross-forest management solution by using FIM 2010.

This guide does not cover the installation and configuration details of FIM 2010. For more information about the installation of FIM 2010, see Installation Guide (https://go.microsoft.com/fwlink/?LinkId=165845).

Reader Prerequisites

This guide assumes that you are familiar with configuring and administering FIM 2010, AD DS, and Windows SharePoint® Services 3.0.

Intended Audience

This guide is intended for IT planners, systems architects, technology decision makers, consultants, infrastructure planners, and secondary IT personnel involved in planning and deploying a cross-forest management solution by using FIM 2010.

Cross-Forest Object Management

Cross-forest management in AD DS requires the coordination of objects representing users between forests to maintain referential integrity and to enable clients to find users. For any users in a remote forest to be a member of a group in a local forest, the user must have a local representation: either a Foreign Security Principal (FSP) for security groups or a contact for distributions lists.

Cross-forest object management in AD DS is normally managed using Active Directory Users and Computers. However, by taking advantage of many of the elements of the Active Directory Users and Computers implementation, an external solution such as FIM 2010 can help you with cross-forest object management.

To enable cross-forest object management in AD DS, a number of individual solutions are needed. Specifically, the following items are required:

• FIM sets containing all members in the groups in a given domain who are not users in that domain (one set per domain)

• Codeless provisioning to create FSPs

• Ability to provision FSPs

• Codeless provisioning to create contacts

• Ability to provision contacts

• Codeless provisioning to flow group membership between FIM and AD DS

• Scoped reference attribute value transformation

• Ability to add non-users to non-groups in the FIM Add-in for Outlook®

• Group validation to ensure that group membership requests match group scores

In the Group Management feature of FIM 2010, each user may reside in any forest and should have the ability to be added to any group. By taking advantage of sets to determine which users or group are outside of their “home” forest, you can use codeless provisioning to create FSPs or contacts and the FIM Synchronization Service Component can provision the FSPs or contacts. Once created, codeless provisioning flows the membership between FIM 2010 and AD DS. Scoped reference attribute value transformation can ensure that the correct object, FSP, or contact, is added to the correct group type. Additionally, group membership validation must be performed to ensure that group scope membership rules are not violated.

In the FIM Add-in for Outlook, users can add other users to distribution lists without a full understanding of the underlying cross-forest topology. This requires the FIM Add-in for Outlook to make group management requests with objects that represent both local forest (users and groups) and remote forest (contacts) object types.

User Objects in AD DS and FIM 2010

A real person may have one or more AD DS accounts within any AD DS deployment, whether it is single or multi-forest. In most of these cases, these accounts represent the privileges for the real person, such as one account with administrator access and one account for daily work. In addition, trusted forest deployment may also have FSPs or contacts that represent the real person.

This solution maps every active, enabled AD DS account to a single FIM person. This FIM person may have zero or more associated FSPs and zero or more associated contacts. FSPs and contacts are managed by using synchronization rules. FIM only contains a single person object. This person object in FIM may have zero or more associated non-Active Directory accounts such as a Service Advertising Protocol (SAP) account created by using synchronization rules.

When more than one active AD DS account exists for a single real person, this real person is represented in FIM by multiple person objects. It is the end user’s responsibility to manage the correct FIM person object and its group memberships.

When implemented, this solution creates the following objects in AD DS:

FSPs Used to Represent Users/Groups

Between trusted AD DS deployments, an FSP can be used to represent a user or group in a remote, trusted forest, FSPs are always created in the organizational unit (OU) of the FSP (OU= ForeignSecurityPrincipals) within a domain. Each domain maintains a list of FSPs. Each FSP has the following required value:

• DN

• objectSid

• objectGuid

The objectGuid and objectSid are managed by AD DS. The objectGuid is a unique GUID created for the user when they are added to AD DS. The objectSid is the value of the objectSid from the remote user or group within the trusted forest. Security identifiers (SIDs) contain a domain component so that each objectSid uniquely identifies the domain in which the user or group resides. The DN, by convention, contains the relative distinguished name (also known as RDN) composed of the objectSid, formatted as a string, the FSP’s OU, and the domain. Therefore, a user or group in a remote forest and FSPs from the local domain can be equated by using the objectSid.

Domains within a forest do not require FSPs for group membership. A user from one domain can be added to a group in another domain within a single forest.

Group Membership Restrictions

Each group type and scope limits the types of object that can be members of the group. Specifically, distribution lists may contain mail-enabled objects, such as users, contacts, and distribution lists. Security groups may contain security-enabled objects, such as users, FSPs, and security groups.

Additionally, the following rules apply to groups based on the group scope:

• Domain local groups can have members from anywhere in the forest, from trusted domains in other forests, and from trusted lower-level domains.

• Global groups can have members from within their own domain (only).

• Universal groups can have members from any Microsoft Windows® 2000 domain in the forest. (Universal groups can contain members from mixed-mode domains in the same forest, but this is not recommended. Members from such domains cannot have the universal group's SID added to their access token because universal groups are not available in mixed-mode domains. Therefore, troubleshooting access problems would be difficult). This is primarily true for Windows 2000 mixed mode domains.

For more information about AD DS users and groups, see Active Directory Users, Computers, and Groups (https://go.microsoft.com/fwlink/?LinkId=186402).

Limitations

This section details the limitations of using FIM 2010 for cross-forest management as it pertains to:

• Group membership

• Group management

• Mail-enabled security groups

• Password reset

Group membership

FIM allows users and groups to be members of groups in FIM and does not enforce Active Directory semantics such as group scope and trusts. As a result, FIM allows group memberships that may not be accepted by AD DS. Some examples of memberships that FIM allows but that AD DS does not, include:

• Adding a User or Security Group that resides in one Forest to a Universal Security Group that resides in another forest.

• Adding a User or Security Group that resides in one Forest to a Domain-Local Security Group that resides in another forest which does not trust the forest in which the member User or Group resides

• Adding a User or Security Group that resides in one domain of a forest to a global Security Group that resides in another domain in the same forest

Group management

To manage cross-forest security groups, the FIM system must be able to detect transitions in and out of security groups and compare the forest of the added or removed member with the forest of the group. For static groups, this is detected by using a management agent policy scoped to Add and Remove operations on the Explicit Member attribute of objects in the All Security Groups set.

For dynamic groups, this detection is more of a challenge. Depending on the dynamic conditions for the group, FIM may need to detect every operation on potential members to determine if this change results in a transition to a dynamic, Domain Local, cross-forest security group.

To avoid examining all operations made to potential group members, we suggest that you implement cross-forest dynamic groups as a series of nested groups. First, start with a Dynamic Global Security Group for each domain. Each of these groups would likely contain the same filter, such as All People whose Manager is Britta Simon, and an additional clause, such as Domain is DomainName. Then, create a single Domain Local Security Group with static membership and add the Dynamic Global Security Groups as Explicit Members of this group. This creates FSPs for each Dynamic Global Security Group that requires one and allows the members of the Dynamic Global Security Groups access to the resources protected by the Static Domain Local Security Group.

Members are dynamically added and removed from the Dynamic Global Security Groups without the need for FSP since the Users are in the same domain as the Security Group, and therefore do not require the triggering of the management policy that controls FSP generation. Only the Dynamic Global Security Groups requires FSPs, and their addition to the Static Domain Local Security Group triggers the policies that result in the generation of FSP.

Mail-enabled security groups

Mail-enabled security groups are treated as security groups by the set and synchronization rule provisioning described later in this document. As a result, mail-enabled security groups, like non-mail-enabled security groups, have an affinity for a security principal. When a cross-forest user or group is added to a mail-enabled security group, the synchronization service attempts to include security principal, the foreignSecurityPrincipal, instead of the mail object, the contact.

However, mail-enabled security groups created by FIM 2010 are Universal. Since Universal groups cannot contain cross-forest security principals, AD DS does not accept the group membership.

Password reset

For password reset, there is only one known limitation. To perform password reset, the FIM Service account must be trusted by all domains that contain users whose passwords might be reset by FIM. This trust can be configured in a variety of ways, including Forest Trust, Forest Trust with SID filtering, or an External Trust. FIM Password Reset can work with any of these trusts providing that the FIM Service account is trusted by each domain that contains users that FIM manages.