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