| 2021-01-18 17:43:06 |
Robert Schneider |
bug |
|
|
added bug |
| 2021-01-19 13:04:26 |
Lucas Kanashiro |
bug |
|
|
added subscriber Ubuntu Server |
| 2021-01-19 13:04:33 |
Lucas Kanashiro |
bug |
|
|
added subscriber Sergio Durigan Junior |
| 2022-06-02 10:28:35 |
Christian Ehrhardt |
openldap (Ubuntu): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2022-06-02 10:28:42 |
Christian Ehrhardt |
tags |
|
server-todo |
|
| 2022-06-02 15:20:41 |
Sergio Durigan Junior |
bug task added |
|
cyrus-sasl2 (Ubuntu) |
|
| 2022-06-02 15:20:47 |
Sergio Durigan Junior |
cyrus-sasl2 (Ubuntu): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2022-06-02 15:20:57 |
Sergio Durigan Junior |
cyrus-sasl2 (Ubuntu): assignee |
Sergio Durigan Junior (sergiodj) |
Andreas Hasenack (ahasenack) |
|
| 2022-06-02 15:21:39 |
Launchpad Janitor |
cyrus-sasl2 (Ubuntu): status |
New |
Confirmed |
|
| 2022-06-02 15:21:39 |
Launchpad Janitor |
openldap (Ubuntu): status |
New |
Confirmed |
|
| 2022-07-21 17:37:33 |
Andreas Hasenack |
cyrus-sasl2 (Ubuntu): status |
Confirmed |
In Progress |
|
| 2022-07-22 19:19:00 |
Andreas Hasenack |
bug watch added |
|
https://github.com/cyrusimap/cyrus-sasl/issues/637 |
|
| 2022-07-22 20:25:55 |
Andreas Hasenack |
bug watch added |
|
https://github.com/cyrusimap/cyrus-imapd/issues/3317 |
|
| 2022-08-16 19:10:55 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/cyrus-sasl2/+git/cyrus-sasl2/+merge/428422 |
|
| 2022-08-16 20:49:21 |
Andreas Hasenack |
openldap (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2022-08-16 20:49:51 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Jammy |
|
| 2022-08-16 20:49:51 |
Andreas Hasenack |
bug task added |
|
cyrus-sasl2 (Ubuntu Jammy) |
|
| 2022-08-16 20:49:51 |
Andreas Hasenack |
bug task added |
|
openldap (Ubuntu Jammy) |
|
| 2022-08-16 20:50:14 |
Andreas Hasenack |
openldap (Ubuntu Jammy): status |
New |
Fix Released |
|
| 2022-08-22 14:48:20 |
Launchpad Janitor |
cyrus-sasl2 (Ubuntu): status |
In Progress |
Fix Released |
|
| 2022-08-24 15:16:46 |
Andreas Hasenack |
cyrus-sasl2 (Ubuntu Jammy): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2022-08-24 15:16:50 |
Andreas Hasenack |
cyrus-sasl2 (Ubuntu Jammy): status |
New |
Triaged |
|
| 2022-08-31 15:15:37 |
Robie Basak |
cyrus-sasl2 (Ubuntu Jammy): assignee |
Andreas Hasenack (ahasenack) |
|
|
| 2022-09-21 15:22:16 |
Lena Voytek |
cyrus-sasl2 (Ubuntu Jammy): assignee |
|
Lena Voytek (lvoytek) |
|
| 2022-09-21 15:22:20 |
Lena Voytek |
cyrus-sasl2 (Ubuntu Jammy): status |
Triaged |
In Progress |
|
| 2022-09-27 19:24:10 |
Lena Voytek |
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. |
[Impact]
When attempting to bind to a SASL channel using GSSAPI or GSS-SPNEGO for Windows Active Directory, 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.
To fix the issue, 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:
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
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. |
|
| 2022-09-27 19:40:57 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~lvoytek/ubuntu/+source/cyrus-sasl2/+git/cyrus-sasl2/+merge/430580 |
|
| 2022-09-28 18:16:02 |
Andreas Hasenack |
description |
[Impact]
When attempting to bind to a SASL channel using GSSAPI or GSS-SPNEGO for Windows Active Directory, 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.
To fix the issue, 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:
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
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. |
[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
[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
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
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. |
|
| 2022-09-28 18:18:14 |
Andreas Hasenack |
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 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:
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
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. |
[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}
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. |
|
| 2022-09-28 18:20:33 |
Andreas Hasenack |
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}
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. |
[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.
[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. |
|
| 2022-09-28 18:28:24 |
Andreas Hasenack |
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.
[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. |
[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. |
|
| 2022-10-06 08:54:04 |
Ank3n |
bug |
|
|
added subscriber Ank3n |
| 2022-10-06 08:54:32 |
Ank3n |
removed subscriber Ank3n |
|
|
|
| 2022-10-19 16:56:08 |
Michał Małoszewski |
tags |
server-todo |
|
|
| 2022-10-26 18:26:38 |
Andreas Hasenack |
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. |
[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
This SRU is also pulling in the new DEP8 tests in the kinetic package for cyrus-sasl2. The only changes made to those tests are the list of mechanisms to test, which is slightly smaller in jammy, and an extra package to install for one of the tests due to packaging differences in jammy wrt kinetic.
[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. |
|
| 2022-12-06 21:59:05 |
Brian Murray |
cyrus-sasl2 (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2022-12-06 21:59:07 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-12-06 21:59:09 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2022-12-06 21:59:16 |
Brian Murray |
tags |
|
verification-needed verification-needed-jammy |
|
| 2022-12-07 15:07:05 |
Lena Voytek |
tags |
verification-needed verification-needed-jammy |
verification-done verification-done-jammy |
|
| 2023-01-04 13:28:36 |
Launchpad Janitor |
cyrus-sasl2 (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2023-01-04 13:28:45 |
Robie Basak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
