When to Use Resource Accounts

Applies To: Windows Server 2008

Resource accounts are simply user accounts that are stored in a resource partner forest. What makes a resource account different from a standard user account is that the sole purpose of a resource account is to represent the security context of a single identity that does not originate from the resource forest or from any trusting forests.

Because a federated identity is not created from the resource forest, it does not have a security identifier (SID) that identifies it as a security principal to standard, Windows-based authorization controls (such as access control lists (ACLs)) on servers in the resource forest. Therefore, the federated identity is prevented from gaining access to any Web-based federated resources in the resource partner, such as Windows NT token–based applications, that use ACLs.

Active Directory Federation Services (AD FS) requires a way for a federated identity to correspond or map to an existing security principal that does, in fact, have a SID that represents the resource forest. AD FS uses resource accounts to map federated identities to existing security principals.

AD FS creates a security token using the resource account. It then presents the SID of the resource account to any access control mechanism in the resource partner forest or a trusting forest. At this point—because there is a one-to-one mapping of the federated identity to the resource account—the federated identity can be treated like any other user account by Web server administrators.

Consider using the resource account mapping method when:

• You are deploying a Windows NT token–based application as your federated application, and it requires access control settings.

• You want to provide more detailed levels of access to sensitive or private data.

  For example, say that user AlanSh must have a different set of rights than the rest of the Information Technology (IT) staff. In this case, the fact that a user account is AlanSh is given preference in terms of access rights over the fact that he is a member of the group that represents IT staff so that he can get the allowed level of privilege.

So that federated users can access Windows NT token–based applications, resource accounts must be security principals in Active Directory Domain Services (AD DS). You cannot use Active Directory Lightweight Directory Services (AD LDS) user accounts as resource accounts in the resource partner forest. However, you can use AD LDS user accounts in the account partner forest. You can create a corresponding resource account in the resource partner forest to represent each AD LDS user account.

Best practices for using resource accounts

The following practices are recommended for using resource accounts to map to a federated user:

• As a security best practice, add all resource accounts to a security group. Then, add this group to the Deny log on locally and Deny log on through Terminal Services user rights in Group Policy.

• Create a single organizational unit (OU)—or perhaps one OU per account partner—where you can place all the resource accounts for a particular partner so that you can more easily manage or delegate administrative control through Group Policy.

• To prevent possible interruption of service for federated users as a result of password restrictions, configure each account (in the properties of the user account) so that the password never expires.

• To optimize how resource accounts are processed in the resource Federation Service, review the advantages and disadvantages of various resource account options. For more information, see Select the Optimal Resource Account Option.

• To decrease administrative overhead, write your own provisioning software with a claim transformation module to create a resource account automatically, based on the incoming claims. For more information, see Configure a Claims Transform Module.

Comparing resource accounts to resource groups

A single resource account has a one-to-one mapping to a federated user—and only that user. A resource group, however, has a one-to-many mapping scheme. You can use a single resource group to map to one or more federated users that are members of a security group in the account partner forest. For more information about resource groups, see When to Use Resource Groups.

Although both resource account mapping methods provide similar functionality, meaning that both methods provide federated users with a means to access resources without possessing their own resource forest SID, a resource group can usually provide a more well-rounded set of benefits than its resource account counterpart. This is mostly attributable to the amount of administrative resources that you can consume by regularly creating, managing, and pruning individual resource accounts.

As shown in the following illustration, the choice of a correct resource account mapping method for your deployment is important, because it can, over time, severely affect the level of administrative overhead in your organization.

Preparing the resource forest for resource accounts

If you decide to use the resource account mapping method, you must make some minor changes to AD DS. You must also make some minor access control changes to the AD FS-enabled Web server. As shown in the following illustration and described in the following steps, these changes include the following:

• Adding the appropriate user principal name (UPN) suffixes to the resource forest

• Creating each resource account using the appropriate UPN suffix

• Assigning the appropriate permissions to the resource accounts in the Windows NT token–based application

1. Add a UPN suffix to the resource forest for each account partner

The first step in successfully routing authentication requests that are sent from federated users in the forest of the account partner organization to Windows NT token–based applications that are hosted on an AD FS-enabled Web server in the forest of the resource partner organization is to add a UPN suffix to the resource partner forest for each account partner forest that contains federated users. For example, if you have two account forests named Adatum.com and Tailspintoys.com and the resource forest is named Treyresearch.net, you add Adatum.com and Tailspintoys.com as UPN suffixes in the Treyresearch.net forest.

For more information about adding a UPN suffix to a forest, see Add user principal name suffixes (https://go.microsoft.com/fwlink/?LinkId=108517).

2. Create the resource accounts using the account partner UPN suffix

After you add a UPN suffix in the resource forest to mirror the UPN suffix of the account forest, you create individual resource accounts and assign the newly added UPN suffix to them. The UPN suffix in the Security Assertion Markup Language (SAML) tokens that are created by the account partner must match the UPN suffix of the associated resource accounts for successful access to federated Windows NT token–based applications. For more information about creating a resource account, see Create a Resource Account in the Resource Partner Forest.

For example, say that Alan Shen is an employee of A. Datum Corporation. He regularly logs in to the network using his UPN, AlanSh@Adatum.com. The administrator for Trey Research has been given the task of creating a resource account for the AlanSh account. In this example, Adatum.com is the name of the account partner forest, and Treyresearch.net is the name of the resource partner forest. The administrator of Treyresearch.net uses the Active Directory Users and Computers snap-in to create a new user account. In the New Object - User dialog box, he types AlanSh in the User logon name field. He then selects the newly created UPN suffix @adatum.com in the drop-down list and creates the user account.

3. Assign access permissions to the resource accounts

After you create your resource accounts, configure your Windows NT token–based application on the AD FS-enabled Web server with the appropriate access permissions for those accounts. Depending on the application, you can configure access permissions using standard ACLs or the authorization controls that are built directly into some Windows NT token–based applications.

For example, if you want to configure an AD FS-enabled Web server to federate a Microsoft® Windows® SharePoint® Services site across organizations, you assign the resource account permissions using the Site Settings link on the Windows SharePoint Services site. For more information about AD FS and Windows SharePoint Services support, see Identify the Type of Federated Application to Deploy.