Learn more about these different git repos.
Other Git URLs
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.
host/fqdn
SHORTNAME$
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.
milestone: NEEDS_TRIAGE => SSSD 1.13 beta
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)
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
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)
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.