** Description changed:

  [Impact]
  
- When attempting to bind to a SASL channel using GSSAPI or GSS-SPNEGO for
- Windows Active Directory, authentication will fail stating invalid
+ When attempting to authenticate against a Windows Active Directory
+ server configured to require SASL channel binding over SSL/TLS ldap
+ connections (ldaps), authentication will fail stating invalid
  credentials as the cause.
  
- This is due to cyrus-sasl2 missing the feature of GSSAPI/GSS-SPNEGO
- channel binding and interoperability with Windows over TLS.
+ This is due to cyrus-sasl2 missing the sasl channel binding feature of
+ GSSAPI/GSS-SPNEGO.
  
- To fix the issue, these items are added as patches from a set of
+ Furthermore, for interoperability with Windows Active Directory Server,
+ it's necessary to be able to set the SASL SSF (security strength factor)
+ to 0 (zero) when it's used over an already encrypted connection like
+ ldaps.
+ 
+ To fix these issues, these items are added as patches from a set of
  upstream commits.
  
  [Test Plan]
  
  To reproduce this issue, a machine running Windows with Active Directory
  must be available over the network. As an example, for Windows Server
  2019 Evaluation:
  
  The ISO can be downloaded from 
https://www.microsoft.com/en-us/evalcenter/download-windows-server-2019
  Install Windows Server and Active Directory, then add the following registry 
changes from 
https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a
  
  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
  "ldapserverintegrity"=dword:00000002
  "LdapEnforceChannelBinding"=dword:00000002
  
  Also enable LDAP logging for Active Directory:
  
  Reg Add
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v
  "16 LDAP Interface Events" /t REG_DWORD /d 2
  
- 
- With the Windows machine available, set up an Ubuntu system and do the 
following:
+ With the Windows machine available, set up an Ubuntu system and do the
+ following:
  
  Connect to the Windows machine's network
  Reboot and check if an IP from Windows Server was provided
  
  Install packages with:
  $ sudo apt install ldap-utils libsasl2-modules-gssapi-mit krb5-user
  When the Configuring Kerberos Authentication prompt shows up, use the realm 
of the Windows Server
  
  Save the Windows Server AD CA certificate file as 
/usr/local/share/ca-certificates/ad-ca.crt then run
  $ sudo update-ca-certificates
  
  In /etc/ldap/ldap.conf set
  BASE dc={REALM NAME}
  URI ldaps://{WINDOWS SERVER MACHINE NAME}.{REALM NAME}
  
  With Ubuntu set up, the actual test can be run:
  
  $ kinit
  Enter Password
  $ ldapwhoami -Y GSSAPI -O maxssf=0 -o SASL_CBINDING=tls-endpoint
  
  Prior to the fix, this would display the following:
  
  SASL/GSSAPI authentication started
  ldap_sasl_interactive_bind_s: Invalid credentials (49)
-         additional info: 80090346: LdapErr: DSID-..., comment: 
AcceptSecurityContext error, data 80090346, v4563
+         additional info: 80090346: LdapErr: DSID-..., comment: 
AcceptSecurityContext error, data 80090346, v4563
  
  With the fix, the authentication will display the user information.
  
- The same happens with 
+ The same happens with
  $ ldapwhoami -Y GSS-SPNEGO -O maxssf=0 -o SASL_CBINDING=tls-endpoint
  
  SASL/GSS-SPNEGO authentication started
  ldap_sasl_interactive_bind_s: Invalid credentials (49)
-         additional info: 80090346: LdapErr: DSID-..., comment: 
AcceptSecurityContext error, data 80090346, v4563
+         additional info: 80090346: LdapErr: DSID-..., comment: 
AcceptSecurityContext error, data 80090346, v4563
  
  [Where problems could occur]
  
  Based on the patches added, any problems that show up would likely
  occour either in the gssapi plugin or the SASL2 macros. The two files
  changed  are plugins/gssapi.c and m4/sasl2.m4, along with some tests.
  
  There are various situations apart from this one in which GSS-API can be
  used, and this change may affect the way some of these interactions over
  the network are handled.
  
  [Other Info]
