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 <k...@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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos