Am Wed, Nov 13, 2024 at 09:24:28PM +0000 schrieb Kodiak Firesmith via
sssd-users:
> Hi Folks,
> We need to start using LDAPS rather than non-TLS LDAP in our SSSD AD
> environment. I only have a single AD domain so I can't test with other
> domains to see if the problem is on the SSSD client side or AD server side.
>
> When we set ad_use_ldaps = True, we lose enumeration, and regardless of
> debug level, all we see related to the issue is the following:
>
> Nov 13 14:28:37 u20-test.college.edu sssd_be[125884]: Could not start TLS
> encryption. Error in the pull function.
> Nov 13 14:28:37 u20-test.college.edu sssd_be[125884]: Could not start TLS
> encryption. Error in the pull function.
> Nov 13 14:28:37 u20-test.college.edu sssd_be[125884]: Backend is offline
>
> Documentation is a bit scant, which led me to believe that this would be a
> simple matter of setting a single setting, but this didn't work out. After
> that I poked around on the internet and ended up trying the following
> additional sssd.conf settings:
>
> ldap_id_use_start_tls = False
> ldap_uri = ldaps://ad1.college.edu,ldaps://ad2.college.edu
> ldap_tls_cacert = /etc/sssd/certs/ad_ca.pem
>
> Unfortunately this resulted in the same error. When googling around for the
> specific error, there were no exact matches which makes me think I've
> encountered something sort of rare. I've been able to infer from searching
> that Error in the pull function. is an error message from GnuTLS which I
> assume SSSD wraps for LDAPS, but there are no hits for the full error message
> above with the sssd_be syslog label.
>
> The AD environment is 2016, the client is a Ubuntu 20.04 LTS system. The
> versions in use are requirements of the environment and I am unable to test
> against newer releases.
>
> I hesitate to mention it in case it creates false leads, but the system is
> largely compliant with the DoD MAC-1 Classified STIG, with all of the
> controls that brings over. Surprisingly there were no controls that directly
> affected SSSD or any LDAP libraries, and we're not enforcing FIPS validated
> cryptographic modules so it's unlikely due to STIG controls IMO.
>
> Questions:
>
> - Under normal circumstances, should the ad_use_ldaps setting be all we need
> for this to "just work"?
Hi,
yes, SSSD relies on OpenLDAP here. So if somthing like
kinit -k '[email protected]'
ldapsearch -Y GSS_SPNEGO -H ldaps://ad1.college.edu
works, SSSD should work as well.
> - Any ideas what we might be able to try in order to further root out the
> issue?
For testing you might want to try to set `ldap_tls_reqcert = never` to
tell OpenLDAP to not check any certificate.
You can also switch on the debug output of OpenLDAP's libldap by setting
ldap_library_debug_level = -1
The output can be found in the SSSD debug logs in /var/log/sssd/.
HTH
bye,
Sumit
>
> Thanks!
>
> - Kodiak
>
> Sent with [Proton Mail](https://proton.me/mail/home) secure email.
> --
> _______________________________________________
> sssd-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[email protected]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