-  
+ 
  This issue was fixed in kinetic in version 2.1.28+dfsg-6ubuntu2
  
  [Original Description]
  
  > Are you uncertain if your issue is really a bug?
  Effect is an authentication error. Root case is a "missing feature" (see 
below) and requires updating dependencies, downporting.
  
  > If you are certain this is a bug please include the source package the bug 
is in.
  It's in the interaction between three libraries: openldap, cyrus-sasl, krb5
  
  > 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> 
About Ubuntu
  Broken in 18.04 and also in 20.10 (I guess it's also broken in anything 
inbetween)
  
  > 2) The version of the package you are using, via 'apt-cache policy
  pkgname' or by checking in Software Center
  
  libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1
  ldap-utils: 2.4.53+dfsg-1ubuntu1.2
  libgssapi-krb5-2: 1.17-10ubuntu0.1
  
  > 3) What you expected to happen
  # kinit
  $ export LDAPSASL_CBINDING=tls-endpoint
  $ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps://<DC-fqdn>
  SASL/GSSAPI authentication started
  SASL username: <some-username>
  SASL SSF: 0
  u:<some-username>
  
  > 4) What happened instead
  SASL/GSSAPI authentication started
  ldap_sasl_interactive_bind_s: Invalid credentials (49)
-         additional info: 80090346: LdapErr: DSID-0C090597, comment: 
AcceptSecurityContext error, data 80090346, v4563
+         additional info: 80090346: LdapErr: DSID-0C090597, comment: 
AcceptSecurityContext error, data 80090346, v4563
  
  ---------------
  
  Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends 
activating this as a required feature. See 
https://access.redhat.com/articles/4661861
  Authentication to any AD DC which has mandatory channel binding fails.
  
  Channel binding requires at least an update to cyrus-sasl, which is not
  in any release as far as I can see:
  
  https://github.com/cyrusimap/cyrus-
  sasl/commit/975edbb69070eba6b035f08776de771a129cfb57
  
  It also needs this commit in openldap:
  
  
