Vista Remote Desktop Connection Authentication FAQ

Vista Remote Desktop Connection Authentication FAQ

Rate This

 Update: Some additional improvements are coming in this area.  Please see this article.

There has been a lot of feedback about the new authentication features introduced in the latest version of the Remote Desktop Connection client. These features are part of our efforts to improve security for Terminal Services (TS) in Windows Vista and Windows Server code name “Longhorn” , however some users have run into a variety of problems that have caused frustration. In order to alleviate some of the frustrations, below is an FAQ on various symptoms users have run into, along with solutions and workarounds.

  1. Prompted for Authentication Twice when connecting to TS in Windows Server 2003
  2. Prompted for Authentication Twice when connecting to TS in Windows 2000 Server
  3. Credentials Entered in TS client rejected when connecting to Windows Server 2003
  4. Saved credentials do not work
  5. Cannot use smart card credentials to logon when running Remote Desktop on XP or Windows Server 2003?
  6. How to remove invalid pre-populated domain names
  7. The pre-populated username in the credentials dialog does not match the username that is in the RDP file?
  8. Can’t change domain name when running Vista Remote Desktop Connection client.
  9. How to eliminate the  ‘Remote Desktop Cannot verify the identity of the computer you want to connect to…” messages
  10. When to use the “enablecredsspsupport:i:0” RDP file option.

Prompted for Authentication Twice when connecting to TS in Windows Server 2003

When using Remote Desktop Client 6.0 to connect to a Windows 2003 machine, some users have to enter credentials twice. Once before connection they will see Picture 1 below if they have Windows XP or Windows Server 2003 as the client or Picture 2 if they are using Windows Vista as the client.

Picture 1 - Windows XP - Windows Server 2003

Picture 1

Picture 2 - Windows Vista


 The second time they will be prompted as the remote servers logon screen (picture 3)

No error messages will be shown.

Picture 3

 

Answer: This is most likely the result of the way the remote server is configured. There are two possible settings that may be causing this:

  1. The most likely is the “Always prompt for password” setting is enabled on the server. In order to disable the setting,  the administrator of the server you are connecting to must run Terminal Server Configuration administrative tool (tscc.msc) and double click on RDP-Tcp. In the “Logon Settings” tab, there is an option labeled “Always prompt for password” (see the option circled in red below).

  2. Alternatively: For Windows Server 2003, an administrator may have set the group policy located at: “Administrative Templates\Windows Components\Terminal Services\Encryption and Security\Always prompt client for password upon connection”. For Vista, this same policy is located “Administrative Templates\Windows Components\Terminal Services\Terminal Server\Security\Always prompt client for password upon connection.”  Note: This policy is set as not configured by default; if this has been set remember it could have been configured either on the local group policy or a domain based group policy.

When either the option in Terminal Server Configuration administrative tool (tscc.msc) is selected or the group policy is enabled, the TS server will always show a winlogon prompt, regardless of what version of the Remote Desktop Client the user is running.

Prompted for Authentication Twice when connecting to Terminal Services in Windows 2000 Server

Why do users always have to enter credentials twice on Windows 2000 Server?

Answer: The setting in tscc.msc mentioned in the first question is enabled by default on Windows 2000. The administrator should disable this setting to fix the undesired behavior. Afterwards, the user can expect to not run into the winlogon screen or duplicate prompts.

Credentials Entered in TS client rejected when connecting to Windows Server 2003

Why is it that when connecting to Windows Server 2003, the credentials entered in the credentials dialog are rejected as follows:

AlwaysPrompt

Answer: The above behavior is caused when winlogon on the TS server cannot validate your credentials. This may be from a number of reasons: For example, the password or username may be incorrect. Other times, (and this may be the most frustrating to users), the domain may be in a format that is not recognized by the TS server. The best thing to do, when entering credentials into the credentials dialog, is to make sure that the domain, username, and password are all in a format that the server will accept. For example, let’s say one tries to connect to MyServer and you intend to log in with the MyUserName account from the MyDomain domain. If the user will just type in “MyUserName” in the User Name field in Credentials Dialog, the Windows 2003 Server will automatically pick “MyServer” as the domain value for login and the login will fail. But if the user provides “MyDomain\MyUserName” as input for the User Name, logon will complete successfully.

Saved credentials do not work

Despite having saved credentials, users are still prompted to enter credentials on the remote server’s winlogon screen.

Answer: This can be due to one of two reasons. Either one of the policies mentioned in the answer to the first question are enabled, or the credentials that have been saved are not valid.

