Citrix has something which they call "pass through authentication" to provide single sign-on for users on a fat workstation to citrix servers. It previously got the clear text password from Windows, but these days it uses the kerberos ticket to authenticate. It is unsure if RDP has something like this today, but Microsoft claims that Longhorn will accept some form of client delegation. It would be nice if we could use this feature in rdesktop. It would remove the extra pin code input when logging on to a WTS from ThinLinc.
This does indeed seem to be a new feature for Vista/Longhorn: http://blogs.msdn.com/ts/archive/2007/04/19/how-to-enable-single-sign-on-for-my-terminal-server-connections.aspx
Windows 2008 tools for handling SPN: List all service princ names: setspn -l hostname Register a service princ name: setspn -s service/name hostname setspn -s TERMSRV/10.47.4.30 10.47.4.30
Just for a reminder: http://blogs.freebsdish.org/juli/2011/12/31/interop-ms-tls/
http://blogs.msdn.com/b/rds/archive/2007/04/19/how-to-enable-single-sign-on-for-my-terminal-server-connections.aspx
http://www.ibm.com/developerworks/aix/library/au-kerbauthent/index.html http://support.citrix.com/proddocs/topic/xenapp5fp-w2k3/ps-securing-cfg-kerb-logon-v2.html http://blogs.msdn.com/b/rds/archive/2008/07/21/configuring-terminal-servers-for-server-authentication-to-prevent-man-in-the-middle-attacks.aspx
http://technet.microsoft.com/en-us/library/cc742808.aspx
Conclusion, SSO with kerberos authentication is not functional with with Windows 2003r2 terminal server, to get this working from a MSTSC -> WTS one need to activate credential delegation which by CredSSP protocol passes a TSPassWordCreds filled with cached username/password. This is verified by changing the password of the AD user and connect with MSTSC which will fail the login with invalid password.
New RDS features with Win 2012 server: http://blogs.technet.com/b/windowsserver/archive/2012/05/09/windows-server-2012-remote-desktop-services-rds.aspx?PageIndex=2
(In reply to comment #10) > Conclusion, > > SSO with kerberos authentication is not functional with with Windows 2003r2 > terminal server, to get this working from a MSTSC -> WTS one need to activate > credential delegation which by CredSSP protocol passes a TSPassWordCreds > filled with cached username/password. > > This is verified by changing the password of the AD user and connect with > MSTSC which will fail the login with invalid password. s/2003/2008
http://technet.microsoft.com/en-us/library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f28
http://social.msdn.microsoft.com/Forums/en-US/os_windowsprotocols/thread/da074f0f-0887-4151-88ea-19a671ed91d9
Implemented upstream, vendor drop remains.
Related upstream commits are: r1676, r1677, r1678, r1682, r1683
Commit r26242 adds libgssglue to buildsystem.
(In reply to comment #23) > Commit r26242 adds libgssglue to buildsystem. r26245 completes the previous commit
Two things left: 1. Add static compile with gssglue lib 2. Update the license document
This bug brings NLA with kerberos+CredSSP support and tester should verify connection to supported windows client and server plarforms. There has been a changes with the fallback route taken regarding protocol negotiation and this is what rdesktop tries: credssp -> tls -> plain rdp so any configuration on serverside regardning securitylevel is to be tested to verify the correct behaviour. How to configure security level: 1. go to Server Manager->Remote Desktop Services->RD Session Host Configuration 2. doubleclick "RDP-tcp" connection item and on the general tab and there you will find security level. Also test kerberos+CredSSP with and without intial TGT.
Commit 26265 adds license information for libgssapi (libgssglue)
*** Bug 4601 has been marked as a duplicate of this bug. ***
First issue found: You have to connect to the WTS using the hostname of the machine. IP-address, or alternative names for it will not work. I'm guessing as this is because we compute the wrong principal name for it. Note that Microsoft's client does not have this restriction, so I assume the name is available somewhere in the RDP handshake.
RDP + Compatible + Force NLA + Valid TGT : OK RDP + Compatible + Force NLA + Valid TGT + Valid ST : OK RDP + Compatible + Force NLA + No TGT : Fail (expected) TLS + Compatible + Force NLA + Valid TGT : OK TLS + Compatible + Force NLA + Valid TGT + Valid ST : OK TLS + Compatible + Force NLA + No TGT : Fail (expected) TLS + Compatible + Valid TGT : OK TLS + Compatible + Valid TGT + Valid ST : OK TLS + Compatible + No TGT : OK (fallback to non-CredSSP)
Possible second issue: If you use CredSSP and don't specify username/password, then you'll be greeted with a graphical "The user name or password is incorrect. Try again." from the server. Without CredSSP you get a login prompt without any errors. Trying to compare with a Microsoft client proved difficult. I can't find any way in the new client to connect without specifying a user/password in a local prompt. So I cannot reproduce a similar scenario. Another difference is that Microsoft's client checks the result of the RDP authentication. If it fails, it will pop up a local dialog telling you this. Older clients would just continue on and let the WTS sort out the problems (which is also what rdesktop does).
Tested different security levels: FIPS: OK High: OK Compatible: OK Low: OK
(In reply to comment #33) > Possible second issue: > > If you use CredSSP and don't specify username/password, then you'll be greeted > with a graphical "The user name or password is incorrect. Try again." from the > server. Without CredSSP you get a login prompt without any errors. > This is by design of CredSSP, credentials should be fullfilled on client side for delegation to serverside. See protocol examples step 9 in MS-CSSP specification. If i exclude sendint the last TSRequest, i get disconnected, This is also happening if i send an empty TSRequest as authInfo (User creds) is optional by spec.
(In reply to comment #31) > First issue found: > > You have to connect to the WTS using the hostname of the machine. IP-address, > or alternative names for it will not work. I'm guessing as this is because we > compute the wrong principal name for it. > > Note that Microsoft's client does not have this restriction, so I assume the > name is available somewhere in the RDP handshake. It shows that MS Client fallbacked to CredSSP+NTLM when using ip adress. With other words rdesktop behaves the same as MS client. rdesktop lacks CredSSP+NTLM and therefor will fallback to a SSL connection. See bug #4705 for a better end-user experience.
Everything seems to be working fine. Closing.
