On Sat, Apr 23, 2016 at 09:14:17AM -0700, Ray Van Dolson wrote:
> 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...
Found the answer:
http://mailman.mit.edu/pipermail/kerberos/2014-April/019805.html
In short, Wnidows SSPI implementation on the client side checks the
trusted delegation setting for the target in AD, whereas the MIT
implementation doesn't.
Interesting read (the whole thread).
yes, I think this answers all your questions. Since you have access to
your TGT you are free to copy it to any host you want. The trusted for
delegation checking should just prevent sending the TGT automatically to
un-trusted hosts. E.g. on a Linux/UNIX system the root user can
typically read the credential cache of every user and if the TGT is
forwarded to a compromised host the attacker can use the TGT to access
all of the users resources in the network. So delegation should in
general be used with care.
bye,
Sumit
>
> Ray
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>