https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6
  
  Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5).
  
  RH also mentions it needs up-to-date krb5 libraries, but I can't tell
  what minimum version this needs.
  
  I can build all libraries from source, current master (except for krb5
  where I've used 1.18.3) and can confirm that channel binding works when
  using those libraries.
  
  I'm not sure if Samba is affected, but at least adcli, ldap-utils, and I
  would guess by extension also SSSD and realmd.

** Description changed:

  [Impact]
  
  When attempting to authenticate against a Windows Active Directory
  server configured to require SASL channel binding over SSL/TLS ldap
  connections (ldaps), authentication will fail stating invalid
  credentials as the cause.
  
  This is due to cyrus-sasl2 missing the sasl channel binding feature of
  GSSAPI/GSS-SPNEGO.
  
  Furthermore, for interoperability with Windows Active Directory Server,
  it's necessary to be able to set the SASL SSF (security strength factor)
  to 0 (zero) when it's used over an already encrypted connection like
  ldaps.
  
  To fix these issues, these items are added as patches from a set of
  upstream commits.
  
  [Test Plan]
  
  To reproduce this issue, a machine running Windows with Active Directory
  must be available over the network. As an example, for Windows Server
  2019 Evaluation:
  
  The ISO can be downloaded from 
https://www.microsoft.com/en-us/evalcenter/download-windows-server-2019
- Install Windows Server and Active Directory, then add the following registry 
changes from 
https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a
+ Install Windows Server, Active Directory, and Certificate Services, then add 
the following registry changes from 
https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a
  
  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
  "ldapserverintegrity"=dword:00000002
  "LdapEnforceChannelBinding"=dword:00000002
  
  Also enable LDAP logging for Active Directory:
  
  Reg Add
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v
  "16 LDAP Interface Events" /t REG_DWORD /d 2
  
- With the Windows machine available, set up an Ubuntu system and do the
- following:
- 
- Connect to the Windows machine's network
- Reboot and check if an IP from Windows Server was provided
+ With the Windows machine available, set up an Ubuntu system on a network
+ that can reach the Windows server. This works best and with less
+ configuration needed if the Windows server is acting as DNS and DHCP
+ server for that network.
  
  Install packages with:
  $ sudo apt install ldap-utils libsasl2-modules-gssapi-mit krb5-user
- When the Configuring Kerberos Authentication prompt shows up, use the realm 
of the Windows Server
+ When the Configuring Kerberos Authentication prompt shows up, use the realm 
of the Windows Server. If prompted, use the windows server IP for the Kerberos 
KDC and admin servers.
  
  Save the Windows Server AD CA certificate file as 
/usr/local/share/ca-certificates/ad-ca.crt then run
  $ sudo update-ca-certificates
  
  In /etc/ldap/ldap.conf set
  BASE dc={REALM NAME}
  URI ldaps://{WINDOWS SERVER MACHINE NAME}.{REALM NAME}
  
  With Ubuntu set up, the actual test can be run:
  
  $ kinit
  Enter Password
  $ ldapwhoami -Y GSSAPI -O maxssf=0 -o SASL_CBINDING=tls-endpoint
  
  Prior to the fix, this would display the following:
  
  SASL/GSSAPI authentication started
  ldap_sasl_interactive_bind_s: Invalid credentials (49)
          additional info: 80090346: LdapErr: DSID-..., comment: 
AcceptSecurityContext error, data 80090346, v4563
  
  With the fix, the authentication will display the user information.
  
  The same happens with
  $ ldapwhoami -Y GSS-SPNEGO -O maxssf=0 -o SASL_CBINDING=tls-endpoint
  
  SASL/GSS-SPNEGO authentication started
  ldap_sasl_interactive_bind_s: Invalid credentials (49)
          additional info: 80090346: LdapErr: DSID-..., comment: 
AcceptSecurityContext error, data 80090346, v4563
  
  [Where problems could occur]
  
  Based on the patches added, any problems that show up would likely
  occour either in the gssapi plugin or the SASL2 macros. The two files
  changed  are plugins/gssapi.c and m4/sasl2.m4, along with some tests.
  
  There are various situations apart from this one in which GSS-API can be
  used, and this change may affect the way some of these interactions over
  the network are handled.
  
  [Other Info]
  
  This issue was fixed in kinetic in version 2.1.28+dfsg-6ubuntu2
  
  [Original Description]
  
  > Are you uncertain if your issue is really a bug?
  Effect is an authentication error. Root case is a "missing feature" (see 
below) and requires updating dependencies, downporting.
  
  > If you are certain this is a bug please include the source package the bug 
is in.
  It's in the interaction between three libraries: openldap, cyrus-sasl, krb5
  
  > 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> 
About Ubuntu
  Broken in 18.04 and also in 20.10 (I guess it's also broken in anything 
inbetween)
  
  > 2) The version of the package you are using, via 'apt-cache policy
  pkgname' or by checking in Software Center
  
  libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1
  ldap-utils: 2.4.53+dfsg-1ubuntu1.2
  libgssapi-krb5-2: 1.17-10ubuntu0.1
  
  > 3) What you expected to happen
  # kinit
  $ export LDAPSASL_CBINDING=tls-endpoint
  $ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps://<DC-fqdn>
  SASL/GSSAPI authentication started
  SASL username: <some-username>
  SASL SSF: 0
  u:<some-username>
  
  > 4) What happened instead
  SASL/GSSAPI authentication started
  ldap_sasl_interactive_bind_s: Invalid credentials (49)
          additional info: 80090346: LdapErr: DSID-0C090597, comment: 
AcceptSecurityContext error, data 80090346, v4563
  
  ---------------
  
  Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends 
activating this as a required feature. See 
https://access.redhat.com/articles/4661861
  Authentication to any AD DC which has mandatory channel binding fails.
  
  Channel binding requires at least an update to cyrus-sasl, which is not
  in any release as far as I can see:
  
  https://github.com/cyrusimap/cyrus-
  sasl/commit/975edbb69070eba6b035f08776de771a129cfb57
  
  It also needs this commit in openldap:
  
  
