** Summary changed: - Support new AD requirements (ADV190023) + Support "ad_use_ldaps" flag for new AD requirements (ADV190023)
** Description changed: - Please backport the following patch to add the option ad_use_ldaps. + [Impact] - With this new boolean option the AD provider should only use the LDAPS port - 636 and the Global Catalog port 3629 which is TLS protected as well. - https://github.com/SSSD/sssd/pull/969 + Microsoft has released a new security advisory for Active Directory (AD) + which outlines that man-in-the-middle attacks can be performed on a LDAP + server, such as AD DS, that works by an attacker forwarding an + authentication request to a Windows LDAP server that does not enforce + LDAP channel binding or LDAP signing for incoming connections. - This is required as LDAP signing is now required. - https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows + To address this, Microsoft has announced new Active Directory + requirements in ADV190023 [1][2]. - FFe request for the adcli package - ================================= - These are two new features that I would like to add to the package, straight from upstream commits. They are not really new implementations, but just "selectors". adcli doesn't implement GSS-SPNEGO for example, it now will just give it preference if it's available. It also doesn't implement LDAPS, it just adds the possibility. All involved libraries already support both of these changes. + [1] https://msrc.microsoft.com/update-guide/en-us/vulnerability/ADV190023 + [2] https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows - Test PPA: https://launchpad.net/~ahasenack/+archive/ubuntu/adcli-fixes + These new requirements strongly encourage system administrators to + require LDAP signing and authenticated channel binding in their AD + environments. - a) support for GSS-SPNEGO - https://gitlab.freedesktop.org/realmd/adcli/-/commit/a6f795ba3d6048b32d7863468688bf7f42b2cafd - """ - Currently adcli uses the GSSAPI SASL mechanism for LDAP authentication - and to establish encryption. While this works in general it does not - handle some of the more advanced features which can be required by AD - DCs. + The effects of this is to stop unauthenticated and unencrypted traffic + from communicating over LDAP port 389, and to force authenticated and + encrypted traffic instead, over LDAPS port 636 and Global Catalog port + 3629. - The GSS-SPNEGO mechanism can handle them and is used with this patch by - adcli if the AD DC indicates that it supports it. + Microsoft will not be forcing this change via updates to their servers, + system administrators must opt in and change their own configuration. - Related to https://bugzilla.redhat.com/show_bug.cgi?id=1762420 - """ + To support these new requirements in Ubuntu, changes need to be made to + the sssd and adcli packages. Upstream have added a new flag + "ad_use_ldaps" to sssd, and "use-ldaps" has been added to adcli. - I tested this joining a windows 2019 AD domain, and verified it used - GSS-SPNEGO + If "ad_use_ldaps = True", then sssd will send all communication over + port 636, authenticated and encrypted. - b) add option use-ldaps - https://gitlab.freedesktop.org/realmd/adcli/-/commit/85097245b57f190337225dbdbf6e33b58616c092 - """ - In general using the LDAP port with GSS-SPNEGO should satifiy all - requirements an AD DC should have for authentication on an encrypted - LDAP connection. + For adcli, if the server supports GSS-SPNEGO, it will be now be used by + default, with the normal LDAP port 389. If the LDAP port is blocked, + then "use-ldaps" can now be used, which will use the LDAPS port 636 + instead. - But if e.g. the LDAP port is blocked by a firewall using the LDAPS port - with TLS encryption might be an alternative. For this use case the - --use-ldaps option is added. + These patches are needed to stay in line with Microsoft security + advisories, since security conscious system administrators would like to + firewall off the LDAP port 389 in their environments, and use LDAPS port + 636 only. - Related to https://bugzilla.redhat.com/show_bug.cgi?id=1762420 - """ - I also tested this with a windows 2019 AD server, after having setup the proper certificates. + [Testcase] + + To test these changes, you will need to set up a Windows Server 2019 + box, install and configure Active Directory, import the AD certificate + to the Ubuntu clients, and create some users in Active Directory. + + From there, you can try do a user search from the client to the AD + server, and check what ports are used for communication. + + Currently, you should see port 389 in use: + + $ sudo netstat -tanp |grep sssd + tcp 0 0 x.x.x.x:43954 x.x.x.x:389 ESTABLISHED 27614/sssd_be + tcp 0 0 x.x.x.x:54381 x.x.x.x:3268 ESTABLISHED 27614/sssd_be + + Test packages are available in the following ppa: + + https://launchpad.net/~mruffell/+archive/ubuntu/sf294530-test + + Instructions to install (on a bionic or focal system): + 1) sudo add-apt-repository ppa:mruffell/sf294530-test + 2) sudo apt update + 3) sudo apt install adcli sssd + + Then, modify /etc/sssd/sssd.conf and add "ad_use_ldaps = True", restart + sssd. + + Add a firewall rule to block traffic to LDAP port 389 and Global Catalog + 3268. + + $ sudo ufw deny 389 + $ sudo ufw deny 3268 + + Then do another user lookup, and check ports in use: + + $ sudo netstat -tanp |grep sssd + tcp 0 0 x.x.x.x:44586 x.x.x.x:636 ESTABLISHED 28474/sssd_be + tcp 0 0 x.x.x.x:56136 x.x.x.x:3269 ESTABLISHED 28474/sssd_be + + We see LDAPS port 636, and Global Catalog port 3629 in use. The user + lookup will succeed even with ports 389 and 3268 blocked, since it uses + their authenticated and encrypted variants instead. + + [Where problems could occur] + + Firstly, the adcli and sssd packages will continue to work with AD + servers that haven't had LDAP signing or authenticated channel binding + enforced, due to the measures being optional. + + For both sssd and adcli, the changes don't implement anything new, and + instead, the changes add configuration and logic to "select" what + protocol to use to talk to the AD server. LDAP and LDAPS are already + implemented in both sssd and adcli, the changes just add some logic to + select the use of LDAPS over LDAP. + + For sssd, the changes are hidden behind configuration parameters, such + as "ldap_sasl_mech" and "ad_use_ldaps". If a regression were to occur, + it would be limited to systems where the system administrator had + enabled these configuration options to the /etc/sssd/sssd.conf file. + + For adcli, the changes are more immediate. adcli will now use GSS-SPENGO + by default if the server supports it, which is a behaviour change. The + "use-ldaps" option is a flag on the command line, e.g. "--use-ldaps", + and if a regression were to occur, users can remove "--use-ldaps" from + their command to fall back to the new GSS-SPENGO defaults on port 389. + + The risk of regression is low, due to these features being opt-in via + command line flags and configuration parameters, which would likely be + well tested by a system administrator in their own AD environment before + they roll changes out to their production systems. There is some risk + with adcli moving to GSS-SPENGO by default, but this happens only if the + server supports it, and the change should be safe. + + [Other Info] + + Previous description, including FFe for adcli in Groovy: + https://paste.ubuntu.com/p/jpQ3FprJDx/ + + List of commits backported are below: + + adcli + ===== + + For both Bionic and Focal: + -------------------------- + + commit a6f795ba3d6048b32d7863468688bf7f42b2cafd + Author: Sumit Bose <sb...@redhat.com> + Date: Fri Oct 11 16:39:25 2019 +0200 + Subject: Use GSS-SPNEGO if available + Link: https://gitlab.freedesktop.org/realmd/adcli/-/commit/a6f795ba3d6048b32d7863468688bf7f42b2cafd + + commit 85097245b57f190337225dbdbf6e33b58616c092 + Author: Sumit Bose <sb...@redhat.com> + Date: Thu Dec 19 07:22:33 2019 +0100 + Subject: add option use-ldaps + Link: https://gitlab.freedesktop.org/realmd/adcli/-/commit/85097245b57f190337225dbdbf6e33b58616c092 + + sssd + ==== + + Bionic only (dependency) + ------------------------ + + commit 070f22f896b909c140ed7598aed2393d61a834ae + Author: Sumit Bose <sb...@redhat.com> + Date: Tue May 21 10:22:04 2019 +0200 + Subject: sdap: inherit SDAP_SASL_MECH if not set explicitly + Link: https://github.com/SSSD/sssd/commit/070f22f896b909c140ed7598aed2393d61a834ae + + For Bionic and Focal: + --------------------- + + commit 090cf77a0fd5f300a753667658af3ed763a88e83 + Author: Sumit Bose <sb...@redhat.com> + Date: Thu Sep 26 20:24:34 2019 +0200 + Subject: ad: allow booleans for ad_inherit_opts_if_needed() + Link: https://github.com/SSSD/sssd/commit/090cf77a0fd5f300a753667658af3ed763a88e83 + + commit 341ba49b0deb42e17d535744824786c2499656b7 + Author: Sumit Bose <sb...@redhat.com> + Date: Thu Sep 26 20:27:09 2019 +0200 + Subject: ad: add ad_use_ldaps + Link: https://github.com/SSSD/sssd/commit/341ba49b0deb42e17d535744824786c2499656b7 + + commit 78649907b81b4bdaf8fc6a6e6ae55ed3cd5419f5 + Author: Sumit Bose <sb...@redhat.com> + Date: Fri Sep 27 11:49:59 2019 +0200 + Subject: ldap: add new option ldap_sasl_maxssf + Link: https://github.com/SSSD/sssd/commit/78649907b81b4bdaf8fc6a6e6ae55ed3cd5419f5 + + commit 24387e19f065e6a585b1120d5568cb4df271d102 + Author: Sumit Bose <sb...@redhat.com> + Date: Fri Sep 27 13:45:13 2019 +0200 + Subject: ad: set min and max ssf for ldaps + Link: https://github.com/SSSD/sssd/commit/24387e19f065e6a585b1120d5568cb4df271d102 ** Tags added: bionic focal sts -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1868703 Title: Support "ad_use_ldaps" flag for new AD requirements (ADV190023) To manage notifications about this bug go to: https://bugs.launchpad.net/cyrus-sasl2/+bug/1868703/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
