[STS-SPONSOR]

* Was it intentional to add the patchset at the bottom of the quilt
stack in the SSSD src package ?

If not, could you please correct it and add them at the top of the stack
? At first glance, they should still apply cleanly after that chane.

* I came accross this change in adcli:
76ca1e6737742208d83e016d43a3379e378f8d90

76ca1e6 tools: add missing use-ldaps option to update and testjoin
    When adding the use-ldaps option the update and testjoin sub-commands
    were forgotten.


https://gitlab.freedesktop.org/realmd/adcli/-/commit/76ca1e6737742208d83e016d43a3379e378f8d90

Did/could you check the feasibility of a backport ?
Look like it's worth looking at this oversight from upstream that has been then 
fixed later.

** 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/cp.pacs'. 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 
+ 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 
+ 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

-- 
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

Reply via email to