[39423] in Kerberos
Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol
daemon@ATHENA.MIT.EDU (James Ralston)
Mon Apr 29 19:25:20 2024
MIME-Version: 1.0
In-Reply-To: <202404170130.43H1UpOg023445@hedwig.cmf.nrl.navy.mil>
From: James Ralston <ralston@pobox.com>
Date: Mon, 29 Apr 2024 19:19:29 -0400
Message-ID: <CAEkxbZupQObPrSC7PLvVV9+de8Pjj=d=dYRZWFvY3wMyUQPxMA@mail.gmail.com>
To: kerberos@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Tue, Apr 16, 2024 at 9:31 PM Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:
> Simo already explained the thinking there, but I think the thing
> you're not considering is that not all services require delegated
> credentials. Yes, in your environment (and ours) delegated
> credentials for host principals is essential, but you don't normally
> need that for other types of credentials. I haven't run into Simo's
> experience of badly coded applications delegating credentials when
> they shouldn't, but I could believe it happens.
Our experience is similar: while I agree it could happen, we have not
encountered it, so it is mystifying to us why Microsoft was so
insistent upon implementing this feature.
We deploy ssh_config settings on all of our managed hosts that disable
credential forwarding (as well as GSSAPI) for hosts outside of our
domain. We also configure web browsers to perform GSSAPI only for
hosts within our domain. So beyond the ok-as-delegate flag, we take
efforts to disable all things Kerberos/GSSAPI (not just credential
delegation) when connecting to hosts we do not control.
> And, well .. one thing I guess I do not understand is, exactly, what
> is your problem with turning on that setting on your KDC? If this
> is just a cri de cœur about lousy AD admins, fair enough; I can
> understand your pain there (most AD admins really don't know how
> Kerberos works, sadly).
It’s not a competency issue: our AD/Windows admins are highly
competent (if I do say so myself), and we Linux admins enjoy good
rapport with them. Rather, they expressed two concerns:
1. While setting the TRUSTED_FOR_DELEGATION flag in the
userAccountControl attribute has the effect of setting the
ok-as-delegate flag on service tickets issued for that host, it is
not clear from Microsoft’s documentation what other effects (if
any) setting the TRUSTED_FOR_DELEGATION flag will have in AD.
Based on past experiences, they want to make sure that setting the
TRUSTED_FOR_DELEGATION flag to achieve one particular effect won’t
have unwanted side-effects (especially ones that may be subtle and
not obvious at first).
2. Our AD admins have delegated the ability to create (join) and
delete computer objects in two OUs that are specifically designed
for Linux hosts (one OU for servers; another OU for clients).
This permits Linux admins to [de]commission hosts on our own,
without requiring them to intervene to create/destroy the computer
objects. There are some non-trivial ACL/permission configurations
required to make this work correctly, and they will need to figure
out how to additionally delegate the “Linux admins in this group
may set TRUSTED_FOR_DELEGATION flag on computer objects created in
this OU” in the same way.
#2, in particular, is a dealbreaker: we have a fair amount of Linux
host churn (“cattle, not pets”), and thus Linux admins cannot go
running to the AD admins to set the TRUSTED_FOR_DELEGATION flag every
time we join a new computer object into one of the OUs designated for
Linux hosts. If we need to set it, we (the Linux admins) must be able
to set it ourselves.
> Speaking about the OK-AS-DELEGATE flag, the ONLY thing that does is
> set the flag in the ticket which the client uses as a hint (it is
> free to ignore that hint). I cannot speak for the AD
> TRUSTED_FOR_DELEGATION flag as a whole; it's possible it does
> something else than set the OK-AS-DELEGATE ticket flag.
Yes, that’s exactly the first concern.
> So if there is NOT a delegation flag on the ticket, the realm-config
> entry is checked. If the first byte has the least-significant bit
> set, the all of the delegation flags are cleared. I suspect this is
> what you're hitting.
Perhaps?
Upstream Heimdal has the enforce_ok_as_delegate krb5.conf
configuration option, the same as the MIT Kerberos, and like MIT
Kerberos, it defaults to false (only enforced when an application
specifically requests enforcement) (1).
But from testing, ssh on Macs won’t delegate the credential unless the
service ticket of the target host has the ok-as-delegate flag. So
either that’s not the default for Apple’s version of Heimdal, or
something is overriding the default.
> I will confess that we supply to our users Kerberos kits which are
> all MIT sources, including OpenSSH, for this exact reason; there's
> too much weird variance like this.
In the past, we did the same thing, but we reverted to using the
macOS-provided Kerberos implementation, because decisions Apple made
in later macOS releases just made it too painful to replace it (or
even provide an alternative implementation alongside the macOS
implementation).
(1) https://github.com/heimdal/heimdal/blob/master/lib/krb5/krb5.conf.5
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
