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 <
[email protected]> 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 <[email protected]>
> 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 '[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 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
>
--
_______________________________________________
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
