#941 return multiple server addresses to the Kerberos locator plugin
Closed: Fixed 2 years ago Opened 9 years ago by jhrozek.

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

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

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

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

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

Fields changed

cc: => rharwood@redhat.com

Fields changed

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

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

3 years ago

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

Metadata Update from @fidencio:
- 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 sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None

2 years ago

Metadata Update from @fidencio:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue status updated to: Open (was: Closed)

2 years ago

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.

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue close_status updated to: Fixed

2 years ago

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

Metadata Update from @fidencio:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

2 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/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.

Login to comment on this ticket.

Metadata