Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?
On Tue, Apr 16, 2024 at 9:31 PM Ken Hornstein 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
Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?
On Tue, Apr 16, 2024 at 1:46 PM Simo Sorce 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
