Bug 4920

Summary: Fix issues with server redirection implementation of rdesktop.
Product: ThinLinc Reporter: Henrik Andersson <hean01>
Component: | rdesktop (deprecated)Assignee: Henrik Andersson <hean01>
Status: CLOSED FIXED    
Severity: Normal Keywords: astrand_tester, prosaic
Priority: P2    
Version: 4.1.1   
Target Milestone: 4.2.0   
Hardware: PC   
OS: Unknown   
Acceptance Criteria:
Bug Depends on: 4933    
Bug Blocks: 4911    

Description Henrik Andersson cendio 2013-11-28 07:01:56 CET
There are several issues identified but the main parts are:

- Implemented the unimplemented parts of the redirection packet.

- Stop handle password as string, it's a blob that should be passthough
  to the target server.
Comment 1 Henrik Andersson cendio 2013-11-28 07:06:40 CET
(In reply to comment #0)
> - Implemented the unimplemented parts of the redirection packet.
> 

Investigate and implement the following redirection data:
PDU_REDIRECT_DONT_STORE_USERNAME
PDU_REDIRECT_USE_SMARTCARD
PDU_REDIRECT_INFORMATIONAL
PDU_REDIRECT_HAS_TARGET_FQDN
PDU_REDIRECT_HAS_TARGET_NETBIOS
PDU_REDIRECT_HAS_TARGET_IP_ARRAY
Comment 2 Henrik Andersson cendio 2013-11-28 07:11:36 CET
Upstream commit r1756 renames PDU_REDIRECT_HAS_COOKIE to its proper term PDU_REDIRECT_HAS_LOAD_BALANCE_INFO and makes it dynamically allocated.
Comment 3 Henrik Andersson cendio 2013-11-28 07:13:17 CET
(In reply to comment #1)
> Investigate and implement the following redirection data:
> PDU_REDIRECT_INFORMATIONAL

Upstream commit r1758 prevents a redirection if redirect packet is flagged for informational use.
Comment 4 Henrik Andersson cendio 2013-11-28 07:16:17 CET
(In reply to comment #1)
> PDU_REDIRECT_HAS_TARGET_FQDN

If target fqdn is provided use it as target for the redirection.
Upstream commits r1759 and r1760 fixes this.

Commit 1761 fixes a related bug with string size.
Comment 5 Henrik Andersson cendio 2013-11-29 08:04:08 CET
(In reply to comment #0)
> There are several issues identified but the main parts are:
> - Stop handle password as string, it's a blob that should be passthough
>   to the target server.

This is done in several steps:

Upstream commit r1769 , fixes a bug were wrong codepath was chosen. The codepath is used by reconnect not redirect.

Upstream commit r1768. make use of the redirect password blob if exists in the logon packet sent to server.

Upstream commit r1766, cleans up and clarifies the logon packet,
TS_INFO_PAKCKET, TS_EXTENDED_INFO_PACKET, almost a total rewrite due to strange implementation.

Upstream commit r1765, reads the password in a server redirect packet as a blob (cookie) instead of a unicode string.

Upstream commit r1764, fixes so that parsing of the redirect packet is done as by the spec. This is however a strange thing and need more investigation and testing against 2003 server, because obviously this have worked against windows 2003.
Comment 6 Henrik Andersson cendio 2013-11-29 08:09:23 CET
The current implementation used a constant PDU_REDIRECT_HAS_COOKIE which actually is a load balance info blob, cleaned up and clarified the implementation in upstream commit r1756.
Comment 7 Henrik Andersson cendio 2013-12-05 15:11:49 CET
Commit r1770 fixes an error with redirection in a WTS 2003 farm, a network error was raised due to connection was dropped by the WTS. While this flag was true and a connection to the target server failed.
Comment 8 Henrik Andersson cendio 2013-12-05 15:12:41 CET
Commit r1771 makes use of g_redirect flag in logics where it is used and when used clear this flag.
Comment 9 Henrik Andersson cendio 2013-12-05 15:14:56 CET
Tested:

2008r2 farm with 2 servers, both servers configured with SSL, server redirection works as expected, no credentials is needed to be entered in the logon to target server in the redirection.

2003 farm with 2 servers, one configured to use SSL and the other plain RDP, redirection works as expected.
Comment 10 Henrik Andersson cendio 2013-12-10 12:36:08 CET
Upstream commit r1777 fixes a problem with server redirection on Windows 2012r2 platform which with this fix is working as expected.
Comment 11 Henrik Andersson cendio 2013-12-12 13:36:47 CET
> PDU_REDIRECT_HAS_TARGET_NETBIOS

This is useless and left unimplemented.

> PDU_REDIRECT_HAS_TARGET_IP_ARRAY

This redirect data is left unimplemented due to its a big code change
and not clear from spec why and how its used.
Comment 12 Henrik Andersson cendio 2013-12-12 16:30:12 CET
Vendordrop of upstream in commit 28197
Comment 13 Peter Åstrand cendio 2014-04-16 14:30:28 CEST
I'm re-opening this bug not because I have found any faults, but because I've failed to setup a 2012R2 test environment. Thus, need to cooperate with the Guru to achieve this. Documentation of work so far:

Determined that we should test on the following platforms:

Windows Server 2003		
Windows Server 2008 R2		
Windows Server 2012 R2	

As far as I can tell, it should be possible to run the RDP Session host on the DC in all these cases, thus allow us to use only 2 machines. I started out with Windows 2012 R2, but failed. I've tried re-building the 2012R2 setup 3 times, using different approaches. Still no go:

* With rdesktop, it sometimes works to create a new session. When I had 2 machines, it worked to create sessions on the "slave" (machine only running RD Session Host). Now with 3 machines, it only works to create sessions on the machine with RD Session host as well as the Broker. In other cases, rdesktop just exits silently with exit code 76. 

* With mstsc.exe on Windows 7, it basically does not work at all. Note the difference that in this case Kerberos-CredSSP is not used, but instead NTLM-CredSSP. In many cases, I just get an error saying "Logon failed". In other cases (when I had 2 machines), I got a very long error message saying that the client could "verify the farm". This person has the same problem:
http://serverfault.com/questions/479026/how-do-i-connect-to-an-rd-farm-using-the-farm-name

When I get "Logon failed" with the Windows 7 client, this is followed by an error event in the Event Viewer:

Source:        Microsoft-Windows-Security-Auditing
Date:          2014-04-16 13:46:45
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      peter-216.lkpg.cendio.se
Description:
An account failed to log on.

Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Logon Type:			3

Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		astrand
	Account Domain:		Win7

Failure Information:
	Failure Reason:		Unknown user name or bad password.
	Status:			0xC000006D
	Sub Status:		0xC0000064

Process Information:
	Caller Process ID:	0x0
	Caller Process Name:	-

Network Information:
	Workstation Name:	WIN7
	Source Network Address:	-
	Source Port:		-

Detailed Authentication Information:
	Logon Process:		NtLmSsp 
	Authentication Package:	NTLM
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

When Googling for this, we got some hints about that it should help to "Disabling Loopback Checking" (see 
http://social.technet.microsoft.com/Forums/windowsserver/en-US/1001bb80-c490-4ec6-828a-9090588c570c/cannot-remote-desktop-into-windows-2008-server-eventid-4625?forum=winserverTS). However, it was not clear if this was a solution or not. 

Eventually, I was able to solve the "Logon failed" problem on Windows 7: I had to enter the username as "DOMAIN\user", instead of just "user"! The UI did not give a clue about this. 

Unfortunately, this does not solve the problem for "rdesktop", it still silently exits for the "other" server.
Comment 14 Peter Åstrand cendio 2014-04-16 15:01:50 CEST
For the "silent exit" problem in rdesktop, I've recompiled with --with-debug-credssp --with-debug. When running against my server peter-216 = 10.47.1.216, I get at the end:

Connection established using CredSSP.
Failed to parse crypt info
Received licensing PDU (message type 0x01)
Sending licensing PDU (message type 0x12)
Received licensing PDU (message type 0xff)
RDP packet #1, (type a)
0000 5d 00 0a 00 ea 03 36 2e 00 04 54 00 5c d2 85 40 ].....6...T.\..@
0010 0d 00 00 00 18 00 00 00 31 00 30 00 2e 00 34 00 ........1.0...4.
0020 37 00 2e 00 31 00 2e 00 32 00 31 00 35 00 00 00 7...1...2.1.5...
0030 10 00 00 00 61 00 73 00 74 00 72 00 61 00 6e 00 ....a.s.t.r.a.n.
0040 64 00 00 00 0c 00 00 00 50 00 45 00 54 00 45 00 d.......P.E.T.E.
0050 52 00 00 00 b4 00 00 00 00 00 00 00 82          R............

As you can see, the "215" server seems to be referenced in there, but we are not taking any action. Or at least not saying anything about it. Perhaps we simply fail to parse this redirection?
Comment 15 Henrik Andersson cendio 2014-04-23 07:34:14 CEST
(In reply to comment #14)
> For the "silent exit" problem in rdesktop, I've recompiled with
> --with-debug-credssp --with-debug. When running against my server peter-216 =
> 10.47.1.216, I get at the end:
> 
> Connection established using CredSSP.
> Failed to parse crypt info
> Received licensing PDU (message type 0x01)
> Sending licensing PDU (message type 0x12)
> Received licensing PDU (message type 0xff)
> RDP packet #1, (type a)
> 0000 5d 00 0a 00 ea 03 36 2e 00 04 54 00 5c d2 85 40 ].....6...T.\..@
> 0010 0d 00 00 00 18 00 00 00 31 00 30 00 2e 00 34 00 ........1.0...4.
> 0020 37 00 2e 00 31 00 2e 00 32 00 31 00 35 00 00 00 7...1...2.1.5...
> 0030 10 00 00 00 61 00 73 00 74 00 72 00 61 00 6e 00 ....a.s.t.r.a.n.
> 0040 64 00 00 00 0c 00 00 00 50 00 45 00 54 00 45 00 d.......P.E.T.E.
> 0050 52 00 00 00 b4 00 00 00 00 00 00 00 82          R............
> 
> As you can see, the "215" server seems to be referenced in there, but we are
> not taking any action. Or at least not saying anything about it. Perhaps we
> simply fail to parse this redirection?

The problem is identified to that when rdesktop is connecting, it will send a logon packet and wait for license PDU packets before opening up UI and continue in the main rdp loop. In the case where kerberos is used with a enhanced redirection packet, this PDU is sent first of all and is not handled as expected. When not using kerberos the license PDU packets comes first then the redirection.
Comment 16 Henrik Andersson cendio 2014-04-23 08:17:47 CEST
(In reply to comment #15)
> (In reply to comment #14)
> > For the "silent exit" problem in rdesktop, I've recompiled with
> > --with-debug-credssp --with-debug. When running against my server peter-216 =
> > 10.47.1.216, I get at the end:
> > 
> > Connection established using CredSSP.
> > Failed to parse crypt info
> > Received licensing PDU (message type 0x01)
> > Sending licensing PDU (message type 0x12)
> > Received licensing PDU (message type 0xff)
> > RDP packet #1, (type a)
> > 0000 5d 00 0a 00 ea 03 36 2e 00 04 54 00 5c d2 85 40 ].....6...T.\..@
> > 0010 0d 00 00 00 18 00 00 00 31 00 30 00 2e 00 34 00 ........1.0...4.
> > 0020 37 00 2e 00 31 00 2e 00 32 00 31 00 35 00 00 00 7...1...2.1.5...
> > 0030 10 00 00 00 61 00 73 00 74 00 72 00 61 00 6e 00 ....a.s.t.r.a.n.
> > 0040 64 00 00 00 0c 00 00 00 50 00 45 00 54 00 45 00 d.......P.E.T.E.
> > 0050 52 00 00 00 b4 00 00 00 00 00 00 00 82          R............
> > 
> > As you can see, the "215" server seems to be referenced in there, but we are
> > not taking any action. Or at least not saying anything about it. Perhaps we
> > simply fail to parse this redirection?
> 
> The problem is identified to that when rdesktop is connecting, it will send a
> logon packet and wait for license PDU packets before opening up UI and continue
> in the main rdp loop. In the case where kerberos is used with a enhanced
> redirection packet, this PDU is sent first of all and is not handled as
> expected. When not using kerberos the license PDU packets comes first then the
> redirection.

Fixed in upstream commit 1794
Comment 17 Henrik Andersson cendio 2014-04-23 09:42:21 CEST
(In reply to comment #16)
> > 
> > The problem is identified to that when rdesktop is connecting, it will send a
> > logon packet and wait for license PDU packets before opening up UI and continue
> > in the main rdp loop. In the case where kerberos is used with a enhanced
> > redirection packet, this PDU is sent first of all and is not handled as
> > expected. When not using kerberos the license PDU packets comes first then the
> > redirection.
> 
> Fixed in upstream commit 1794

Vendordrop in commit 28911.
Comment 18 Peter Åstrand cendio 2014-05-05 13:22:16 CEST
Seems to work fine now, mostly tested on bug 4911.