Problems using default credentials with Vista RDP clients with Single Sign-on Enabled
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:
Possible causes (and their recommended solutions) are identical to the issues presented for saved credentials. Just as it does with saved credentials, Windows Vista Credential Delegation policy does not allow a Vista RDP client to send default credentials to a TS server when the TS server is not authenticated. By default Vista RDP clients use the Kerberos protocol for server authentication. Alternatively, they can use SSL server certificates, but these are not deployed to servers by default. There are three common scenarios where using the Kerberos protocol to authenticate the server is not possible, but using SSL server certificates is possible. Because SSL server certificates are not deployed by default, using default credentials does not work in these scenarios.
Below is a list of scenarios in which this problem appears, along with recommended solutions. This is identical to the scenarios for saved credentials.
Scenario 1: 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.
Scenario 2: Connecting to a stand-alone computer
When connecting to a stand-alone server, the Kerberos protocol is not used.
Scenario 3: 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.
Recommended Solution for Scenarios 1 & 2
For scenarios 1 and 2, 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 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.
Recommended Solution for Scenario 3
To enable server authentication in a server farm, use SSL certificates that are issued by a trusted Certificate Authority and that have the farm name in the subject field. Deploy them to all servers in your farm. The SSL certificate will provide server authentication for a TS server and therefore Credential Delegation policy will allow saved credentials to be used for remote desktop connections.
Alternative workaround for these scenarios (less secure than recommended options):
Another option is to allow delegation of users’ default credentials with NTLM authentication mechanism. This option is not recommended because NTLM-only server authentication does not confirm the server's identity. Sending your credentials to such servers can be dangerous.
- 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.
