On Tue, Apr 16, 2024 at 9:31 PM Ken Hornstein <k...@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