honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

[Stephen Frost]

Greetings,

* Ken Hornstein via Kerberos (kerberos at mit.edu) wrote:
> >Has anyone else struggled with ssh clients being unable to delegate
> >As far as we can tell, for reasons we still have been unable to
> >fathom, Microsoft decided that simply permitting credential delegation
> >based on whether the TGT has the forwardable flag set was
> >insufficient. Instead, Microsoft implemented a new flag in the MS-SFU
> >Kerberos Protocol Extensions, TRUSTED_FOR_DELEGATION. The flag is a
> >property of the service principal of the *target* host: if the target
> >host does not have the TRUSTED_FOR_DELEGATION flag set in the
> >userAccountControl attribute of the host’s machine account in Active
> >Directory, then if the Kerberos library that the ssh client uses
> >honors the MS-SFU Kerberos Protocol Extensions and honors the
> >TRUSTED_FOR_DELEGATION flag, it will refuse to delegate the user’s
> >credentials to the target host, *even* if all other settings would
> >permit credential delegation.
> 
> I'm a LITTLE confused as to what you're describing here.  As I
> understand you, the TRUSTED_FOR_DELEGATION flag doesn't appear on the
> wire and only in the account properties.  What, exactly, is there for a
> client implementation to honor or not honor?  If you're talking about
> the OK-AS-DELEGATE flag in the Kerberos ticket, MIT Kerberos does
> implement that flag (but ... the library already provides an option
> to ignore that flag and it seems that by default it DOES ignore that
> flag).  It seems like some versions of Heimdal also will ignore the
> OK-AS-DELEGATE flag by default and you can configure Heimdal to respect
> that flag but I am unclear what the OS X Heimdal does.  Calling that a
> Microsoft extension is incorrect, though, as that appears in RFC 4120.
> As for the thinking behind this flaga, well, the RFC provides what I
> would consider a cognizant explanation:
> 
> 	https://datatracker.ietf.org/doc/html/rfc4120#section-2.8
> 
> If you're talking about something else, I would be curious as to what
> you mean.  I didn't think ssh could utilize any of the S4U stuff
> but it's always possible that could have changed.

Before delving too deeply here ... frankly, I'd *strongly* encourage you
to ignore what OSX comes with in terms of Kerberos "support" and push to
move everything away from what OSX ships with and to instead use MIT
Kerberos.  In my experience, this is far from the only issue you're
going to run into with the hacked up Kerberos from OSX and they don't
seem to care to properly maintain it.

Thanks,

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mailman.mit.edu/pipermail/kerberos/attachments/20240415/c6899a4d/attachment.sig>