[39414] in Kerberos

home help back first fref pref prev next nref lref last post

Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol

daemon@ATHENA.MIT.EDU (Stephen Frost)
Mon Apr 15 20:41:05 2024

Date: Mon, 15 Apr 2024 20:40:49 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: James Ralston <ralston@pobox.com>, kerberos@mit.edu
Message-ID: <Zh3JEbB0IfDztgSQ@tamriel.snowman.net>
MIME-Version: 1.0
In-Reply-To: <202404152356.43FNu4Wj009470@hedwig.cmf.nrl.navy.mil>
Content-Type: multipart/mixed; boundary="===============1552446600161855297=="
Errors-To: kerberos-bounces@mit.edu


--===============1552446600161855297==
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="B9sCEppJ1CQvzV++"
Content-Disposition: inline


--B9sCEppJ1CQvzV++
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Ken Hornstein via Kerberos (kerberos@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=E2=80=99s machine account in Ac=
tive
> >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=E2=80=
=99s
> >credentials to the target host, *even* if all other settings would
> >permit credential delegation.
>=20
> 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:
>=20
> 	https://datatracker.ietf.org/doc/html/rfc4120#section-2.8
>=20
> 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

--B9sCEppJ1CQvzV++
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEwf6gbxKhD863zrx/7WyKOINHZFUFAmYdyQ4ACgkQ7WyKOINH
ZFXIRhAAhidSCPUTu/ygxBsRobEB79VzvlZzrqmg/QFWBbpA17x+kTZJuXpx1wbT
07IPFYgHlqmLhnFBbwWPpK6Vs3trqsL9NOiAV+Sn+EisCftqs/HmEyrintkOz0U8
LESKO03TYYmui1RfB0KlycDaAE4cmEImr6OC5TuVZ2WeB2p74LDRyHvSwlywTXz4
T1peUiAZ6zfDEg6uydoQC0HhZJHtiBizo2xj6L80ptwBVf7gLTyOJkLwW7YEC4Va
9c2yrrJkB12oKcIkWlo4Mlaz8Pp4xYfHRKxS1uEtZLUfT/l2LgVYh9Kf2d+JqoyJ
/w4nTd9TWroxmrjzKcAS9CsE/A/n14bnDyTZ0bnA83co1GBXem3CV3JY7qaXd1jG
FnP7l4eXCH/9d+j22YPQQInCXteMklzGUxb/orLROLxj8dBP2ho9Tzv7frfUL9lo
Ho8FEp1iUHrIvLncXe5HLaFE+xxZ9UBYqNZRdcMnqT3JGZZBBNMqw6mSPNVbMP87
Phdz4QtaMXgxAamjQU96/QKWmRgP9vQwYfNf+lRftWHTniM69DZfPAFbqEQHyTiJ
hU3OBJvf4FZQmTq3BOrHIaUgu3g8CIxsp2x4gYdjevSnr0coGJXbNUxv9NpzGI8P
OrmpHYjvHMNBR4XEBFdYeniAV8Bfv4JwsiRo/9Er2+gAqT3zRWU=
=4zAr
-----END PGP SIGNATURE-----

--B9sCEppJ1CQvzV++--

--===============1552446600161855297==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

--===============1552446600161855297==--

home help back first fref pref prev next nref lref last post