Problems with RDP/RDC from Mac OSX to Windows Server 2008 on External IP

Question

We have a customer that is using Mac and Microsoft's RDC for Mac to their servers.
They've just upgraded from Windows Server 2003 to 2008 and can't connect through RDP to their TS server on external IP.
Their servers is not in any domain and it work for them to connect to another Windows Server 2008 that is located in their office when they use internal IP.
The problem is that when using RDC to the external IP they get bellow:
"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."
From here they can choose "Connect" as they did on the Server 2003 but now they get: "Remote Desktop Connection cannot verify the identity of the computer that you want to connect to.Try reconnecting to the Windows-based computer, or contact our administrator."
and is only able to choose "Ok".
I've changed the settings on the "configuration for host server for remote desktop sessions" under General from "RDP-Security Layer" to "Negotiate" and in this case I get a logon windows where i type in all my information click logon. Here I get another
error message which says something like: (We get it in Swedish). "Connection to the windows-based computer broke since there was a problem associated with the licensificationprotocol... Try to connect again" Where I can choose "Cansel" or "reconect"
but it just keeps poping up if i chose reconnect.
I've tried all settings in the TS server and there is not much to change on the RDP client. We have installed the server certificate on the Mac client but it didn't help.
We've also tried with CoRD and it works fine as RDP from a normal Windows based computer.
The only solution I've found on google is to use CoRD instead but we got problems with that connection since it keep crasching on our computer.
In my eyes the problem is on the security requirements that the RDC for Mac needs but I can't find any inforamtion on MS sites about it.
Greatfull for all tips and trix!

Answer 1

I too was having the problem same as everyone else. 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.