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 4 and 6 and type the answer here:
  • Post
  • Speed: can be fixed (see higher up in the log)

    Annoying window when accessing an older client: can be fixed - but you have to do it per RDP file. I have over 100. Well OK, you are working on it, fine.

    The fact that you make our jobs more annoying, make our users mad with US instead of you ("What is a domain? Turn it off!") and call that "balking at anything new", telling us it is our job to give support: that is infuriating.

    Last but not least: "Newer means different, and just because it exists doesn't mean you have to install it. " (Patrick Rous): LOL

    Is this an official statement? So now we are instructed to all turn off automatic updates?

    Good one!

    Please: come out of your ivory tower, listen to the IT people IN THE FIELD who deal with normal users. I really want to use your client, it is fast, secure and reliable. And it USED TO BE user-friendly.

  • I am one of the IT People in the field, and have been for 10+ years, not a MSFT Employee.  My contention is that developers that MSFT add features and make changes at the behest of customers, and people that bash them as if they're working 60 hours a week to intentionally annoy you with new features is a bit childish.  Points are received better if you merely make your case why a new feature is difficult to use, causes business interuption, loss of productivity or poses a security risk.  Calling people names and screaming like a 3 year old (not everyone in this blog) is pointless and non-productive.

    The bottom line is that one can choose to use Vista or not, use RDP 6.0 or not, roll back to RDP 5.1.x or 5.2.x or not, manage their clients or not, make tactful comments or not.  

    We've provided MSFT with your comments and concerns (along with our own) so you have been hear loud and clear.  

    P.S. When the next version is released, it would be prudent to test it before allowing it to be deployed on all of your systems.  I realize that no one has complete control over every piece of software installed on every system they support, but subscribing to "it was in Windows Update, therefor I installed it" is a system that will eventually bite you.  Any software deployed to a corporate environment should undergo some kind of testing.  Applying updates and hoping for the best is not a way to keep your end users happy and productive.  Supporting what gets installed on end user's home PCs is more challenging, but not impossible.  It's better to provide remote access via TSWeb (AKA Remote Desktop Web Connection - RDWC) or 3rd party software that you can control.  With RDWC you can control user's RDP Client configuration.

    If you have comments and suggestions (that haven't already been voiced in this blog) on how to improve the RDP Client, by all means provide as much detail about the problem/concern as you can, but please keep it civil.  

    Another place to ask questions about Terminal Services or RDP Client Functionality is:

    Windows Terminal Services Newsgroup:

    http://www.microsoft.com/technet/community/newsgroups/dgbrowser/en-us/default.mspx?dg=microsoft.public.windows.terminal_services

    Longhorn Server (LHS) Terminal Services Forum:

    http://forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=580&SiteID=17

    Patrick C. Rouse

    Microsoft MVP - Terminal Server

    Provision Networks VIP

    Citrix Technology Professional

    President - Session Computing Solutions, LLC

    http://www.sessioncomputing.com

  • When logging on to a SBS 2003 server, and trying to remotely access a client machine (Vista) I can only connect as localmachine\user and get dumped with a session denied if I try to connect as domain\user or just user with the domain preselected. This never happened with XP.

  • Steve Lavaysse's post above fixed my problem.   Dell on call couldn't figure it out, my computer administrator at work couldn't figure it out and I paid $50 to a consultant to figure it out. Thank you so much STEVE!!!

    Susan Schniepp

  • Why does the Remot Desktop now insert the string  "numeric domain/username" on the connection dialogue? This is not my username.

    It won't save my credentials using a "new account" either.

    I end up having to log in twice everytime. Seems to be a completely unnecessary hassle.

    Overall? I hate Vista.

  • When will an updated version of the 6.0 client be released that addresses the numerous bugs in the first release?  There are other MS forums that indicate that a bug release will be forthcoming but those posts are months old.  One is at:

    http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=988640&SiteID=17

    The excuses that MS has posed here and in other places about how the new RDP client works just isn't cutting it.  Simple Google search return numerous complaints and that MS provided no good ways to disable all the junk they added (how many of you are running Gold copies of Longhorn servers in production environments as of March 2007, exactly zero would be the answer) so the forcing of all the new junk on us is unacceptable, especially when there's no easy way to globally turn them off.  I personally carry the 5.2 client on a USB key and install it on every system, including Vista RTM boxes, to restore functionality.  I'd sure like the speed and dual monitor support of RDP 6 but the other bugs make it unusable.

  • Many users have downloaded the RDP 6.0 TS client through Windows update since it was released. We have

  • I have to also protest at the painful update the version 6 client is.  As I support many machines over 50 sites, I find using this client absolutely painful for pretty much all of the reasons given by your other readers (I wont go into boring details)

    Every one of my collegues I speak to in the industry agree.

    As a diagnostic tool the client is so painful to use I now telnet to port 3389 as it is quicker than launching the client, typing a username/password (oops, thats username\password because in a domain structure *everyone* wants to connect to the local user account of a server!) then getting security warnings, then wait 10 seconds while it authenticates, then comes back with an error saying it couldnt connect! Oh hang on, telnet isnt enabled by default in Vista. PAINFUL!

    You get the idea, give me back my version 5 clinet, it was a dream compared to 6.

    Thank you

  • remotely connecting to my customers from Vista has caused problems.

    1) whenever I connect now, I get prompted twice - the first time I enter my credentials, the second time it adds ip-address\user and password.  Clicking ok doesn't work, I have to retype it.  makes no sense

    2) After connecting to a 2003 server, now that server from an XP machine will not allow full-screen mode.. meaning the ability to have the Tack at the top of the screen is gone.  Only scroll bars are available now.

    We're about to start testing Vista in a large enterprise, these two things will surely cause us grief.  Any updates to RDP forthcomming?

  • Steve Lavaysse's post has nothing to do with the RDP client is' the foolish "autotuning" MS put into Vista that causes many more problems than it fixes.  For the most part the problem also isn't Vista it's hardware that doesn't support autotuning.  I know of $5,000 Cisco routers that don't support it.  The problem with autotuning is it isn't smart enough to see when it's casuing problems and AUTOmatically turn itself off.  

    Note to MS: AUTO means both ends of the spectrum.  Automatic cars downshift as well as upshift.  Autotuning needs to be able to disable itself when it's breaking more than it fixes.

    Now, let's get the rest of the RDP 6 "features" rolled back or otherwise fixed.

  • I have 10 pc's that are shared by 100 or so folks using terminal service. I make them type their full name and and a lengthy password to keep it secure, like a good admin should. They don't like remembering/typing all of this and complain. Thanks to RDP 6, they must now also type the domain as well. They hate me and have stopped sitting with me at lunch.

  • Those 100 people are just going to start clicking the save password box on the dumb RDP6 client and then they'll start buying you lunch because you cannot stop them now since MS, in their continued wisdom, has given us no Group Policy management tools to prevent this and no way like with the CMAK for VPNs to deploy a complied RDP client to prevent security breaches like this.  What will fix this is the first high-level developer or VP at Microsoft who gets a laptop stolen that had a bunch of RDP sessions with saved pwds in it and the next day there'll be an update to RDP 6 that allows us to turn it off (unless MS isn't using the public version on their desktops, which could be possible too).

  • I am trying to connect a Vista Enterprise to a 2003 Server with no luck, any ideas?

  • I'm having an impossible time getting Vista to connect to Win 2003 Server using Remote Desktop.  Was working fine until I upgraded to Vista Business on my laptop.  Now, I can never connect, not once has it worked, get a nonspecific error message "This computer can't connect to the remote computer..."

    I'm able to connect from XP Pro just fine  (it's on the same network as the Vista laptop) to the Win2003 server but not from the Vista laptop.

    Server 2003 is running RDP 5.2.

    Vista machine: Firewall is turned off, Server authentication set to "always connect...", TS Gateway set to "Do not use TS Gateway", confirmed login settings are correct.  I don't use a domain at the remote computer.

    Any help greatly appreciated.

  • With SP1 of Windows Server 2003 we got the ability to run RDP over a TLS/SSL

    session.  It requires a computer certificate on the server.  The certificate

    is a lot like a web site certificate but which has the FQDN of the computer

    as subject.

    In Vista, there is a certificate category called Remote Desktop which

    contains a self-signed computer certificate which is usable for TLS/SSL but

    which is not from a known certificate authority.  Hence, the client

    application warns the user.  Not a nice warning in these times.

    If I issue a computer certificate from my CA to my Vista machine, it goes

    into the Personal category.  Upon an RDP to the machine, the self-signed

    certificate is presented and the certificate from my certificate authority,

    which is known to the client, is not.  Hence, the same warning.  Both

    certificates have the same FQDN as subject.  The issued certificate is the

    right kind of certificate for RDP/TLS in Windows Server 2003.

    I wonder if there exist some official directions about how to clean this up?

    I found some workaround discussion in a Microsoft forum which was not good

    enough for a production process.

    Does the computer cert need to be in the Remote Desktop category?  Windows

    Server 2003 SP1 has no Remote Desktop category? Should the self-signed cert

    be removed?  Does the issued certificate need to be moved to the Remote

    Desktop category?  Will a new self-signed cert replace a deleted one?

Page 6 of 17 (244 items) «45678»