Description of problem: Since the upgrade to Fedora 28 I cant authenticate with kerberos ticket to the windows AD when doing ldapsearch over TLS protected ldaps protocol. It worked on Fedora 27 on the same infrastructure (and still works even from rhel6 / rhel7) Version-Release number of selected component (if applicable): openldap-clients-2.4.46-1.fc28.x86_64 openssl-libs-1.1.0h-3.fc28.x86_64 How reproducible: 100% Steps to Reproduce: 1. run kinit to initialize your kerberos ticket kinit myuser 2. Run this command against the Windows Sever 2012 with Domain Controller role ldapsearch -v -Omaxssf=0 -H ldaps://ad_server.example.com -b DC=example,DC=com -o ldif-wrap=no -D CN=myuser,OU=Users,DC=example,DC=com cn=myuser Actual results: ldap_initialize( ldaps://ad_server.example.com:636/??base ) SASL/GSS-SPNEGO authentication started ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) additional info: 00002029: LdapErr: DSID-0C090526, comment: Cannot bind using sign/seal on a connection on which TLS or SSL is in effect, data 0, v2580 Expected results: In RH6/7 and up to Fedora 27 the response look like this. $ ldapsearch -v -Omaxssf=0 -H ldaps://ad_server.example.com -b DC=example,DC=com -o ldif-wrap=no -D CN=myuser,OU=Users,DC=example,DC=com cn=myuser # mambroz, Users, ROPC, prg-dc.dhl.com dn: CN=mambroz,OU=Users,OU=ROPC,DC=prg-dc,DC=dhl,DC=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: myuser sn: User .... Additional info:
Hi and thanks for the report. 1) You mentioned this does not happen on RHEL6/7. Did you try with the latest rhel-7.5 or centos-7.5 (openldap-2.4.44-13.el7 or latter)? If not, could you do so? 2) Could you provide both actual and expected output from ldapsearch ran with full debugging (-d -1) as attachments to this bug? For the expected, only the part before the requested data being received would be sufficient. Feel free to redact personal data (uniquely, however). Thanks!
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. 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 '28'. 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 28 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.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-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 '29'. 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 29 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.
Created attachment 1655427 [details] openldap debug log presenting bind error in GSSAPI
Same behaviour here too.. adding some context.. attached log In centos 7.*: $ rpm -qa | grep openldap-clients openldap-clients-2.4.44-21.el7_6.x86_64 $ kinit -k THISCOMPUTER$ $ ldapsearch -Q -b "" -s base defaultNamingContext -H ldaps://adsdca01p10.adir.hull.ac.uk -O maxssf=0 -o "ldif-wrap=no" # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: defaultNamingContext # # dn: defaultNamingContext: DC=something,DC=com # search result search: 5 result: 0 Success # numResponses: 2 # numEntries: 1 In centos 8: $ rpm -qa | grep openldap-clients openldap-clients-2.4.46-10.el8.x86_64 $ kinit -k THISCOMPUTER$ $ ldapsearch -Q -b "" -s base defaultNamingContext -H ldaps://ad.something.com -O maxssf=0 -o "ldif-wrap=no" ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) additional info: 00002029: LdapErr: DSID-0C090526, comment: Cannot bind using sign/seal on a connection on which TLS or SSL is in effect, data 0, v2580
Hello Tom, thank you for the provided output. For more investigation, I would kindly ask you for the following: 1. Looking at the domains of the ADs' hosts... are those two different servers? 2. Could you please provide a log of the working case (using .el7 package) with the same debug level? 3. Could you please provide `rpm -qa cyrus-sasl-lib` from both clients? Thank you!
Created attachment 1655717 [details] centos 7 gssapi ldap bind successful
1. Looking at the domains of the ADs' hosts... are those two different servers? Sorry my poor attempt at anonymising things - these are the same AD server 2. Could you please provide a log of the working case (using .el7 package) with the same debug level? Yep, attached as 'centos 7 gssapi ldap bind successful' 3. Could you please provide `rpm -qa cyrus-sasl-lib` from both clients? Sure, c7: cyrus-sasl-lib-2.1.26-23.el7.x86_64 c8: cyrus-sasl-lib-2.1.27-1.el8.x86_64 Thanks!
From the logs it seems the el7 goes with GSSAPI, and el8 with GSS-SPNEGO; not sure why it is so. Could you please try running the commands with explicit mechs vice-versa to check what the behaviour will be? That is, on el7 with `-Y GSS-SPNEGO`, and on el8 with `-Y GSSAPI`. I suspect SPNEGO won't work there either. Thanks!
Cool ... explicit switching to GSSAPI makes the query work over ldaps on Fedora 31 (and I guess all the others with the new libs). Thanks. To recap: Seems that with newer openldap libraries the preffered mechanism from the ones offered by Windows Active Directory will be GSS-SPNEGO. For some reason it will work over LDAP but not over encrypted LDAPS. Overriding that with -Y GSSAPI will make the authentication to work over encrypted LDAPS channel. GSSAPI is the way which was default on older versions of openldap on RHEL6, RHEL7, Fedora27-. Possibly related to https://bugzilla.redhat.com/show_bug.cgi?id=1421663 For documentation: export LDAPURL="ldaps://domain.example.com:636" export LDAPBASE="DC=domain,DC=example,DC=com" export OPT_NOWRAP="ldif-wrap=no" export LDAPBIND="CN=user01,OU=Users,DC=domain,DC=example,DC=com" export MAXPAGE=1000 ldapsearch -Y GSSAPI -Omaxssf=0 -H "$LDAPURL" -E pr=${MAXPAGE}/noprompt -b "$LDAPBASE" -o $OPT_NOWRAP -D "$LDAPBIND" cn=test01 dn ========== On RHEL6: $ rpm -q cyrus-sasl-lib cyrus-sasl-lib-2.1.23-15.el6_6.2.x86_64 ldapsearch -Omaxssf=0 -H "$LDAPURL" -E pr=${MAXPAGE}/noprompt -b "$LDAPBASE" -o $OPT_NOWRAP -D "$LDAPBIND" cn=test01 => works and GSSAPI is the default for both LDAP and LDAPS ldapsearch -Y GSSAPI -Omaxssf=0 -H "$LDAPURL" -E pr=${MAXPAGE}/noprompt -b "$LDAPBASE" -o $OPT_NOWRAP -D "$LDAPBIND" cn=test01 => works $ ldapsearch -v -Y GSS-SPNEGO -Omaxssf=0 -H "$LDAPURL" -E pr=${MAXPAGE}/noprompt -b "$LDAPBASE" -o $OPT_NOWRAP -D "$LDAPBIND" cn=test01 dn ldap_initialize( ldaps://server001.domain.example.com:636/??base ) ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: No worthy mechs found =========== On RHEL7: $ rpm -q cyrus-sasl-lib cyrus-sasl-lib-2.1.26-23.el7.x86_64 $ ldapsearch -Omaxssf=0 -H "$LDAPURL" -E pr=${MAXPAGE}/noprompt -b "$LDAPBASE" -o $OPT_NOWRAP -D "$LDAPBIND" cn=test01 dn SASL/GSSAPI authentication started => works the GSSAPI is the default for both LDAP and LDAPS =========== I do not have RHEL8 at hand but I guess it will be similar like on Fedora31: # Using the LDAPS + GSS-SPNEGO fails $ export LDAPURL="ldaps://${AD_PDC}:636" $ ldapsearch -Omaxssf=0 -H "$LDAPURL" -E pr=${MAXPAGE}/noprompt -b "$LDAPBASE" -o $OPT_NOWRAP -D "$LDAPBIND" cn=test01 dn SASL/GSS-SPNEGO authentication started ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) additional info: 00002029: LdapErr: DSID-0C09052E, comment: Cannot bind using sign/seal on a connection on which TLS or SSL is in effect, data 0, v3839 # same as $ ldapsearch -Y GSS-SPNEGO -Omaxssf=0 -H "$LDAPURL" -E pr=${MAXPAGE}/noprompt -b "$LDAPBASE" -o $OPT_NOWRAP -D "$LDAPBIND" cn=test01 dn SASL/GSS-SPNEGO authentication started ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) additional info: 00002029: LdapErr: DSID-0C09052E, comment: Cannot bind using sign/seal on a connection on which TLS or SSL is in effect, data 0, v3839 # Using LDAPS + GSSAPI works $ ldapsearch -Y GSSAPI -Omaxssf=0 -H "$LDAPURL" -E pr=${MAXPAGE}/noprompt -b "$LDAPBASE" -o $OPT_NOWRAP -D "$LDAPBIND" cn=test01 dn SASL/GSSAPI authentication started dn: CN=TEST01,OU=Users,DC=domain,DC=example,DC=com # Using the plain LDAP + GSS-SPNEGO works $ export LDAPURL="ldap://${AD_PDC}:389" $ ldapsearch -Omaxssf=0 -H "$LDAPURL" -E pr=${MAXPAGE}/noprompt -b "$LDAPBASE" -o $OPT_NOWRAP -D "$LDAPBIND" cn=test01 dn SASL/GSS-SPNEGO authentication started dn: CN=TEST01,OU=Users,DC=domain,DC=example,DC=com => the GSS-SPNEGO is the default mechanism out of those offered by ActiveDirectory. It will work over LDAP but will fail over LDAPS. Best regards Michal Ambroz
Confirmed works on CentOS 8.. good detective work! Thanks Hopefully this will help others - MS is going to make LDAP signing mandatory as of March 2020: https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows $ ldapsearch -Y GSSAPI -Q -b "" -s base defaultNamingContext -H ldaps://ad.something.com -O maxssf=0 -o "ldif-wrap=no" # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: defaultNamingContext # # dn: defaultNamingContext: DC=ad,DC=something,DC=com # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
(In reply to Tom Aitken from comment #11) > Confirmed works on CentOS 8.. good detective work! Thanks > > Hopefully this will help others - MS is going to make LDAP signing mandatory > as of March 2020: > https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding- > and-ldap-signing-requirement-for-windows Hi Tom, is there still any issue here that you'd like to solve? If not, can we close the issue? Thanks! Simon
This same change in behavior was recently reported by someone using ldapsearch to an LDAP environment we support. See section 15.2.1. GSSAPI of https://www.openldap.org/doc/admin24/sasl.html for background information related to this. In the LDAP configuration based on the documentation above, the following is the historically documented authz configuration for OpenLDAP: authz-regexp uid=(.*)@<domain>,cn=gssapi,cn=auth uid=$1,<base> For a domain of xyz.com, the configuration would look like: authz-regexp uid=(.*)@xyz.com,cn=gssapi,cn=auth uid=$1,dc=xyz,dc=com If the following is also added to the OpenLDAP configuration, the explicit specification of the mechanism with -Y GSSAPI is not necessary and GSS-SPNEGO is also supported. authz-regexp uid=(.*)@<domain>,cn=gss-spnego,cn=auth uid=$1,<base> For a domain of xyz.com, the configuration would look like: authz-regexp uid=(.*)@xyz.com,cn=gss-spnego,cn=auth uid=$1,dc=xyz,dc=com Or a combined regex to support both GSSAPI and GSS-SPNEGO: authz-regexp uid=(.*)@xyz.com,cn=gss(api|-spnego),cn=auth uid=$1,dc=xyz,dc=com
FEDORA-2021-a80e385c4f has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a80e385c4f
FEDORA-2021-a80e385c4f has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a80e385c4f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a80e385c4f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-a80e385c4f has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.