SASL is a "glue" between LDAP and Kerberos, that translates an identity
established through Kerberos AuthN to an LDAP Distinguished Name (among
other possible uses). When communications between Kerberos and LDAP happen,
SASL also provides encryption.

I have setup Kerberos, SASL, OpenLDAP and SSSD all on Fedora and it all
works.  I dont have to muck with SSL/TLS and the different implementations
with their specific nuances.

Though you dont know much about Kerberos, its not too difficult to
implement. You seem to have the aptitude to do so. Might just be a matter
of reading up on how to.

On Sep 29, 2017 10:00 AM, "Robert Heller" <[email protected]> wrote:

> At Fri, 29 Sep 2017 07:52:34 -0400 brendan kearney <[email protected]>
> wrote:
>
> >
> >
> > Late ti the thread, so forgive the stupid question, but why arent you
> using
> > SASL and forgoing all the OpenSSL vs MozNSS kerfuffle? If you have
> OpenLDAP
> > and SSSD going on, surely Kerberos is something you are able to setup.
>
> Does SASL replace TLS/SSL?  I thought SASL had to do with password hashing
> and
> not anything to do with the connection protocol.  I know basicly nothing
> about
> Kerberos.
>
> >
> > On Sep 29, 2017 2:20 AM, "Michael Wandel" <[email protected]> wrote:
> >
> > > On 28.09.2017 21:41, Robert Heller wrote:
> > > > Will these spit out useful error messages?  If I just get "TLS
> > > Negotiation
> > > > failure" it is not going to be helpful.
> > > >
> > >
> > > You can make it a little bit more verbose with the option "-d -1"
> > >
> > > It is only a suggestion, but can you test the parameter
> > >
> > > TLS_REQCERT allow
> > >
> > > in your /etc/openldap/ldap.conf
> > >
> > > This ist not a good option for production systems, but it seems you
> come
> > > in trouble with your certificates.
> > >
> > > You have to set your
> > >
> > > TLS_CACERT
> > > xor
> > > TLS_CACERTDIR
> > >
> > > correctly in your /etc/openldap/slapd.conf to work stressless with your
> > > ssl/tls.
> > >
> > > best regards
> > > Michael
> > >
> > > > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount <
> [email protected]>
> > > wrote:
> > > >
> > > >>
> > > >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller
> > > >> <[email protected]> wrote:
> > > >>
> > > >>
> > > >>> Slapd is reporting TLS Negotiation failure when SSSD tries to
> connect
> > > to
> > > >>> it.   For both port 389 (ldap:///) and 636 (ldaps:///).  So I guess
> > > >>> something is  wrong with slapd's TLS configuration -- it is
> failing to
> > > do
> > > >>> TLS Negotiation,  either it is just not doing it or it is doing it
> > > wrong
> > > >>> (somehow).  Unless SSSD  is not configured properly.
> > > >>
> > > >> You need to start with the following:
> > > >>
> > > >>>> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w
> > > >>
> > > >> to test startTLS
> > > >>
> > > >> and
> > > >>
> > > >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w
> > > >>
> > > >> to test without startTLS
> > > >>
> > > >> If you can get those to work, then you can move on to SSSD.
> > > >>
> > > >> --Quanah
> > > >>
> > > >> --
> > > >>
> > > >> Quanah Gibson-Mount
> > > >> Product Architect
> > > >> Symas Corporation
> > > >> Packaged, certified, and supported LDAP solutions powered by
> OpenLDAP:
> > > >> <http://www.symas.com>
> > > >>
> > > >>
> > > >
> > >
> > >
> > > --
> > > Michael Wandel
> > > Braakstraße 43
> > > 33647 Bielefeld
> > >
> > >
> >
> >
>
> --
> Robert Heller             -- 978-544-6933
> Deepwoods Software        -- Custom Software Services
> http://www.deepsoft.com/  -- Linux Administration Services
> [email protected]       -- Webhosting Services
>
>

Reply via email to