Adding support for optimistic preauth to kinit

Greg Hudson ghudson at mit.edu
Tue Apr 6 01:12:23 EDT 2021


On 4/4/21 11:43 PM, Ken Hornstein wrote:
> Really, the REAL goal is to force a particular preauth mechanism.  We have
> patches to kinit that make it so when kinit is called as "pkinit", it
> will try PKINIT by default.  The way this is done is by setting the
> optimistic preauth list.

I'm curious what this was needed for.  Our initial ticket code is pretty
aggressive about trying PKINIT if the KDC offers it.  Not only do KDCs
tend to offer PKINIT first when they're configured for it, but even if
they don't, the client code sorts the PKINIT types to the front of the
list (overridable with [libdefaults] preferred_preauth_types).  So,
putting PKINIT in the optimistic preauth list wouldn't seem to change
the behavior of kinit except to save a round trip.

>> A path of lower resistance is to add an option to force a particular
>> preauth mech (single choice, hard-failing if it isn't available or
>> doesn't work).  clpreauth modules already declare names like "pkinit"
>> and "sam2" which could be matched against.
> 
> Honestly, I'd be fine with this (although it does occur to me that you
> might want to specify more than one preauth to use)
What use cases do you have in mind for specifying more than one?

I'd be willing to consider a patch in this direction, since my other
ideas aren't well-formed enough to pursue.


More information about the krbdev mailing list