RDP from 2008 R2 through a tunnel fails

Question

I'm trying to RDP from a Win7 to a 2008 R2 machine through a tunnel (think SSH, but not exactly).

It fails and the following is in the 2008 R2 (destination) event log:

System Event Log, LsaSrv source, Event ID 6037

"The program lsass.exe, with the assigned process ID 632, could not authenticate locally by using the target name TERMSRV/{WIN7_name}. The target name used is not valid. A target name should refer to one of the local computer names, for example, the DNS host name.

Try a different target name. "

The WIN7 side shows:

System Event Log, TermDD event source, Event ID 56

The Terminal Server security layer detected an error in the protocol stream and has disconnected the client. Client IP: {WIN7_name}.

(with an error code of C000018D = STATUS_TRUSTED_RELATIONSHIP_FAILURE)

So apparently the the RDP client is passing the local server name to the remote side (I did tell it to RDP to the Win7 machine, but to a tunneled port).

I haven't been able to find any way to tell the RDP client or server to ignore this problem. It looks like it would be possible to use setspn.exe to set the {Win7_name} service principle name on the 2008 R2 box, but that seems messy, and in my case, my clients won't know how to do that. Plus, you'd have to do it for all clients that might connect to that server.

Is anyone else able to RDP between 2008 R2 and Win 7 using tunneling?

Answer 1

It sounds like you've got the server computer setup to only allow RDP connections that pass "Network Level Authentication" (certificate-based authentication to prevent man-in-the-middle attacks). You can turn this off on the server side by going into "Remote Desktop Session Host Configuration", bringing up the properties for the "RDP-Tcp" connection in the "Connections" dialog, and unticking the "Allow connections only from comptuers running Remote Desktop with Network Level Authentication".

When you do this be warned that an attacker could setup a bogus RDP server that appears to be your server for the purpose of collecting passwords.

Edit:

Using rinetd to tunnel a local port on a Windows 7 Professional machine to the RDP port on a Windows Server 2008 R2 computer I am able to access the remote computer fine w/ the Microsoft RDP client.

It feels like your RDP client isn't falling back to NTLM after Kerberos fails. I'm not immediately seeing what configuration setting might casue that to happen, though. Do you have any policy settings on the server computer to disallow NTLM authentication?

I'd be curious to know if disabling CredSSP would help. Save the RDP connection properties to a file, edit the file with your favorite text editor, and add a line enablecredsspsupport:i:0 (or, if the line already exists, change '1' to '0' and the end of the line).