Fields changed

rhbz: => 720688

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.8.0

We are allowed to call {{{cbfunc()}}} multiple times in {{{sssd_krb5_locator_lookup()}}} which will enqueue an ordered list of servers that the client tools can try.

This should solve the problem easily.

Should this done by default, though?

If we resolve all servers that are configured in our failover list, there's several problems that may arise -- we might need to periodically refresh the list to honour TTL, the users might get confused about kpasswd/kinit talking to a different server than SSSD due to failover happening differently at two places etc.

Regarding TTL: I think it's a reasonable limitation to document that we will only refresh the locator plugin list when the TTL of the primary IP address is expired. At that time, we'll refresh all of the entries from the locator.

Secondly, you're right. If we're using a SRV record with 50 possible KDCs, we shouldn't resolve all of them for the locator. I suggest that we provide an option for the number of servers to resolve and pass back (defaulting to 3).

As for the users being confused, this is still better than the workaround that people are currently using (which is disabling the locator plugin).

Right now, the problem is that we won't notice if the KDC we're pointing at is down unless SSSD tries to use it. With this solution, until such time as SSSD becomes aware of it, kinit and friends will quietly use a failover KDC.

However, once the SSSD reorients itself, it will also update the locator plugin at the same time. So from a user's perspective, there is never a time that they're operating simultaneously against different KDCs. KDC_A dies, kinit switches to using KDC_B. When SSSD tries to do an auth, it discovers KDC_A is down and tries KDC_B next, which is working.

The only special case would be if SSSD refreshes the SRV record, which could result in the ordering changing. But even in that case, it doesn't really matter. The KDC being contacted would change, but the tools would also change, so it's at least consistent.

Fields changed

description: If a user uses tools that don't go through the PAM stack for changing Kerberos password (like kpasswd), then SSSD does not know that the server is down and has no way of using fail over to present the locator plugin with a new address.

We should investigate whether it is possible to return multiple addresses to the plugin so that libkrb can fail over. => https://bugzilla.redhat.com/show_bug.cgi?id=720688

If a user uses tools that don't go through the PAM stack for changing Kerberos password (like kpasswd), then SSSD does not know that the server is down and has no way of using fail over to present the locator plugin with a new address.

We should investigate whether it is possible to return multiple addresses to the plugin so that libkrb can fail over.

Fields changed

rhbz: 720688 => [https://bugzilla.redhat.com/show_bug.cgi?id=720688 720688]

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.8.0 => SSSD 1.9.0

Fields changed

milestone: SSSD 1.9.0 => SSSD Kerberos improvemens

When we resolve this, we need to ensure that we do the DNS lookup at SSSD startup, not on first action. This will resolve #1401 as well.

feature_milestone: =>

Fields changed

milestone: SSSD Kerberos Improvements Feature => SSSD 1.9.0 beta 5
priority: major => blocker

This enhancement is not going to happen in beta6. Putting into NEEDS_TRIAGE for discussion.

milestone: SSSD 1.9.0 beta 6 => NEEDS_TRIAGE

Fields changed

component: SSSD => Kerberos Locator

We were wondering if this could have been used to solve the domain_realm mapping problem and it turned out it can't. At the same time, the scope of this enhancement is too big for the last 1.9 beta.

Moving to 1.10 beta.

milestone: NEEDS_TRIAGE => SSSD 1.10 beta

Stephen started a design document:
https://fedorahosted.org/sssd/wiki/DesignDocs/KerberosLocator

Fields changed

milestone: SSSD 1.10 beta => SSSD Kerberos Improvements Feature
proposed_priority: => Important

Moving all the features planned for 1.10 release into 1.10 beta.

milestone: SSSD Kerberos Improvements Feature => SSSD 1.10 beta

Fields changed

priority: blocker => major

Fields changed

priority: major => minor

Fields changed

priority: minor => major

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=869318 (Red Hat Enterprise Linux 5)

rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=720688 720688] => [https://bugzilla.redhat.com/show_bug.cgi?id=720688 720688], [https://bugzilla.redhat.com/show_bug.cgi?id=869318 869318]

Fields changed

selected: => Not need

Moving tickets that are not a priority for SSSD 1.10 into the next release.

milestone: SSSD 1.10 beta => SSSD 1.11 beta

Fields changed

mark: => 0

Nice to have but probably won't happen in 1.13..

changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
milestone: SSSD 1.13 beta => SSSD 1.13 backlog
review: => 0

Mass-moving tickets not planned for the 1.13 release to 1.14

milestone: SSSD 1.13 backlog => SSSD 1.14 beta

Unfortunately, this ticket is out of scope for the 1.14 release, moving to 1.15

milestone: SSSD 1.14 beta => SSSD 1.15 beta
sensitive: => 0

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1350012 (Red Hat Enterprise Linux 7)

rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=720688 720688], [https://bugzilla.redhat.com/show_bug.cgi?id=869318 869318] => [https://bugzilla.redhat.com/show_bug.cgi?id=720688 720688], [https://bugzilla.redhat.com/show_bug.cgi?id=869318 869318], [https://bugzilla.redhat.com/show_bug.cgi?id=1350012 1350012]

Fields changed

cc: => rharwood@redhat.com

Fields changed

cc: rharwood@redhat.com => rharwood@redhat.com, msauton@redhat.com

Issue linked to Bugzilla: Bug 1494690

Commit 2124275 relates to this ticket

Commit c1fbc6b relates to this ticket

Commit 9f68324 relates to this ticket

Commit efae950 relates to this ticket

Related fixes are part of the following series ...
master:
efae950
9f68324
c1fbc6b
2124275
cc79227
d91661e
4759a48
f28d995

I'm going to reopen the ticket.

To make it clear what was pushed to upstream:
- the Kerberos locator plugin is now able to consume multiple addresses from the kdcinfo files.
- BUT there is no mechanism yet in SSSD which would write multiple addresses into the kdcinfo files

• the patches add the ability to generate the kdcinfo files for trusted domains of directly joined AD clients and IPA masters in a trust relationship with an AD domain
• BUT there is no mechanism yet for writing the kdcinfo files on IPA clients in an IPA-AD trust setup. I'm working on a subsequent patch that would implement this.

I hope it is clearer what was implemented and what is still in the works.

@jhrozek, thanks for jumping in an clarifying this. I've also edited the comment about the patches.

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/1983

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.