Note: This post was updated with improved suggestions.
With Single Sign-on enabled, the current user’s credentials, also known as “default credentials”, are used to log on to a remote computer. In several scenarios, users may get the following error message when trying to connect to a TS server with Vista clients using default credentials:
Below is a list of scenarios in which this problem appears, along with recommended solutions.
Scenario 1: Connecting to a stand-alone computer
Windows Credential Delegation policy does not allow the RDP client to send default credentials to a TS server when the TS server is not authenticated if you have enabled only the "Allow Delegating Default Credentials" Group Policy described in the Single Sign-on blog post. By default RDP clients use the Kerberos protocol for server authentication. When connecting to a stand-alone server that is not domain-joined, the Kerberos protocol cannot be used for server authentication.
To enable server authentication, use SSL certificates that are issued by a trusted Certificate Authority and have the server name in the subject field. Deploy them to all servers that you want to have server authentication. To set the SSL certificate on a TS server for a connection:
Scenario 2: Connecting to a terminal server farm
Kerberos authentication does not work in terminal server farm scenarios because farm names do not have accounts associated with them in Active Directory. Without these accounts, Kerberos-based server authentication is not possible.
To enable server authentication in a server farm, use an SSL certificate that is issued by a trusted Certificate Authority and that has the farm name in the subject field. Import and deploy the same SSL farm certificate to all the TS servers (and dedicated redirectors) in your farm following steps outlined in Scenario 1 above.
Note: When importing the farm SSL certificate to multiple TS servers in the farm, ensure that it can be used for server authentication and is exported/imported along with its private key.
If you cannot deploy SSL certificates as described in the recommendations above, another option is to allow delegation of users’ default credentials with NTLM authentication mechanism, which is less secure compared to Certificates or Kerberos. To set this Group Policy setting locally on your client machine you need to:
When enabling this policy, you also need to add "TERMSRV/<Your server name>" to the server list for all servers to which you want to allow NTLM-only server authentication.
Scenario 3: Connecting from home to a TS server through a TS Gateway server
When you connect from home through a TS Gateway server to a TS server hosted behind a corporate firewall, the TS client has no direct connectivity to a key distribution center hosted on a domain controller behind the corporate firewall. As a result, server authentication using the Kerberos protocol fails.
First, you will need to set the Group Policy Setting "Set TS Gateway server authentication method", which is illustrated in the Single Sign-on blog post.
Second, you will also need to set the “Allow Default Credentials With NTLM-only Server Authentication" Group Policy setting described above for the endpoint TS Servers.
PingBack from http://microsoftnews.askpcdoc.com/authentication/problems-using-default-credentials-with-vista-rdp-clients-with-single-sign-on-enabled
I saw USB Key credential provider:
Tried it both as a local/GPO and not working for me. Running VMM2008 Trial version. My hyper-v machines running server 2008 Ent with hyper-v and are also domain controllers.
Are you running Terminal Servers on those Hyper-V machines? That's what this blog post is referring to.
not running TS on the servers, only hyper-v virtual machines
You may want to check out the Hyper-V blog, http://blogs.technet.com/virtualization/ or the Virtualization community: http://technet.microsoft.com/en-us/virtualserver/bb676714.aspx
I'm stuck in scenario 3 trying to create an SSL certificate with the farm name in the subject field and authorise it with our CA Server.
Any suggestions what I'm doing wrong, please?
- 1) create custom certificate request in MMC on the terminal server, setting either the DNS name to farm.example.com, or cn=farm,dc=example,dc=com
- 2) Save it and import into the CA
- 3) CA rejects it saying "The DNS name is unavailable and cannot be added to the subject alternate name. 0x8009480f. Denied by policy module"
It sounds like this error is because the farm name has no account associated with it in AD. But if that's the problem, how does one ever get around it?
First, thanks for the article. I have a question about Scenario 1. Do I need to get a SAN certificate since the Subject name needs to be the server name? The subject name would also need to be th External FQDN for the website to avoid ssl warnings within the browser as well.
I am playing with TS 2008 and have it running but when I connect to the TS I get prompted
Reply to Simon...
It sounds as though your CA is Enterprise - nedd to change the policy module to manual so that you can deliver the certificate yourself.
My name Jos Munnik and I’m working for a company in the Netherlands where we are implementing an SBC envirionment. I’ve read your article on www.virtualizationadmin.com about “Enable Single Sign-On for Windows Server 2008 Terminal Services”.
When following this great guideline and implemented it in our new environment I stumbled with an big issue. When connection directly to an Remote Desktop Server SSO work perfect. Only in our case we are connecting to an Remote Desktop Session Host Farm implemented with an clustered connection Broker and DNS-Round-Robin.
DELEGATION OF CREDENTIALS IS NOT POSSIBLE TO THIS HOST. (BECAUSE THE HOST DOES NOT REALLY EXIST)
When I was investigation this problem I figured out that it isn’t possible to delegate the users credentials to the farm address. After research I found an article to enable an Kerberos Identity for the RD Session Host Farm.
Only we cannot use this configuration because we run our Connection Broker as a node in a Failover Cluster.
Important! Kerberos identity is not supported if the Connection Broker runs as a node in a Failover Cluster.
My question to you is do you know if this problem is solved when we use certificates to authenticate (SSO)?
- If this problem can be tackled with Certificates do you know an where to find an guidline how to configure this with certificates ?
- Do we need Subject Alternative Name Certificates for this configuration ? with the farm name included ?
Additional Infrastructure Information:
New SBC project;
- 10 Remote Desktop Session Hosts (Windows Server 2008 Enterprise R2)
o Configured as joined in an Farm
- Connection Broker runs as a node in a Failover Cluster
o Round Robin (because of best practice)
- 2 Remote Desktop WebAccess / Gateways
o Load Balanced with NLB unicast 2 Nics in every machine.
If you have an better idea about this configuration please let us know.
Waiting for your answers.
With Kind Regards,
Could you please explain the steps in performing this procedure using the Microsoft PKI CA infastructure? We can request Certs just fine and have SSO working when using a single server however the SSO does not work with the farm for the reasons explained above. What are the steps to request a cert using the MS PKI and having it based on the farm name in the subject field.
Yes, installing a farm certificate should solve your problem.
To Jos and bzwart:
You'd have to manually request a certificate for your farm. You can create a new certificate template just for this purpose (using Certificate Templates MMC Snap-in) and in the "Subject Name" tab select "Supply in the request". This template would allow you to specify the subject name and the subject alternative name in the request. The subject alternative name should be set to the DNS name of your farm.
Alternatively, you can purchase a certificate for your farm from a public CA.
I've the problem only with Windows 7 client. When I try connect with Windows XP/SP3, the issue don´t appears, but when I use the Windows 7 the TS SSO don´t work. I've tryed the recommendations for scenarios 1 and 2 and tryed the workaround, but the problem persist.
Are there any things to do on the server side?
I am implementing SSO without SSL certificate but with default credential delegation. However, i can connect to my WTS2008 R2 SP1 from XP SP3 computer, but i cannot connect from 2008R2 SP1 computer. I ensure "Allow Default Credentials With NTLM-only Server Authentication" and "Allow Delegating Default Credentials" are enabled in GPO with "TERMSRV/*".
I try to find the solution from internet with google, microsoft, this blog but no result. I even installed hotfix KB2522762 which to solve same in RDWeb, but it still does not help me.
can you please advice?