In instances where the saved credentials are not valid, there is one possible scenario that may lead to this behavior and cause user confusion. Consider the following:

  1. User tries to connect to server. His username is “MyDomain\test1” and his password is “LogMeOn”
  2. In the credentials dialog, user mistypes his credentials. For his password, instead of typing “LogMeOn”, he types “LogMeO”.
  3. User hits connect, and hits the winlogon screen. There is an error on the server stating “The system could not log you on. Make sure your User name and domain…”, just as in the example above
  4. User properly types his credentials into winlogon, and gets his session.
  5. The next time he goes to connect to the server, the saved credentials will not work.

This is because the credentials that have been saved on the client side are:        

Username: MyDomain\test1

          Password: LogMeO

Note that the password saved is not correct. This happens because whenever the user selects “Remember my credentials” in the credentials dialog, the credentials that are saved are whatever was typed in the credentials dialog. If the credentials are updated after connecting to the server, the correct credentials are not propagated back to the TS client and updated.

If the saved credentials are not correct, you may edit or delete them in Remote Desktop by clicking on the “Options” button. The dialog below should appear. Clicking “delete” will delete the saved credentials, and clicking “edit” will allow you to modify them.

Note that if the text “The saved credentials for this…” do not appear, then credentials are not saved.

Cannot use smart card credentials to logon when running Remote Desktop on Windows XP or Windows Server 2003?

Some users are having trouble using smart card credentials to logon.

Answer: To ensure that you can connect to Windows XP or Windows Server 2003 with smartcards, make sure that smartcards redirection is enabled.

  1. Smart cards must be redirected. To redirect smart cards, click “Options” and select the “Local Resources” tab. In the tab, click on the button labeled “More”. In the dialog that pops up, make sure “Smart Cards” is clicked, as shown below:

  2. Use the drop down box in the credentials dialog to select your smart card credentials. In the example below, the user has the credentials “ZK-07\Administrator” selected. Instead, he needs to select the smart card credentials “Foo-Bar - ITG XXXXX” that is circled in red below.

How to remove invalid pre-populated domain names

Some users have noticed that an invalid pre-populated domain name is placed in front of the user name in the credential dialog. Users are frustrated at having to delete this bad domain on every connection. The sequence of steps causing this behavior is as follows:

  1. User wants to connect to a machine via IP address, say 127.0.0.1.
  2. He enters the correct password and username “Administrator”. He successfully logs on.
  3. The next time he attempts to connect to 127.0.0.1, he sees in the “User name” field of the credentials dialog “127.0.0.1\Administrator”. The user deletes the text “127.0.0.1\” from the user name field and logs on. On successive connections, he is forced to keep deleting this extraneous text.

Answer: When a domain is not presented for the username, Remote Desktop assumes by default that a local server account will be used and the domain name is pre-filled accordingly. In this case, the server name entered was “127.0.0.1”, and as a result, the domain entered was the same. This was done for various reasons in Vista that are too complicated (and irrelevant) to go into detail here.

The best workaround for this behavior is to always enter a proper domain into the credentials dialog. If you are connecting to machine “MyMachine” using the “Administrator” account, do not just enter “Administrator” as the username, enter “MyMachine\Administrator”. From there on out, the proper domain and username will be prepopulated in the credentials dialog. Alternatively, if the user account is an account named “DomainUser” in the domain “MyDomain”, use “MyDomain\DomainUser” instead of just “DomainUser”.

The pre-populated username in the credentials dialog does not match the username that is in the RDP file?

Despite having a string in the RDP file “username:s:Machine\Administrator”, the pre-populated username in the credentials dialog is something different (or maybe even blank).

Answer: This is a result of a design change. Instead of populating the credentials dialog with the last username used to connect to any server, we felt (and received positive feedback) that we should populate the credentials dialog with the last username used to connect to the specific server the user is connecting to. We felt this would provide a better experience. The downside is that users connecting to various machines with the same username would now have to reenter the username once upon their first connection to a machine. From then on, the username will be pre-populated on subsequent connections.

Can’t change domain name when running Windows Vista Remote Desktop Connection client:

In the dialog below, some users don’t see how to change the domain from “127.0.0.1” to “MyDomain”

Answer: To change the domain used in the credential dialog box show above you simply put a fully qualified domain username or UPN.  For example if the domain is called “MyDomain”. Simply enter “MyDomain\<username>” or username@domain.<fqdn> into the username field and the domain will automatically be updated, as shown in the two examples below.

 

 

 

