Re: CVE-2020-17049

On Mon, Nov 16, 2020 at 10:48 AM Luke Hebert wrote: > We've just started encountering problems at customer sites with > Kerberos enabled clients as a result of how Microsoft appears to be > approaching CVE-2020-17049 > . The > details

Re: Is there a "batchable" way to do ktutil list

On Wed, Apr 21, 2021 at 6:42 AM Ken Hornstein wrote: > > Is there another command that is more script-friendly? If not, > > can someone share a good way to pass args to the MIT ktutil? > > I think "klist -k" does what you want. You can pass arguments to > ktutil in a script via stdin and parse

Re: kerberos credential cache filename with sshd causing problems for long running jobs

On Wed, Jul 7, 2021 at 8:20 PM Jason Keltz wrote: > I assume that the reason that SSHd creates the sshd credential cache > in /tmp/krb5cc__ is so that an ssh session will > not share the same credential cache with say, a local workstation > login. The reason why sshd creates the Kerberos file cr

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

Has anyone else struggled with ssh clients being unable to delegate Kerberos credentials to a remote host because the Kerberos library that the ssh client uses implements the MS-SFU Kerberos Protocol Extensions and therefore honors the TRUSTED_FOR_DELEGATION flag of the target host? More generally

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

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?

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?

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?

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