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:


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
  2. He enters the correct password and username “Administrator”. He successfully logs on.
  3. The next time he attempts to connect to, he sees in the “User name” field of the credentials dialog “\Administrator”. The user deletes the text “\” 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 “”, 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 “” 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 8 and 2 and type the answer here:
  • Post
  • @ Stan

    Its called backup your data and reinstall XP, there is no rollback

  • I hear your complaints, but have one comment.  I never provide end users with direct access to the Remote Desktop Client, but rather have them logon via the Remote Desktop Web Connection, where you force the proper configuration on the end user, rather than relying on the end user to select the proper configuration settings.

    For managing many machines, there are better suited tools than mstsc.exe, i.e. the Remote Desktops MMC or even better the free vRD (VisionApp Remote Desktop).

    Your comment about offering an authentication mechanism in a client that is not available in every server OS is not logical.  Is Microsoft supposed to go back and add NLA to RDP 4.0, 5.0, 5.1, 5.2, i.e. on every OS that ships with Terminal Services (not going to happen).

    Client features have always been limited by the capability of the RDP host, i.e. Terminal Server, and the client OS, i.e. one can't connect to 2000 TS witn color depth > 8 bit, and one can't save credentials on legacy clients, i.e. Win9x, because the cryptography mechanism is not downlevel compatibile.

    Constructive criticism to MSFT is a good thing, but complaining because they made something new to work with a future OS is a bit much.

    It's your job to implement technology appropriately, and there are several ways around each of the problems people are complaining about, i.e. don't use the RDP 6 client, use the Remote Desktop Web Connection, don't check the NLA settings, block installation of the client via GPO...

    Newer means different, and just because it exists doesn't mean you have to install it.  If you do install it, or allow it to be installed, it's up to you to test and implement it in a way that you can support it.

    Patrick Rouse

    Microsoft MVP - Terminal Server

    Citrix Technology Professional

    Provision Networks VIP

    President - Session Computing Solutions, LLC

  • I upgraded my XP Professional to Vista Ultimate, so why is it that I can NOT connect to  my office computer using Remote Desktop? It did work perfectly on the XP and very quickly....Is there something I need to do? It asks for my screen name and passwrd, but will not accept it.... Please help...and advise


    Stan , Miami FL

  • how do I remove remote desktop 5.1, I want to install rd 6.0

  • Rosalie, You can get it from Windows update.

  • When ever I connet to my Vista box via remote desktop I am unable to get a normal console session to run after disconnecting

  • @ Patrick

    You miss the point, its not offering a new protocol/client and creating updates for the old OS's out there...

    its making the client have the SIMPLIFIED ability to run as its predecessors.

    ie. you click on the options button and change the Default Security behavior from that of RDP6, to be that of RDP5... that way the client can act like RDP 5 did and won't require pre-filling out the user and password.

    Now let me also expand on THAT part.. have you ever fat fingered an IP or host name?

    So then how secure is it, if you have a user fat fingering IP's or Hosts, putting in their user credentials, and then sending them off to some unknown IP somewhere?

    The point of the credentials first wasn't security on the client side, and wasn't really security at all from what I've gathered.. but rather to make a DoS attack less easy to the server, by making the authentication happen *before* the server creates a user login space, and uses those resources.  Thus no denial from opening 100 connections to the server, it attempting to create 100 sessions with only 512 megs of ram, or any other resource the server doesn't have ample supply of..

    And that part is actually even more simple... that is handled by having VPNs!  Client double clicks the icon, it starts the local VPN to office connection, and then starts RDP to the server of their choice..

    It just seems microsoft didn't get that people actually have to work with their softare, and that people wouldn't be so annoyed by some BS stance on security.  Well.. they were wrong again..

    just like forcing people to use UNC style naming for domain\usr ... there is NO need for the user to understand UNC if they have three boxes (user / pass / computer or domain)

  • MSTSC 6.0 - So is there a way to skip the initial credientials dialog box and force the user to authenticate at the server login prompt? Our users are hard to train and we don't want them to be confused by this. I have written a script that you can double click and type the server name and it bypasses this but I would prefer to just roll out a policy that surpresses the dialog and forces the login at the screen. PHEW!

    Thoughts or work-arounds?

  • OK, I'm not a Terminal Services expert and I don't understand half of this nonsense, I merely have a 2000 Terminal Server with access restricted to a single App through the RDP client. This is all internal.

    So my boss gets "Automatic Updates" and installs this stupid RDP client (to take issue with Patrick this update was installed by our German IT manager and he wouldn't have known it would cause all these problems even if he'd read the update notes. It is so trivial I don't blame him, it is down to MS to decide what are "appropriate" updates and suprise suprise they pick one which causes me a couple of hours work and sends us all gaily skipping down the path to Vista upgrade through exhaustion).

    OK, so I've got around the dual login issue no problem.

    As far as I can see you haven't answered the domain problem. It is this. In the old RDP client you could input a server name and a domain to log onto, then the client would log into the particular server, but the login screen would be populated with the domain name.

    As it is there doesn't seem to be a way to get the client to do this any more, therefore the dialogue defaults to logging onto the server, however I want them to default to logging onto the domain, they don't have a server account.

    End result they have to change the server name to the domain name every time.

    You've mentioned this but you don't seem to understand the problem, and everyone else appears to have given up on it.

  • Rich, the implicit understanding when connecting to Win2k3 and XP machines is that if the username you enter has no domain, then the server name is assumed to be the domain.

    If you want the proper domain and username, look at

    The users need to enter "MyDomain\username" instead of "username", and from then on out, "MyDomain\username" will show up as the username hint in the credentials dialog.

    This is the intended behavior

  • So, How to I get back to where I can store credentials?  My RDP either has only the Delete option for credentials (on RDP files I previously had stored), or for a new RDP file, only says Credentials will be prompted for when you connect.

    I need to change a password and cannot find out how to get to the edit option, and for new connections, really want to save credentials.

  • credentials are now stored in the credentials manager (credman) of windows.

    In mstsc.exe, click on the options tab and you should see how to edit/delete credentials

  • Saved credencials my be a good thik, if I could get it to work.  Otherwise, it's a pain to enter that info in twice.  I agree that we should have a choice.  And who idea was it to remove Hyper Terminal?  I found the download and reinstalled and it works just fine.


  • A comment and a question:

    I've currently only updated my personal workstation.  All users continue to connect through a custom web page which launches the RDP5 ActiveX control.  A quirk I've noticed is that even though I connect with a fqdn which is saved locally and works well enough, upon logoff the domain name is removed from the Winlogon section of the registry.  Users come along after me and can't logon because the logon defaults to the local machine.  I've had to set a script to run at admin logoff that repopulates the domain name in the terminal server's registry.  

    Something else I've noticed is that when I connect to the same RDP5 ActiveX web page the users do, I get a prompt from what's clearly the RDP6 client requesting access to local drives.  Strange given that I didn't remove the control nor did I alter the web page.  Would someone elaborate on the relationship between the ActiveX control and the new RDP6 client?  Is the ActiveX OBJECT tag in the web page even necessary now?



  • Some places have been suggesting to use 'enablecredsspsupport:i:0' as a way to avoid getting prompted for username and password on RDP connections. The side effect is that it also disables Network Level Authentication support in Vista and Longhorn, whic

Page 3 of 17 (244 items) 12345»

Vista Remote Desktop Connection Authentication FAQ