[39417] in Kerberos
Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Tue Apr 16 21:32:34 2024
Message-Id: <202404170130.43H1UpOg023445@hedwig.cmf.nrl.navy.mil>
To: James Ralston <ralston@pobox.com>
cc: kerberos@mit.edu
In-Reply-To: <CAEkxbZvn=3G3MVossM0aRC3pFd+JCX13ugUo6BwyKqaKtv--xg@mail.gmail.com>
MIME-Version: 1.0
Date: Tue, 16 Apr 2024 21:30:52 -0400
From: Ken Hornstein via Kerberos <kerberos@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
>> 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.
>
>Yes. Apologies; I should have been more precise: when Microsoft AD is
>acting as the KDC, whether AD sets the the OK-AS-DELEGATE flag in the
>TGS-REP is determined by whether the userAccountControl attribute in
>Active Directory of the host for which a service ticket is being
>requested has the TRUSTED_FOR_DELEGATION flag set. If
>TRUSTED_FOR_DELEGATION is set, OK-AS-DELEGATE is set in the TGS-REP;
>otherwise, OK-AS-DELEGATE is not set in the TGS-REP.
Okay, THAT makes more sense.
>Heimdal appears to implement the same option (enforce_ok_as_delegate),
>but although the upstream source claims the default is false (do not
>enforce), Macs seem to enforce it by default. So either Apple has
>changed that default in the code, or else they are overriding the
>default somewhere in the Kerberos configuration.
>In terms of Windows, Microsoft’s Kerberos implementation seems to
>enforce compliance with the OK-AS-DELEGATE flag. (PuTTY on Windows
>will not delegate a credential unless the target host has the
>TRUSTED_FOR_DELEGATION flag set in AD.) Perhaps there is a way to
>disable this behavior, but we have not yet found a way to do so.
Well, I figured out what is going on there ... see below.
>> the RFC provides what I would consider a cognizant explanation:
>>
>> https://datatracker.ietf.org/doc/html/rfc4120#section-2.8
>
>Microsoft provides a similar explanation, but it is still an
>unsatisfying one, because it does not speak to our issue: if denying
>the ability to delegate a credential (in order to protect it from
>exposure to a possibly-untrustworthy host) forces the user to instead
>acquire a credential directly from the possibly-untrustworthy host
>(thereby exposing the user’s actual password), then this is not a
>security improvement. And while I acknowledge that RFC4120 is 19 years
>old and a lot has changed since it was originally published, neither
>the RFC authors nor Microsoft seems to have considered/predicted this
>scenario.
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 normallty 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. It does make sense to be able to control this
centrally based on KDC configuration (that's one of the advantages
to _having_ a KDC). 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).
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.
However, we use MIT Kerberos for our KDC and we occasionally use the
MacOS X ssh client and it delegates credentials just FINE for us without
the use of OK-AS-DELEGATE, so I was curious as to what was going on there.
I did some digging into the MacOS X Heimdal code, and here's what I found.
- The OpenSSH code is mostly the same for our purposes in terms of the
Kerberos support; use of the -K flag turns on the right flags for
credential delegation (in addition to GSSAPI authentication support).
- In the gss_init_sec_context() code path I found this little snippet:
/*
* If the credential doesn't have ok-as-delegate, check if there
* is a realm setting and use that.
*/
if (!ctx->kcred->flags.b.ok_as_delegate && ctx->ccache) {
krb5_data data;
ret = krb5_cc_get_config(context, ctx->ccache, NULL,
"realm-config", &data);
if (ret == 0) {
/* XXX 1 is use ok-as-delegate */
if (data.length < 1 || ((((unsigned char *)data.data)[0]) & 1) == 0)
req_flags &= ~(GSS_C_DELEG_FLAG|GSS_C_DELEG_POLICY_FLAG);
krb5_data_free(&data);
}
}
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.
So, what sets that realm configuration? As far as I can tell, that
ONLY happens inside of kinit. Specifically, this code block:
if (ok_as_delegate_flag || windows_flag || use_referrals_flag) {
unsigned char d = 0;
krb5_data data;
if (ok_as_delegate_flag || windows_flag)
d |= 1;
if (use_referrals_flag || windows_flag)
d |= 2;
data.length = 1;
data.data = &d;
krb5_cc_set_config(context, ccache, NULL, "realm-config", &data);
}
So if you are using the --ok-as-delegate flag _or_ the --windows flag
to kinit, you get this behavior. Are you using one of those? I can't
find another code path that sets this behavior. However, I tried
reproducing this here and setting --windows on kinit still lets me
delegate credentials using the vendor ssh, so I think I missed
something.
>> 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.
>
>It has been our experience that ripping out a vendor-supplied
>library/package and replacing it with an in-house version almost
>always has a higher long-term cost than simply living with whatever
>warts the vendor-supplied library/package has. So we are reluctant to
>take this approach unless there is truly no other choice.
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. But you don't have to "rip out" the
vendor Kerberos code; it runs along side it. We do provide MacOS X
kits as well (the code signing is a pain, but doable).
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