https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6
  
  Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5).
  
  RH also mentions it needs up-to-date krb5 libraries, but I can't tell
  what minimum version this needs.
  
  I can build all libraries from source, current master (except for krb5
  where I've used 1.18.3) and can confirm that channel binding works when
  using those libraries.
  
  I'm not sure if Samba is affected, but at least adcli, ldap-utils, and I
  would guess by extension also SSSD and realmd.

** Description changed:

  [Impact]
  
  When attempting to authenticate against a Windows Active Directory
  server configured to require SASL channel binding over SSL/TLS ldap
  connections (ldaps), authentication will fail stating invalid
  credentials as the cause.
  
  This is due to cyrus-sasl2 missing the sasl channel binding feature of
  GSSAPI/GSS-SPNEGO.
  
  Furthermore, for interoperability with Windows Active Directory Server,
  it's necessary to be able to set the SASL SSF (security strength factor)
  to 0 (zero) when it's used over an already encrypted connection like
  ldaps.
  
  To fix these issues, these items are added as patches from a set of
  upstream commits.
  
  [Test Plan]
  
  To reproduce this issue, a machine running Windows with Active Directory
  must be available over the network. As an example, for Windows Server
  2019 Evaluation:
  
  The ISO can be downloaded from 
https://www.microsoft.com/en-us/evalcenter/download-windows-server-2019
  Install Windows Server, Active Directory, and Certificate Services, then add 
the following registry changes from 
https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a
  
  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
  "ldapserverintegrity"=dword:00000002
  "LdapEnforceChannelBinding"=dword:00000002
  
  Also enable LDAP logging for Active Directory:
  
  Reg Add
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v
  "16 LDAP Interface Events" /t REG_DWORD /d 2
  
  With the Windows machine available, set up an Ubuntu system on a network
  that can reach the Windows server. This works best and with less
  configuration needed if the Windows server is acting as DNS and DHCP
  server for that network.
  
  Install packages with:
  $ sudo apt install ldap-utils libsasl2-modules-gssapi-mit krb5-user
  When the Configuring Kerberos Authentication prompt shows up, use the realm 
of the Windows Server. If prompted, use the windows server IP for the Kerberos 
KDC and admin servers.
  
  Save the Windows Server AD CA certificate file as 
/usr/local/share/ca-certificates/ad-ca.crt then run
  $ sudo update-ca-certificates
  
  In /etc/ldap/ldap.conf set
- BASE dc={REALM NAME}
+ BASE dc={REALM NAME} # split the domain components like dc=example,dc=com
  URI ldaps://{WINDOWS SERVER MACHINE NAME}.{REALM NAME}
  
  With Ubuntu set up, the actual test can be run:
  
  $ kinit
  Enter Password
  $ ldapwhoami -Y GSSAPI -O maxssf=0 -o SASL_CBINDING=tls-endpoint
  
  Prior to the fix, this would display the following:
  
  SASL/GSSAPI authentication started
  ldap_sasl_interactive_bind_s: Invalid credentials (49)
          additional info: 80090346: LdapErr: DSID-..., comment: 
AcceptSecurityContext error, data 80090346, v4563
  
  With the fix, the authentication will display the user information.
  
  The same happens with
  $ ldapwhoami -Y GSS-SPNEGO -O maxssf=0 -o SASL_CBINDING=tls-endpoint
  
  SASL/GSS-SPNEGO authentication started
  ldap_sasl_interactive_bind_s: Invalid credentials (49)
          additional info: 80090346: LdapErr: DSID-..., comment: 
AcceptSecurityContext error, data 80090346, v4563
  
  [Where problems could occur]
  
  Based on the patches added, any problems that show up would likely
  occour either in the gssapi plugin or the SASL2 macros. The two files
  changed  are plugins/gssapi.c and m4/sasl2.m4, along with some tests.
  
  There are various situations apart from this one in which GSS-API can be
  used, and this change may affect the way some of these interactions over
  the network are handled.
  
  [Other Info]
  
  This issue was fixed in kinetic in version 2.1.28+dfsg-6ubuntu2
  
  [Original Description]
  
  > Are you uncertain if your issue is really a bug?
  Effect is an authentication error. Root case is a "missing feature" (see 
below) and requires updating dependencies, downporting.
  
  > If you are certain this is a bug please include the source package the bug 
is in.
  It's in the interaction between three libraries: openldap, cyrus-sasl, krb5
  
  > 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> 
About Ubuntu
  Broken in 18.04 and also in 20.10 (I guess it's also broken in anything 
inbetween)
  
  > 2) The version of the package you are using, via 'apt-cache policy
  pkgname' or by checking in Software Center
  
  libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1
  ldap-utils: 2.4.53+dfsg-1ubuntu1.2
  libgssapi-krb5-2: 1.17-10ubuntu0.1
  
  > 3) What you expected to happen
  # kinit
  $ export LDAPSASL_CBINDING=tls-endpoint
  $ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps://<DC-fqdn>
  SASL/GSSAPI authentication started
  SASL username: <some-username>
  SASL SSF: 0
  u:<some-username>
  
  > 4) What happened instead
  SASL/GSSAPI authentication started
  ldap_sasl_interactive_bind_s: Invalid credentials (49)
          additional info: 80090346: LdapErr: DSID-0C090597, comment: 
