Share via

Determine your resource account mapping method

  • Article

Applies To: Windows Server 2003 R2

In the past, Windows NT token–based applications could be used only by Windows users from the local forest or in trusting forests, that is, by users who could log on to the computer with Windows authentication techniques. By using Active Directory Federation Services (ADFS) and resource account mapping methods, you can extend access limits for Windows NT token-based applications, even across organizational boundaries in nontrusted forests.

In ADFS, resource account mapping is the act of mapping a federated user or a group of federated users to a security principal in Active Directory in the resource partner organization so that standard Windows authorization mechanisms can be applied to that security principal on the ADFS-enabled Web server. Resource account mapping is required when you federate Windows NT token–based applications because the Windows NT token–based Web Agent must reference an Active Directory security principal in the resource partner forest to build the Windows NT access token and thereby enforce access control permissions on the application.

Note

Claims-aware applications do not require resource account mapping because they use the ASP.NET membership and roles model, which means that they can inherently consume user principal names (UPNs) and group claims directly from the ADFS security token.

The federation server in the resource partner organization supports any combination of the following three resource account mapping methods:

  • Resource account

  • Resource group

  • Group-to-UPN mapping

You can use the information in the following table to help you determine which of these resource account mapping methods best suits your administrative needs.

Resource account mapping method Description Advantages Disadvantages

Resource account

A single security principal—usually a user account—created in Active Directory that is used to map to a single federated user
  • Detailed user access control

  • Verbose auditing results

High administrative overhead. Requires that account provisioning (creation, maintenance, and deletion) in Active Directory in the resource partner be tightly coupled with Active Directory in the account partner

Resource group

A single security group that is created in Active Directory that incoming group claims (ADFS group claims from the account partner) are mapped to. You can create more than one resource group.
  • Eliminates the need to create and manage separate resource accounts for each federated user

  • Uses standard access control lists (ACLs) to control authorization

  • Highly scalable: one resource group can support an unlimited number of federated users that are mapped to it

  • Accurate and accountable auditing results: The resource federation server provides a mechanism by which auditing can record events that uniquely identify each federated user.

The resource organization cannot control access to individual users, and it has to trust the account organization regarding group memberships

Group-to-UPN mapping

A group of federated users represented by the UPN of a user account that is created in the resource forest
  • Eliminates the need to create and manage separate resource accounts for each federated user

  • Highly scalable: one resource group can support a nearly unlimited number of federated users that are mapped to it

Inaccurate auditing results. Multiple user accounts are mapped to a single resource account that corresponds to a single UPN. Therefore, auditing cannot distinguish between the different accounts that were mapped.

Because resource accounts, resource groups, and group-to-UPN mappings are all used solely for resource mapping, these methods are not used when the following conditions are true:

  • The ADFS-enabled Web server and the resource federation server are joined to a domain in the forest or in a trusting forest where the identity resides.

  • A one-way, cross-forest trust exists from the resource partner forest to the account partner forest.

In these situations, the federated user needing access to the Windows NT token–based application can access the resources directly in the resource forest by using the Windows trust.

The following topics are also relevant to resource account mapping methods: