Copy: kerberos@mit.edu

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: ralston@pobox.com (James Ralston)
Copy: kerberos@mit.edu

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’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.

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

-----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-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Apr 15, 2024 at 7:56 PM Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:

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.

the [MIT Kerberos] library already provides an option to ignore that
[the OK-AS-DELEGATE] flag and it seems that by default it DOES
ignore that flag)

I think the enforce_ok_as_delegate is the option you’re referring to?

The man page claims it is disabled by default (unless an application specifically requests it). That matches our experiences.

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.

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.

On Mon, Apr 15, 2024 at 8:40 PM Stephen Frost <sfrost@snowman.net> wrote:

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.

But this segues back to my original question: how are other sites that
use Microsoft AD as their KDCs handling this?

Are other sites ensuring that the TRUSTED_FOR_DELEGATION flag is set for
Linux hosts, so that all various Kerberos libraries (including ones
that enforce OK-AS-DELEGATE by default) will correctly delegate
credentials to Linux hosts?

Are other sites configuring their Kerberos libraries (on a per-OS
basis) to ignore the OK-AS-DELEGATE flag?

Have few other sites that use Microsoft AD as their KDC even run into
this, because they don’t have services (e.g. home directories mounted
via NFSv4+RPCGSS) that require a Kerberos credential, and therefore
don’t need to forward Kerberos credentials to the remote host when
making an ssh connection to it?

My read of the MIT Kerberos kdc.conf man page is that ok-as-delegate
is not one of the flags in default_principal_flags that defaults to
enabled. So heterogeneous sites that use MIT Kerberos as their KDCs
(not AD) should also be seeing this issue.

At least so far, we *think* the best course of action is to always set
the TRUSTED_FOR_DELEGATION flag for Linux hosts in AD, so that
credential delegation won’t depend on whether the Kerberos library
that any specific host uses pays attention to the OK-AS-DELEGATE flag.
And this does seem to be the intention of the TRUSTED_FOR_DELEGATION / OK-AS-DELEGATE flags: it’s advice to Kerberos clients that it’s OK to delegate credentials to the target host, which is exactly what we want
to happen.

The only thing we’re not completely sure about is whether setting the TRUSTED_FOR_DELEGATION flag in AD will have other security
ramifications that aren’t clear from Microsoft’s documentation. Which
is why I was hoping that others on this list have already been down
this particular road and could offer advice.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: kerberos@mit.edu

The correct action is for you to ask the Domain Administrators to mark
the target hosts as ok for delegation, it is unclear why MIT Kerberos
should make it easy to override Realm policies.

Delegating a whole TGT is generally a bad idea, and often clients are misconfigured to broadly forward it everywhere. That is why Microsoft
took back control in the hands of administrators. It is not a bad
thing, and if your setup has been vetted such that TGT delegation is an acceptable risk, then it should be easy to get it fixed the proper way,
by getting your domain admins to set the right flag on the permitted
target hosts.

Note that if ticket delegation is needed solely to allow jumping from
hosts to host, you should be able to achieve the same result via agent forwarding, it would be a safer option.

But all that said I would like to note that it is certainly
inappropriate to call people names before fully understanding the scope
of a security measure, just because it is a little inconvenient.

If you wanted a knob like the one you ask for it should probably be
called:
dishonor_trusted_for_delegation_mr_auditor_please_be_lenient

As for users that type their passwords onto random hosts, that is a
user education problem in general, but that can be addressed simply by
forcing the use of 2FA authentication on the user's part, preferably
via a hardware token and pkinit, but an OTP solution would work as
well.

Cheers,
Simo.

On Tue, 2024-04-16 at 03:03 -0400, James Ralston wrote:

On Mon, Apr 15, 2024 at 7:56 PM Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:

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.

the [MIT Kerberos] library already provides an option to ignore that
[the OK-AS-DELEGATE] flag and it seems that by default it DOES
ignore that flag)

I think the enforce_ok_as_delegate is the option you’re referring to?

The man page claims it is disabled by default (unless an application specifically requests it). That matches our experiences.

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.

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.

On Mon, Apr 15, 2024 at 8:40 PM Stephen Frost <sfrost@snowman.net> wrote:

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.

But this segues back to my original question: how are other sites that
use Microsoft AD as their KDCs handling this?

Are other sites ensuring that the TRUSTED_FOR_DELEGATION flag is set for Linux hosts, so that all various Kerberos libraries (including ones
that enforce OK-AS-DELEGATE by default) will correctly delegate
credentials to Linux hosts?

Are other sites configuring their Kerberos libraries (on a per-OS
basis) to ignore the OK-AS-DELEGATE flag?

Have few other sites that use Microsoft AD as their KDC even run into
this, because they don’t have services (e.g. home directories mounted
via NFSv4+RPCGSS) that require a Kerberos credential, and therefore
don’t need to forward Kerberos credentials to the remote host when
making an ssh connection to it?

My read of the MIT Kerberos kdc.conf man page is that ok-as-delegate
is not one of the flags in default_principal_flags that defaults to
enabled. So heterogeneous sites that use MIT Kerberos as their KDCs
(not AD) should also be seeing this issue.

At least so far, we *think* the best course of action is to always set
the TRUSTED_FOR_DELEGATION flag for Linux hosts in AD, so that
credential delegation won’t depend on whether the Kerberos library
that any specific host uses pays attention to the OK-AS-DELEGATE flag.
And this does seem to be the intention of the TRUSTED_FOR_DELEGATION / OK-AS-DELEGATE flags: it’s advice to Kerberos clients that it’s OK to delegate credentials to the target host, which is exactly what we want
to happen.

The only thing we’re not completely sure about is whether setting the TRUSTED_FOR_DELEGATION flag in AD will have other security
ramifications that aren’t clear from Microsoft’s documentation. Which
is why I was hoping that others on this list have already been down
this particular road and could offer advice.

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

--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Apr 16, 2024 at 1:46 PM Simo Sorce <simo@redhat.com> wrote:

The correct action is for you to ask the Domain Administrators to
mark the target hosts as ok for delegation, it is unclear why MIT
Kerberos should make it easy to override Realm policies.

I think the core issue here is that RFC4120§2.8 was unclear in
defining the ok-as-delegate flag. Quoting RFC4120§2.8, emphasis mine:

* The ticket flags … *MAY* have the ok-as-delegate flag set
* A client *CAN* use the presence of this flag to *HELP* it decide
* It is acceptable to *IGNORE* the value of this flag

All of these statements are wishy-washy statements that provide no
concrete guidance for server/client implementers:

* Should server implementations set this flag by default unless
administrators specifically elect to disable it, or should server
implementations clear this flag by default unless administrators
specifically elect to enable it?

* Should client implementations honor this flag by default unless
administrators specifically elect to ignore it, or should client
implementations ignore this flag by default unless administrators
specifically elect to honor it?

* Given heterogeneous environments where there are likely to be
multiple independent client implementations, how should this feature
be deployed at a client and server level in order to minimize
interoperability issues?

In light of the failure of RFC4120§2.8 to answer any of these
difficult questions, I would argue that the MIT Kerberos behavior is
reasonable (arguably, the most reasonable): servers do not set the
flag by default, and clients do not honor the flag by default. This
leaves it up to individual sites to determine whether the additional
control this feature offers is desired, and if so, how to deploy it
without breaking things.

Delegating a whole TGT is generally a bad idea, and often clients
are misconfigured to broadly forward it everywhere. That is why
Microsoft took back control in the hands of administrators. It is
not a bad thing, and if your setup has been vetted such that TGT
delegation is an acceptable risk, then it should be easy to get it
fixed the proper way, by getting your domain admins to set the right
flag on the permitted target hosts.

The issue is not that this feature exists; the issue is that until
recently, we simply *did not know* that this feature exists. And why
would we?

* Windows admins never had any reason to be aware of this feature,
because they use remote desktop to login to remote Windows hosts
from other Windows hosts.

* Linux admins never had any issues with delegating credentials from a
Linux host to another Linux host, because MIT Kerberos clients
ignore the flag by default.

* We assumed that the inability to delegate credentials from Windows
host to Linux hosts via PuTTY was a PuTTY implementation issue,
because that was the only instance where we saw delegation failing.
And PuTTY, at least with default logging, showed no warning/error
messages. Furthermore, because so few people were regularly logging
into Linux hosts from Windows hosts (people who did this often
simply requested a Linux workstation), it wasn’t worth the
time/effort to investigate further.

This state continued for the better part of a decade. It was only
when we began to officially support Mac desktops, and ssh clients on
those Macs also failed to delegate credentials (the same as PuTTY on
Windows), that we began to suspect there was a deeper issue at play.

Note that if ticket delegation is needed solely to allow jumping
from hosts to host, you should be able to achieve the same result
via agent forwarding, it would be a safer option.

We use automounted NFS sec=krbp (AUTH_GSS security) home directories everywhere, so users *must* possess a credential in order to access
their home directories. So even if we permitted publickey
authentication, it would not solve the issue of needing a credential
on the target host.

But all that said I would like to note that it is certainly
inappropriate to call people names before fully understanding the
scope of a security measure, just because it is a little
inconvenient.

Speaking as a Linux administrator in a heterogeneous environment where
our Linux hosts rely on Microsoft Active Directory, I assure you that
I have been calling Microsoft names for quite some time. ;-)

(Don’t even get me started about AD’s continued lack of support for aes256-cts-hmac-sha384-192 or aes128-cts-hmac-sha256-128, when it’s approaching 10 years since RFC8009 defined them, and Microsoft knows
that the legacy SHA-1 AES encryption types are increasingly giving
sites that are under the gun for FIPS compliance fits.)

I suspect that Microsoft was the main proponent of adding §2.8 to
RFC4120, and they cared little about clarifying behavior in the face
of heterogeneous KDC/client Kerberos implementations, because they
knew exactly how *they* intended to implement it for their KDC and
client.

And I stand by my criticism: silently denying the ability to delegate credentials behind an obscure flag in the userAccountControl attribute
of the target host, in environments where it is *necessary* to possess
a valid credential on the target host, simply results in users
exposing their actual passwords to the target host (GSSAPI
authentication + kinit on the command line, or keyboard-interaction authentication).

This is akin to password complexity / password change interval
restrictions that are so Draconian that users cannot remember their
passwords, and resort to writing their passwords on sticky notes that
they attach to their monitors.

As for users that type their passwords onto random hosts, that is a
user education problem in general

Not in this case, because these aren’t random hosts; they are hosts
that we (our site-wide IT team) build, deploy, and administer.

but that can be addressed simply by forcing the use of 2FA
authentication on the user's part

We already employ MFA for keyboard-interactive ssh logins, and for
console logins.

preferably via a hardware token and pkinit

We have a subset of systems which must comply with DISA STIGs and for
which we must employ PKINIT using smart cards. For those systems, we
are grateful for all of the work you and others have put into sssd to
enable Linux hosts to perform PKINIT with AD as the KDC.

But for our systems that do not require PKINIT… due to our profoundly negative experiences with hardware tokens, one of our requirements
when selecting an MFA implementation was software-based TOTP/HOTP with fully-supported Android/iOS apps (a la Google Authenticator, although
we went with a different solution). Our solution doesn’t use PKINIT,
but instead performs an additional challenge once [non-PKINIT]
password authentication has already succeeded.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

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. The "wishy-washy" statements you describe are standard for introducing new protocol
extensions. 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.

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.

In fairness ... in the normal Microsoft world, they do full credential delegation very rarely, and they spent a lot of effort on constrained delegation protocol extensions because the security issues associated
with delegating a TGT. Being able to centrally manage these things from
the KDC is not unreasonable! And yes, I do wonder what world people
live in when they suggest ssh agent forwarding as an alternative
to TGT delegation; to me ssh agent forwarding seems like a much worse
solution, but to each his or her own.

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:
[...]

I sympathize with these concerns, I do; it sounds like you're in a
tough spot.

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).

First off, I would advise you to NOT look at upstream Heimdal, because
that's not helpful because it's not actually the code in question.
Instead maybe look at the actual Heimdal source code used on MacOS X?

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.

Here's the thing: I, personally, cannot reproduce this in our realm.
While we do provide our own ssh client, the stock MacOS X client still delegates credentials just fine for us. Clearly it does not work
for you, so maybe investigating WHY it doesn't work for you would be
helpful. My guess is that there is some internal realm configuration
flag being set that tags your realm as a "windows" realm and triggers
the enforcement of the ok-as-delegate flag.

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).

I do not agree with this statement. We still do this today, our
code works fine on everything up to and including Sonoma, and it
interoperates with the MacOS X Kerberos code fine. I am not sure what decisions you are referring to.

--Ken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: ralston@pobox.com (James Ralston)
Copy: kerberos@mit.edu

On 4/30/24 12:49, Ken Hornstein via Kerberos wrote:

First off, I would advise you to NOT look at upstream Heimdal, because
that's not helpful because it's not actually the code in question.
Instead maybe look at the actual Heimdal source code used on MacOS X?

To expand on this: the Apple forks of open-source projects are available
at opensource.apple.com, and at
https://github.com/apple-oss-distributions (not sure if the latter is
official or community-maintained).

I looked at the Apple fork of Heimdal and didn't find any obvious code
change to honor ok-as-delegate by default. In fact, it doesn't even
implement enforce_ok_as_delegate. But both versions do implement a
ccache config setting called "realm-config" and enforce ok-as-delegate
if the 1 bit is set in the first byte of the value. Nothing in Heimdal
or Apple's fork of it sets realm-config, but the macOS native ccache implementation or login system might do so. James could perhaps this
test theory by setting KRB5CCNAME to FILE:something, running kinit -f,
and seeing if ssh will forward those tickets.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I looked at the Apple fork of Heimdal and didn't find any obvious code
change to honor ok-as-delegate by default. In fact, it doesn't even >implement enforce_ok_as_delegate. But both versions do implement a
ccache config setting called "realm-config" and enforce ok-as-delegate
if the 1 bit is set in the first byte of the value. Nothing in Heimdal
or Apple's fork of it sets realm-config, but the macOS native ccache >implementation or login system might do so.

You missed this code in kuser/kinit.c:

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);
}

However, if I run "kinit --ok-as-delegate" in my MIT-based realm, using
the MacOS X ssh client, "ssh -K foo'" still delegates a credential fine,
so something else is clearly going on.

--Ken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)