1

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?

DougN
  • 670
  • 2
  • 7
  • 16
  • 1
    Have you tried adjusting the RDP restriction on the Windows 2008 server? – Vick Vega Apr 14 '11 at 20:10
  • How would I do that? I've looked around, and the only option I've found is when connecting you can specify "Connect and don't warn me" if server authentication fails. The server is already set to "Allow connections from computers running any version of Remote Desktop". Are there other settings? – DougN Apr 15 '11 at 04:04
  • No, can you tell me what you see in the enent log of both machines? What the event ids? – Vick Vega Apr 15 '11 at 13:45
  • Added information about the events – DougN Apr 19 '11 at 22:30
  • You said the tunneling was like SSH, but not exactly...can you tell us more specifically how the tunneling works? That might be causing the issue. – Rjcassara Apr 20 '11 at 19:06
  • Well, it's custom. I questioned my implementation, but it works great for RDPing to Win2003, XP, VNC, etc. Just fails with 2008/Win7 -- and the Event Log entries show why -- the RDP client is sending what it thinks is the server name to the server, and the server doesn't recognize the name it received. The 2008 machine expected TERMSRV/{2008_server_name}, but received TERMSRV/{WIN7_name}. So the Win7 client sent it's own name (makes sense--that's the side of the tunnel it connected to). But now you can't tunnel RDP... – DougN Apr 25 '11 at 19:27

1 Answers1

3

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).

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • That looked very promising, but so far none of the servers that I've investigated have had that box ticked. – DougN Aug 19 '11 at 16:43
  • @DougN: I've dropped on an edit w/ some addt'l ideas. – Evan Anderson Aug 19 '11 at 18:52
  • Well I can't reproduce the problem any more :( But I know it was happening -- I had those Event Log entries to show for it. I'll award you the points and answer the question. If it ever happens again, I'll come back. Thanks – DougN Aug 24 '11 at 19:37