How to eliminate the ‘Remote Desktop cannot verify the identity of the computer you want to connect to…” messages

When you connect to server with the ‘always connect, even if authentication fails’ setting set you will see the following notification dialog:

 

Answer: Before connecting, in Remote Desktop, do the following:

  1. Click on “Options”
  2. Click on the “Advanced Tab”
  3. In “Authentication Options”, select “Always connect, even if authentication fails, as seen below:

This will disable the warning prompt. Please be aware that selecting this option makes it possible for attackers to intercept and modify the data exchanged between client and server.

When to use the “enablecredsspsupport:i:0” RDP file option.

Several other forums on the internet have suggested placing “enablecredsspsupport:i:0” in the RDP file used by the Remote Desktop client.

Answer: This option does disable the new credential prompting behavior, but it also disables support for Network Level Authentication for Vista (and Longhorn Server) RDP connections; Network Level Authentication requires credentials to be provided by the client before a session is created on the server side.

This option is meant for dealing with unexpected failures on connections using Network Level Authentication.

We strongly recommend users avoid using this flag unless none of other fixes described in this post work and no other alternative is available.  If this setting is used try to limit its scope as much as possible by using it only those RDP files meant for connections to specific servers (i.e. avoid setting it in your Default.rdp file).

Deploying this configuration option widely will cause hard to diagnose issues when connecting to Vista and Longhorn Server computers that require Network Level Authentication.

 Update: Some additional improvements are coming in this area.  Please see this article.

