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.
(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
Upstream commit r1756 renames PDU_REDIRECT_HAS_COOKIE to its proper term PDU_REDIRECT_HAS_LOAD_BALANCE_INFO and makes it dynamically allocated.
(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.
(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.
(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.
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.
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.
Commit r1771 makes use of g_redirect flag in logics where it is used and when used clear this flag.
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.
Upstream commit r1777 fixes a problem with server redirection on Windows 2012r2 platform which with this fix is working as expected.
> 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.
Vendordrop of upstream in commit 28197
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.
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?
(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.
(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
(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.
Seems to work fine now, mostly tested on bug 4911.