AcceptSecurityContext error, data 80090346, v4563
  
  ---------------
  
  Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends 
activating this as a required feature. See 
https://access.redhat.com/articles/4661861
  Authentication to any AD DC which has mandatory channel binding fails.
  
  Channel binding requires at least an update to cyrus-sasl, which is not
  in any release as far as I can see:
  
  https://github.com/cyrusimap/cyrus-
  sasl/commit/975edbb69070eba6b035f08776de771a129cfb57
  
  It also needs this commit in openldap:
  
  
https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6
  
  Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5).
  
  RH also mentions it needs up-to-date krb5 libraries, but I can't tell
  what minimum version this needs.
  
  I can build all libraries from source, current master (except for krb5
  where I've used 1.18.3) and can confirm that channel binding works when
  using those libraries.
  
  I'm not sure if Samba is affected, but at least adcli, ldap-utils, and I
  would guess by extension also SSSD and realmd.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1912256

Title:
  Missing channel binding prevents authentication to ActiveDirectory

Status in cyrus-sasl2 package in Ubuntu:
  Fix Released
Status in openldap package in Ubuntu:
  Fix Released
Status in cyrus-sasl2 source package in Jammy:
  In Progress
Status in openldap source package in Jammy:
  Fix Released

Bug description:
  [Impact]

  When attempting to authenticate against a Windows Active Directory
  server configured to require SASL channel binding over SSL/TLS ldap
  connections (ldaps), authentication will fail stating invalid
  credentials as the cause.

  This is due to cyrus-sasl2 missing the sasl channel binding feature of
  GSSAPI/GSS-SPNEGO.

  Furthermore, for interoperability with Windows Active Directory
  Server, it's necessary to be able to set the SASL SSF (security
  strength factor) to 0 (zero) when it's used over an already encrypted
  connection like ldaps.

  To fix these issues, these items are added as patches from a set of
  upstream commits.

  [Test Plan]

  To reproduce this issue, a machine running Windows with Active
  Directory must be available over the network. As an example, for
  Windows Server 2019 Evaluation:

  The ISO can be downloaded from 
https://www.microsoft.com/en-us/evalcenter/download-windows-server-2019
  Install Windows Server, Active Directory, and Certificate Services, then add 
the following registry changes from 
https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a

  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
  "ldapserverintegrity"=dword:00000002
  "LdapEnforceChannelBinding"=dword:00000002

  Also enable LDAP logging for Active Directory:

  Reg Add
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
  /v "16 LDAP Interface Events" /t REG_DWORD /d 2

  With the Windows machine available, set up an Ubuntu system on a
  network that can reach the Windows server. This works best and with
  less configuration needed if the Windows server is acting as DNS and
  DHCP server for that network.

  Install packages with:
  $ sudo apt install ldap-utils libsasl2-modules-gssapi-mit krb5-user
  When the Configuring Kerberos Authentication prompt shows up, use the realm 
of the Windows Server. If prompted, use the windows server IP for the Kerberos 
KDC and admin servers.

  Save the Windows Server AD CA certificate file as 
