#1871 krb5 validation code always picks the first matching principal
Opened 6 years ago by jhrozek. Modified 2 years ago

Reported on #sssd by John Hodrien.

The krb5 validation code always tries the first principal for the particular realm that is present in keytab and falls back to the last one. This might not be correct for the (arguably frequent) case where the keytab contains both host/fqdn keys and SHORTNAME$ keys. In this case, we should be using SHORTNAME$ the same way we do for Kerberos authentication.

Triaged. Not an issue. Explanation will follow. The ticket will be closed.

milestone: NEEDS_TRIAGE => SSSD 1.10.0
rhbz: => 0

As I was reminded today the validation would work OK with any valid service principal, it really doesn't have to be the same principal as was used for kinit. So the service principal was invalid.

Not a bug.

resolution: => invalid
status: new => closed

Fields changed

changelog: =>
milestone: SSSD 1.10.0 => NEEDS_TRIAGE
resolution: invalid =>
status: closed => reopened
type: defect => enhancement

This problem affects me. I use msktutil to join the host to an AD domain. Msktutil uses a special account with permission to add hosts to the domain, and nothing else. In particular, it lacks permission to list users. Hence it is unfit to fetch the data sssd needs.
Because msktutil is the first application on a newly installed host to use Kerberos, the principal for the join account holds the first key in the keytab. Sssd then tries to use that principal and fails.

There are workarounds: remove the key from the keytab after the machine has joined the domain. Or tell msktutil to use a different keytab. But IMHO sssd's assumption that the first key in the keytab will always work is just wrong, even though it often does work. There are other applications that store their keys in the system keytab, and assuring no useless key gets in the way of sssd currently depends on their configurational flexibility.

IMHO, the best solution would be for sssd to try the usual suspects (shortname$@realm), then fall back to trying every key in the keytab. Lacking that, configuration options to choose a particular key or keytab, or both, would work.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13 beta

Fields changed

mark: => 0

I'm not sure if we can change the behaviour in a non-backwards compatible way at all..

milestone: SSSD 1.13 beta => SSSD 1.13 backlog
priority: major => minor

Mass-moving tickets not planned for the next two releases.

Please reply with a comment if you disagree about the move..

milestone: SSSD 1.13 backlog => SSSD 1.15 beta

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD Future releases (no date set yet)

2 years ago

Login to comment on this ticket.