Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
389-ds-bot opened this issue Sep 13, 2020 · 27 comments
Closed

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

389-ds-bot opened this issue Sep 13, 2020 · 27 comments
Labels
closed: fixed Migration flag - Issue

Comments

@389-ds-bot
Copy link

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/49474

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.
@389-ds-bot 389-ds-bot added the closed: fixed Migration flag - Issue label Sep 13, 2020
@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2017-11-28 16:41:39

Metadata Update from @Firstyear:

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2017-11-28 16:43:39

Metadata Update from @Firstyear:

  • Issue assigned to Firstyear

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2017-11-30 09:14:37

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

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2017-11-30 09:15:20

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

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2017-11-30 14:39:51

0002-Ticket-49474-sasl-allow-mechs-does-not-operate-corre.patch

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2017-11-30 14:40:11

0001-Ticket-49474-Improve-GSSAPI-testing-capability.patch

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2017-11-30 14:40:15

Metadata Update from @Firstyear:

  • Custom field reviewstatus adjusted to review (was: None)

@389-ds-bot
Copy link
Author

Comment from tbordaz (@tbordaz) at 2017-11-30 15:15:05

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 ?

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2017-11-30 15:22:40

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

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2017-11-30 15:59:24

0002-Ticket-49474-sasl-allow-mechs-does-not-operate-corre.patch

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2017-11-30 15:59:35

0001-Ticket-49474-Improve-GSSAPI-testing-capability.patch

@389-ds-bot
Copy link
Author

Comment from tbordaz (@tbordaz) at 2017-11-30 16:25:49

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

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2017-12-01 08:57:22

@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 @droideck and I will work next week on making these tests work "everywhere".

How does that sound?

@389-ds-bot
Copy link
Author

Comment from tbordaz (@tbordaz) at 2017-12-01 11:49:44

That sounds a very good plan. You have my ACK for the fix.

@389-ds-bot
Copy link
Author

Comment from tbordaz (@tbordaz) at 2017-12-01 11:49:45

Metadata Update from @tbordaz:

  • Custom field reviewstatus adjusted to ack (was: review)

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2017-12-01 11:55:01

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

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2017-12-13 23:29:50

0001-Ticket-49474-Improve-GSSAPI-testing-capability.patch

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

@389-ds-bot
Copy link
Author

Comment from spichugi (@droideck) at 2018-01-02 14:24:23

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?

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2018-01-04 01:26:31

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

@389-ds-bot
Copy link
Author

Comment from spichugi (@droideck) at 2018-01-04 07:54:04

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()".

@389-ds-bot
Copy link
Author

Comment from spichugi (@droideck) at 2018-01-10 09:05:00

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

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2018-01-11 01:46:54

0001-Ticket-49474-purge-saslmaps-before-gssapi-test.patch

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2018-01-11 01:47:05

Metadata Update from @Firstyear:

  • Custom field reviewstatus adjusted to review (was: ack)

@389-ds-bot
Copy link
Author

Comment from spichugi (@droideck) at 2018-01-11 06:23:39

Metadata Update from @droideck:

  • Custom field reviewstatus adjusted to ack (was: review)

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2018-01-12 01:01:18

commit 0457ea6
To ssh://git@pagure.io/389-ds-base.git
575d9e2..0457ea6 master -> master

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2018-01-12 01:01:18

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)

@389-ds-bot
Copy link
Author

Comment from vashirov (@vashirov) at 2020-02-12 17:35:09

Metadata Update from @vashirov:

  • Issue set to the milestone: None (was: 0.0 NEEDS_TRIAGE)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
closed: fixed Migration flag - Issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@389-ds-bot