Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1516676
Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.
Description of problem: gssapi authentication fails after upgrading to 389-ds-base-1.3.6.1-21.el7_4 Version-Release number of selected component (if applicable): 389-ds-base-1.3.6.1-21.el7_4 Actual results: [root@lxdst1 ~]# KRB5_TRACE=/dev/stdout ldapwhoami -H ldaps://host.example.com:1636 -Y GSSAPI SASL/GSSAPI authentication started [11000] 1509623699.486143: ccselect module realm chose cache KEYRING:persistent:0:0 with client principal user@example.com for server principal ldap/host.example.com@example.com [11000] 1509623699.486216: Getting credentials user@example.com -> ldap/host.example.com@example.com using ccache KEYRING:persistent:0:0 [11000] 1509623699.486286: Retrieving user@example.com -> ldap/host.example.com@example.com from KEYRING:persistent:0:0 with result: 0/Success [11000] 1509623699.486339: Creating authenticator for user@example.com -> ldap/host.example.com@example.com, seqnum 200756403, subkey aes256-cts/5D86, session key aes256-cts/1EDD ldap_sasl_interactive_bind_s: Authentication method not supported (7) additional info: sasl mechanism not supported Additional info: My customer mentioned after upgrading to latest fix, It has stopped authenticating GSSAPI. [root@lxdst1 ~]# KRB5_TRACE=/dev/stdout ldapwhoami -H ldaps://host.example.com:1636 -Y GSSAPI SASL/GSSAPI authentication started [11000] 1509623699.486143: ccselect module realm chose cache KEYRING:persistent:0:0 with client principal user@example.com for server principal ldap/host.example.com@example.com [11000] 1509623699.486216: Getting credentials user@example.com -> ldap/host.example.com@example.com using ccache KEYRING:persistent:0:0 [11000] 1509623699.486286: Retrieving user@example.com -> ldap/host.example.com@example.com from KEYRING:persistent:0:0 with result: 0/Success [11000] 1509623699.486339: Creating authenticator for user@example.com -> ldap/host.example.com@example.com, seqnum 200756403, subkey aes256-cts/5D86, session key aes256-cts/1EDD ldap_sasl_interactive_bind_s: Authentication method not supported (7) additional info: sasl mechanism not supported the problem arised immediately after upgrading from "389-Directory/1.3.6.1 B2017.158.1159" - where GSSAPI worked - to "389-Directory/1.3.6.1 B2017.278.2050". $ grep 389-ds installed-rpms 389-ds-base-1.3.6.1-21.el7_4.x86_64 Tue Oct 24 09:24:11 2017 389-ds-base-libs-1.3.6.1-21.el7_4.x86_64 Tue Oct 24 09:24:02 2017 389-ds-base-snmp-1.3.6.1-21.el7_4.x86_64 Tue Oct 24 09:25:58 2017 389-ds-console-1.2.16-1.el7dsrv.noarch Wed Nov 16 14:21:50 2016 389-ds-console-doc-1.2.16-1.el7dsrv.noarch Wed Nov 16 14:21:50 2016 $ grep nsslapd-allowed-sasl-mechanisms etc/dirsrv/slapd-example/dse.ldif nsslapd-allowed-sasl-mechanisms: GSSAPI EXTERNAL ANONYMOUS After downgrading 389-ds-base and 389-ds-base-libs from 1.3.6.1-21 to 1.3.6.1-19 GSSAPI works as expected. Updating again to 1.3.6.1-21 the "Authentication method not supported" error occurs again. KDC is Active Directory.
Metadata Update from @firstyear: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1516676
Metadata Update from @firstyear: - Issue assigned to firstyear
Metadata Update from @firstyear: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None - Issue priority set to: critical
The root cause is a fault in ids_sasl_mech_supported. I am analysing and developing a fix now.
<img alt="0002-Ticket-49474-sasl-allow-mechs-does-not-operate-corre.patch" src="/389-ds-base/issue/raw/files/27ef699f4031fff96a51d35d59f9b05a1402e70dfd4da1508307d9e3edaffc1c-0002-Ticket-49474-sasl-allow-mechs-does-not-operate-corre.patch" />
<img alt="0001-Ticket-49474-Improve-GSSAPI-testing-capability.patch" src="/389-ds-base/issue/raw/files/8d835a7a10b41da05777a3b52f3f026bc7714a4ac6341a56d350699710f3cd74-0001-Ticket-49474-Improve-GSSAPI-testing-capability.patch" />
Metadata Update from @firstyear: - Custom field reviewstatus adjusted to review (was: None)
The patch looks good. A remark, ids_sasl_mech_supported is checking that a given mechanism is supported and allowed. It looks close to what is done in ids_sasl_listmech.
Do you think those two functions can be merged ?
Yes, perhaps. I will check this @tbordaz :)
<img alt="0002-Ticket-49474-sasl-allow-mechs-does-not-operate-corre.patch" src="/389-ds-base/issue/raw/files/1dc342f9149a4da4066edbe24dd4c44c6994f89b1bf991d061b4bf0695078d81-0002-Ticket-49474-sasl-allow-mechs-does-not-operate-corre.patch" />
<img alt="0001-Ticket-49474-Improve-GSSAPI-testing-capability.patch" src="/389-ds-base/issue/raw/files/26f6d828c90ce813325df3ab12ed3df4afab8cdc8f5a1d4aa227511cffa3a5c5-0001-Ticket-49474-Improve-GSSAPI-testing-capability.patch" />
The fix looks good to me. ACK The lib389/tests are also looking good, but I would wait for @spichugi feedback
@tbordaz The tests past for me, but because it's krb/gssapi/sasl, it's really fragile. Having some issues getting them to run reliably for QE.
I think I would like to merge the fix now, and @spichugi and I will work next week on making these tests work "everywhere".
How does that sound?
That sounds a very good plan. You have my ACK for the fix.
Metadata Update from @tbordaz: - Custom field reviewstatus adjusted to ack (was: review)
commit f75cfbc To ssh://git@pagure.io/389-ds-base.git 4f2207a..f75cfbc master -> master
commit ef204a3 To ssh://git@pagure.io/389-ds-base.git bd23be0..ef204a3 389-ds-base-1.3.7 -> 389-ds-base-1.3.7
commit 4a8a896 To ssh://git@pagure.io/389-ds-base.git 9e8a68e..4a8a896 389-ds-base-1.3.6 -> 389-ds-base-1.3.6
<img alt="0001-Ticket-49474-Improve-GSSAPI-testing-capability.patch" src="/389-ds-base/issue/raw/files/04e9cd0ee6e48b17b8899e7b9ae52b2d622aa3efa7142bd1ab11eb769531294b-0001-Ticket-49474-Improve-GSSAPI-testing-capability.patch" />
@spichugi This might help fix your issues as it changes to fix a hostname detection issue with gssapi related tests.
Looks good to me, ack.
One test failed though - dirsrvtests/tests/suites/gssapi/simple_gssapi_test.py::test_invalid_sasl_map
And I think I remember you said something about it, that it is expected. Am I right? Could you please remind me the info about it?
I need to see the failure you received to be certain, :)
commit 87609c0 To ssh://git@pagure.io/389-ds-base.git debe278..87609c0 master -> master
It expects "with pytest.raises(ldap.INVALID_CREDENTIALS):" but the exception doesn't happen during "conn = testuser.bind_gssapi()".
Ok, as per discussion with William, we need to modify the test_invalid_sasl_map. In the test, we should remove existing mappings and add only the one from the test.
Existing mappings from dse.ldif default install:
dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: Kerberos uid mapping nsSaslMapRegexString: (.)@(.).(.*) nsSaslMapBaseDNTemplate: dc=\2,dc=\3 nsSaslMapFilterTemplate: (uid=\1)
dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: rfc 2829 dn syntax nsSaslMapRegexString: ^dn:(.) nsSaslMapBaseDNTemplate: \1 nsSaslMapFilterTemplate: (objectclass=)
dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: rfc 2829 u syntax nsSaslMapRegexString: ^u:(.*) nsSaslMapBaseDNTemplate: dc=example,dc=com nsSaslMapFilterTemplate: (uid=\1)
dn: cn=suffix map,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: suffix map nsSaslMapRegexString: (.*) nsSaslMapBaseDNTemplate: dc=example,dc=com nsSaslMapFilterTemplate: (invalidattr=\1) creatorsName: cn=directory manager modifiersName: cn=directory manager createTimestamp: 20180108211710Z modifyTimestamp: 20180108211717Z
dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: uid mapping nsSaslMapRegexString: ^[^:@]+$ nsSaslMapBaseDNTemplate: dc=example,dc=com nsSaslMapFilterTemplate: (uid=&)
<img alt="0001-Ticket-49474-purge-saslmaps-before-gssapi-test.patch" src="/389-ds-base/issue/raw/files/e6743de00abbe45f0d776fd626db5544b8154575ddd506d183f7e215ea09e6bc-0001-Ticket-49474-purge-saslmaps-before-gssapi-test.patch" />
Metadata Update from @firstyear: - Custom field reviewstatus adjusted to review (was: ack)
Metadata Update from @spichugi: - Custom field reviewstatus adjusted to ack (was: review)
commit 0457ea6 To ssh://git@pagure.io/389-ds-base.git 575d9e2..0457ea6 master -> master
Metadata Update from @firstyear: - Custom field reviewstatus adjusted to review (was: ack) - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @vashirov: - Issue set to the milestone: None (was: 0.0 NEEDS_TRIAGE)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2533
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.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.