Issue #49474: gssapi authentication fails after upgrading 389-ds-base - 389-ds-base

389-ds-base

#49474 gssapi authentication fails after upgrading 389-ds-base

Closed: wontfix Jan 12, 2018 Opened Nov 28, 2017 by firstyear.

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

Nov 28, 2017

Metadata Update from @firstyear:
- Issue assigned to firstyear

Nov 28, 2017

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

Nov 30, 2017

firstyear commented Nov 30, 2017

The root cause is a fault in ids_sasl_mech_supported. I am analysing and developing a fix now.

firstyear commented Nov 30, 2017

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to review (was: None)

Nov 30, 2017

tbordaz commented Nov 30, 2017

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 ?

firstyear commented Nov 30, 2017

Yes, perhaps. I will check this @tbordaz :)

firstyear commented Nov 30, 2017

tbordaz commented Nov 30, 2017

The fix looks good to me. ACK
The lib389/tests are also looking good, but I would wait for @spichugi feedback

firstyear commented Dec 1, 2017

@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?

tbordaz commented Dec 1, 2017

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)

Dec 1, 2017

firstyear commented Dec 1, 2017

commit f75cfbce07b79272a7f1a2e387dc232d45c169f5
To ssh://git@pagure.io/389-ds-base.git
4f2207a..f75cfbc master -> master

commit ef204a35caa0cc9b2766e37e26f4ae6ddf7bd4f5
To ssh://git@pagure.io/389-ds-base.git
bd23be0..ef204a3 389-ds-base-1.3.7 -> 389-ds-base-1.3.7

commit 4a8a896c00a5266edf189c0cda4a5345fb29fe60
To ssh://git@pagure.io/389-ds-base.git
9e8a68e..4a8a896 389-ds-base-1.3.6 -> 389-ds-base-1.3.6

firstyear commented Dec 13, 2017

@spichugi This might help fix your issues as it changes to fix a hostname detection issue with gssapi related tests.

spichugi commented Jan 2, 2018

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?

Edited Jan 2, 2018 by spichugi

firstyear commented Jan 4, 2018

I need to see the failure you received to be certain, :)

commit 87609c0a150cbf5db404aa57e8e7ad63e4d222fa
To ssh://git@pagure.io/389-ds-base.git
debe278..87609c0 master -> master

spichugi commented Jan 4, 2018

I need to see the failure you received to be certain, :)

It expects "with pytest.raises(ldap.INVALID_CREDENTIALS):" but the exception doesn't happen during "conn = testuser.bind_gssapi()".

spichugi commented Jan 10, 2018

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=&)

firstyear commented Jan 11, 2018

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to review (was: ack)

Jan 11, 2018

Metadata Update from @spichugi:
- Custom field reviewstatus adjusted to ack (was: review)

Jan 11, 2018

firstyear commented Jan 12, 2018

commit 0457ea62dcfaddfe50e5d0d0924524eb55f86a50
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)

Jan 12, 2018

Metadata Update from @vashirov:
- Issue set to the milestone: None (was: 0.0 NEEDS_TRIAGE)

Feb 12, 2020

spichugi commented Sep 13, 2020

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

Sep 13, 2020

Metadata

Assignee

firstyear

Tags

None

Blocking

None

Depending on

None

Priority

Low

rhbz

https://bugzilla.redhat.com/show_bug.cgi?id=1516676

origin

None

reviewstatus

review

389-ds-base

#49474 gssapi authentication fails after upgrading 389-ds-base Closed: wontfix Jan 12, 2018 Opened Nov 28, 2017 by firstyear.

Metadata

#49474 gssapi authentication fails after upgrading 389-ds-base

Closed: wontfix Jan 12, 2018 Opened Nov 28, 2017 by firstyear.