Re: [Sts-sponsors] Please review and consider sponsoring LP #1906627 for cyrus-sasl2, which fixes adcli regression

2020-12-07 Thread Matthew Ruffell
Hello Eric and Lukasz,

I have created new debdiffs for adcli. Please review and also sponsor one
of them to -proposed.

Since there are multiple versions of adcli floating around I made two debdiffs.

Please choose the one most convenient / cleanest to apply.

The first simply builds ontop of 0.8.2-1ubuntu1 currently in -proposed, and is
the version pull-lp-source pulls down. It simply adds the dependency
to the fixed
libsasl2-modules-gssapi-mit package with a greater than or equal to
relationship.

Use of this debdiff requires 0.8.2-1ubuntu2 to be deleted from the upload queue,
and treated as 0.8.2-1ubuntu2 never existed.

https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1906627/+attachment/5441872/+files/lp1906627_adcli_option_one.debdiff

Option two builds upon 0.8.2-1ubuntu2, and re-applies all of the --use-ldaps
patches from the previous SRU which 0.8.2-1ubuntu2 reverts. It also adds the
dependency to the fixed libsasl2-modules-gssapi-mit package with a
greater than
or equal to relationship.

https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1906627/+attachment/5441873/+files/lp1906627_adcli_option_two.debdiff

My preference is for option one, but use whatever is required. I only made both
of these to lower round trip time due to timezones if you don't like the option
one idea.

Thanks,
Matthew

On Mon, Dec 7, 2020 at 3:25 PM Matthew Ruffell
 wrote:
>
> Hi Eric, Lukasz,
>
> Please review and potentially sponsor the cyrus-sasl2 debdff attached
> to LP1906627.
>
> [1] https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1906627
>
> It fixes the root cause of the GSS-SPNEGO implementation being incompatible 
> with
> Microsoft's implementation in Active Directory.
>
> If you are still planning to re-release adcli and sssd to -security, then you
> should also build cyrus-sasl2 in the same way:
>
> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4336/+packages
>
> Again, I am sorry for causing the regression and these patches should fix the
> underlying cause.
>
> Thanks,
> Matthew

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression

2020-12-07 Thread Matthew Ruffell
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 STS
Sponsors, which is subscribed to the bug report.
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 

[Sts-sponsors] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression

2020-12-07 Thread Matthew Ruffell
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 STS
Sponsors, which is subscribed to the bug report.
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 

[Sts-sponsors] [Bug 1906627] [NEW] GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression

2020-12-07 Thread Launchpad Bug Tracker
You have been subscribed to a public bug by Eric Desrochers (slashd):

[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 16 15:25:56 2017 -0500
Subject: Fix GSS-SPNEGO mechanism's incompatible behavior
https://github.com/cyrusimap/cyrus-sasl/commit/816e529043de08f3f9dcc4097380de39478b0b16

commit ed2ad48f242fe16e846a9db552a04fca1a5da45f
Author: Simo Sorce 
Date:   Tue Apr 11 18:31:46 2017 -0400
Subject: Drop unused parameter from gssapi_spnego_ssf()
https://github.com/cyrusimap/cyrus-sasl/commit/ed2ad48f242fe16e846a9db552a04fca1a5da45f

** Affects: adcli (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: cyrus-sasl2 (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: adcli (Ubuntu Bionic)
 Importance: High
 Assignee: Matthew