** Description changed:

  [Impact]
  
  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.
  
  To address this, Microsoft has announced new Active Directory
  requirements in ADV190023 [1][2].
  
  [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
  
  These new requirements strongly encourage system administrators to
  require LDAP signing and authenticated channel binding in their AD
  environments.
  
  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.
  
  Microsoft will not be forcing this change via updates to their servers,
  system administrators must opt in and change their own configuration.
  
  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.
  
  If "ad_use_ldaps = True", then sssd will send all communication over
  port 636, authenticated and encrypted.
  
  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.
  
  This is currently reporting the following on Ubuntu 18.04/20.04LTS
  machines with the following error:
  
  "[sssd] [sss_ini_call_validators] (0x0020):
  [rule/allowed_domain_options]: Attribute 'ad_use_ldaps' is not allowed
  in section 'domain/test.com'. Check for typos."
  
  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.
  
  [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 Hirsute, Groovy, Focal and Bionic:
+ --------------------------------------
+ 
+ commit 76ca1e6737742208d83e016d43a3379e378f8d90
+ Author: Sumit Bose <sb...@redhat.com>
+ Date:   Wed Oct 14 17:44:10 2020 +0200
+ Subject: tools: add missing use-ldaps option to update and testjoin
+ Link: 
https://gitlab.freedesktop.org/realmd/adcli/-/commit/76ca1e6737742208d83e016d43a3379e378f8d90
+ 
  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

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1868703

Title:
  Support "ad_use_ldaps" flag for new AD requirements (ADV190023)

Status in Cyrus-sasl2:
  Unknown
Status in sssd package in Ubuntu:
  Fix Released
Status in adcli source package in Bionic:
  In Progress
Status in sssd source package in Bionic:
  In Progress
Status in adcli source package in Disco:
  Won't Fix
Status in sssd source package in Disco:
  Won't Fix
Status in adcli source package in Eoan:
  Won't Fix
Status in sssd source package in Eoan:
  Won't Fix
Status in adcli source package in Focal:
  In Progress
Status in sssd source package in Focal:
  In Progress
Status in adcli source package in Groovy:
  Fix Released
Status in sssd source package in Groovy:
  Fix Released
Status in sssd source package in Hirsute:
  Fix Released

Bug description:
  [Impact]

  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.

  To address this, Microsoft has announced new Active Directory
  requirements in ADV190023 [1][2].

  [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

  These new requirements strongly encourage system administrators to
  require LDAP signing and authenticated channel binding in their AD
  environments.

  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.

  Microsoft will not be forcing this change via updates to their
  servers, system administrators must opt in and change their own
  configuration.

  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.

  If "ad_use_ldaps = True", then sssd will send all communication over
  port 636, authenticated and encrypted.

  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.

  This is currently reporting the following on Ubuntu 18.04/20.04LTS
  machines with the following error:

  "[sssd] [sss_ini_call_validators] (0x0020):
  [rule/allowed_domain_options]: Attribute 'ad_use_ldaps' is not allowed
  in section 'domain/test.com'. Check for typos."

  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.

  [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 Hirsute, Groovy, Focal and Bionic:
  --------------------------------------

  commit 76ca1e6737742208d83e016d43a3379e378f8d90
  Author: Sumit Bose <sb...@redhat.com>
  Date:   Wed Oct 14 17:44:10 2020 +0200
  Subject: tools: add missing use-ldaps option to update and testjoin
  Link: 
https://gitlab.freedesktop.org/realmd/adcli/-/commit/76ca1e6737742208d83e016d43a3379e378f8d90

  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

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

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

Reply via email to