[SSSD] LDAP Service Discovery Problem

Jakub Hrozek jhrozek at redhat.com
Fri May 10 15:35:36 UTC 2013


On Fri, May 10, 2013 at 11:17:16AM -0400, Simo Sorce wrote:
> 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.

I completely agree, but as I said, this is the second time this request
has came up in the last month alone. I merely think we should be
tracking it as a RFE and if somebody contributes a patch, we'll accept
it.



More information about the sssd-devel mailing list