Error citing a Remote Access Policy problem prevents connection via Terminal Services Gateway

Error citing a Remote Access Policy problem prevents connection via Terminal Services Gateway

  • Comments 2
  • Likes

Hello All! It’s Brett Crane from the Networking teams here at Microsoft. Today I wanted to take a few minutes to talk a little about an issue that we have found regarding Terminal Services Gateway.

The problem that we have seen may occur when a TSG client tries to connect up through the Terminal Server Gateway. It gives an error stating the following information in the popup:

Terminal Services Resource Authorization Policy (TS RAP) 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 this remote computer through the TS Gateway server.

- The name specified for the remote computer does not match the name in the TS RAP.

Contact your administrator for further assistance.

But if you look at your Resource Authorization Policy there doesn’t seem to be any problem. “I am trying to connect to a client that’s listed in my policy!” Well, that just may be the case…

There are a few things you should check in your environment to see if you are in a situation where your clients will notice this behavior even though you are configured properly:

1. How are you requesting your resource from your client? By this I mean... go into the RDP Client settings and look at the "General" tab. Under Logon settings, what does your client have listed as "Computer"? This will be the backend resource when going through TSG. Are you requesting the resource by NetBIOS machine name or by FQDN?

clip_image002

2. Do you have TSG configured to use Active Directory Security Groups?

clip_image004

3. What is the FQDN of the domain your clients are connecting to?

4. What is the NetBIOS name of the domain your clients are connecting to?

So now you have done the research and answered the questions listed above… what is the problem? Well, basically, when your Fully Qualified Domain Name differs from your NetBIOS domain name and you are using Existing AD security groups, we don’t complete a process properly when we access security rights for a RAP check. So when you use an FQDN when trying to request a specific back-end resource the failure happens.

“What can we do?” Well, we have found out what the problem was and have fixed the issue in future releases of the product.

“What about those of us who are in the predicament now?” We’ve released a Hotfix that will resolve this issue. You can download the hotfix by going to this link:

http://support.microsoft.com/kb/967933

Once there, click on “View and request hotfix downloads” found at the top of the page.

* When choosing the hotfix you will notice that the “Product” is listed as “Windows Vista”. This is normal. Windows Server 2008 and Windows Vista are built around the same platform.

** This hotfix will be included in Windows Server 2008 Service Pack 2.

“With all that known, is there a workaround?”  Yes! The easiest workaround to this whole issue is to not use a FQDN to reference the back-end resource in your Remote Desktop Client. Just call the resource by its NetBIOS name and everything should work fine. If there is an instance to where you need to use the FQDN, then configure the option in your TSG Resource Authorization Policy to use TS Gateway managed groups instead of existing Active Directory Security groups.

I hope this information has been very informative. Until next time… Safe computing!

- Brett Crane

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • remote desktop computer at work with us once in a while I'm connected to my work is very good care of me I thank you also for your

  • I guess this is the same in NPS on 2008 R2 when NetBIOS differs from FQDN of the domain. I cannot make connections to my RADIUS-clients because I get "There is no domain controller for domain NetBIOSname" all the time.