honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?
Ken Hornstein
kenh at cmf.nrl.navy.mil
Mon Apr 15 19:56:04 EDT 2024
>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.
--Ken
More information about the Kerberos
mailing list