www.cendio.com
Bug 4920 - Fix issues with server redirection implementation of rdesktop.
: Fix issues with server redirection implementation of rdesktop.
Status: CLOSED FIXED
: ThinLinc
rdesktop
: 4.1.1
: PC Unknown
: P2 Normal
: 4.2.0
Assigned To:
:
:
: 4933
: 4911
  Show dependency treegraph
 
Reported: 2013-11-28 07:01 by
Modified: 2014-05-05 13:22 (History)
Acceptance Criteria:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2013-11-28 07:01:56
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 From cendio 2013-11-28 07:06:40 -------
(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 From cendio 2013-11-28 07:11:36 -------
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 From cendio 2013-11-28 07:13:17 -------
(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 From cendio 2013-11-28 07:16:17 -------
(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 From cendio 2013-11-29 08:04:08 -------
(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 From cendio 2013-11-29 08:09:23 -------
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 From cendio 2013-12-05 15:11:49 -------
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 From cendio 2013-12-05 15:12:41 -------
Commit r1771 makes use of g_redirect flag in logics where it is used and when
used clear this flag.
------- Comment #9 From cendio 2013-12-05 15:14:56 -------
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 From cendio 2013-12-10 12:36:08 -------
Upstream commit r1777 fixes a problem with server redirection on Windows 2012r2
platform which with this fix is working as expected.
------- Comment #11 From cendio 2013-12-12 13:36:47 -------
> 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 From cendio 2013-12-12 16:30:12 -------
Vendordrop of upstream in commit 28197
------- Comment #13 From cendio 2014-04-16 14:30:28 -------
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 From cendio 2014-04-16 15:01:50 -------
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 From cendio 2014-04-23 07:34:14 -------
(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 From cendio 2014-04-23 08:17:47 -------
(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 From cendio 2014-04-23 09:42:21 -------
(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 From cendio 2014-05-05 13:22:16 -------
Seems to work fine now, mostly tested on bug 4911.