www.cendio.com
Bug 4911 - make rdesktop support enhanced security server redirection PDU 10.
: make rdesktop support enhanced security server redirection PDU 10.
Status: CLOSED FIXED
: ThinLinc
rdesktop
: 4.1.1
: PC Unknown
: P2 Normal
: 4.2.0
Assigned To:
:
:
: 4920
:
  Show dependency treegraph
 
Reported: 2013-11-22 15:14 by
Modified: 2014-05-05 09:12 (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-22 15:14:13
If SSL or CredSSP is used this PDU is sent instead of the standard security
redirection packet.

See: http://msdn.microsoft.com/en-us/library/ee441597.aspx
------- Comment #1 From cendio 2013-11-22 15:27:42 -------
This doesn't seem to be such a big issue, the new way just encapsulates the
standard redirection pkt, which rdesktop alread supports;
http://msdn.microsoft.com/en-us/library/ee443575.aspx

However there will probably be some coding to make the handling of the standard
redirection packet fully supported and make it use of additional information
such password etc..
------- Comment #2 From cendio 2013-11-23 10:48:20 -------
There are also some problems with the current implementation of the standard
security redirection packet, see
https://sourceforge.net/p/rdesktop/patches/214/
for patches.
------- Comment #3 From cendio 2013-11-28 07:08:42 -------
(In reply to comment #2)
> There are also some problems with the current implementation of the standard
> security redirection packet, see
> https://sourceforge.net/p/rdesktop/patches/214/
> for patches.

Bug 4920 has been added for this.
------- Comment #4 From cendio 2013-11-28 07:56:29 -------
Looks like we need to cleanup the implementation of sec_out_mcs_data().

Current implementation is hardcoding the following paths:

REDIRECTION_SUPPORTED | REDIRECTION_VERSION3
to get redirection packets... hence a server redirection packet includes a
session id that should be passed but is currently ignored...

or

REDIRECTION_SUPPORTED | REDIRECTED_SESSIONID_FIELD_VALID | REDIRECTION_VERSION3

for console connections, session id == 0


See http://msdn.microsoft.com/en-us/library/cc240514.aspx for more information.
------- Comment #5 From cendio 2013-11-28 08:14:21 -------
(In reply to comment #4)
> Looks like we need to cleanup the implementation of sec_out_mcs_data().
> 
> Current implementation is hardcoding the following paths:
> 
> REDIRECTION_SUPPORTED | REDIRECTION_VERSION3
> to get redirection packets... hence a server redirection packet includes a
> session id that should be passed but is currently ignored...
> 
> or
> 
> REDIRECTION_SUPPORTED | REDIRECTED_SESSIONID_FIELD_VALID | REDIRECTION_VERSION3
> 
> for console connections, session id == 0
> 
> 
> See http://msdn.microsoft.com/en-us/library/cc240514.aspx for more information.

<4> Section 2.2.1.3.5: REDIRECTION_VERSION1 (0x00) is not advertised by any
Microsoft RDP clients.
<5> Section 2.2.1.3.5: REDIRECTION_VERSION2 (0x01) is not advertised by any
Microsoft RDP clients.
<6> Section 2.2.1.3.5: REDIRECTION_VERSION3 (0x02) is advertised only by
Microsoft RDP 5.1 and 5.2 clients.
<7> Section 2.2.1.3.5: REDIRECTION_VERSION4 (0x03) is advertised only by
Microsoft RDP 6.0 and 6.1 clients.
<8> Section 2.2.1.3.5: REDIRECTION_VERSION5 (0x04) is advertised only by
Microsoft RDP 7.0 and 7.1 clients.
<9> Section 2.2.1.3.5: REDIRECTION_VERSION6 (0x05) is advertised only by
Microsoft RDP 8.0 clients.
------- Comment #6 From cendio 2013-11-29 07:54:01 -------
(In reply to comment #5)
> (In reply to comment #4)
> > Looks like we need to cleanup the implementation of sec_out_mcs_data().
> > 
> > Current implementation is hardcoding the following paths:
> > 
> > REDIRECTION_SUPPORTED | REDIRECTION_VERSION3
> > to get redirection packets... hence a server redirection packet includes a
> > session id that should be passed but is currently ignored...
> > 
> > or
> > 
> > REDIRECTION_SUPPORTED | REDIRECTED_SESSIONID_FIELD_VALID | REDIRECTION_VERSION3
> > 
> > for console connections, session id == 0
> > 
> > 
> > See http://msdn.microsoft.com/en-us/library/cc240514.aspx for more information.
> 
> <4> Section 2.2.1.3.5: REDIRECTION_VERSION1 (0x00) is not advertised by any
> Microsoft RDP clients.
> <5> Section 2.2.1.3.5: REDIRECTION_VERSION2 (0x01) is not advertised by any
> Microsoft RDP clients.
> <6> Section 2.2.1.3.5: REDIRECTION_VERSION3 (0x02) is advertised only by
> Microsoft RDP 5.1 and 5.2 clients.
> <7> Section 2.2.1.3.5: REDIRECTION_VERSION4 (0x03) is advertised only by
> Microsoft RDP 6.0 and 6.1 clients.
> <8> Section 2.2.1.3.5: REDIRECTION_VERSION5 (0x04) is advertised only by
> Microsoft RDP 7.0 and 7.1 clients.
> <9> Section 2.2.1.3.5: REDIRECTION_VERSION6 (0x05) is advertised only by
> Microsoft RDP 8.0 clients.

Upstream commit r1762 cleans up and clarifies the implementation of
TS_UD_CS_CLUSTER packet.
------- Comment #7 From cendio 2013-11-29 08:07:44 -------
(In reply to comment #1)
> This doesn't seem to be such a big issue, the new way just encapsulates the
> standard redirection pkt, which rdesktop alread supports;
> http://msdn.microsoft.com/en-us/library/ee443575.aspx
> 

Upstream commit r1757 and r1763, adds the actual hadnling of PDU 10
------- Comment #8 From cendio 2013-12-12 16:30:18 -------
Vendordrop of upstream in commit 28197
------- Comment #9 From cendio 2014-04-23 16:23:07 -------
When CredSSP is in use and you are redirected to another server, any
client-side password is not passed along, so you have to enter that manually.
In this case, you do not get any PDU_REDIRECT_HAS_PASSWORD. My guess is that
the idea is that you should simply pass the password you have on the
client-side to the second server as well. This currently does not work because
it is cleared too early in rdesktop:

        DEBUG(("Connection successful.\n"));
        memset(password, 0, sizeof(password));

Also, in the case when you have not entered any password on the command line,
you get the error message "The username or password is incorrect". Perhaps we
are "always" passing some kind of autologin flag, even when -p is not specified
and when there's no PDU_REDIRECT_HAS_PASSWORD?
------- Comment #10 From cendio 2014-04-24 14:04:49 -------
(In reply to comment #9)
> When CredSSP is in use and you are redirected to another server, any
> client-side password is not passed along, so you have to enter that manually.
> In this case, you do not get any PDU_REDIRECT_HAS_PASSWORD. My guess is that
> the idea is that you should simply pass the password you have on the
> client-side to the second server as well. This currently does not work because
> it is cleared too early in rdesktop:
> 
>         DEBUG(("Connection successful.\n"));
>         memset(password, 0, sizeof(password));
> 

This is fixed in upstream commit 1795.

> Also, in the case when you have not entered any password on the command line,
> you get the error message "The username or password is incorrect". Perhaps we
> are "always" passing some kind of autologin flag, even when -p is not specified
> and when there's no PDU_REDIRECT_HAS_PASSWORD?

This is a side affect of using CredSSP which requires a user/password to be
sent to server. The windows client always delegates credentials to the server
when using CredSSP.
------- Comment #11 From cendio 2014-04-24 14:13:27 -------
(In reply to comment #10)
> (In reply to comment #9)
> 
> This is fixed in upstream commit 1795.
> 
Vendordrop in commit 28918.
------- Comment #12 From cendio 2014-04-30 14:15:58 -------
I've tested thinlinc-rdesktop-4.1.1post-4339.x86_64 against a Windows 2012 R2
cluster now, using NLA and CredSSP-Kerberos. Seems to work. I was finally able
to create sessions on both servers, and have thus verified that redirection
works both ways (from Broker to Slave, and the other way around). 

Will test on 2008R2 and 2003R2 as well.
------- Comment #13 From cendio 2014-05-05 09:12:35 -------
(In reply to comment #12)
> I've tested thinlinc-rdesktop-4.1.1post-4339.x86_64 against a Windows 2012 R2
> cluster now, using NLA and CredSSP-Kerberos. Seems to work. I was finally able
> to create sessions on both servers, and have thus verified that redirection
> works both ways (from Broker to Slave, and the other way around). 
> 
> Will test on 2008R2 and 2003R2 as well.

Now verified, works great.