Yes, when --use-ldaps is specified, adcli will make a TLS connection to the domain controller, and speak LDAPS. This works, and is the reason why this bug slipped through our regression testing. I should have tested without the --use-ldaps flag as well.
Regardless, this bug seems to be caused by the GSS-SPNEGO implementation in the cyrus-sasl2 package being broken. adcli links to libsasl2 -modules-gssapi-mit, which is a part of cyrus-sasl2, since adcli does not implement GSS-SPNEGO itself, and relies on cyrus-sasl libraries. I downloaded the source package of cyrus-sasl2 2.1.27+dfsg-2 from Focal, and I built it on Bionic, and installed it. I then tried a adcli join, and it worked: https://paste.ubuntu.com/p/R8PyHJMNtT/ Looking at the cyrus-sasl2 source repo, it seems the Bionic version is missing a lot of commits related to GSS-SPNEGO support. Commit 816e529043de08f3f9dcc4097380de39478b0b16 From: Simo Sorce <s...@redhat.com> Date: Thu, 16 Feb 2017 15:25:56 -0500 Subject: Fix GSS-SPNEGO mechanism's incompatible behavior Link: https://github.com/cyrusimap/cyrus-sasl/commit/816e529043de08f3f9dcc4097380de39478b0b16 Commit 4b0306dcd76031460246b2dabcb7db766d6b04d8 From: Simo Sorce <s...@redhat.com> Date: Mon, 10 Apr 2017 19:54:19 -0400 Subject: Add support for retrieving the mech_ssf Link: https://github.com/cyrusimap/cyrus-sasl/commit/4b0306dcd76031460246b2dabcb7db766d6b04d8 Commit 31b68a9438c24fc9e3e52f626462bf514de31757 From: Ryan Tandy <r...@nardis.ca> Date: Mon, 24 Dec 2018 15:07:02 -0800 Subject: Restore LIBS after checking gss_inquire_sec_context_by_oid Link: https://github.com/cyrusimap/cyrus-sasl/commit/31b68a9438c24fc9e3e52f626462bf514de31757 This doesn't even seem to be a complete list either, and if we backport these patches to the Bionic cyrus-sasl2 package, it fails to build for numerous reasons. I also found a similar bug report in Debian, which features the above third commit: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917129 >From what I can tell, GSS-SPNEGO in cyrus-sasl2 for Bionic has never worked, and changing it to the default was a bad idea. So, we have a decision to make. If supporting the new Active Directory requirements in ADV190023 [1][2] which adds --use-ldaps for adcli, as a part of bug 1868703 is important, and something the community wants, we need to fix up cyrus-sasl2 to have a working GSS-SPNEGO implementation. [1] https://msrc.microsoft.com/update-guide/en-us/vulnerability/ADV190023 [2] https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows If we don't want --use-ldaps for adcli, then we can revert the patches for adcli on Bionic, and go back to what was working previously, with GSS-API. ** Bug watch added: Debian Bug tracker #917129 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917129 ** Also affects: cyrus-sasl2 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: adcli fails, can't contact LDAP server Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: New Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: New Bug description: Package: adcli Version: 0.8.2-1ubuntu1 Release: Ubuntu 18.04 LTS When trying to join the domain with this new version of adcli, it gets to the point of 'Using GSS-SPNEGO for SASL bind' and then it will not do anything for 10 minutes. It will then fail, complaining it can't reach the LDAP server. Logs: Dec 03 01:39:50 example001.domain.com realmd[6419]: * Authenticated as user: domain-join-acco...@domain.com Dec 03 01:39:50 example001.domain.com adcli[6459]: GSSAPI client step 1 Dec 03 01:39:50 example001.domain.com realmd[6419]: * Authenticated as user: domain-join-acco...@domain.com Dec 03 01:39:50 example001.domain.com adcli[6459]: GSSAPI client step 1 Dec 03 01:39:50 example001.domain.com realmd[6419]: * Using GSS-SPNEGO for SASL bind Dec 03 01:39:50 example001.domain.com realmd[6419]: * Using GSS-SPNEGO for SASL bind Dec 03 01:39:50 example001.domain.com adcli[6459]: GSSAPI client step 1 Dec 03 01:55:27 example001.domain.com realmd[6419]: ! Couldn't lookup domain short name: Can't contact LDAP server Dec 03 01:55:27 example001.domain.com realmd[6419]: ! Couldn't lookup domain short name: Can't contact LDAP server Dec 03 01:55:27 example001.domain.com realmd[6419]: * Using fully qualified name: example001.domain.com Dec 03 01:55:27 example001.domain.com realmd[6419]: * Using fully qualified name: example001.domain.com Dec 03 01:55:27 example001.domain.com realmd[6419]: * Using domain name: domain.com Dec 03 01:55:27 example001.domain.com realmd[6419]: * Using domain name: domain.com Dec 03 01:55:27 example001.domain.com realmd[6419]: * Using computer account name: EXAMPLE001 Dec 03 01:55:27 example001.domain.com realmd[6419]: * Using computer account name: EXAMPLE001 Dec 03 01:55:27 example001.domain.com realmd[6419]: * Using domain realm: domain.com Dec 03 01:55:27 example001.domain.com realmd[6419]: * Using domain realm: domain.com Dec 03 01:55:27 example001.domain.com realmd[6419]: * Calculated computer account name from fqdn: EXAMPLE001 Dec 03 01:55:27 example001.domain.com realmd[6419]: * Calculated computer account name from fqdn: EXAMPLE001 Dec 03 01:55:27 example001.domain.com realmd[6419]: * With user principal: host/example001.domain....@domain.com Dec 03 01:55:27 example001.domain.com realmd[6419]: * With user principal: host/example001.domain....@domain.com Dec 03 01:55:27 example001.domain.com realmd[6419]: * Generated 120 character computer password Dec 03 01:55:27 example001.domain.com realmd[6419]: * Generated 120 character computer password Dec 03 01:55:27 example001.domain.com realmd[6419]: * Using keytab: FILE:/etc/krb5.keytab Dec 03 01:55:27 example001.domain.com realmd[6419]: * Using keytab: FILE:/etc/krb5.keytab Dec 03 01:55:27 example001.domain.com realmd[6419]: ! Couldn't lookup computer account: EXAMPLE001$: Can't contact LDAP server Dec 03 01:55:27 example001.domain.com realmd[6419]: ! Couldn't lookup computer account: EXAMPLE001$: Can't contact LDAP server Dec 03 01:55:27 example001.domain.com realmd[6419]: adcli: joining domain domain.com failed: Couldn't lookup computer account: EXAMPLE001$: Can't contact LDAP server Dec 03 01:55:27 example001.domain.com realmd[6419]: adcli: joining domain domain.com failed: Couldn't lookup computer account: EXAMPLE001$: Can't contact LDAP server Dec 03 01:55:27 example001.domain.com realmd[6419]: process exited: 6459 Dec 03 01:55:27 example001.domain.com realmd[6419]: ! Failed to join the domain Dec 03 01:55:27 example001.domain.com realmd[6419]: ! Failed to join the domain On the network level, adcli gets to the point of send an ldap query to the domain controller and the domain controller returns an ack tcp packet, but then there is no more traffic between the domain controller and the server except for ntp packets until it fails. The domain controller traffic also shows that it is receiving the ldap query packet from the server but it never sends a reply and there is no log in directory services regarding the query. We also couldn't find anything in procmon regarding this query either. Workaround/Fix: Downgrading the adcli package back to version 0.8.2-1 fixes the issues and domain join works properly again. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1906627/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
