A connection authorization failure occurs when you use Windows Server 2008 R2 Remote Desktop Gateway to connect to an RD server, a virtual machine, or a desktop resource in a multidomain or multi-forest scenario
You use Windows Server 2008 R2 Remote Desktop Gateway (RD Gateway) to connect to an RD server, to a virtual machine, or to a desktop resource in an Active Directory Domain Services (AD DS) multidomain or multi-forest scenario. However, a connection authorization failure occurs, even for the users who are authorized in the RD Gateway connection authorization policy (CAP).
When the Remote Desktop Connection (RDC) 7.0 client is used to connect through the RD Gateway, you receive the following error message:
Remote Desktop can’t connect to the remote computer "<End Resource Name>" for one of these reasons:
1) Your user account is not authorized to access the RD Gateway "<RD Gateway Server Name>" 2) Your computer is not authorized to access the RD Gateway "<RD Gateway Server Name>" 3) You are using an incompatible authentication method (for example, the RD Gateway might be expecting a smart card but you provided a password)
When RDC 6.1 or an earlier version of the RDC client is used to connect through the RD Gateway, you receive the following error message:
Terminal Services connection authorization policy (TS CAP) is preventing connection to the remote computer through TS Gateway, possibly due to one of the following reasons:
* You do not have permission to connect to the TS Gateway server. * You used password authentication but the TS Gateway server is expecting smart card authentication (or vice versa).
A sample scenario
Definitions of terms that are used in the following sections
A foreign user or group: A user or security group that belongs to one domain (domain B) and that is included as a member of a security group that is defined in another domain (domain A).
A CAP root group: A security group that is included in the RD Gateway Connection Authorization Policy (RD CAP).
To authorize users who belong to a cross-forest user group, you must add the cross-forest user group directly as one of the authorized user groups in the RD Gateway CAP policy.
To authorize specific foreign users and not all users in a foreign group, you must add the users directly to universal groups in the RD Gateway domain.
For example, suppose that there is a Domain Local security group that is known as “CAP_root,” and this security group is created in domain A. This group is added as an authorized user group in the RD CAP.
The CAP_root security group has the following users and groups from domain A and domain B as its members:
Members of “CAP_root” security group
User from domain A
User from domain B
Security group that was created in domain A and that contains users from domain A
Security group that was created in domain B and that contains users from domain B
In this sample scenario, all users and groups from domain B (UserB and all users who are included in GroupB) encounter the issue that is described in this "Symptoms" section.Be aware that this configuration does work on Windows Server 2008. However, when you upgrade from Windows Server 2008 to Windows Server 2008 R2, foreign users who previously could connect through RD Gateway now receive the error that is described in this section.
This problem affects all RD Gateway foreign users and groups. This problem occurs in either of the following configurations in RD Gateway CAP:
Configuration 1: The foreign users are added directly to the domain local user groups in the RD Gateway domain. In this configuration, the foreign users' connections are denied, even if the domain local group is added directly to the RD Gateway CAP.
Configuration 2: The foreign group is nested in one of the domain groups that belong to the RD Gateway domain. In this configuration, the connections of the users who belong to the foreign group are denied, even if the parent domain group is added to the RD Gateway CAP.
To work around this problem, do not set Domain Local groups as CAP root groups in scenarios that require authorization of foreign users. In such scenarios, Universal security groups must be used as CAP root groups. However, the foreign security groups that are nested into the CAP root group do not have to be Universal. The foreign security groups can be Global instead.
In this example, if the "CAP_root" group is created as Universal (or if the CAP_root group is converted from Domain Local to Universal), then all nested users and groups are authorized appropriately.
Note This workaround has a limitation. Because Universal groups cannot contain users or groups from other forests, the administrator has to create a Universal group for each forest that has users or groups that require connections through the RD Gateway.
Consider the following scenario:
Create “CAP_root_ForestA” Universal security group, and then include users and groups from domains in Forest A in it.
Create “CAP_root_ForestB” Universal security group, and then include users and groups from domains in Forest B in it.
Create a RD Gateway Connection Authorization Policy with both groups, “CAP_root_ForestA” and “CAP_root_ForestB,” or create separate RD Gateway Connection Authorization Policies that have one of CAP root groups in each policy.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
This problem also occurs in Windows Server 2008 R2 Foundation, in Windows Small Business Server 2008 R2, and in Windows Essential Business Server 2008 R2.
For more information about the definition and scope of Windows Security Groups, visit the following Microsoft Web site:
For more information about how to configure a Remote Desktop Connection Authorization Policy, follow the steps that are provided in the RD Gateway step-by-step guide. To do this, visit the following Microsoft Web site: