On Thu, Apr 21, 2016 at 11:39:02AM +0200, Sumit Bose wrote:
On Thu, Apr 21, 2016 at 10:13:20AM +0100, John Hodrien wrote:
> On Thu, 21 Apr 2016, Sumit Bose wrote:
>
> >In this case SSSD has nothing to do with ccache handling, everything is
> >done by sshd.
>
> I was suspicious about windows not providing a forwardable ticket by default,
> and it not being ssh or sssd's fault.
>
> Have you managed SSO with delegation to a machine not running sssd using
> putty?
ah, this reminds me that the host must be configured to be trusted for
delegation, see AD's 'AD Users and Computers' tool, find your target
host and check the 'Delegation' tab.
HTH
bye,
Sumit
So, this solves my problem, but still leaves me a little bit puzzled as
to why some scenarios work without it.
SERVER1: RHEL7+sssd joined to AD but is not explicitly trusted for
delegation.
SERVER2: RHEL6+sssd joined to AD but is not explicitly trusted for
delegation.
CLIENT1: Windows 7, joined to AD. Running PuTTY w/ 'Allow GSSAPI
credential delegation' set.
CLIENT2: Windows 7, not joined to AD but has TGT via MIT Keberos w/
PuTTY set up exactly the same as CLIENT1
If I connect from CLIENT1 to SERVER1, I don't get a TGT in my cache.
If I connect from CLIENT1 to SERVER2, I don't get a TGT in my cache,
but if I manually kinit once on SERVER2 and then ssh -K to SERVER1, I
get a TGT in SERVER1's cache.
If I connect from CLIENT2 to either SERVER1 or SERVER2 I get a TGT in
their caches.
So it seems like the delegation trust setting against the server
computer object in AD is only needed for clients using PuTTY with
native Windows kerberos.
Clients using OpenSSH or MIT kerberos seem to work fine even without
the delegation trust setting...
I see some references to this behaviour elsewhere[1]...
This is probably something I should follow up with on the SSH list or
servervault though. :)
Ray
[1]
http://serverfault.com/questions/646854/putty-kerberos-gssapi-authenticat...