[39435] in Kerberos
Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol
daemon@ATHENA.MIT.EDU (James Ralston)
Thu Jun 27 02:21:57 2024
MIME-Version: 1.0
In-Reply-To: <202404301649.43UGnfNE028201@hedwig.cmf.nrl.navy.mil>
From: James Ralston <ralston@pobox.com>
Date: Thu, 27 Jun 2024 02:19:58 -0400
Message-ID: <CAEkxbZuo2GEZoAhXY-vbcYsMUn0jeRWRyaPB_2YCVNc2oLq_GA@mail.gmail.com>
To: kerberos@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
To wrap up this thread: after discussing this issue with our Windows
admins over the past few months, we have concluded that the correct
course of action here is to set the TRUSTED_FOR_DELEGATION flag in the
userAccountControl attribute for all Linux host machine accounts that
we control. This will ensure that AD sets the OK-AS-DELEGATE flag in
the TGS-REP, which ensures that ssh credential forwarding will work
correctly regardless of whether the specific Kerberos client
implementation honors the OK-AS-DELEGATE flag by default.
Our considerations were:
* Kerberos clients are free to honor or ignore the OK-AS-DELEGATE
flag, and it is not necessarily obvious which clients do or do not
honor it by default.
* Thus, if we do not set the OK-AS-DELEGATE flag, then we would need
to continually identify all Kerberos client implementations in play
in our enterprise, determine which ones honor the OK-AS-DELEGATE
flag by default, determine a way to override that default to ignore
the OK-AS-DELEGATE flag, and find a way to automate that override.
This would require nontrivial effort.
* Setting the TRUSTED_FOR_DELEGATION flag in the userAccountControl
attribute is intended to indicate that the host is administered by
reputable/trusted parties and that it can be trusted for delegation.
This is the case for us, so we are using the TRUSTED_FOR_DELEGATION
flag exactly as it was intended.
Unfortunately, our Windows admins have yet to be able to find a way to
delegate the ability to set the TRUSTED_FOR_DELEGATION flag in the
userAccountControl attribute on a per-OU basis. They can delegate
just about any other ability to us (the Linux admins) for hosts in the
OUs that contain Linux hosts, but no matter what they try, we get an
*Insufficient privileges* error whenever we attempt to set the
TRUSTED_FOR_DELEGATION flag on a Linux host. (They are beginning to
suspect that Active Directory might have some special hardcoded “only
domain admins can set the TRUSTED_FOR_DELEGATION flag” rule that
cannot be overridden or delegated.)
Ultimately, they might have to resort to (e.g.) automating a
Powershell script to enumerate the host machine accounts in our Linux
OUs, and automatically setting the TRUSTED_FOR_DELEGATION flag for any
hosts that are missing it.
If we can figure out a way to delegate the ability to set the
TRUSTED_FOR_DELEGATION flag, I’ll post it to this thread, for anyone
in the future who might find themselves in the same position.
My thanks to everyone who provided feedback in this thread.
On Tue, Apr 30, 2024 at 12:49 PM Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:
> > I think the core issue here is that RFC4120§2.8 was unclear in
> > defining the OK-AS-DELEGATE flag.
>
> I have to say that IMHO, the explanation in RFC 4120 is clear to me
> and the current implementations within the MacOS X Kerberos code fall
> squarely within the scope of the RFCs explanation.
Yes, it was clearly written; yes, clients are not violating the RFC.
And yet: the implementation of this feature still resulted in 5+ years
of silent breakage, the avoidance of which required delegating users’
actual *passwords* to the remote systems. Had the systems in question
had in fact been untrustworthy, this would have resulted in a far
greater security risk than simply delegating the credentials in the
first place.
The OK-AS-DELEGATE flag might have satisfied the specific itch that
Microsoft wanted to scratch, but it was poorly conceived and poorly
implemented. Especially for people in heterogeneous environments,
this flag is a treacherously subtle landmine.
> You are, of course, free to express your opinions about the
> implementation of these protocols extensions, but ... well, other
> than the satisfaction of primal screaming into the void, I'm not
> sure how helpful that will be.
Poorly-conceived and implemented protocol extensions should be called
out, if for no other reason than to avoid repeating their mistakes.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
