I was unable to find a way of searching the current SSSD archives in development but I found the following issue in an attempt to combine SASL (Kerberos) and LDAP service discovery.
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.
In order for LDAP and Kerberos service discovery to work there needs to be the following basic records in the configured DNS (where kerberos.my-domain.com and ldap.my-domain.com are the two servers in question):
$ORIGIN my-domain.com _kerberos TXT "MY-DOMAIN.COM" _kerberos._udp SRV 0 0 88 kerberos _kerberos-master._udp SRV 0 0 88 kerberos _kerberos-adm._tcp SRV 0 0 749 kerberos _kpasswd._tcp SRV 0 0 464 kerberos _kpasswd._udp SRV 0 0 464 kerberos
_ldap._tcp SRV 0 0 636 ldap
The SSSD client appears to perform DNS discovery just fine:
(Thu May 9 11:54:53 2013) [sssd[be[default]]] [sssm_ldap_id_init] (0x1000): Service name for discovery set to ldap (Thu May 9 11:54:53 2013) [sssd[be[default]]] [fo_new_service] (0x0400): Creating new service 'LDAP' (Thu May 9 11:54:53 2013) [sssd[be[default]]] [sdap_service_init] (0x0100): No primary servers defined, using service discovery (Thu May 9 11:54:53 2013) [sssd[be[default]]] [fo_add_srv_server] (0x0400): Adding new SRV server to service 'LDAP' using 'tcp'. (Thu May 9 11:54:53 2013) [sssd[be[default]]] [fo_new_service] (0x0400): Creating new service 'KERBEROS' (Thu May 9 11:54:53 2013) [sssd[be[default]]] [krb5_service_init] (0x0100): No primary servers defined, using service discovery (Thu May 9 11:54:53 2013) [sssd[be[default]]] [fo_add_srv_server] (0x0400): Adding new SRV server to service 'KERBEROS' using 'udp'. (Thu May 9 11:54:53 2013) [sssd[be[default]]] [fo_add_srv_server] (0x0400): Adding new SRV server to service 'KERBEROS' using 'tcp'. (Thu May 9 11:54:53 2013) [sssd[be[default]]] [krb5_servers_init] (0x0400): Added service lookup
.... And then later when I attempt to lookup user information (id fred). It successfully finds the services:
(Thu May 9 11:57:03 2013) [sssd[be[default]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Thu May 9 11:57:03 2013) [sssd[be[default]]] [get_port_status] (0x1000): Port status of port 0 for server '(no name)' is 'neutral' (Thu May 9 11:57:03 2013) [sssd[be[default]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Thu May 9 11:57:03 2013) [sssd[be[default]]] [resolve_srv_send] (0x0200): The status of SRV lookup is neutral (Thu May 9 11:57:03 2013) [sssd[be[default]]] [resolve_srv_send] (0x0400): SRV resolution of service 'LDAP'. dns_discovery_domain not specified. Need to look it up. (Thu May 9 11:57:03 2013) [sssd[be[default]]] [resolve_get_domain_send] (0x1000): Host name is: ldap.my-domain.com (Thu May 9 11:57:03 2013) [sssd[be[default]]] [resolv_is_address] (0x4000): [ldap.my-domain.com] does not look like an IP address (Thu May 9 11:57:03 2013) [sssd[be[default]]] [resolv_gethostbyname_step] (0x2000): Querying files (Thu May 9 11:57:03 2013) [sssd[be[default]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of ' ldap.my-domain.com' in files (Thu May 9 11:57:03 2013) [sssd[be[default]]] [resolv_gethostbyname_step] (0x2000): Querying files (Thu May 9 11:57:03 2013) [sssd[be[default]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'ldap.my-domain.com' in files (Thu May 9 11:57:03 2013) [sssd[be[default]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry (Thu May 9 11:57:03 2013) [sssd[be[default]]] [resolv_gethostbyname_step] (0x2000): Querying DNS (Thu May 9 11:57:03 2013) [sssd[be[default]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of ' ldap.my-domain.com' in DNS (Thu May 9 11:57:03 2013) [sssd[be[default]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 5 seconds (Thu May 9 11:57:03 2013) [sssd[be[default]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Thu May 9 11:57:03 2013) [sssd[be[default]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Thu May 9 11:57:03 2013) [sssd[be[default]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply (Thu May 9 11:57:03 2013) [sssd[be[default]]] [request_watch_destructor] (0x0400): Deleting request watch And Kerberos DNS discovery works... (Thu May 9 12:04:30 2013) [sssd[be[default]]] [resolve_srv_cont] (0x0100): Searching for servers via SRV query '_KERBEROS._udp.my-domain.com' (Thu May 9 12:04:30 2013) [sssd[be[default]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_KERBEROS._udp.my-domain.com' (Thu May 9 12:04:30 2013) [sssd[be[default]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 5 seconds (Thu May 9 12:04:30 2013) [sssd[be[default]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Thu May 9 12:04:30 2013) [sssd[be[default]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Thu May 9 12:04:30 2013) [sssd[be[default]]] [request_watch_destructor] (0x0400): Deleting request watch (Thu May 9 12:04:30 2013) [sssd[be[default]]] [resolve_srv_done] (0x0400): Inserted server 'kerberos.my-domain.com:88' for service KERBEROS (Thu May 9 12:04:30 2013) [sssd[be[default]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'KERBEROS' as 'resolved' (Thu May 9 12:04:30 2013) [sssd[be[default]]] [get_server_status] (0x1000): Status of server 'kerberos.my-domain.com' is 'name not resolved' (Thu May 9 12:04:30 2013) [sssd[be[default]]] [resolv_is_address] (0x4000): [kerberos.my-domain.com] does not look like an IP address (Thu May 9 12:04:30 2013) [sssd[be[default]]] [resolv_gethostbyname_step] (0x2000): Querying files (Thu May 9 12:04:30 2013) [sssd[be[default]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of ' kerberos.my-domain.com' in files (Thu May 9 12:04:30 2013) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server 'kerberos.my-domain.com' as 'resolving name' (Thu May 9 12:04:30 2013) [sssd[be[default]]] [resolv_gethostbyname_step] (0x2000): Querying files (Thu May 9 12:04:30 2013) [sssd[be[default]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'kerberos.my-domain.com' in files (Thu May 9 12:04:30 2013) [sssd[be[default]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry (Thu May 9 12:04:30 2013) [sssd[be[default]]] [resolv_gethostbyname_step] (0x2000): Querying DNS (Thu May 9 12:04:30 2013) [sssd[be[default]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of ' kerberos.my-domain.com' in DNS
But refuses to construct the URI for LDAP in the discovery service as *ldaps * (which is correct!) and instead makes it regular old *ldap* which is bound to fail.
(Thu May 9 12:04:30 2013) [sssd[be[default]]] [sdap_uri_callback] (0x0400): Constructed uri 'ldap://ldap.my-domain.com:636' (Thu May 9 12:04:30 2013) [sssd[be[default]]] [sss_ldap_init_send] (0x4000): Using file descriptor [22] for LDAP connection. (Thu May 9 12:04:30 2013) [sssd[be[default]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Thu May 9 12:04:30 2013) [sssd[be[default]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap:// ldap.my-domain.com:636/??base] with fd [22]. (Thu May 9 12:04:30 2013) [sssd[be[default]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse
My thought was to change my SRV record from _ldap (the service name) to _ldaps but then Service Discovery in SSSD doesn't find an LDAP server!
Any suggestions?
The bad part is with this current configuration it also causes a SEGFAULT in libldap (insult to injury) which it appears to happen right after the attempt to connect to the wrongly constructed LDAP URI:
May 9 12:04:31 ldap kernel: sssd_be[10292]: segfault at 20 ip 0000003e51218561 sp 00007fffd49ef310 error 4 in libldap-2.4.so.2.5.6[3e51200000+49000] May 9 12:04:31 ldap abrt[10301]: Can't open /proc/10292/status: No such file or directory May 9 12:04:31 ldap sssd[be[default]]: Starting up
Versions - *Kernel:* Linux ldap.my-domain.com 2.6.32-358.6.1.el6.x86_64 #1 SMP Fri Mar 29 16:51:51 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
*SSSD:* sssd.x86_64 1.9.2-82.7.el6_4 sssd-client.x86_64 1.9.2-82.7.el6_4
Here's my /etc/sssd/sssd.conf file: [domain/default] debug_level = 0xFFF0
ldap_krb5_init_creds = true ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/ldap.my-domain.com
ldap_id_use_start_tls = false cache_credentials = True ldap_search_base = dc=my-domain,dc=com krb5_realm = MY-DOMAIN.COM id_provider = ldap auth_provider = krb5 chpass_provider = krb5 krb5_kpasswd = kerberos.my-domain.com [sssd] config_file_version = 2 services = nss, pam domains = default
[nss]
[pam]
Note: There is a valid Kerberos key in /etc/krb5.keytab for host/ ldap.my-domain.com and krb5.conf is configured with the realm MY-DOMAIN.COM
Joshua Riffle Software Engineer *Azusa Pacific University*
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.
_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.
My thought was to change my SRV record from _ldap (the service name) to _ldaps but then Service Discovery in SSSD doesn't find an LDAP server!
I'm not clear that there *is* an approved way to autodiscover ldaps.
Any suggestions?
Do you have a really strong and sound reason to want SSL?
Just use GSSAPI and point it at your plain LDAP port, and peer at the wireshark traces to see just how non-plain the traffic is.
jh
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
My thought was to change my SRV record from _ldap (the service name) to _ldaps but then Service Discovery in SSSD doesn't find an LDAP server!
I'm not clear that there *is* an approved way to autodiscover ldaps.
Any suggestions?
Do you have a really strong and sound reason to want SSL?
Just use GSSAPI and point it at your plain LDAP port, and peer at the wireshark traces to see just how non-plain the traffic is.
jh
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
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.
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.
This is all great feedback. Thanks everyone. I'm trying to figure out how to grab a copy of the SEGFAULT core for SSSD which I will provide as an attachment back to this conversation when I figure out how to extract it.
I noticed that providers/ldap/ldap_common.c:855 automatically uses SSS_LDAP_SRV_NAME to construct the LDAP uri on discovery which is statically set (providers/ldap/ldap_common.h:36) to "ldap" and is very problematic if ldap is supposed to be ldaps in the uri.
Why this combination might lead to a SEGFAULT is still a bit of a mystery to me so I'll try to find the additional troubleshooting information.
As pointed out to me in a couple of the other responses TLS and not SSL is probably the better way to go which is surprising to me but admittedly I am new to the LDAP security world and that will give me something to research more deeply. Does SSSD cater more to the TLS + LDAP combination?
My hope was to see how far I could get with a fairly secure Kerberos + LDAP combination that could (mostly) automatically be pushed to the clients (SSSD) with as little configuration as possible. Initially LDAPS seemed to make sense and SRV records for DNS Discovery also seemed like a decent choice.
Joshua Riffle Software Engineer *Azusa Pacific University*
On Fri, May 10, 2013 at 8:17 AM, Simo Sorce simo@redhat.com 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.
-- Simo Sorce * Red Hat, Inc * New York
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Fri, 10 May 2013, Joshua Riffle wrote:
As pointed out to me in a couple of the other responses TLS and not SSL is probably the better way to go which is surprising to me but admittedly I am new to the LDAP security world and that will give me something to research more deeply. Does SSSD cater more to the TLS + LDAP combination?
I think this is just a general truism. You end up with a single service on a single port that allows connections at an appropriate security level as defined in rules server side. TLS is the successor to SSL.
My hope was to see how far I could get with a fairly secure Kerberos + LDAP combination that could (mostly) automatically be pushed to the clients (SSSD) with as little configuration as possible. Initially LDAPS seemed to make sense and SRV records for DNS Discovery also seemed like a decent choice.
I think you're basically spot on, apart from your choice of SSL over TLS. Service Discovery is *clearly* the way to go IMO.
Feel free to ask about anything else, minimal configuration LDAP(TLS) + krb5 is the setup I use, albeit against Active Directory.
jh
sssd-devel@lists.fedorahosted.org