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.
Recommendation:
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:
- At a command prompt, run tsconfig.msc. Note: tsconfig.msc is only available on servers.
- Double-click the RDP-Tcp connection object.
- On the General tab, click Select .
- Select the certificate you want to assign to the connection, and then click OK .
Scenario 2: C onnecting 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.
Recommendation: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.
Alternative workaround for scenarios 1 and 2:
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:
- At a command prompt, run gpedit.msc to open the Group Policy Object Editor.
- Navigate to Computer Configuration -> Administrative Templates -> System -> Credentials Delegation.
- Select the "Allow Default Credentials With NTLM-only Server Authentication" setting:
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.
Recommendation:
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.