#1871 krb5 validation code always picks the first matching principal
Closed: wontfix 4 years ago by pbrezina. Opened 10 years ago by jhrozek.

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)

7 years ago

Metadata Update from @thalman:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue tagged with: Canditate to close

4 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2913

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata