Does the Windows 7 RDP client authenticate differently than win 2008, vista, etc.?
I am having an ongoing issue, that I have been working at from the Win2008 TS side, but am now convinced that it is isolated to my Win 7 clients. I have a Windows 2008 server setup as my TS server, TSgateway. From all of my clients (with the exception of win 7) Vista, XP sp3, Win 2003 R2, Win 2008 R2 - I can RDP to my TS server and authenticate without issue. From my domain Win 7 32 or 64 bit clients, I recieve an error stating that "the certificate is not valid for this usage". If I view the certificate (a third party cert) from the client all my clients (win 7 included) show the certificate and the certificate chaing as "ok". I am going to setup a new Win 7 install and test connecting to the TS server, before I add the computer to my domain. I am trying this, because I don't recall having this issue from my home computer and it has been Win 7 for sometime. But all of my internal win 7 clients are displaying this error preventing connection and none of my non-win 7 clients are displaying this. Note the server certificate - SSL - name is the external server name - not the local domain name, but this is also the name I am using to connect to the server, and is the same for all the clients.So: my question - Does Windows 7 RDP client authentication work differently than win 2008, vista, etc?Fred Zilz
February 26th, 2010 9:44pm

Also, I just confirmed that if I remove my Windows 7 client from my domain - so that the computer is a workgroup computer (still physically on my local network), the error is no longer presented. Fred Zilz
Free Windows Admin Tool Kit Click here and download it now
February 26th, 2010 9:51pm

Hi, Regarding your question, I would like to share the following with you: Remote Desktop Connection 7 for Windows 7, Windows XP & Windows Vista If the issue persists, please also capture some netmon trace for our further research: 1. Download the Microsoft Network Monitor 3.3. 2. Install network monitor on the Windows 7 computer which is not in domain currently and start to capture. 3. Establish the RDP connection. 4. After it connects successfully, stop capturing and save the netmon trace file to check the related network activations. Then, add this Windows 7 computer to the domain, start capture; when the issue occurs, stop capture and save the trace. For your convenience, I have created a workspace for you. You can also upload the screenshot via the following link. (Please choose "Send Files to Microsoft") https://sftasia.one.microsoft.com/choosetransfer.aspx?key=a4fbd1e7-d13f-4cc5-92ad-040b008ad7e5 Password is “4e@y{B[mbFah” (without quotations). Thanks. Nicholas Li - MSFT
March 2nd, 2010 12:39pm

Thank you. Fred Zilz
Free Windows Admin Tool Kit Click here and download it now
March 3rd, 2010 2:18am

Ok- scratching my head. captured trace of RDP connection with Win 7 client before joining domain, then joined the desktop to the domain - and what does it do? It connects to the TS server without issue. I went back to a 32 bit and a 64 bit Win 7 clients and confirmed they are still showing the issue. Would it do any good to capture the trace from a seperate client which is demonstrating this issue? I uploaded the screen capture of the error message as well as the view of the certificate - which shows no error in web browser, etc.Fred Zilz
March 3rd, 2010 3:24am

I have checked several of the clients on my network and it now appears that the win 7 enterprise clients in my network are connecting to my TS server without an issue (looks like it did not have anything to do with the fact that the clients were domain or non domain win 7 clients). This leaves me with 2 clients both win 7 ultimate, one 32 bit and one 64 bit both showing the same error. I am checking to see if I can find another win 7 ultimate on my network to confirm if it is something to do with the ultimate version of win 7 or if it is something else entirely and this is just coincidental.Fred Zilz
Free Windows Admin Tool Kit Click here and download it now
March 3rd, 2010 3:43am

Hi, Thank you for updating and collecting the information. I found this may be also related to the certification; please check if there are any differences on the certificates between the worked Windows 7 computer and failed Windows 7 computer. In addition, I got the following: 1.3.6.1.4.1.4146.1.20 Organization Validation Certificates Policy You can also contact GlobalSign for more information and investigation: GlobalSign support Note: Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information. Regarding capturing netmon traces on the Windows 7 clients, I mean that we can make a compare of the worked Windows 7 client and failed Windows 7 client. In this way, we can narrow down the issue. Thanks. Nicholas Li - MSFT
March 3rd, 2010 10:52am

I'll capture a trace using netmon on a working and on a client that gets the error and upload today. Thank you again for assisting me with this. It is very frustrating. Note both the working and non working win 7 clients are connecting to the same TS server and or TS Gateway then server, and so all looking at the same certificate. and all clients when viewing the certificate show it as ok as well as the certificate chain. The RDP is set to auto for gateway use and the server is configured to not use the gateway for local network. I have verified that all clients have RDP configured the same. All clients are in the same subnet, on the same domain, have same dns settings. My Gateway service, server service, and and remoteapp service are all on the same physical server (we have a max of 10 users at a time (10 licenses) and usually only 2 or 3. If it is a problem with the certificate, then wouldn't all clients particularly all clients using the same version of RDP show the same error? This is the only reason I have not gone back to the SSL cert provider as I can't tell them what is wrong if something is wrong.Thanks again.Fred Zilz
Free Windows Admin Tool Kit Click here and download it now
March 3rd, 2010 8:19pm

I got to thinking about it and compared the root and intermediate globalsign certificates on all of the clients and saw that the intermediate cert on the two failing clients were different than the one on the working client - all were valid and showed as ok, but after removing the intermediate certs from the failing client and reconnecting - no more issue.Thank you so very much.It is funny that this turned out to be the issue as I have had an issue with the intermediate cert in the past, so this time I specifically installed the cert and intermediate along with the root to the server, but did not look to be sure that a different intermediate might be on the client.Fred ZilzFred Zilz
March 3rd, 2010 8:50pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics