Windows Vista Credential Delegation policy does not allow a Vista RDP client to send saved 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 saved credentials does not work in these scenarios.
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.
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:
1. At a command prompt, run tsconfig.msc. Note: tsconfig.msc is only available on servers.
2. Double-click the RDP-Tcp connection object.
3. On the General tab, click Select.
4. Select the certificate you want to assign to the connection, and then click OK.
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 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.
PingBack from http://blogs.msterminalservices.org/conger/2007/07/31/problems-using-saved-credentials-with-vista-rdp-clients-and-above/
You speak about kerberos for server authentication with saved credentials.
But does the RDP client support plain kerberos authentication for authenticating the server to the RDP client but also for authenticating the user to the TS ?
Yes, RDP client supports Kerberos user authentication.
However, it never uses plain Kerberos protocol. It uses CredSSP instead: http://msdn2.microsoft.com/en-us/library/bb204772.aspx
I currently use a Certificate for the TS Gateway. But always wondered what to do then teh Session Broker "Farm" serves up TS1 or TS2.
In addition to the FARM I've pretty much added many computers to the TS RAP. Does each machine need to have it's own Certificate or should they all have a common Certificate?
If I set up AutoEnrollment on an Enterprise CA (2008) for all domain joined computers and I am remotely connecting to these domain joined computers, should I having the Enterprise Root Certificate installed on my ..... I think I'm answering my own question... that might not be good; what about others logining in....
How about this: How can I access ALL the domain joined computers using a Cert. (some type of a common Cert) and still allow individuals to access a specific servers by issuing a Cert. for just that Server/Machine?
I'm still getting aquainted with rolling out a CA, in general.
Treetop Publishing, Inc.
As a general rule sertificate's subject name must match the name used to connect to this server. So, certificates on computers joined to a farm should have the farm name, while certificates for stand-alone TS servers should have computer name.
You can use a common certificate for a farm, but you need a separate cert for each stand-alone server.
Vista will be the biggest failure in Microsoft's history.
It would be nice if they could support existing customers and fix problems with 6.0 - such as the fact that many organisations rely heavily on the domain:s: parameter in RDP files because of being a multi-domain, multi-terminal server site with trusts.
Such issue was reported back in late 2006!
With 6.1 client you can use "username" parameter in RDP file for the same purpose. If you only need to specify domain name you can set it like this:
username:s:<your domain name>\
This will not work with 6.0 client, though.
With 6.0 client you can acheive the same result by modifying “HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\UsernameHint” registry key.
Regarding with Scenario3: I think the issue is the SPN. It is impossible to registering the same SPN to multiple servers. However it is possible to registering the SPN to the user account too. So if the services are running under a Service Account, you can registering the SPN to this Service Account.
Is there anyway available to configure the Terminal Server service is running under the specified Service Account. Is it tested? Is it supported?
Unfortunately, it is not possible today to configure TS to run under an account other than NETWORK SERVICE (or SYSTEM). Other services and drivers rely on TS to run under this account. We are working on solving this problem (Kerberos authentication in TS farm scenarios) in the next OS release.
With Single Sign-on enabled , the current user’s credentials, also known as “default credentials”, are
There needs to be another scenario - connecting to a Windows 2008 server. It seems as though he default security settings in Windows 2008 do not allow a Vista client to connect with saved credentials. This is behavior that has changed from Windows 2003 Server, but it is not documented, nor is the solution commonly known. This blog would benefit from the additional information.
Thanks for your feedback. The scenarios in the blog post above assumes that you are connecting to Windows 2008 Server. There could be several reasons why you are not able to connect with saved credentials - do you have SSL certs deployed on the WS08 or do both client and server have access to KDC to do Kerberos Authentication?
You should check what your GP for set credentials are set to under Computer Configuration -> Administrative Templates -> System -> Credentials Delegation. You can also refer to the similar post on default credentials for more information: http://blogs.msdn.com/ts/archive/2008/04/30/problems-using-default-credentials-with-vista-rdp-clients-with-single-sign-on-enabled.aspx
We want to implement a SSO solution based on a Smardcard that contents the information for the authentification. But we want also allow RDP session to this Desktop from a SSL VPN solutions using a End Point that will not have the Smartcard drive. How to have the compatibility of the SSO infrastructure with the RDP Session through SSL VPN Session
Are you using the remote computer name or the computer IP to connect using RDP? I have a Vista client that would connect with saved credentials to one TS but not another. The only difference was computer name vs. computer IP. I changed the problem RDP to the computer name and was able to connect with saved credentials.