/usr/local/share/ca-certificates/ad-ca.crt then run
  $ sudo update-ca-certificates

  In /etc/ldap/ldap.conf set
  BASE dc={REALM NAME} # split the domain components like dc=example,dc=com
  URI ldaps://{WINDOWS SERVER MACHINE NAME}.{REALM NAME}

  With Ubuntu set up, the actual test can be run:

  $ kinit
  Enter Password
  $ ldapwhoami -Y GSSAPI -O maxssf=0 -o SASL_CBINDING=tls-endpoint

  Prior to the fix, this would display the following:

  SASL/GSSAPI authentication started
  ldap_sasl_interactive_bind_s: Invalid credentials (49)
          additional info: 80090346: LdapErr: DSID-..., comment: 
AcceptSecurityContext error, data 80090346, v4563

  With the fix, the authentication will display the user information.

  The same happens with
  $ ldapwhoami -Y GSS-SPNEGO -O maxssf=0 -o SASL_CBINDING=tls-endpoint

  SASL/GSS-SPNEGO authentication started
  ldap_sasl_interactive_bind_s: Invalid credentials (49)
          additional info: 80090346: LdapErr: DSID-..., comment: 
AcceptSecurityContext error, data 80090346, v4563

  [Where problems could occur]

  Based on the patches added, any problems that show up would likely
  occour either in the gssapi plugin or the SASL2 macros. The two files
  changed  are plugins/gssapi.c and m4/sasl2.m4, along with some tests.

  There are various situations apart from this one in which GSS-API can
  be used, and this change may affect the way some of these interactions
  over the network are handled.

  In parallel with this SRU, we tested, in jammy, cyrus-imapd server and
  gssapi authentication over tls, with and without this updated sasl
  package. Using as a client thunderbird, imtest (from cyrus-imapd-
  clients), curl (it has imap support), mutt, evolution. All
  authenticated without issues. Also postfix with gssapi authentication
  was tested, and also worked.

  [Other Info]

  This issue was fixed in kinetic in version 2.1.28+dfsg-6ubuntu2

  [Original Description]

  > Are you uncertain if your issue is really a bug?
  Effect is an authentication error. Root case is a "missing feature" (see 
below) and requires updating dependencies, downporting.

  > If you are certain this is a bug please include the source package the bug 
is in.
  It's in the interaction between three libraries: openldap, cyrus-sasl, krb5

  > 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> 
About Ubuntu
  Broken in 18.04 and also in 20.10 (I guess it's also broken in anything 
inbetween)

  > 2) The version of the package you are using, via 'apt-cache policy
  pkgname' or by checking in Software Center

  libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1
  ldap-utils: 2.4.53+dfsg-1ubuntu1.2
  libgssapi-krb5-2: 1.17-10ubuntu0.1

  > 3) What you expected to happen
  # kinit
  $ export LDAPSASL_CBINDING=tls-endpoint
  $ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps://<DC-fqdn>
  SASL/GSSAPI authentication started
  SASL username: <some-username>
  SASL SSF: 0
  u:<some-username>

  > 4) What happened instead
  SASL/GSSAPI authentication started
  ldap_sasl_interactive_bind_s: Invalid credentials (49)
          additional info: 80090346: LdapErr: DSID-0C090597, comment: 
AcceptSecurityContext error, data 80090346, v4563

  ---------------

  Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends 
activating this as a required feature. See 
https://access.redhat.com/articles/4661861
  Authentication to any AD DC which has mandatory channel binding fails.

  Channel binding requires at least an update to cyrus-sasl, which is
  not in any release as far as I can see:

  https://github.com/cyrusimap/cyrus-
  sasl/commit/975edbb69070eba6b035f08776de771a129cfb57

  It also needs this commit in openldap:

  
https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6

  Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5).

  RH also mentions it needs up-to-date krb5 libraries, but I can't tell
  what minimum version this needs.

  I can build all libraries from source, current master (except for krb5
  where I've used 1.18.3) and can confirm that channel binding works
  when using those libraries.

  I'm not sure if Samba is affected, but at least adcli, ldap-utils, and
  I would guess by extension also SSSD and realmd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1912256/+subscriptions


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

Reply via email to