Learn more about these different git repos.
Other Git URLs
https://bugzilla.redhat.com/show_bug.cgi?id=894988 (Red Hat Enterprise Linux 6)
Description of problem: If sssd.conf contains "krb5_server = slave-kdc" and "krb5_kpasswd = master-kdc" and "slave-kdc" has a password for a user different from the one "master-kdc" has (e.g. propagation hasn't yet occurred), it is possible to authenticate as that user with both master-kdc's and slave-kdc's passwords. Version-Release number of selected component (if applicable): libsss_autofs-1.9.2-68.el6.x86_64 libsss_idmap-1.9.2-68.el6.x86_64 sssd-client-1.9.2-68.el6.x86_64 sssd-1.9.2-68.el6.x86_64 libsss_sudo-1.9.2-68.el6.x86_64 How reproducible: always Steps to Reproduce: Setup: 1. Setup master/slave KDC pair. 2. Setup master->slave database propagation, but don't setup automatic propagation. 3. Setup DNS to describe the realm and KDCs, using the attached zone files as reference. 4. Setup LDAP directory, using the attached LDIF file as reference. 5. Add a user principal to master KDC database with password #1. 6. Propagate the database to slave KDC manually. 7. Change the user's password on master KDC to password #2, but don't propagate the database. 8. Setup SSSD client using the attached sssd.conf as reference. Set krb5_server to point to the slave KDC and krb5_kpasswd to point to the master KDC. Tests: 1. On SSSD client, authenticate as the user, using password #1. 2. On SSSD client, authenticate as the user, using password #2. Actual results: 1. Authentication successful. 2. Authentication successful. Expected results: 1. Authentication successful. 2. Authentication fails. Additional info: The reference setup has master KDC on manual-srv1.example.com (192.168.121.10) and slave KDC on manual-srv2.example.com (192.168.121.11). The client is on manual-clnt.example.com (192.168.121.12). This works as expected, if krb5_kpasswd is not set, or if both krb5_server and krb_kpasswd are set to the same KDC host, either master or slave.
Fields changed
blockedby: => blocking: => coverity: => design: => design_review: => 0 feature_milestone: => fedora_test_page: => milestone: NEEDS_TRIAGE => SSSD Deferred selected: => testsupdated: => 0
Ben Kaduk thinks (and I agree) that this behavior comes from line 292 of sssd_krb5_locator_plugin.c. A request for locate_service_master_kdc is asking for a KDC to authenticate against as a fallback if the initial authentication fails.
Thank you for the second look. Yes, this looks plausible. Sorry I suspected libkrb5 initially.
Still, I don't think this is worth fixing. I think this upstream ticket should stay in the Deferred queue unless it's causing real problems for anyone.
Metadata Update from @jhrozek: - Issue set to the milestone: SSSD Patches welcome
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/2804
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.