www.cendio.com
Bug 2571 - Add CredSSP support to rdesktop
: Add CredSSP support to rdesktop
Status: CLOSED FIXED
: ThinLinc
| rdesktop (deprecated)
: pre-1.0
: PC Linux
: P2 Enhancement
: 4.1.0
Assigned To:
:
:
: 3681
:
  Show dependency treegraph
 
Reported: 2007-11-05 10:36 by
Modified: 2013-06-14 14:48 (History)
Acceptance Criteria:


Attachments


Note

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


Description From cendio 2007-11-05 10:36:37
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.
------- Comment #1 From cendio 2007-11-05 10:52:14 -------
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
------- Comment #4 From cendio 2012-09-10 11:35:59 -------
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
------- Comment #6 From cendio 2012-09-14 13:55:34 -------
Just for a reminder:
http://blogs.freebsdish.org/juli/2011/12/31/interop-ms-tls/
------- Comment #9 From cendio 2012-09-27 08:42:39 -------
http://technet.microsoft.com/en-us/library/cc742808.aspx
------- Comment #10 From cendio 2012-09-27 11:07:11 -------
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.
------- Comment #12 From cendio 2012-10-01 15:55:27 -------
(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
------- Comment #21 From cendio 2012-11-28 10:03:43 -------
Implemented upstream, vendor drop remains.
------- Comment #22 From cendio 2012-11-29 10:15:23 -------
Related upstream commits are: r1676, r1677, r1678, r1682, r1683
------- Comment #23 From cendio 2012-11-29 14:16:14 -------
Commit r26242 adds libgssglue to buildsystem.
------- Comment #24 From cendio 2012-11-29 16:45:37 -------
(In reply to comment #23)
> Commit r26242 adds libgssglue to buildsystem.

r26245 completes the previous commit
------- Comment #25 From cendio 2012-11-29 16:55:41 -------
Two things left:

1. Add static compile with gssglue lib

2. Update the license document
------- Comment #27 From cendio 2012-12-04 07:57:21 -------
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.
------- Comment #28 From cendio 2012-12-04 10:58:46 -------
Commit 26265 adds license information for libgssapi (libgssglue)
------- Comment #29 From cendio 2013-04-30 12:26:23 -------
*** Bug 4601 has been marked as a duplicate of this bug. ***
------- Comment #31 From cendio 2013-06-11 18:57:02 -------
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.
------- Comment #32 From cendio 2013-06-11 19:30:19 -------
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)
------- Comment #33 From cendio 2013-06-11 19:40:55 -------
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).
------- Comment #34 From cendio 2013-06-11 19:44:59 -------
Tested different security levels:

FIPS: OK
High: OK
Compatible: OK
Low: OK
------- Comment #35 From cendio 2013-06-13 16:13:57 -------
(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.
------- Comment #36 From cendio 2013-06-14 14:34:52 -------
(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.
------- Comment #37 From cendio 2013-06-14 14:48:46 -------
Everything seems to be working fine. Closing.