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.
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
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)
to comment on this ticket.