Bug 720688
Summary: | [RFE] return multiple server addresses to the Kerberos locator plugin | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Jan Wenzel <scripter01> | ||||
Component: | sssd | Assignee: | Tomas Halman <thalman> | ||||
Status: | CLOSED ERRATA | QA Contact: | Amith <apeetham> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 7.0 | CC: | amore, apeetham, cbolz, charles_sheridan, dmoessne, dpal, grajaiya, jhrozek, kbanerje, mkarg, mkosek, msauton, mzidek, patdung100+redhat, prc, salmy, sbose, sgoveas, sssd-maint, thalman, tscherf, yjog | ||||
Target Milestone: | pre-dev-freeze | Keywords: | FutureFeature, Reopened | ||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | sssd-1.16.4-11.el7 | Doc Type: | Enhancement | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 1695582 (view as bug list) | Environment: | |||||
Last Closed: | 2019-08-06 13:02:00 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 736857, 1203710, 1205796, 1644708, 1647919, 1695582 | ||||||
Attachments: |
|
Description
Jan Wenzel
2011-07-12 13:56:27 UTC
Set krb5_kpasswd = kerberos.example.com:991 in sssd.conf. By default, the locator plugin will use the value of krb5_kdcip if krb5_kpasswd isn't specified separately. See sssd-krb5(5) for more details. (In reply to comment #2) > Set > krb5_kpasswd = kerberos.example.com:991 > > in sssd.conf. By default, the locator plugin will use the value of krb5_kdcip > if krb5_kpasswd isn't specified separately. > > See sssd-krb5(5) for more details. I already have krb5_kpasswd = kdc-01:28607,kdc-02:28607 in my sssd.conf. It does not work. Note: We are using the ldap backend for kerberos, so failover works. Can you try upgrading to SSSD 1.5.x in RHEL 6.1? If I remember correctly, we had a bug at some point where the locator plugin wasn't returning the kpasswd values unless a password-change had been initiated by SSSD (as opposed to kpasswd). OK, password change with kpassed works with sssd-1.5.1-34.el6_1.1.x86_64 from RHEL 6.1 Sorry but I have to reopen this bug: The port argument is only used for the first server entry. If the first server is offline, it tries to connect to the second server with the default port. So this is still a bug with the current version. Also, the log file says that krb5_kdcip is deprecated and should be replaced by krb5_server. If I do this, it uses the default kpwasswd even for the first server entry. (In reply to comment #7) > Sorry but I have to reopen this bug: > The port argument is only used for the first server entry. If the first server > is offline, it tries to connect to the second server with the default port. So > this is still a bug with the current version. > I'm sorry, but it's not really clear to me what the behavior is vs. what it should be. Given your example above, if "kdc-01:28607" is down, kpasswd does not try to contact the second server (kdc-02) at all or does it "just" ignore the port number? > Also, the log file says that krb5_kdcip is deprecated and should be replaced by > krb5_server. If I do this, it uses the default kpwasswd even for the first > server entry. Sorry, but which server do you mean by "default kpasswd"? Are you saying that if sssd defines krb5_server and krb5_kpasswd, kpasswd only contacts the KDC and not the kpasswd server? Would you mind attaching your sssd.conf? Also, it would be helpful to see the logs - can you please put "debug_level = 9" into the domain section of your /etc/sssd/sssd.conf, restarting sssd, re-running the testcase and then attaching /var/log/sssd/sssd_$DOMAINNAME.log Of course, feel free to sanitize the logs by removing sensitive data if needed. Thank you! (In reply to comment #9) > (In reply to comment #7) > > Sorry but I have to reopen this bug: > > The port argument is only used for the first server entry. If the first server > > is offline, it tries to connect to the second server with the default port. So > > this is still a bug with the current version. > > > > I'm sorry, but it's not really clear to me what the behavior is vs. what it > should be. > > Given your example above, if "kdc-01:28607" is down, kpasswd does not try to > contact the second server (kdc-02) at all or does it "just" ignore the port > number? It "just" ignores the port number for the second server. > > Also, the log file says that krb5_kdcip is deprecated and should be replaced by > > krb5_server. If I do this, it uses the default kpwasswd even for the first > > server entry. > > Sorry, but which server do you mean by "default kpasswd"? Are you saying that > if sssd defines krb5_server and krb5_kpasswd, kpasswd only contacts the KDC and > not the kpasswd server? I mean the default kpasswd port. kpasswd contacts the defined kpasswd server with the default kpasswd port instead of the configured port if i replace krb5_kdcip with krb5_server. > > Would you mind attaching your sssd.conf? As you wish. > Also, it would be helpful to see the logs - can you please put "debug_level = > 9" into the domain section of your /etc/sssd/sssd.conf, restarting sssd, > re-running the testcase and then attaching /var/log/sssd/sssd_$DOMAINNAME.log > > Of course, feel free to sanitize the logs by removing sensitive data if needed. I will do this if needed. > Thank you! Thank you, too! (In reply to comment #12) > (In reply to comment #9) > > (In reply to comment #7) > > > Sorry but I have to reopen this bug: > > > The port argument is only used for the first server entry. If the first server > > > is offline, it tries to connect to the second server with the default port. So > > > this is still a bug with the current version. > > > > > > > I'm sorry, but it's not really clear to me what the behavior is vs. what it > > should be. > > > > Given your example above, if "kdc-01:28607" is down, kpasswd does not try to > > contact the second server (kdc-02) at all or does it "just" ignore the port > > number? > > It "just" ignores the port number for the second server. > I am surprised it even tries to contact the second server, for two reasons: First, the fix which always resolves the kpasswd server from SSSD is not present in sssd-1.5.1-34.el6_1.1, it went to the RHEL6.2 branch only as far as I can tell. Second, even if SSSD resolves the first kpasswd server, it has no way of telling it needs to fail over if the "kpasswd" utility is used. The "kpasswd" utility completely bypasses SSSD and the PAM stack and talks directly to the kpasswd server (unlike passwd). > I am surprised it even tries to contact the second server, for two reasons: > > First, the fix which always resolves the kpasswd server from SSSD is not > present in sssd-1.5.1-34.el6_1.1, it went to the RHEL6.2 branch only as far as > I can tell. > > Second, even if SSSD resolves the first kpasswd server, it has no way of > telling it needs to fail over if the "kpasswd" utility is used. The "kpasswd" > utility completely bypasses SSSD and the PAM stack and talks directly to the > kpasswd server (unlike passwd). The kpasswd utility uses the krb5_locator plugin as mentioned in the subject of this bug. If it completely bypasses sssd (if we move the plugin away) it works as expected. So this must be a sssd related bug. I can prepare a debug level 10 log of this domain in the next week if this will help you. (In reply to comment #14) > > I am surprised it even tries to contact the second server, for two reasons: > > > > First, the fix which always resolves the kpasswd server from SSSD is not > > present in sssd-1.5.1-34.el6_1.1, it went to the RHEL6.2 branch only as far as > > I can tell. > > > > Second, even if SSSD resolves the first kpasswd server, it has no way of > > telling it needs to fail over if the "kpasswd" utility is used. The "kpasswd" > > utility completely bypasses SSSD and the PAM stack and talks directly to the > > kpasswd server (unlike passwd). > The kpasswd utility uses the krb5_locator plugin as mentioned in the subject of > this bug. If it completely bypasses sssd (if we move the plugin away) it works > as expected. So this must be a sssd related bug. > > I can prepare a debug level 10 log of this domain in the next week if this will > help you. Right, kpasswd (or rather libkrb) uses the server it gets via krb5_locator plugin. That's not the problem. The problem is that kpasswd has no way of telling SSSD that the server given to libkrb5 by the plugin is down because it does not talk to SSSD but rather to the kpasswd server directly. If passwd was used instead of kpasswd, the change password request would go through the PAM stack and eventually reach pam_sss and SSSD. SSSD has means to detect that the server is down and is able to fail over. My customer would like to see this in 6.3 if anyhow possible - can we get pm ack on this one please? Thanks Marko Thank you for filing this bug report. Since fixing this bug requires work in the upstream SSSD project which is not scheduled for the immediate future, I added a conditional development nack, pending upstream availability. Sorry, this is still work-in-progress. I have a patch for the plugin itself so that it can handle multiple addresses. But the SSSD side to make those addresses available to the plugin is still missing. Fixed as part of the following series ... master: efae950 9f68324 c1fbc6b 2124275 cc79227 d91661e 4759a48 f28d995 I'm going to move the bug back to ASSIGNED. I know the upstream tickets were really less than clear, cross-referenced each other and so did the bugzillas. So to make it clear what was pushed to upstream: - the Kerberos locator plugin is now able to consume multiple addresses from the kdcinfo files. This will most probably be in 7.6 (modulo the usual disclaimer about future releases..) - 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 and I hope that the patch makes 7.6 (modulo the usual disclaimer about future releases..) We're now working on another, subsequent patchset that would write multiple addresses into kdcinfo files, but /only in the IPA-AD client case/. I hope it is clearer what was implemented and what is still in the works. I'm moving the bug to 7.7, because the scope of the work *as described in the subject* is still not implemented and not even started. But at the same time, I believe that the use-case tracked in most of the customer cases is either implemented in the 7.6 codebase already or being worked on and planned. To summarize the previous comment again: - the Kerberos locator plugin can consume multiple addresses - clients joined directly to AD generate kdcinfo files to be consumed by the kdcinfo files. So far the kdcinfo files would only contain one address, but previously the files were not created at all. This is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1494690 - the previous point applies also for IPA servers in a trust relationship with an AD domain - currently I'm working on generating the kdcinfo files for IPA clients in a trust relationship. The patches work, but need a little cleanup. I'm quite hopeful they would make 7.6 and this work is tracked with https://bugzilla.redhat.com/show_bug.cgi?id=1416528 Upstream ticket: https://pagure.io/SSSD/sssd/issue/3973 First ticket fixed: master: 63ccbfe sssd-1-16: 96e4d71 Another master PR: * master: 208a79a * sssd-1-16: c225ed7 Final PR: * master: e8d806d9bbb1ba288ed6a83158113f4d8f8a8929 * sssd-1-16: ec0c31a71ef8ec61e11b1c6d21edcf9b923ce4ca Hi thalman, could you add verification steps for this. in sssd.conf specify more servers, Some of them doesn't have to exist for the test, put at least 4 servers and at least 2 backup servers krb5_server = server1, server2, server3, server4 krb5_backup_server = bck1, bck2 krb5_use_kdcinfo = true You can do the same for krb5_kpasswd, krb5_backup_kpasswd options * re/start sssd * log into system with kerberos credentials * check /var/lib/sss/pubconf for created kdcifo file. Expected result: ** KDC info file should have 3 servers + one backup server, one server per line. ** Some servers can have their name in file, some can be already resolved to IP address ** Order of servers in file can change depending on failover mechanism * set krb5_kdcinfo_lookahead to different values (default is "3:1", so try "4:0", "4:2") Expected result: ** Number of servers in KDC info file changes accordingly Hi, Jackub, Tomas Could you have a look in comment #49 If steps are wrong could you add correct steps based on above test. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:2177 |