[SSSD] LDAP Service Discovery Problem

Simo Sorce simo at redhat.com
Fri May 10 15:17:16 UTC 2013


On Fri, 2013-05-10 at 10:40 +0200, Jakub Hrozek wrote:
> On Fri, May 10, 2013 at 09:23:33AM +0100, John Hodrien wrote:
> > On Thu, 9 May 2013, Joshua Riffle wrote:
> > 
> > >In the case of service discovery there seems to be no way of getting LDAP to
> > >be treated as LDAPS (secure) and I think this may be leading to a
> > >segmentation fault in the sss_ldap library.
> > 
> 
> A segmentation fault? Can you get us a backtrace or a core file, please?
> Even if the functionality didn't work as expected, we should never ever
> segfault.
> 
> > >_ldap._tcp              SRV  0 0 636 ldap
> > 
> > >ldaps (which is correct!) and instead makes it regular old ldap which is
> > >bound to fail.
> > 
> > I think this is the point.  It's an LDAP record, so it'll get used as LDAP, so
> > that entry is incorrect and should point to the plain/tls port not the LDAPS
> > port.
> > 
> 
> IIRC the exact same issue came up recently on #sssd on freenode. Someone
> (Stephen perhaps?) suggested that if the port in the SRV entry was set to
> 636 we could try ldaps:// first and fall back to ldap:// instead of simply
> trying ldap:// all the time.
> 
> I'm going to file this request as an RFE, but to be honest I'd consider
> it a "nice-to-have-patch-welcome" feature rather than something that
> would be available in the next release:
> https://fedorahosted.org/sssd/ticket/1920

Keep in mind that LDAPS has been deprecated for a decade now which is
why there is also no _ldaps SRV record defined. LDAP + TLS should be
used these days.

(I do not object to trying ldaps if the port is 636 although I agree
this is a low prio RFE)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list