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

[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 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  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

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

[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, 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?

[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 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 

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

[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 AD is
acting as the KDC, whether AD sets the the OK-AS-DELEGATE flag in the
TGS-REP is determined by whether the userAccountControl attribute in
Active Directory of the host for which a service ticket is being
requested has the TRUSTED_FOR_DELEGATION flag set. If
TRUSTED_FOR_DELEGATION is set, OK-AS-DELEGATE is set in the TGS-REP;
otherwise, OK-AS-DELEGATE is not set in the TGS-REP.

> the [MIT Kerberos] library already provides an option to ignore that
> [the OK-AS-DELEGATE] flag and it seems that by default it DOES
> ignore that flag)

I think the enforce_ok_as_delegate is the option you’re referring to?

The man page claims it is disabled by default (unless an application
specifically requests it). That matches our experiences.

Heimdal appears to implement the same option (enforce_ok_as_delegate),
but although the upstream source claims the default is false (do not
enforce), Macs seem to enforce it by default. So either Apple has
changed that default in the code, or else they are overriding the
default somewhere in the Kerberos configuration.

In terms of Windows, Microsoft’s Kerberos implementation seems to
enforce compliance with the OK-AS-DELEGATE flag. (PuTTY on Windows
will not delegate a credential unless the target host has the
TRUSTED_FOR_DELEGATION flag set in AD.) Perhaps there is a way to
disable this behavior, but we have not yet found a way to do so.

> the RFC provides what I would consider a cognizant explanation:
>
> https://datatracker.ietf.org/doc/html/rfc4120#section-2.8

Microsoft provides a similar explanation, but it is still an
unsatisfying one, because it does not speak to our issue: if denying
the ability to delegate a credential (in order to protect it from
exposure to a possibly-untrustworthy host) forces the user to instead
acquire a credential directly from the possibly-untrustworthy host
(thereby exposing the user’s actual password), then this is not a
security improvement. And while I acknowledge that RFC4120 is 19 years
old and a lot has changed since it was originally published, neither
the RFC authors nor Microsoft seems to have considered/predicted this
scenario.

On Mon, Apr 15, 2024 at 8:40 PM Stephen Frost  wrote:

> I'd *strongly* encourage you to ignore what OSX comes with in terms
> of Kerberos "support" and push to move everything away from what OSX
> ships with and to instead use MIT Kerberos. In my experience, this
> is far from the only issue you're going to run into with the hacked
> up Kerberos from OSX and they don't seem to care to properly
> maintain it.

It has been our experience that ripping out a vendor-supplied
library/package and replacing it with an in-house version almost
always has a higher long-term cost than simply living with whatever
warts the vendor-supplied library/package has. So we are reluctant to
take this approach unless there is truly no other choice.

But this segues back to my original question: how are other sites that
use Microsoft AD as their KDCs handling this?

Are other sites ensuring that the TRUSTED_FOR_DELEGATION flag is set for
Linux hosts, so that all various Kerberos libraries (including ones
that enforce OK-AS-DELEGATE by default) will correctly delegate
credentials to Linux hosts?

Are other sites configuring their Kerberos libraries (on a per-OS
basis) to ignore the OK-AS-DELEGATE flag?

Have few other sites that use Microsoft AD as their KDC even run into
this, because they don’t have services (e.g. home directories mounted
via NFSv4+RPCGSS) that require a Kerberos credential, and therefore
don’t need to forward Kerberos credentials to the remote host when
making an ssh connection to it?

My read of the MIT Kerberos kdc.conf man page is that ok-as-delegate
is not one of the flags in default_principal_flags that defaults to
enabled. So heterogeneous sites that use MIT Kerberos as their KDCs
(not AD) should also be seeing this issue.

At least so far, we *think* the best course of action is to always set
the TRUSTED_FOR_DELEGATION flag for Linux hosts in AD, so that
credential delegation won’t depend on whether the Kerberos library
that any specific host uses pays attention to the OK-AS-DELEGATE flag.
And this does seem to be the intention of the TRUSTED_FOR_DELEGATION /
OK-AS-DELEGATE flags: it’s advice to Kerberos clients that it’s OK to
delegate credentials to the target host, which is exactly what we want
to happen.

The only thing we’re not completely sure about is whether setting the
TRUSTED_FOR_DELEGATION flag in AD will have other security
ramifications that aren’t clear from Microsoft’s documentation. Which
is why I was hoping that others on this list have already been down
this particular road and could of

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

[James Ralston]

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: does anyone know exactly what Microsoft was thinking
when they dreamed up this flag?

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 implemented a new flag in the MS-SFU
Kerberos Protocol Extensions, TRUSTED_FOR_DELEGATION. The flag is a
property of the service principal of the *target* host: if the target
host does not have the TRUSTED_FOR_DELEGATION flag set in the
userAccountControl attribute of the host’s machine account in Active
Directory, then if the Kerberos library that the ssh client uses
honors the MS-SFU Kerberos Protocol Extensions and honors the
TRUSTED_FOR_DELEGATION flag, it will refuse to delegate the user’s
credentials to the target host, *even* if all other settings would
permit credential delegation.

Because MIT Kerberos doesn’t honor the TRUSTED_FOR_DELEGATION flag (or
any part of the MS-SFU Kerberos Protocol Extensions?), our folks who
use only Linux systems have never noticed an issue. But we have an
increasing number of Mac users who wish to ssh from their Macs to
Linux hosts, and since Macs use Heimdal, which *does* implement the
MS-SFU Kerberos Protocol Extensions and therefore honors the
TRUSTED_FOR_DELEGATION flag, Mac users cannot ssh to Linux hosts and
delegate their credentials. Because we use NFS-mounted home
directories with RPCGSS security, this means that Mac users get
"Permission denied" errors when accessing their home directories if
they use gssapi-with-mic or gssapi-keyex ssh authentication to Linux
hosts: they can login via gssapi-with-mic or gssapi-keyex, but without
the credential, they cannot access their home directories.

(The irony here is that the only way for Mac users to login to Linux
hosts and actually have a home directory is if they perform
gssapi-with-mic/gssapi-keyex authentication and then manually run
kinit, or else use an ssh authentication mechanism that performs kinit
explicitly as part of the authentication (password or
keyboard-interaction auth). If Microsoft’s goal for the
TRUSTED_FOR_DELEGATION flag was to prevent users from passing their
credentials to a remote host that might be operated by a grey-hat or
otherwise not-completely-trusted administrator, then congratulations:
by attempting to prevent exposure of the credential to that
not-completely-trusted admin, you’ve only guaranteed that users must
now expose their *actual passwords* instead.)

Once we finally figured out that it was the TRUSTED_FOR_DELEGATION
flag that was preventing Mac users from passing credentials, we asked
our Active Directory administrators to grant our Linux admins the
ability to set the TRUSTED_FOR_DELEGATION flag for Linux hosts, so
that we can set the flag when we create a new Linux host and join it
to AD. But our AD admins are balking, because Microsoft’s
documentation is abysmally unclear in explaining the greater security
ramifications of setting the TRUSTED_FOR_DELEGATION for a host.

Our tentative conclusion at this point is that the
TRUSTED_FOR_DELEGATION flag was a fantastically stupid idea on
Microsoft’s part and the correct course of action is to work-around
its existence as best we can: by ensuring that the flag is set on the
AD host machine account on every Linux host which accepts remote ssh
logins. As far as we can discern, the only thing this will enable is
the ability for anyone to delegate a forwardable Kerberos credential
to the host—which is exactly what we want.

Have we misunderstood the goal of the TRUSTED_FOR_DELEGATION flag?
Does anyone know of any security ramifications of enabling it that we
have not considered?

(As a side note, if MIT Kerberos ever decides to implement/honor the
TRUSTED_FOR_DELEGATION flag, we fervently hope that the implementation
also creates a new krb5.conf flag to ignore it; e.g.,
honor_trusted_for_delegation_die_die_die.)


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[James Ralston]

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 credential cache with
mkstemp() is to avoid race condition attacks, where an attacker
leverages the fact that a user's credential cache file is in a
predictable location to either execute a denial-of-service attack or
steal the victim's credentials.

This is also why there is no option to disable it.

> In addition, if the user wants to run a really long job, and that
> job will run for longer than 7 days, I can instruct the user to
> create a keytab file, then pass that to kinit periodically via cron,
> but I'll have the same problem -- they would have to specify the
> full path to their credential cache because kinit would otherwise
> assume the default location of /tmp/krb5cc_.
>
> Let's assume that the user won't be logging into the local
> workstation and will only connect via SSH.  Would it be reasonable
> for me to manually copy /tmp/krb5cc__ to
> /tmp/krb5cc_ when required, then change KRB5CCNAME to point to
> /tmp/krb5cc_ instead of /tmp/krb5cc__ so that
> things just work? This way, sshd can delete it's cache as required
> on logout, and the user can continue to easily run their compute job
> (albeit being careful about local workstation login versus remote
> ssh login to the same machine).

Running long jobs that need Kerberos credentials is really a problem
for k5start(1).  Is there a reason why you can't use it?

https://www.eyrie.org/~eagle/software/kstart/k5start.html

> I know there are other mechanisms for credential cache.  In my case,
> those won't work on my current installation.

If you can't use k5start, your effort would probably be best spent in
finding a way to make other credential cache types (e.g.,
KEYRING:persistent: or KCM:) usable on your installation, as the
issues you are encountering with the FILE: cache type are inherent
limitations.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[James Ralston]

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 the output (we do that via a
> script), that looks something like:
>
> (echo "rkt $keytab" ; echo "list") | ktutil | [parse output]
>
> The script this is from is so old, it predates the widespread use of
> the 'printf' command; that would probably be cleaner now.

Related to this: it would be tremendously useful if klist had a flag
to generate output intended to be machine-parsable, such as CSV or
JSON.

Yeah, I get it: the MIT Kerberos software predates UTF-8, let alone
JSON, and was written at a time when wizened greybeards (not machines)
were the ones parsing "klist" output.  In terms of development
priorities versus free developer cycles, making klist output CSV/JSON
is probably far down on the priority stack.

But still.  Not being able to get machine-readable output out of klist
turns what should be simple and useful scripting tasks, such as "scan
the 9 different TGTs in my credential cache collection and renew any
that expire in less than 12 hours", into "whee, I guess I'm writing a
finite-state automaton in shell again".

And while "klist -k" is a lot easier to parse than "klist" output
(because it's not multi-line), given that at our site we send a
boatload of host telemetry into Splunk every 30 minutes via an input
script that just execs "puppet facts --render-as json", it's
frustrating that there's no easy way to send up keytab data as well.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: CVE-2020-17049

[James Ralston]

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 on this CVE are slim on Mitre and there is a small amount of
> additional information on the microsoft portal. I thought I'd ask
> the list what their thoughts are on what is being done here.
> Disabling service ticket and tgt renewability is not great and it
> obviously breaks long running processes that rely on renewability of
> these items.

I believe we are being bitten by this change as well. Here’s what we
see.

I perform an initial kinit, and request a renewable ticket:

$ kinit usern...@example.org
Password for usern...@example.org:

As klist shows, the ticket is renewable:

$ klist -f
Ticket cache: KCM:2000:78917
Default principal: usern...@example.org

Valid starting   Expires  Service principal
2020-11-13 13:15:57  2020-11-14 13:15:50  krbtgt/example@example.org
renew until 2020-11-20 13:15:50, Flags: FRIA

Decoding the Flags field:

+--+--+
| flag | meaning  |
+--+--+
|  F   | Forwardable  |
|  R   | Renewable|
|  I   | Initial  |
|  A   | preAuthenticated |
+--+--+

But attempting to renew this ticket throws an error:

$ kinit -R
kinit: KDC can't fulfill requested option while renewing credentials

From packet tracing, the TGS-REQ packet contains the following options:

kdc-options: 4082
.1..  = forwardable: True
1...  = renewable: True
 ..1. = renew: True

This is exactly what a renewal request should contain: a renew request
(renew: True) using a non-expired renewable ticket (renewable: True).

But the reply from the server is KRB-ERROR, and contains:

krb-error
msg-type: krb-error (30)
error-code: eRR-BADOPTION (13)

Curiously, we have multiple AD realms, and not all of them show this
problem, despite the fact that our Windows admins assert that all
realms received the Microsoft updates that contain the fix for
CVE-2020-17049.

I’ve asked our Windows admins to enumerate what the
PerformTicketSignature registry keys are set to for all of our DCs,
for all realms.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos