Problems using default credentials with Vista RDP clients with Single Sign-on Enabled

Problems using default credentials with Vista RDP clients with Single Sign-on Enabled

Rate This
  • Comments 28

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:

  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 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.

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:

  1. At a command prompt, run gpedit.msc to open the Group Policy Object Editor.
  2. Navigate to Computer Configuration -> Administrative Templates -> System -> Credentials Delegation.
  3. 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. 


    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.

    Leave a Comment
    • Please add 8 and 1 and type the answer here:
    • Post
    • @wins

      There is a chance that your connection problem might not be related to SSO.

      What error are you getting when connecting from your 2008R2 SP1 machine?



    • I post a comment but disappeared.

      I got a same error information as your first picture to indicate "your credential did not work". The username displayed in the screeen is same with current logon credential and right. After i key-in password then all is working fine.

      please advice.


    • @wins

      Are you connecting back to the local machine by any chance?

      In that case you might want to apply the workaround described here:



    • @Sergey

      I post this comment many times with about 2 hours interval, but it always is not displayed. Any limitation?

      This KB is for WIN2003 SP1 not 2008R2 SP1. Anyway, i try to applied this KB to change the registry in my 2008R2 environment, but it still failed after reboot.

      I also try to RDP local computer itself and it failed as well.

      If you can help to test it in your 2008R2 environment that would be appreciated.


    • Hi, Sergey:

      I try as possible as i can and it still failed.

      Please help.


    • I’m not sure what else could go wrong here. You could try adding "*" to both policies: "Allow Default Credentials with NTLM-only Server Authentication" and "Allow Delegating Default Credentials".

      This is just to rule out misspelling. Please check that the policies are enabled on the client side, not on the server. Also, please check that the error message you are getting is indeed the same as in the first picture of this blog, and it says that default credentials cannot be used because server’s identity is not fully verified.

      Thx, Sergey

    • @Sergey

      Yes. I add "TERMSRV/*" to both policies.

      Sorry for fault. I can not paste picture here.

      The error information is

      Windows Security

      Your credentials did not work

      The credentials that were used to connect to TS-SERVER did not work. Please enter new credentials



      the logon attemp failed.

    • @wins

      Ok. So it seems that your policy is configured properly.

      I did not quite understand form your previous replies: are your client and server two separate machines or you are connecting back to the same computer?

      When you are connecting to a file share on the same server, does it ask you for credentials?

      Are you using smartcard or password?

      Have you changed your password recently?



    • @Sergey

      yes. my client and server are two separate machines. Of course, i also try connecting back to same computer, but both failed.

      i am using password. i try to map network drive to the share folder on server and it is OK. I am not asked for credentials.

      no, i do not change password recently.


    • @Sergey

      Any advice would be appreciated.


    • @wins.

      I'm sorry, I'm starting to run out of ideas :-(

      One possibility is that you are connecting to a wrong machine, but then accessing a share on the same box would not work either.

      I don't know what else could it be.



    • @Wins, the best place to get help for an issue is in the RDS Web Forums found here: Many more people--dedicated support, MVPs, and other members of the community--will see your question there.

      Hope this helps,


    • @Christa

      yes. I searched before and same issue i found and not solved.

      that is why i did not ask there. anyway i will to ask later.


    Page 2 of 2 (28 items) 12