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.