Remote Desktop cannot verify the identity of the computer you want to connect to. This problem can occur if:
- The remote computer is running a version of Windows that is earlier than Windows Vista.
- The remote computer is configured to support only the RDP security layer.
Contact your network administrator or the owner of the remote computer for assistance.
On your RDP client use the following procedure
- Click on “Options”
- Click on the “Advanced Tab”
- In “Authentication Options”, select “Always connect, even if authentication fails"
You did not provide additional info, so I cannot help you more.
what os versions do you have (client and server)?
what is your rdp version?
With kind regards
Follow me on twitter
I had a similar problem, however I was trying to connect to a Win7 machine from an iMac running 10.6.6.
All was working fine for the last few months then suddenly stopped allowing me to connect this morning.
I followed these instructions and now it's all back to normal so far.
Both give the same info, just happened across them at the same time. Hope this helps.
Is there any thing we can do on the remote computer side that'll fix the problem? I have the same problem with snow leopard connect to windows 2003 server.
If there is a win2003 hot fix for that, the problem shall fixed once for all. Identity cannot been verified may well be a problem of a server anyway.
I got the very same problem, trying to connect to a Windows 2008 Server, after the recent Office 2011 SP2 update (14.2.2). The server currently has a self signed security certificate. Clicking "Connect anyway" (or setting preferences to do so) worked before this update.
Same Issue with US , Solved by this.Need to update on Terminal Services Licensing Server and Terminal ServerTo resolve this issue, back up and then remove the X509 Certificate registry keys, restart the computer, and then reactivate the Terminal Services Licensing server. To do this, follow these steps.
NOTE: Perform the following procedure on each of the terminal servers.
- Make sure that the terminal server registry has been successfully backed up.
- Start Registry Editor.
- Locate and then click the following registry subkey:
- On the Registry menu, click Export Registry File.
- Type exported-parameters in the File name box, and then click
NOTE: If you have to restore this registry subkey in the future, double-click the Exported-parameters.reg file that you saved in this step.
- Under the Parameters registry subkey, right-click each of the following values, click
Delete, and then click Yes to confirm the deletion:
X509 Certificate ID
- Quit Registry Editor, and then restart the server.
- Reactivate the Terminal Services Licensing server by using the Telephone connection method in the Licensing Wizard.
NOTE: If you activate the Terminal Services Licensing server using the Telephone option, the licensing server uses a different form of certificate.
- Edited by Dhananjay Rai Tuesday, September 11, 2012 12:26 PM
Im using a Mac Mountain Lion OS X 10.8.2 and Remote Desktop version 2.1.1.
If you get an alert on Mac: in Remote Desktop Connection go to RDC Menu > Preferences > Security, then choose the option "Always connect, even if authentication fails".
This stopped these alerts on my machine.
- Edited by samoir Monday, November 19, 2012 8:46 PM
I too was having the problem same as error on my mac clients (which had previously worked fine). However, for me the problem all started when I replaced my SSL certificate that was used/selected in the Remote Desktop Session Host Configuration utility, connections, RDP-TCP Properties. The security layer is negotiate and the certificate is the one selected on that screen. It was not licensing related.
The certificate had expired and I didn't believe I needed it. But turns out I did, so I had to generate and validate a new one using GoDaddy (though they specifically were not part of the problem). As my Terminal Servers (Remote desktop servers) do not have IIS installed, I was a bit stumped on how to create a new certificate request. I finally found some instructions on how to create a certificate request using the MMC snap-in, advanced operations, create custom request. The template chosen was "legacy key", and without boring the rest of the details that part was the root cause of my problem. The legacy key was not able to be processed correctly by the Mac RDC client. Neither the official 2.1.1 client or the 2.1.2 download.
The Terminal Server system event log was showing the following two errors, 36874 and 36888. The first one contained the best details and said: "An TLS 1.0 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed." Upon searching the internet for that, I found this page which described the legacy key problem: http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/3a2d2eec-000d-432a-abd7-6b965268c671
So, my solution most familiar to me was to use IIS and create the SSL certificate request, process that with my 3rd party CA, export the certificate with private key and then import that certificate into all of my terminal servers. Then using the session host configuration tool, pick the new certificate and the problem was now solved.
Hello, this is a late follow up but the problem is still very few addressed in google, so here is my 2 cents.
None of the more easily found tricks worked for me (registry, wiping the mac keyring, deleting the config of the mac CDB,..)
The real root of the problem is really the TLS layer and the certificate. This thread was the one which pointed me in the right direction. The preceding post is the right way to do it for corporate users.
If you can't/don't want to afford a paid certificate, just stop using one !
I logged in my RDP servers and switched the RDP connection to only use RDP security.
This is no big deal for me as I also use a VPN to securely contact the production servers.
Only wondering if the RDP security layer alone is safe for a production server opened on Internet ?
I solved this by removing Remote Desktop for mac 2.1.1 and installed 2.0.1
On a fresh RDP Default profile, we were able to connect to our terminal server. Upon closing, saving credentials and configuration settings, we would not be able to log in again. This happens when your terminal server is set to allow "More Secure" RDP connections rather than the "Less secure" option.
Hope this helps someone else, but also try deleting your Default.RDP connection from Documents\RDC Connections.
I think the problem started for me when I upgraded the Windows box to 8.1. After checking here I saw that the mac remote desktop client was on ver 2.1.0, so I figured I'd check a later version.
There's a newer "Microsoft Remote Desktop" app in the mac app store which is at version 8.0.2. Installed that and tried it, works like a charm.
Version 8.0.5 working well w/ self-signed cert to Windows 8.1. I have to NAT my RDP connections, so I configure Windows to listen on a different port (not 3389)... and Microsoft Remote Desktop 8.0.5 works great with ip.address:port as host.