Share via

When to Use Resource Groups

  • Article

Applies To: Windows Server 2008

In its simplest form, a resource group is a security group in the resource partner forest. Depending on the needs of your organization, you can create a resource group in Active Directory as a domain local group, a global group, or a universal group. When it is used with Active Directory Federation Services (AD FS), however, a resource group becomes a highly effective mapping method that administrators can use to easily map multiple federated users to a single security group.

Resource groups are considered to be a low-cost alternative to resource accounts because they do not require the administrative overhead that is associated with creating and maintaining resource accounts. Consider using the resource group mapping method when:

  • You must eliminate or reduce the use of resource accounts. For more information, see When to Use Resource Accounts.

  • A Windows NT token–based application will be deployed as a federated application, and it requires per-group authorization.

Mapping federated users to a resource group

After federated users have been mapped to a resource group, AD FS-enabled Web servers can make authorization decisions to Windows NT token–based applications based on the access permissions that are assigned to the security identifier (SID) for the resource group. Federated users can be mapped to multiple resource groups for role based access control.

Windows NT token–based applications require access control mechanisms that are based on a valid SID that originates from the resource forest. When a Security Assertion Markup Language (SAML) token from an account partner organization is presented to the Federation Service in the resource partner organization, the resource federation server maps the claims in the SAML token to organization claims that are defined in its own organization, and it forms an organizational token. A component of the Federation Service that is referred to as the mapping module maps claims using the rules that you provide in the properties of the account partner in the resource Federation Service. If the organizational token contains any group claims that are associated with resource groups, the resource group information is also added to the SAML token. When this organizational token is presented to the Web application, the AD FS Web Agent for Windows NT token–based applications has an authentication package that can create tokens for federated users with group memberships as the resource groups in their token.

The following illustration shows the mapping module and how organization claims that have been previously mapped to a resource group carry the SID of the resource group into the new SAML token for the federated user. This illustration also shows how you can map multiple account security groups to a single resource group.

How resource groups are applied to the SAML token

The following illustration and corresponding steps show what happens when resource groups are applied to the SAML token.

  1. The SAML token is sent by the account partner, and it contains the incoming group claim payload, along with any other claims that are assigned to Nate.

  2. The mapping module in the Federation Service extracts Nate’s claims from the SAML token and associates those claims with organization claims that reside in the Federation Service.

  3. If the administrator has mapped an organization claim in the Federation Service to a resource group, the SID for that resource group is added to the new SAML token that the resource federation server creates.

  4. The new SAML token for Nate, which now includes the SID of the resource group, is then sent to the AD FS-enabled Web server through a client redirect so that the Web server can perform an access check against the access control lists (ACLs) that are associated with the Windows NT token–based application.

How resource groups provide access control

The following illustration and corresponding steps show what happens when resource groups provide access control.

  1. A separate SAML token is created for each federated user and then sent by an account federation server to the resource federation server. Each token contains incoming group claims along with any other claims that are assigned to that federated user.

  2. The mapping module in the Federation Service extracts the claims and maps them to organization claims that reside in the Federation Service.

  3. If resource group SIDs are mapped to organization claims that are used by the incoming claims, these SIDs are added to the new SAML token that is created by the resource federation server. These SIDs are then sent in the token to the AD FS-enabled Web server.

  4. The SAML token is used by the AD FS-enabled Web server to perform an access check on the Windows NT token–based application.

  5. The access check determines whether or not the client has permission to perform the current operation with the application.

  6. The AD FS-enabled Web server returns a page to the client, depending on the outcome of the access check.