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

Do you know which sssd versions are affected? I tagged ubuntu releases that ship 1.16

For me the version which is shipped with bionic is affected: 1.16.1-1ubuntu1.5

Sadly the patches do not apply cleanly to 1.16.1.

So what I did was to use the latest version 1.16.5 and compiled with [sssd_1.16.3-3ubuntu1.1.diff.gz] from disco (removing all patches before).

And it does work, after adding ad_use_ldaps to my config:

> sudo netstat -tanp | grep sssd
tcp 0 0 10.2.30.39:43564 10.2.30.114:3269 ESTABLISHED 997/sssd_be
tcp 0 0 10.2.30.39:41326 10.2.30.114:636 ESTABLISHED 997/sssd_be

Focal - 20.04 is also affected by this missing option.

I have attached a patch for 2.2.3-3 which applies cleanly and works.

Also relevant: https://<email address hidden>/thread/ACLFYWEWIQVUUF3JDDSV3HZZQWXKB7N7/

The attachment "sssd-ldaps_2.2.3-3.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

The option ad_use_ldaps is not present in Eoan, Focal, and Groovy as well. I am adding a task for each one of them.

When will this be official fixed? Thanks.

The Eoan Ermine has reached end of life, so this bug will not be fixed for that release

The patches proposed in [1] were merged and already available in version 2.3.1. Therefore, this bug was fixed in Groovy.

[1] https://github.com/SSSD/sssd/pull/969

Ok, after a lot of messing around with windows, I was at least able to confirm that with sssd from groovy I can set ad_use_ldaps = True and, after exporting the AD CA cert and marking it as trusted on the client ubuntu box, I see the connection using port 646.

What I couldn't do was *reject* connections not using ssl/tls, even after applying the policy change described in https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows

I wonder if the gssapi SSF is enough to consider the connection encrypted and not require actual TLS/SSL?

ubuntu@g-sssd:~$ kinit john
Password for <email address hidden>:
ubuntu@g-sssd:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: <email address hidden>

Valid starting Expires Service principal
08/31/20 20:12:28 09/01/20 06:12:28 <email address hidden>
        renew until 09/01/20 20:12:26
ubuntu@g-sssd:~$ ldapwhoami -Y GSSAPI
SASL/GSSAPI authentication started
SASL username: <email address hidden>
SASL SSF: 256
SASL data security layer installed.
u:AD1\john
ubuntu@g-sssd:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: <email address hidden>

Valid starting Expires Service principal
08/31/20 20:12:28 09/01/20 06:12:28 <email address hidden>
        renew until 09/01/20 20:12:26
08/31/20 20:12:35 09/01/20 06:12:28 ldap/server1.ad1.example.com@
        renew until 09/01/20 20:12:26
08/31/20 20:12:35 09/01/20 06:12:28 <email address hidden>
        renew until 09/01/20 20:12:26

None of the above used port 636.

When I use a simple bind, I'm forced to use -ZZ, and I can see in the network traffic that TLS 1.2 was selected.

Furthermore, even after I applied the policy change regarding signing on the windows side, sssd without ad_use_ldaps still worked on port 389. I'll chalk that up to my windows knowledge gaps.

In any case, checking that port 636 is being used by sssd seems enough for an SRU test case I guess?

This was also very confusing for me, but there is a nice table which shows which method should work with signing.

And you can configure the domain controllers to report unsigned logins.