Leave a Comment
  • Please add 2 and 3 and type the answer here:
  • Post
  • Maybe i'm stupid .. but who wants to save the credentials to a machine ?

  • I do, because it is more convenient, and I don't see any disadvantage in doing so.

  • I'm on Vista Business Edition. When attempting to RDP to a W2003 server, I cannot paste in the password, even though I have the clipboard configured to do so.

    Is this a new 'feature'?

  • Today I received an angry call from one of our branch offices, telling me that most terminal clients don’t work anymore. Further inspection revealed that the cause is the new handling of credentials in TSC 6.0: The terminal clients are XP machines with a custom GINA that invokes mstsc.exe (within the guest account context) with a pre-defined tsc.rdp file upon CTRL-ALT-DEL. The RDP file contains the username and domain. Thanks to the new “ignore” feature, this doesn’t work anymore and users complain why they have to provide the username and why they have to do this twice (wrong domain name). I just hope that the “store password” feature is disabled under guest account context; otherwise I can kiss security good-bye. Well, I guess its my fault for trusting Microsoft and enabling auto-approval at WSUS. Because removal isn’t possible, I’m now honored of having the privilege to set-up new clients from scratch. But believe me, this time it’s going to be a Linux solution using rdesktop or something alike.

  • Manuel, the username that is no longer stored in the RDP file is now stored in the registry, in "HKCU\Software\Microsoft\Terminal Server Client\UsernameHint". I dont see why entering the username is not a one-time cost. Secondly, what is the wrong domain issue? If your users enter the username with the correct domain the first time around, they should not have to enter the username twice.

    Bryan, I will look at your issue later today and come back with an answer.

  • @Zardosht:

    First of all, thanks for your answer. Allow me to elaborate the problem to further extend.

    “If your users enter the username with the correct domain the first time around, they should not have to enter the username twice.”

    The problem is that most users don’t know what a domain is. Seriously. Up to now, the domain name was stored within the RDP file and was preset, no user knowledge or interaction required. Now they have to retype the domain name every time they log on after somebody else, since a terminal client is used by many users connecting to the same server, or carefully select the previous username with the mouse up to the backslash and change the text, which might even take longer. So not only do they have to know what their domain is, they also have to keep in mind how to combine it with their username correctly.

    However, that’s not the real problem. The real problem is the “save credentials” option, which is enabled by default. I know that it can be disabled by calling mstsc.exe with /public but guess how surprised I was to find out that now one terminal client user could actually open his/her account to everyone else!

    So either change the custom GINA to call mstsc.exe with /public or set enablecredsspsupport:i:0. Well, I choose the second option. Now the only thing users have to do is to select their domain from a list of three (well actually four), which is tolerable. I just don’t get it why you chose to ignore the username/domain settings in RDP files even if enablecredsspsupport is disabled.

    Otherwise, the new Remote Desktop seems to be awesome. Spanning, seamless apps,... Thumbs up on those new features.

  • As for the real problem: "save credentials option, which is enabled by default". Are you sure this is the case? We do not intend on having the "saved credentials" option enabled by default, and we have not heard any reports until now that this was the case.

    As for the other issues, we have received feedback from various sources in different scenarios. We are currently looking at ways to make the experience better, and will take this feedback into consideration.

    Thanks for your input.

  • Bryan: The behavior you see is the intended behavior for the credentials dialog throughout Windows Vista.

  • Zardosht, thanks for the reply.

    I can certainly understand the need for this in the normal UAC elevation prompts, but I respectfully submit that it may be a really bad idea for the RDP client!

    Consider the case of the support technician who follows strong password complexity guidelines for dozens or hundreds of remote systems; keeping his very complex mixed-case+non-alphanum passwords in a string password manager program. He used to be able to open his password manager, copy the password, and paste it into the RDP dialog. Now that's no longer possible and he must type these purposefully long, painful, hard to type and remember passwords into the RDP dialog.

    It probably won't be long before he gives up and goes back to easily typed, remembered, and broken passwords!

    Please, dear god please, provide some option for allowing paasswords to be pasted into the RDP dialog!

  • Bryan, thank you for your feedback. However, this is not a Remote Desktop issue. The credentials dialog is a property of Vista, not Remote Desktop. You will also see the same dialog when you try to join your machine to a domain.

    I will forward your feedback to the appropriate people.

  • Yes, I understand - I'm suggesting that the TS ceredential dialog perhaps *not* use the Vista one, but rather present its own, so as to preserve paste-ability.

    Just a thought, but I suspect admins everywhere will thank you, once they start to grasp the impact of this.

  • As usual Microsoft throws caution to the wind, ignores the whole concept of backwards compatibility, and decides to take something that half worked, and screw it over completely.

    The Authentication implementation is a joke, it seems to drop the connection, takes ages to connect to any server... Surely people who implemented it were using it everyday to check whether it is indeed usable.

    Just like VS 2005 SP1, it fixes somethings, but breaks others, and the thought of having to compile a .Net 1.1 application in 2005? Gasp, horror and God no.

    Thank goodness I can take it off via an update rollback and the old one seems to work okay.

    Progress and change are good, as long as their beneficial and don't implore some fundamental problems.

  • Daniel, not all issues are authentication issues. If you are running the RDP client 6.0 on an XP or windows server 2003 (win2k3 )machine, and connect to a Win2k3/XP machine, I do not think authentication is slowing down the connection.

    Can you please describe the behavior you are seeing in detail? Is the connection dropped? Always? Sometimes? How much longer does it take to connect? Does connecting to all servers exhibit this behavior?

  • need help here...just upgraded my vaio from XP Professional to Vista Ultimate...here I am away on business and now I cant connect to my office...really bad news...costing me hndreds of thousands of dollars...I am eliminating vista for good, how do i remove vista and roll back to xp???? help me quick

  • I would like to add my negative experiences with the RDP client 6.0, we have blocked its installation on our network.  I have the following issues

    1.  The workaround for the dual authentication prompts is not acceptable.  We enable the setting to always prompt for authentication on all our Terminal Servers to ensure that no user connecting to our servers is doing so from cached credentials.  Following your suggestion means that only users with the latest client will be definately be prompted, we cannot ensure this when staff are working from outside the network.

    2.   I agree that it takes much longer to connect to a server with RDP 6.0 than previous versions, the "connecting to" box takes up to 10 secs to appear.

    3.   Having an authentication process that cannot as yet be enabled on the current server operating systems is rediculous.  Whilst an IT savy user will simply okay the warning, most of our users that received the prompt were confused, afraid they were doing something wrong and did not connect until they had contacted support.

    4.   The save password feature does not work when connecting remotely, I try to cache them when working from home and it doesn't save.  I then do the same thing when connected to our LAN and it does then work from then on anywhere.

    5.   Why take away the separate domain field?  I hate this in Vista as well, users get confused by it and it just makes it easier for them to mistype during connection.

    6.   Currently I need only one icon to connect to all our servers with each username password set or I can use another server icon just by changing the computer name.  Now each time I do this I have to re-enter the credentials as well.

    Basically I agree with some of the points that heightened security is good, but I do not think enough thought has gone into its implication in this case.  It is far to confusing for end users, its authentication system must allow it to work alongside current clients without compromising server security and most importantly this must be fixed before vista becomes widespread

Page 2 of 17 (244 items) 12345»