[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
** Tags added: regression-update -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Released Status in cyrus-sasl2 source package in Bionic: Fix Released Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS- SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are needed. The first fixes the problem, the second fixes some unused parameter warnings. commit 816e529043de08f3f9dcc4097380de39478b0b16 Author: Simo Sorce Date: Thu Feb 16 15:25:56 2017 -0500 Subject: Fix GSS-SPNEGO mechanism's
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
This bug was fixed in the package cyrus-sasl2 - 2.1.27~101-g0780600 +dfsg-3ubuntu2.3 --- cyrus-sasl2 (2.1.27~101-g0780600+dfsg-3ubuntu2.3) bionic; urgency=medium * d/p/lp-1906627-01-Fix-GSS-SPNEGO-mechanism-s-incompatible-behavior.patch: d/p/lp-1906627-02-Drop-unused-parameter-from-gssapi_spnego_ssf.patch: - Fix GSS-SPNEGO implementation to be inter-operable with Microsoft Active Directory, fixing the source of the recent adcli regression. (LP: #1906627) -- Matthew Ruffell Mon, 07 Dec 2020 10:54:47 +1300 ** Changed in: cyrus-sasl2 (Ubuntu Bionic) Status: Fix Committed => Fix Released -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Released Status in cyrus-sasl2 source package in Bionic: Fix Released Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
This bug was fixed in the package adcli - 0.8.2-1ubuntu1.2 --- adcli (0.8.2-1ubuntu1.2) bionic; urgency=medium * d/control: Adding specific dependency of libsasl2-modules-gssapi-mit 2.1.27~101-g0780600+dfsg-3ubuntu2.2 to ensure adcli uses fixed GSS-SPNEGO implementation to resolve regression. (LP: #1906627) -- Matthew Ruffell Tue, 08 Dec 2020 12:38:02 +1300 ** Changed in: adcli (Ubuntu Bionic) Status: Fix Committed => Fix Released -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Released Status in cyrus-sasl2 source package in Bionic: Fix Released Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS- SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
The proposed solution fixes the bug I filed when joining against older Windows Active Directory servers. (https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1906673) i.e. The domain join works without the --use-ldaps. We do not currently have the correct certificate set up to use --use- ldaps, so I am not currently able exercise that test case. (Thank you to the Ubuntu team for the rapid response.) -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS- SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
To anyone following this bug: As we get ready to re-release the new adcli package which implements the --use-ldaps flag, if you are happy to spend a few moments testing the new package, I would really appreciate it. I really don't want to cause another regression again. You can install the new adcli package in -proposed like so: Enable -proposed by running the following command to make a new sources.list.d entry: 1) cat << EOF | sudo tee /etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list # Enable Ubuntu proposed archive deb http://archive.ubuntu.com/ubuntu/ $(lsb_release -cs)-proposed main universe EOF 2) sudo apt update 3) sudo apt install adcli 4) sudo apt-cache policy adcli | grep Installed Installed: 0.8.2-1ubuntu1.2 5) sudo apt-cache policy libsasl2-modules-gssapi-mit | grep Installed Installed: 2.1.27~101-g0780600+dfsg-3ubuntu2.3 6) sudo rm /etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list 7) sudo apt update >From there, join your domain like normal, and if you like, try out other adcli or realm commands to ensure they work. Let me know how the new adcli package in -proposed goes. In my testing, it fixes the regression, and works as intended. To Jason Alavaliant, thanks! I really appreciate the help testing. Thanks, Matthew -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Performing verification for Bionic Firstly, I installed adcli and libsasl2-modules-gssapi-mit from -updates: adcli 0.8.2-1 libsasl2-modules-gssapi-mit 2.1.27~101-g0780600+dfsg-3ubuntu2.1 >From there, I joined a Active Directory realm: https://paste.ubuntu.com/p/zJhvpRzktk/ Next, I enabled -proposed and installed the fixed cyrus-sasl2 and adcli packages: https://paste.ubuntu.com/p/cRrbkjjFmw/ We see that installing adcli 0.8.2-1ubuntu1.2 automatically pulls in the fixed cyrus-sasl2 2.1.27~101-g0780600+dfsg-3ubuntu2.3 packages because of the depends we set. Next, I joined a Active Directory realm, using the same commands as previous, i.e. not using the new --use-ldaps flag, but instead, falling back to GSS-API and the new GSS-SPNEGO changes: https://paste.ubuntu.com/p/WdKYxxDBQm/ The join succeeds, and does not get stuck. This shows that the implementation of GSS-SPNEGO is now compatible with Active Directory, and that the new adcli package is using the new implementation. Looking at the packet trace, we see the full 30 or so packets exchanged, which matches the expect count. https://paste.ubuntu.com/p/k9njh3jYHh/ With these changes, the adcli and cyrus-sasl2 packages in -proposed can join realms in the same ways that the initial packages in -updates can. These changes fix the recent adcli regression. Happy to mark verified. ** Tags removed: regression-update verification-needed verification-needed-bionic ** Tags added: verification-done-bionic -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
All regression failures, PASSED after a retry. There is no autopkgtest regression (failures) anymore. -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS- SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are needed. The first fixes the problem, the second fixes some unused parameter warnings. commit 816e529043de08f3f9dcc4097380de39478b0b16 Author: Simo Sorce Date: Thu Feb
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
I have retried all the FAILED tests. * postfix/3.3.0-1ubuntu0.3 (amd64) PASSED the 2nd time: http://autopkgtest.ubuntu.com/packages/p/postfix/bionic/amd64 * kimap/17.12.3-0ubuntu1 (armhf, ppc64el, arm64) are queued and waiting to retry. Stay tune ... - Eric -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS- SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are needed. The first
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
have tested using libsasl2-modules=2.1.27~101-g0780600+dfsg-3ubuntu2.2, libsasl2-modules-db=2.1.27~101-g0780600+dfsg-3ubuntu2.2, libsasl2 -modules-gssapi-mit=2.1.27~101-g0780600+dfsg-3ubuntu2.2 and adcli=0.8.2-1ubuntu1.1 Join to AD without specifying --use-ldaps seemed to run without error. So from my perspective I'd say those combination of packages fixes the problem. Thanks -J -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS- SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake,
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Hello Rolf, or anyone else affected, Accepted adcli into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/adcli/0.8.2-1ubuntu1.1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: adcli (Ubuntu Bionic) Status: In Progress => Fix Committed -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends:
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Hello Rolf, or anyone else affected, Accepted cyrus-sasl2 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cyrus- sasl2/2.1.27~101-g0780600+dfsg-3ubuntu2.2 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Description changed: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS-API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ - Finally, install the fixed cyrus-sasl2 package, which is available from the - below ppa: + Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test - $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus-sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: - |Suggests: ldap-utils - Depends: adcli - Conflicts: libsasl2-modules-gssapi-heimdal - |Suggests: libsasl2-modules - Conflicts: libsasl2-modules-gssapi-heimdal - |Recommends: sssd-krb5-common - |Suggests: slapd - |Suggests: libsasl2-modules - |Suggests: ldap-utils - |Depends: msktutil - Conflicts: libsasl2-modules-gssapi-heimdal - |Depends: libapache2-mod-webauthldap - Depends: freeipa-server
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
[sts-sponsors] cyrus-sasl2 has been sponsored in Bionic. I have already pinged sil2100 for its SRU verification. - Eric -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are needed. The first fixes the problem, the second fixes some unused parameter
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
[sts-sponsors] adcli option #1 has been sponsored in Bionic with the following nitpicking: * Changed version from "0.8.2-1ubuntu2.1" to "0.8.2-1ubuntu1.1" * Changed debian/control to d/control. - Eric -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Unsubscribing ~ubuntu-sponsors as I believe there is no longer anything to sponsor. -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are needed. The first fixes the problem, the second fixes some unused parameter warnings. commit
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Thank you for preparing this revert. Since Bionic 0.8.2-1ubuntu1 was previously in bionic-security, I think this revert needs to go into the security pocket, and therefore cannot be built in the bionic-updates pocket and needs handling via the security team PPA. However I'm not sure, so to avoid confusion I'll leave this for Łukasz. -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Attached is option two: a debdiff for adcli, which builds on 0.8.2-1ubuntu2, which re-introduces all of the --use-ldaps patches, and also adds a depends to the fixed libsasl2-modules-gssapi-mit at greater or equal to relationship. Use this if option 1 is a no go. ** Patch added: "debdiff for adcli on Bionic option two" https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1906627/+attachment/5441873/+files/lp1906627_adcli_option_two.debdiff -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Attached is option one: a debdiff for adcli, which builds on 0.8.2-1ubuntu1 and simply adds a depends to the fixed libsasl2-modules- gssapi-mit at greater or equal to relationship. This will require the 0.8.2-1ubuntu2 package in -unapproved queue to be deleted. ** Patch added: "debdiff for adcli on Bionic" https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1906627/+attachment/5441872/+files/lp1906627_adcli_option_one.debdiff -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Matthew, I was thinking about possibly to declare some package relationships to not allow the offending packages' combination to occur, when I came across the exact same thought from cpaelzer. I don't know if you notice it, here it goes[0]: " One suggestion for the coming related uploads. Do you think it would make sense to ensure that the now-known-bad combinations of packages won't be allowed together. Maybe when you go for adcli and sssd in LP #1868703 again - they might have their dependency to libsasl2-modules-gssapi-mit be versioned to be greater or equal the fixed cyrus_sasl2? " Matthew do you have a plan to ensure the users will have the right combinations/package relationships ? - Eric [0]- https://lists.ubuntu.com/archives/ubuntu-server/2020-December/008613.html -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends:
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Matthew, I was thinking about possibly to declare some package relationships to not allow the offending packages' combination to occur, when I came across the exact same thought from cpaelzer. I don't know if you notice it, here it goes: " One suggestion for the coming related uploads. Do you think it would make sense to ensure that the now-known-bad combinations of packages won't be allowed together. Maybe when you go for adcli and sssd in LP #1868703 again - they might have their dependency to libsasl2-modules-gssapi-mit be versioned to be greater or equal the fixed cyrus_sasl2? " Matthew do you have a plan to ensure user will have the right combinations/package relationships ? - Eric -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
** Tags added: sts-sponsor -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are needed. The first fixes the problem, the second fixes some unused parameter warnings. commit 816e529043de08f3f9dcc4097380de39478b0b16 Author: Simo Sorce Date: Thu Feb
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Attached is a debdiff for cyrus-sasl2 on Bionic, which resolves the incompatibilities of the GSS-SPNEGO implementation with the one in Active Directory. ** Patch added: "cyrus-sasl2 debdiff for Bionic" https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1906627/+attachment/5441530/+files/lp1906627_cyrus_sasl2_bionic.debdiff -- 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: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
** Summary changed: - adcli fails, can't contact LDAP server + GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression ** Description changed: - Package: adcli - Version: 0.8.2-1ubuntu1 - Release: Ubuntu 18.04 LTS + [Impact] - 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. + A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a + regression for some users when attempting to join a Active Directory + realm. adcli introduced a default behaviour change, moving from GSS-API + to GSS-SPNEGO as the default channel encryption algorithm. - 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 + adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- + mit, a part of cyrus-sasl2. The implementation seems to have some + compatibility issues with particular configurations of Active Directory + on recent Windows Server systems. - 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. + Particularly, adcli sends a ldap query to the domain controller, which + responds with a tcp ack, but never returns a ldap response. The + connection just hangs at this point and no more traffic is sent. - The domain controller traffic also shows that it is receiving the ldap - query packet from the server but it never sends a
