Comment 1 Henrik Andersson 2013-11-22 15:27:42 CET

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 Henrik Andersson 2013-11-23 10:48:20 CET

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 Henrik Andersson 2013-11-28 07:08:42 CET

(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 Henrik Andersson 2013-11-28 07:56:29 CET

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 Henrik Andersson 2013-11-28 08:14:21 CET

(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 Henrik Andersson 2013-11-29 07:54:01 CET

(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 Henrik Andersson 2013-11-29 08:07:44 CET

(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 Henrik Andersson 2013-12-12 16:30:18 CET

Vendordrop of upstream in commit 28197

Comment 9 Peter Åstrand 2014-04-23 16:23:07 CEST

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 Henrik Andersson 2014-04-24 14:04:49 CEST

(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 Henrik Andersson 2014-04-24 14:13:27 CEST

(In reply to comment #10)
> (In reply to comment #9)
> 
> This is fixed in upstream commit 1795.
> 
Vendordrop in commit 28918.

Comment 12 Peter Åstrand 2014-04-30 14:15:58 CEST

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 Peter Åstrand 2014-05-05 09:12:35 CEST

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