Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

2024-06-26 Thread James Ralston
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 wil

Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

2024-04-30 Thread Ken Hornstein via Kerberos
>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 bi

Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

2024-04-30 Thread Greg Hudson
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

Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

2024-04-30 Thread Ken Hornstein via Kerberos
>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 "wish

Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

2024-04-29 Thread James Ralston
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,

Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

2024-04-29 Thread James Ralston
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

Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

2024-04-16 Thread Ken Hornstein via Kerberos
>> 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

Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

2024-04-16 Thread Simo Sorce
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 eve

Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

2024-04-16 Thread James Ralston
On Mon, Apr 15, 2024 at 7:56 PM Ken Hornstein 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

Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

2024-04-15 Thread Stephen Frost
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

Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

2024-04-15 Thread Ken Hornstein via Kerberos
>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