Should ad_use_ldaps need additional work/settings to support LDAPS?

[Kodiak Firesmith]

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"?
- Any ideas what we might be able to try in order to further root out the issue?

Thanks!

- Kodiak

Sent with [Proton Mail](https://proton.me/mail/home) secure email.

[Sumit Bose]

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 'YOURCLIENTNAME$@COLLEGE.EDU'
    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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Kodiak Firesmith]

Thank you Sumit, as usual you are an invaluable resource for all things SSSD.  I'll install what I believe are the necessary supporting packages and then try once more.

- Kodiak

Sent with Proton Mail secure email.

On Thursday, November 14th, 2024 at 3:39 AM, Sumit Bose  wrote:
> 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 'YOURCLIENTNAME$@COLLEGE.EDU'
> 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 secure email.
> > --
> > _______________________________________________
> > sssd-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail].o...
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Spike White]

Sumit,

There is one additional small step to do ldapsearch with snego over LDAPS
-- and it is a very AD-specific step.

By default, GSSAPI and GSS-SPNEGO mechanisms encrypt their traffic.
LDAPS also encrypts its traffic.

AD does not allow double-encryption.

So the extra step is to tell openldap not to encrypt its GSS-SPNEGO
traffic, so that over LDAPS it's only singly-encrypted and then AD is happy.

Here's the details.

At the end of the /etc/openldap/ldap.conf file, you add this:

# Allow all certs.
TLS_REQCERT ALLOW

# To tell GSSAPI to not encrypt, so that we can run over LDAPS.
sasl_secprops minssf=0,maxssf=0

#############################
SASL_NOCANON    off
#############################

And then you can use GSS-SPNEGO to ldapsearch fine.  Example:

ldapsearch   -Y GSS-SPNEGO -H  ldaps://AUSDCamer.amer.company.com -b
'dc=AMER,dc=COMPANY,dc=COM' -s sub
'(&(objectClass=user)(name=spike_white))' memberOf

without that line in /etc/openldap/ldap.conf to turn off GSS-SPNEGO
encryption:

sasl_secprops minssf=0,maxssf=0

AD whines as so:

# ldapsearch   -Y GSS-SPNEGO -H  ldaps://AUSDCamer.amer.company.com -b
'dc=AMER,dc=COMPANY,dc=COM' -s sub
'(&(objectClass=user)(name=spike_white))' memberOf
SASL/GSS-SPNEGO authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
        additional info: 00002029: LdapErr: DSID-0C090582, comment: Cannot
bind using sign/seal on a connection on which TLS or SSL is in effect, data
0, v3839

which is a cryptic way to say "double encryption not allowed".

I think most any other LDAP server besides AD would allow
double-encryption.  Don't know why AD whines about it.

Spike

On Thu, Nov 14, 2024 at 11:51 AM Kodiak Firesmith via sssd-users <
[e-mail]> wrote:
> Thank you Sumit, as usual you are an invaluable resource for all things
> SSSD.  I'll install what I believe are the necessary supporting packages
> and then try once more.
> Kodiak
>
> Sent with Proton Mail secure email.
>
> On Thursday, November 14th, 2024 at 3:39 AM, Sumit Bose 
> wrote:
> > 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 'YOURCLIENTNAME$@COLLEGE.EDU'
> > 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 secure email.
> > > --
> > > _______________________________________________
> > > sssd-users mailing list -- [e-mail]
> > > To unsubscribe send an email to
>
> [e-mail]
> > > 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/[e-mail].o...
> > > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue