Bug 1481467
| Summary: | cyrus-sasl-2.1.26-gss-spnego.patch breaks GSSAPI for me | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jason Tibbitts <j> |
| Component: | cyrus-sasl | Assignee: | Jakub Jelen <jjelen> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 26 | CC: | jjelen, plautrba, ssorce, vanmeeuwen+fedora |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-05-29 11:42:57 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I should add that when I run ldapsearch and the client fails, the server logs this: Aug 14 20:35:07 dir2.math.uh.edu slapd[24548]: conn=4468 fd=32 ACCEPT from IP=129.7.128.2:60538 (IP=0.0.0.0:389) Aug 14 20:35:07 dir2.math.uh.edu slapd[24548]: conn=4468 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Aug 14 20:35:07 dir2.math.uh.edu slapd[24548]: conn=4468 op=0 SRCH attr=supportedSASLMechanisms Aug 14 20:35:07 dir2.math.uh.edu slapd[24548]: conn=4468 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 14 20:35:07 dir2.math.uh.edu slapd[24548]: conn=4468 op=1 BIND dn="" method=163 Aug 14 20:35:07 dir2.math.uh.edu slapd[24548]: conn=4468 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: security flags do not match required Aug 14 20:35:07 dir2.math.uh.edu slapd[24548]: conn=4468 op=2 BIND dn="" method=163 Aug 14 20:35:07 dir2.math.uh.edu slapd[24548]: conn=4468 op=2 RESULT tag=97 err=14 text=SASL(0): successful result: security flags do not match required Aug 14 20:35:07 dir2.math.uh.edu slapd[24548]: connection_operation: error: SASL bind in progress (tag=66). Aug 14 20:35:07 dir2.math.uh.edu slapd[24548]: conn=4468 op=3 RESULT tag=48 err=1 text=SASL bind in progress Aug 14 20:35:07 dir2.math.uh.edu slapd[24548]: conn=4468 fd=32 closed So the issue is that by default, openldap will offer GSS-SPNEGO before GSSAPI. If your clients have the patched cyrus-sasl but the server doesn't (or the other way around) then they simply can't talk to each other. A quick fix is to modify /etc/sasl2/slapd.conf to add "mech_list: gssapi" and restart slapd. Then GSS-SPNEGO won't be offered at all, and things will just work with GSSAPI. I guess this isn't so much of a bug as it is something which may need documenting. Though I doubt this problem will hit anyone else, so maybe google indexing this ticket is enough. Thank you for filling the bug and for the self-debugging. I believe Simo or Alexander were trying to implement the functionality somehow backward compatible, but probably did not catch all the cases. Since I didn't wrote the patch, I am not sure how and if it is possible to fix, if so upstream (they are quite responsive recently) or Simo should know. I am adding him. For more discussion about this patch, you can see the bug #1421663 even with a link to upstream pull request. Jakub, as noted upstrem, and in the commit, the GSS-SPNEGO mechanism is backwards incompatible with previous cyrus-sasl implementation, which was anyway fully incompatible with any other implementation that was compatible with the reference implementation (Windows). The problem here seem to stem out of the fact that somehow cyrus-sasl lists GSS-SPNEGO before GSSAPI as sasl mechanism, and latest ldap libraries seem to try to pick a sasl mechanism by default if available. Unfortunately this goes back to previous versions, so changing something on the client will not really make a difference as it seem the ldap server is lisint GSS-SPNEGO first. The only option here is to document that GSS-SPNEGO < f26 is incompatible with GSS-SPNEGO >= f26 and you have to move client and servers in lockstep or disable the GSS-SPNEGO mechanism or instructthe clients to use GSSAPI instead. Another way could be to add code in SASL to try GSSAPI if GSS-SPNEGO fails with specific errors codes, but not sure if that is something we should really do. HTH, Simo. Simo, thank you for clarification. My bad that I missed this part. I will leave this bug open so other can find it and see is expected change. Not sure if we should handle that somehow specially/differently in RHEL, since it is already in 7.4. The note about non-compatibility did not get into release notes and here is certainly a single use case that can burn somebody with heterogeneous deployments. This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Sorry for the cryptic summary; this is an odd problem. I have a fairly old kerberos/openldap setup running, with no fanciness like IPA or whatnot. ldapsearch and such use GSSAPI for authentication. This has worked fine for many years, but I found that it no longer works with F26 clients. In F25: compute00:~❯ ldapsearch SASL/GSS-SPNEGO authentication started SASL username: tibbs.EDU SASL SSF: 56 SASL data security layer installed. [LDIF follows] In F26: ld00:~❯ ldapsearch SASL/GSS-SPNEGO authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: Unable to find a callback: 32775 That callback number is stable. Looking at the cyrus-sasl changelog I see a few commits relating to GSSAPI, so I pulled some koji builds and found that 2.1.26-28 works fine, while 2.1.26-30 doesn't. (There are no intermediate builds available from koji.) I suspect the problem is this: * Tue Mar 07 2017 Jakub Jelen <jjelen> - 2.1.26-29 - Fix GSS SPNEGO support (#1421663) If I drop cyrus-sasl-2.1.26-gss-spnego.patch, cyrus-sasl-2.1.26-gssapi-lock.patch and cyrus-sasl-2.1.26-ssf-from-gssapi.patch from the current 2.1.26-32 package then the resulting package works fine, but if I readd just cyrus-sasl-2.1.26-gss-spnego.patch then things break again. I have a feeling that there is something wrong with my server configuration since that patch is supposed to fix something, but it's been working for well over a decade with no issues. The servers are all Fedora 25 at this point and I can make configuration changes if it would help.