Some of these reports are generated only every 24h. I wanted to enact the policy and prevent such logins, so it's clear when I have a working client. It's what I tried to do, but bionic's sssd is working still fine via port 389. I also ditched the sssd cache there, and even rm -rf'ed /var/lib/sss/*.

I don't think I have "ActiveDirectory_DomainService" logs, I just see "Active Directory Web Services" and "Directory Service". I don't think there is a way to search all events for a specific event id, right? One has to select a source first.

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

On bionic, with sssd 1.16.1-1ubuntu1.6, tshark is telling me that the connection in port 389 is using "GSS-API integrity":
   83 177.024452189 10.51.0.5 _ 10.51.0.15 LDAP 112 bindResponse(3) saslBindInProgress
   84 177.024514712 10.51.0.15 _ 10.51.0.5 LDAP 112 bindRequest(4) "<ROOT>" sasl
   85 177.024804697 10.51.0.5 _ 10.51.0.15 LDAP 80 bindResponse(4) success
   86 177.024966894 10.51.0.15 _ 10.51.0.5 LDAP 204 SASL GSS-API Integrity:

Ok, I got a 2889 event when I did a simple bind on port 389, which is expected. At least shows the logging seems fine. And once I configure TLS and use -ZZ on that simple bind, it works even on port 389.

So what are the scenarios where sssd would use unencrypted connections on port 389? I think for nss, but in the AD scenario, these are all using gss-api integrity, no? Is this for setups where the AD integration from sssd is using just ldap, and not kerberos?

My sssd.conf on bionic (1.16) is:
[sssd]
domains = ad1.example.com
config_file_version = 2
services = nss, pam

[domain/ad1.example.com]
ad_domain = ad1.example.com
krb5_realm = AD1.EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad

Ok, I think this reply from upstream summarizes it quite well:
https://<email address hidden>/msg07415.html
"""
Hi,

this was already discussed here on the list. To summarize:

SASL:

- no changes are needed for the default AD provider configuration with
  SASL/GSSAPI, there are event log messages saying that signing is
  missing on the connection but everything is still working even when
  signing is enforced, so imo the event log messages can be ignored
- you can prevent the event log message by switching to GSS-SPNEGO with
  the help of the 'ldap_sasl_mech' option, see man sssd-ldap for details
- we plan to change the default from GSSAPI to GSS-SPNEGO in one of the
  next release

LDAPS:

- afaik there is no document from Microsoft saying that the default LDAP
  port 389 will be disabled or should not be used anymore as long as
  LDAP signing is used, so in general there is no need to switch to
  LDAPS
- if you have a manual configuration with LDAPS using a simple bind,
  i.e. Bind DN and password to my knowledge no changes are needed
- if you use a manual configuration with LDAPS and SASL bind you have to
  wait for some fixes related to channel binding in OpenLDAP

    https://git.openldap.org/openldap/openldap/-/merge_requests/26

  and CyrusSASL

    https://github.com/cyrusimap/cyrus-sasl/pull/601 (already merged
    upstream)

  with those fixes LDAPS with SASL should work with enforced channel
  binding as well.
"""

I wonder if Microsoft changed the behaviour since early this year? I've seen mailing list posts stating that a simple ldapsearch with gssapi would succeed, even with the server enforcing rules on signing enabled, but still log the 2889 event. But I don't see that now.

This works and does not produce the 2889 event on the server:

$ ldapsearch -H ldap://server1.ad1.example.com -Y GSSAPI -b '' -s base > /dev/null
SASL/GSSAPI authentication started
SASL username: <email address hidden>
SASL SSF: 56
SASL data security layer installed.

If I set maxssf to 0, then it fails and *does* produce the 2889 event on the server:
$ ldapsearch -O maxssf=0 -H ldap://server1.ad1.example.com -Y GSSAPI -b '' -s base > /dev/null
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Strong(er) authentication required (8)
        additional info: 00002028: LdapErr: DSID-0C090266, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v4563

Event:
The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection.

Client IP address:
10.51.0.1:49036
Identity the client attempted to authenticate as:
AD1\john
Binding Type:
0

Status changed to 'Confirmed' because the bug affects multiple users.

Are there any indications of this being included in Focal and Bionic anytime soon?

We're looking at a setup with RHEL 7 and 8 servers where we can use ad_use_ldaps and Ubuntu servers where we cannot.. It would be nicer to be able to use the same config on both :) Unfortunately the network guys want to close 389 and only make 636 available, so we have to look into either waiting for this backport or figuring out something else entirely.

That is very likely, but first I have to get it into groovy, which is past Feature Freeze. The MP was approved already, but I need a +1 from the release team before uploading.

https://support.microsoft.com/en-us/help/4559003/windows-10-update-kb4559003

Reading beyond the "highlights", one can see:

"Addresses an issue that incorrectly reports Lightweight Directory Access Protocol (LDAP) sessions as unsecure sessions in Event ID 2889. This occurs when the LDAP session is authenticated and sealed with a Simple Authentication and Security Layer (SASL) method. "

So that clears up one source of logging.

Oh, I missed that this was an update for the *client* (windows 10), not the server. Hm. Confusing.

Switched bug to "New" so it can be considered by the release team.

This one is a bit more risky, as it changes the default behavior of now preferring GSS-SPNEGO if available. We missed taking care of this one earlier, so arguments 'it's too late' do not make much sense. I assume that the server team did enough testing of this in the meantime, so I think we can risk it. FFe approved - just be sure to upload it before Beta Freeze today!

This bug was fixed in the package adcli - 0.9.0-1ubuntu1

---------------
adcli (0.9.0-1ubuntu1) groovy; urgency=medium

  * New features (LP: #1893784):
    - d/p/tools-add-show-computer-command.patch: add a show-computer
      command to print the LDAP attrs of the computer object
    - d/p/add-description-option-to-join-and-update.patch: allow setting
      an optional description on the computer account
  * Handle new Active Directory requirements from
    https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023
    (LP: #1868703):
    - d/p/Use-GSS-SPNEGO-if-available.patch: prefer GSS-SPNEGO over
      GSSAPI if available, as that can handle some of the more advanced
      features which can be required by an AD server
    - d/p/add-option-use-ldaps.patch: add option to use LDAPS, useful
      if for some reason the LDAP port is blocked.
  * Documentation fixes:
    - d/p/man-move-note-to-the-right-section.patch: move note about
      password lifetime to the update section
    - d/p/man-explain-optional-parameter-of-login-ccache-bette.patch,
      d/p/man-make-handling-of-optional-credential-cache-more-.patch:
      better explain the login-ccache and -C parameters
    - d/p/tools-fix-typo-in-show-password-help-output.patch: typo fix
  * Other fixes:
    - d/p/discovery-fix.patch: do not continue processing on a closed
      connection
    - d/p/delete-do-not-exit-if-keytab-cannot-be-read.patch: fix computer
      deletion when keytab cannot be read
    - d/p/tools-disable-SSSD-s-locator-plugin.patch: ignore MIT's locator
      plugin to avoid conflicts if it returns a different DC than the one
      used for the LDAP connection

 -- Andreas Hasenack <email address hidden> Wed, 02 Sep 2020 09:50:18 -0300

Can we now get patched adcli and sssd backported to bionic and focal?

Yes, that's the plan.

Hi Tobias, Thorstein, and anyone who is after a backport of these patches,

I have completed backporting the below patches to the Bionic and Focal adcli and sssd packages, and I am looking for some help with testing. If you have some spare time, a Windows Active Directory server available, and some test Ubuntu machines, I would really appreciate help ensuring these test packages work as expected.

Source code / debdiffs for the test sssd and adcli packages are below if you are interested:

Focal:
sssd: https://paste.ubuntu.com/p/JCVcV26RS2/
adcli: https://paste.ubuntu.com/p/RSqSWdCYQH/

Bionic:
sssd: https://paste.ubuntu.com/p/vcyYnjVdg7/
adcli: https://paste.ubuntu.com/p/SVpHZc59pq/

Please note, these test packages are NOT SUPPORTED by Canonical, and are for
TEST PURPOSES ONLY. ONLY install in a dedicated test environment.

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
4) sudo apt-cache policy adcli | grep Installed
Installed: 0.9.0-1ubuntu0+sf294530v20201013b1 // for focal
Installed: 0.8.2-1ubuntu0+sf294530v20201019b1 // for bionic
5) sudo apt-cache policy sssd | grep Installed
Installed: 2.2.3-3ubuntu0+sf294530v20201012b1 // for focal
Installed: 1.16.1-1ubuntu1.6+sf294530v20201021b1 // for bionic

Please let me know if these test packages work as expected in regards to the "ad_use_ldaps" flag, or if you run into any problems.

List of commits backported are below:

adcli
=====

For both Bionic and Focal:
--------------------------

commit a6f795ba3d6048b32d7863468688bf7f42b2cafd
Author: Sumit Bose <email address hidden>
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 <email address hidden>
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 <email address hidden>
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 <email address hidden>
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 <email address hidden>
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 <email address hidden>
Date: Fri Sep 27 11:49:59 2019 +0200
Subject: ldap: add new option ldap_sasl_maxssf
Link: https://github.com/SSSD/sssd/commit/78649907b81b4bdaf8...

I've done a fairly simple test using the latest Ubuntu 18.04 and can confirm that with "ad_use_ldaps = True" set in sssd.conf, sssd appears to only be making connections over ports 636 & 3269.

Sorry, I was on vaccation.

I can confirm that the backports work as expected with "ad_use_ldaps = True" on both bionic and focal.

Attached is a debdiff for adcli on Focal.

Attached is a sssd debdiff for Focal

Attached is a adcli debdiff for Bionic

Attached is a sssd debdiff for Bionic

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

[STS-SPONSOR]

* Remove the link "https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023" from d/changelog and please add it in the patches DEP3 header as follows:

Bug: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

NOTE: Please do keep a reference in d/changelog for "ADV190023" but without the link.

Attached is a revised debdiff for sssd for Focal.

Attached is a revised debdiff for sssd for Bionic.

Attached is a debdiff for adcli for Hirsute.

Attached is a debdiff for adcli in Groovy.

Attached is a revised debdiff for adcli for Focal.

Attached is a revised debdiff for adcli in Bionic.

[STS-SPONSOR]

Sponsored in active development release (hirsute). Once it is landed in hirsute-releases, I'll go ahead with the SRU sponsoring.

- Eric

[STS-SPONSOR][GROOVY][ADCLI]

Sponsored in Groovy.

Minor nitpicks:
* Rename the quilt patch from "lp-1868703-01-tools-add-missing-use-ldaps-option-to-update-and-testjoin.patch" to "lp1868703-tools-add-missing-use-ldaps-option-to-update-and-testjoin.patch"

Versioning the patch w/ "01" in this case is not necessary since it's a single patch not part of
a patchset. I know why Matthew has numbered them this way cause starting Focal it will be a patchset. It will make sense w/ Focal downward. For Groovy, I prefer to remove any unnecessary information if not needed to save char space and make it more easy to read.

* Changed the version from "0.9.0-1ubuntu2" to "0.9.0-1ubuntu1.1"

Hirsute has been copied from Groovy, but then at next uploads, the uploads needs to separate the package to have their distinct version (Higher to Lower as we go down the Ubuntu releases)

If after our upload hirsute become "0.9.0-1ubuntu2", then groovy cannot be "0.9.0-1ubuntu2" as well. It needs to be different and lower to not break the upgrade path. In this case using "0.9.0-1ubuntu1.1" is the most logical approach.

Thanks for your collaboration Matthew.

- Eric

I think it might be something we might like to have in -security pocket.

I'll talk to sil2100 to see what he thinks about it, while approving the upload in Groovy for adcli.

Hello! I did a quick review of the adcli changes and those seem to be fine, but I agree this might be something that could go to -security. I would like to at least get the security team to decide. If they say it should go to the -security pocket as well, I have uploaded the groovy package to a security-enabled Bileto PPA here:

https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4336/+packages

So we'll be ready to bin-sync it into -proposed and from there into both -updates/-security.

Thanks Lukasz !

Hello Tobias, or anyone else affected,

Accepted adcli into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/adcli/0.9.0-1ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[STS-SPONSOR] [ADCLI]

Sponsored in both Focal and Bionic.

[FOCAL]
* Changed the version in d/changelog in Focal from "0.9.0-1ubuntu1" to "0.9.0-1ubuntu0.20.04.1".
Groovy has already that version "0.9.0-1ubuntu1".

[BIONIC]
lgtm.

Thanks for your contribution Matthew.

[STS-SPONSOR] [SSSD]

[BIONIC]
lgtm.

[FOCAL]
lgtm.

Please don't forget to ping security team to sponsor it in the -security pocket once landed in -updates for both adcli and sssd.

- Eric

So it seems Brian approved the earlier source upload instead. Let me bump the version number, rebuild, sync and re-accept.

Hello Tobias, or anyone else affected,

Accepted adcli into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/adcli/0.9.0-1ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Tobias, or anyone else affected,

Accepted adcli into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/adcli/0.9.0-1ubuntu0.20.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Tobias, or anyone else affected,

Accepted adcli into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/adcli/0.8.2-1ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Tobias, or anyone else affected,

Accepted sssd into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/sssd/2.2.3-3ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Tobias, or anyone else affected,

Accepted sssd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/sssd/1.16.1-1ubuntu1.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

verification-done-bionic
adcli 0.8.2-1ubuntu1
sssd 1.16.1-1ubuntu1.7

For focal I can't find the new package in proposed and 2.2.3-3ubuntu1 points to a different fix?!
https://launchpad.net/ubuntu/+source/sssd/2.2.3-3ubuntu1
sssd (2.2.3-3ubuntu1) groovy; urgency=medium

  * Fix build with samba 4.12.x:
    - d/p/refresh-ndr-methods.patch
    - d/p/use-ndr_token_peek.patch
    - d/p/use-ndr_pull_steal_switch_value.patch

 -- Andreas Hasenack <email address hidden> Wed, 13 May 2020 14:06:29 +0000

For groovy I need to setup an installation first.

Hello Tobias, or anyone else affected,

Accepted sssd into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/sssd/2.2.3-3ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

verification-done-focal
adcli 0.9.0-1ubuntu0.20.04.1
sssd 2.2.3-3ubuntu0.1

verification-done-groovy
adcli 0.9.0-1ubuntu1.2

@tobias, thanks for your comment.

Could you elaborate on the reproducer you took to test ?
Was it the one from the [test case] ?

SRU team will want the general steps taken to verify that package.

- Eric

Yes, I did all from the testcase.

Additionally I did a AD-Join with LDAPS:
# adcli join --use-ldaps -U admin-karnat -O ou=Dummy,ou=IT,dc=REMONDIS-DE,dc=LOCAL

And a login with an AD-User with public key saved as attribute
# grep ldap_user_ssh_public_key /etc/sssd/sssd.conf
ldap_user_ssh_public_key = sshPublicKeys

# grep AuthorizedKeysCommand /etc/ssh/sshd_config
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

# grep pam_mkhomedir.so /etc/pam.d/common-session
session required pam_mkhomedir.so skel=/etc/skel/

Thanks for the testing Tobias !

Hi Tobias, thanks for testing and verifying! I really appreciate it, and it's good to hear that everything works.

I'll just add some of my own test output below, and we should be good to go for a release to -updates in about a week's time.

Performing verification of adcli on Groovy.

Groovy only required one patch, which fixed a missed enablement of --use-ldaps for the testjoin and update commands.

So, just testing those two.

I installed adcli 0.9.0-1ubuntu1 from -updates, and I set everything up by issuing a join command. After that, I tried the --use-ldaps flag with testjoin and update commands:

# adcli testjoin --use-ldaps --verbose --domain WIN-SB6JAS7PH22.testing.local --domain-controller WIN-SB6JAS7PH22.testing.local
testjoin: unrecognized option '--use-ldaps'
usage: adcli testjoin

# adcli update --use-ldaps --verbose --domain WIN-SB6JAS7PH22.testing.local --domain-controller WIN-SB6JAS7PH22.testing.local
update: unrecognized option '--use-ldaps'
usage: adcli update

I then enabled -proposed, and installed adcli 0.9.0-1ubuntu1.2 and tried again:

We block port 389 on firewall, so

# ufw deny 389
# ufw deny 3268

Then try testjoin and update:

# adcli testjoin --use-ldaps --verbose --domain WIN-SB6JAS7PH22.testing.local --domain-controller WIN-SB6JAS7PH22.testing.local
 * Found realm in keytab: TESTING.LOCAL
 * Found computer name in keytab: UBUNTU
 * Found service principal in keytab: host/UBUNTU
 * Found service principal in keytab: host/ubuntu.testing.local
 * Found host qualified name in keytab: ubuntu.testing.local
 * Found service principal in keytab: RestrictedKrbHost/UBUNTU
 * Found service principal in keytab: RestrictedKrbHost/ubuntu.testing.local
 * Using domain name: WIN-SB6JAS7PH22.testing.local
 * Calculated computer account name from fqdn: UBUNTU
 * Using domain realm: WIN-SB6JAS7PH22.testing.local
 * Sending NetLogon ping to domain controller: WIN-SB6JAS7PH22.testing.local
 * Received NetLogon info from: WIN-SB6JAS7PH22.testing.local
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-6SRtqJ/krb5.d/adcli-krb5-conf-YGzgnK
 * Authenticated as default/reset computer account: UBUNTU
 * Using LDAPS to connect to WIN-SB6JAS7PH22.testing.local
 * Looked up short domain name: TESTING
 * Looked up domain SID: S-1-5-21-960071060-1417404557-720088570
Sucessfully validated join to domain WIN-SB6JAS7PH22.testing.local

# adcli update --use-ldaps --verbose --domain WIN-SB6JAS7PH22.testing.local --domain-controller WIN-SB6JAS7PH22.testing.local
 * Found realm in keytab: TESTING.LOCAL
 * Found computer name in keytab: UBUNTU
 * Found service principal in keytab: host/UBUNTU
 * Found service principal in keytab: host/ubuntu.testing.local
 * Found host qualified name in keytab: ubuntu.testing.local
 * Found service principal in keytab: RestrictedKrbHost/UBUNTU
 * Found service principal in keytab: RestrictedKrbHost/ubuntu.testing.local
 * Using domain name: WIN-SB6JAS7PH22.testing.local
 * Calculated computer account name from fqdn: UBUNTU
 * Using domain realm: WIN-SB6JAS7PH22.testing.local
 * Sending NetLogon ping to domain controller: WIN-SB6JAS7PH22.testing.local
 * Received NetLogon info from: WIN-SB6JAS7PH22.testing.local
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-6FQ1ZS/krb5.d/adcli-krb5-conf-LHowkP
 * Authenticated as default/reset computer account: UBUNTU
 * Using LDAPS to connect to WIN-SB6JAS7PH22.testing.local
 * Looked up short domain name: TESTING
 * ...

Performing verification of adcli on Focal

The patches for Focal are a bit more involved, as it adds the whole --use-ldaps ecosystem.

Firstly, I installed adcli 0.9.0-1 from -updates. The manpage did not have any mention of --use-ldaps, and if I ran a command with --use-ldaps, it would complain it was unrecongized.

# adcli join --use-ldaps --verbose --domain WIN-SB6JAS7PH22.testing.local --domain-controller WIN-SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL
join: unrecognized option '--use-ldaps'
usage: adcli join

I then enabled -proposed and installed adcli 0.9.0-1ubuntu0.20.04.1.

The man page now talks about --use-ldaps

$ man adcli | grep -i ldaps
       --use-ldaps
           Connect to the domain controller with LDAPS. By default the LDAP port is used and SASL GSS-SPNEGO or GSSAPI is used for authentication and to establish encryption. This should
           satisfy all requirements set on the server side and LDAPS should only be used if the LDAP port is not accessible due to firewalls or other reasons.
               $ LDAPTLS_CACERT=/path/to/ad_dc_ca_cert.pem adcli join --use-ldaps -D domain.example.com

I then enabled a firewall rule to block ldap connections:

# ufw deny 389
# ufw deny 3268

And tried the join command:

# adcli join --use-ldaps --verbose -U Administrator --domain WIN-SB6JAS7PH22.testing.local --domain-controller WIN-SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL
 * Using domain name: WIN-SB6JAS7PH22.testing.local
 * Calculated computer account name from fqdn: UBUNTU
 * Using domain realm: WIN-SB6JAS7PH22.testing.local
 * Sending NetLogon ping to domain controller: WIN-SB6JAS7PH22.testing.local
 * Received NetLogon info from: WIN-SB6JAS7PH22.testing.local
 * Using LDAPS to connect to WIN-SB6JAS7PH22.testing.local
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-ihG1h9/krb5.d/adcli-krb5-conf-bt9nd8
Password for <email address hidden>:
 * Authenticated as user: <email address hidden>
 * Using GSS-API for SASL bind
 * Looked up short domain name: TESTING
 * Looked up domain SID: S-1-5-21-960071060-1417404557-720088570
 * Using fully qualified name: ubuntu
 * Using domain name: WIN-SB6JAS7PH22.testing.local
 * Using computer account name: UBUNTU
 * Using domain realm: WIN-SB6JAS7PH22.testing.local
 * Calculated computer account name from fqdn: UBUNTU
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * Found computer account for UBUNTU$ at: CN=UBUNTU,CN=Computers,DC=testing,DC=local
 * Sending NetLogon ping to domain controller: WIN-SB6JAS7PH22.testing.local
 * Received NetLogon info from: WIN-SB6JAS7PH22.testing.local
 * Set computer password
 * Retrieved kvno '13' for computer account in directory: CN=UBUNTU,CN=Computers,DC=testing,DC=local
 * Checking RestrictedKrbHost/ubuntu.testing.local
 * Added RestrictedKrbHost/ubuntu.testing.local
 * Checking host/ubuntu.testing.local
 * Added host/ubuntu.testing.local
 * Checking RestrictedKrbHost/UBUNTU
 * Added RestrictedKrbHost/UBUNTU
 * Checking host/UBUNTU
 * Added host/UBUNTU
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Discovered which keytab salt to use
 * Added t...

Performing verification of adcli on Bionic

The patches for Bionic are a bit more involved, as it adds the whole --use-ldaps ecosystem.

Firstly, I installed adcli 0.8.2-1 from -updates. The manpage did not have any mention of --use-ldaps, and if I ran a command with --use-ldaps, it would complain it was unrecongized.

# adcli join --use-ldaps --verbose --domain WIN-SB6JAS7PH22.testing.local --domain-controller WIN-SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL
join: unrecognized option '--use-ldaps'
usage: adcli join

I then enabled -proposed and installed adcli 0.8.2-1ubuntu1.

The man page now talks about --use-ldaps

$ man adcli | grep -i ldaps
       --use-ldaps
           Connect to the domain controller with LDAPS. By default the LDAP port is used and SASL GSS-SPNEGO or GSSAPI is used for authentication and to establish encryption. This should
           satisfy all requirements set on the server side and LDAPS should only be used if the LDAP port is not accessible due to firewalls or other reasons.
               $ LDAPTLS_CACERT=/path/to/ad_dc_ca_cert.pem adcli join --use-ldaps -D domain.example.com

I then enabled a firewall rule to block ldap connections:

# ufw deny 389
# ufw deny 3268

And tried the join command.

# adcli join --use-ldaps --verbose -U Administrator --domain WIN-SB6JAS7PH22.testing.local --domain-controller WIN-SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL
 * Using domain name: WIN-SB6JAS7PH22.testing.local
 * Calculated computer account name from fqdn: UBUNTU
 * Using domain realm: WIN-SB6JAS7PH22.testing.local
 * Sending NetLogon ping to domain controller: WIN-SB6JAS7PH22.testing.local
 * Received NetLogon info from: WIN-SB6JAS7PH22.testing.local
 * Using LDAPS to connect to WIN-SB6JAS7PH22.testing.local
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-ihG1h9/krb5.d/adcli-krb5-conf-bt9nd8
Password for <email address hidden>:
 * Authenticated as user: <email address hidden>
 * Using GSS-API for SASL bind
 * Looked up short domain name: TESTING
 * Looked up domain SID: S-1-5-21-960071060-1417404557-720088570
 * Using fully qualified name: ubuntu
 * Using domain name: WIN-SB6JAS7PH22.testing.local
 * Using computer account name: UBUNTU
 * Using domain realm: WIN-SB6JAS7PH22.testing.local
 * Calculated computer account name from fqdn: UBUNTU
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * Found computer account for UBUNTU$ at: CN=UBUNTU,CN=Computers,DC=testing,DC=local
 * Sending NetLogon ping to domain controller: WIN-SB6JAS7PH22.testing.local
 * Received NetLogon info from: WIN-SB6JAS7PH22.testing.local
 * Set computer password
 * Retrieved kvno '13' for computer account in directory: CN=UBUNTU,CN=Computers,DC=testing,DC=local
 * Checking RestrictedKrbHost/ubuntu.testing.local
 * Added RestrictedKrbHost/ubuntu.testing.local
 * Checking host/ubuntu.testing.local
 * Added host/ubuntu.testing.local
 * Checking RestrictedKrbHost/UBUNTU
 * Added RestrictedKrbHost/UBUNTU
 * Checking host/UBUNTU
 * Added host/UBUNTU
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Discovered which keytab salt to use
 * Added the ent...

Verification for sssd on Focal:

The customer tested sssd from -updates, version 2.2.3-3 and the package from -proposed, version 2.2.3-3ubuntu0.1.

Begins:

I have successfully tested the [package from -proposed] on Ubuntu 20.04.1.

Before applying the patch [package from -proposed] I confirmed open ports to our domain controllers using ss and grepping for the DC IPs. Before the patch 389 and 3268 were being actively used.

After the patch [installing the package from -proposed] (and after running a few user queries with `id`) ports 636 and 3269 were being used.

Ends.

This matches my testing and testing Tobias has done, so happy to mark sssd as verified for Focal.

Verification for sssd on Bionic:

The customer tested sssd from -updates, version 1.16.1-1ubuntu1.6 and the package from -proposed, version 1.16.1-1ubuntu1.7.

Begins:

Before applying the patch [package from -proposed] I confirmed open ports to our domain controllers using ss and grepping for the DC IPs. Before the patch 389 and 3268 were being actively used.

After the patch [installing the package from -proposed] (and after running a few user queries with `id`) ports 636 and 3269 were being used.

Ends.

This matches my testing and testing Tobias has done, so happy to mark sssd as verified for Bionic.

This bug was fixed in the package adcli - 0.9.0-1ubuntu1.2

---------------
adcli (0.9.0-1ubuntu1.2) groovy; urgency=medium

  * Fixup "use-ldaps" option to add missing subcommands, as a part of
    enabling support for new active directory requirement ADV190023
    (LP: #1868703):
    - d/p/lp1868703-tools-add-missing-use-ldaps-option-to-update-and-testjoin.patch

 -- Matthew Ruffell <email address hidden> Thu, 12 Nov 2020 09:16:14 -0500

The verification of the Stable Release Update for adcli has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package adcli - 0.9.0-1ubuntu0.20.04.1

---------------
adcli (0.9.0-1ubuntu0.20.04.1) focal; urgency=medium

  * Enable support for "use-ldaps" for new Active Directory
    requirement ADV190023 (LP: #1868703):
    - d/p/lp-1868703-01-Use-GSS-SPNEGO-if-available.patch
    - d/p/lp-1868703-02-add-option-use-ldaps.patch
    - d/p/lp-1868703-03-tools-add-missing-use-ldaps-option-to-update-and-testjoin.patch

 -- Matthew Ruffell <email address hidden> Tue, 10 Nov 2020 16:12:33 +1300

This bug was fixed in the package sssd - 2.2.3-3ubuntu0.1

---------------
sssd (2.2.3-3ubuntu0.1) focal; urgency=medium

  * Enable support for "ad_use_ldaps" for new Active Directory
    requirement ADV190023 (LP: #1868703):
    - d/p/lp-1868703-01-ad-allow-booleans-for-ad_inherit_opts_if_needed.patch
    - d/p/lp-1868703-02-ad-add-ad_use_ldaps.patch
    - d/p/lp-1868703-03-ldap-add-new-option-ldap_sasl_maxssf.patch
    - d/p/lp-1868703-04-ad-set-min-and-max-ssf-for-ldaps.patch

 -- Matthew Ruffell <email address hidden> Tue, 10 Nov 2020 11:59:08 +1300

This bug was fixed in the package sssd - 1.16.1-1ubuntu1.7

---------------
sssd (1.16.1-1ubuntu1.7) bionic; urgency=medium

  * Enable support for "ad_use_ldaps" for new Active Directory
    requirement ADV190023 (LP: #1868703):
    - d/p/lp-1868703-01-sdap-inherit-SDAP_SASL_MECH-if-not-set-explicitly.patch
    - d/p/lp-1868703-02-ad-allow-booleans-for-ad_inherit_opts_if_needed.patch
    - d/p/lp-1868703-03-ad-add-ad_use_ldaps.patch
    - d/p/lp-1868703-04-ldap-add-new-option-ldap_sasl_maxssf.patch
    - d/p/lp-1868703-05-ad-set-min-and-max-ssf-for-ldaps.patch

 -- Matthew Ruffell <email address hidden> Tue, 10 Nov 2020 12:10:04 +1300

This bug was fixed in the package adcli - 0.8.2-1ubuntu1

---------------
adcli (0.8.2-1ubuntu1) bionic; urgency=medium

  * Enable support for "use-ldaps" for new Active Directory
    requirement ADV190023 (LP: #1868703):
    - d/p/lp-1868703-01-Use-GSS-SPNEGO-if-available.patch
    - d/p/lp-1868703-02-add-option-use-ldaps.patch
    - d/p/lp-1868703-03-tools-add-missing-use-ldaps-option-to-update-and-testjoin.patch

 -- Matthew Ruffell <email address hidden> Tue, 10 Nov 2020 15:55:44 +1300

As per discussion, and since the packages have been built with -security in mind, I'll proceed with releasing those to the security pockets as well.

@Mattew - FYI a new bug report indicates that this update might have broken some users.
Might I ask you - as the Author - to please investigate bug 1906673

For now, I have pulled the sssd update from -upgrades/-security into -proposed.

It is most likely the adcli package and not sssd as the reported bug happens on the domain join

For what it's worth, we have gotten a report about adcli as well. Lukasz will pull adcli from -upgrades/-security as well. We're investigating the failures.

Hi Tobias,

If you have a moment, could you please help test the new adcli package in -proposed? Mainly focusing on testing Bionic, to ensure the regression has been fixed.

Can you run through some tests with and without the --use-ldaps flag?

You can install the new adcli package in -proposed like so:

Enable -proposed by running the following command to make a new sources.list.d entry:
1) cat << EOF | sudo tee /etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list
# Enable Ubuntu proposed archive
deb http://archive.ubuntu.com/ubuntu/ $(lsb_release -cs)-proposed main universe
EOF
2) sudo apt update
3) sudo apt install adcli
4) sudo apt-cache policy adcli | grep Installed
Installed: 0.8.2-1ubuntu1.2
5) sudo apt-cache policy libsasl2-modules-gssapi-mit | grep Installed
Installed: 2.1.27~101-g0780600+dfsg-3ubuntu2.3
6) sudo rm /etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list
7) sudo apt update

In my testing, everything works as intended. This new version fixes the regression from bug 1906627, as GSS-SPNEGO is now compatible with the one in Active Directory.

I will be marking this bug as verified in the coming days, once I am satisfied with my own testing.

Thanks,
Matthew

verification-done-bionic
adcli 0.8.2-1ubuntu1.2
libsasl2-2 2.1.27~101-g0780600+dfsg-3ubuntu2.1

I did all from the testcase with and without --use-ldaps

# adcli join --verbose -U admin-karnat -O ou=Dummy,ou=IT,dc=REMONDIS-DE,dc=LOCAL --os-name=Ubuntu --os-version=18 .04 -S DE0000D05.REMONDIS-DE.LOCAL * Sending netlogon pings to domain controller: cldap://10.2.1.212 * Received NetLogon info from: DE0000D05.remondis-de.local * Discovered domain name: remondis-de.local * Calculated computer account name from fqdn: DE9899SGT * Calculated domain realm from name: REMONDIS-DE.LOCAL
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-8U1C1r/krb5.d/adcli-krb5-conf-gmZVSx Password for <email address hidden>: * Authenticated as user: <email address hidden> * Using GSS-SPNEGO for SASL bind * Looked up short domain name: REMONDIS-DE * Using fully qualified name: DE9899SGT * Using domain name: remondis-de.local * Using computer account name: DE9899SGT * Using domain realm: remondis-de.local ...

Target server was Windows 2012R2 with 2019 AD schema.

The servicePrincipalName error in the output is unrelated (the reason I still use #net ads join).

Thanks Tobias for the testing. Good to hear it functions as intended.

Performing verification for Bionic

I installed adcli 0.8.2-1ubuntu1.2 from -proposed, and joined a domain without using the --use-ldaps flag.

https://paste.ubuntu.com/p/RByVZRPhCK/

Next, I added the firewall rules from the test section:

# ufw deny out 389
# ufw deny out 3268
# ufw enable

Now, I tried to join, again without --use-ldaps:

https://paste.ubuntu.com/p/KMPNtS5SYK/

I got rejected, due to firewall.

Now, lets try connect with --use-ldaps:

https://paste.ubuntu.com/p/bKzx6K6PXd/

Realm join works, and I checked with strace to see what port is being used:

connect(3, {sa_family=AF_INET, sin_port=htons(636), sin_addr=inet_addr("192.168.122.66")}, 16) = 0

We see port 636 as expected.

I am happy with the packages in -proposed, they implement the new feature properly, and more importantly, fix the regression from bug 1906627. Happy to mark as verified.

Can we get the sssd package moved again please? I've got over 200 VMs depending on this.

Łukasz? From what I understand reading these bugs the regression found was not in sssd, so it should be releasable back to -updates (and -security), but I'd like to check!

This bug was fixed in the package sssd - 2.2.3-3ubuntu0.1

---------------
sssd (2.2.3-3ubuntu0.1) focal; urgency=medium

  * Enable support for "ad_use_ldaps" for new Active Directory
    requirement ADV190023 (LP: #1868703):
    - d/p/lp-1868703-01-ad-allow-booleans-for-ad_inherit_opts_if_needed.patch
    - d/p/lp-1868703-02-ad-add-ad_use_ldaps.patch
    - d/p/lp-1868703-03-ldap-add-new-option-ldap_sasl_maxssf.patch
    - d/p/lp-1868703-04-ad-set-min-and-max-ssf-for-ldaps.patch

 -- Matthew Ruffell <email address hidden> Tue, 10 Nov 2020 11:59:08 +1300

This bug was fixed in the package sssd - 1.16.1-1ubuntu1.7

---------------
sssd (1.16.1-1ubuntu1.7) bionic; urgency=medium

  * Enable support for "ad_use_ldaps" for new Active Directory
    requirement ADV190023 (LP: #1868703):
    - d/p/lp-1868703-01-sdap-inherit-SDAP_SASL_MECH-if-not-set-explicitly.patch
    - d/p/lp-1868703-02-ad-allow-booleans-for-ad_inherit_opts_if_needed.patch
    - d/p/lp-1868703-03-ad-add-ad_use_ldaps.patch
    - d/p/lp-1868703-04-ldap-add-new-option-ldap_sasl_maxssf.patch
    - d/p/lp-1868703-05-ad-set-min-and-max-ssf-for-ldaps.patch

 -- Matthew Ruffell <email address hidden> Tue, 10 Nov 2020 12:10:04 +1300