Hi List,
Any help here would be appreciated.
We've been using SSSD (1.2) on RHEL6 for a while without issue. We are trying to make the move to RHEL6.1 and newer packages of SSSD (1.5.1) and we are running into some problems.
For some reason the client doesnt seem to want to connect to our ldap server using LDAPS. See the following log output:
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_id_op_connect_step] (9): beginning to connect (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP' (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [get_server_status] (7): Status of server 'ldap.example.com' is 'name not resolved' (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [get_server_status] (4): Hostname resolution expired, reseting the server status of 'ldap.example.com ' (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [set_server_common_status] (4): Marking server 'ldap.example.com' as 'name not resolved' (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [get_port_status] (7): Port status of port 636 for server 'ldap.example.com' is 'neutral' (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [get_server_status] (7): Status of server 'ldap.example.com' is 'name not resolved' (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [resolv_gethostbyname_send] (4): Trying to resolve A record of 'ldap.example.com' (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [schedule_timeout_watcher] (9): Scheduling DNS timeout watcher (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [set_server_common_status] (4): Marking server 'ldap.example.com' as 'resolving name' (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [unschedule_timeout_watcher] (9): Unscheduling DNS timeout watcher (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [set_server_common_status] (4): Marking server 'ldap.example.com' as 'name resolved' (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [be_resolve_server_done] (4): Found address for server ldap.example.com: [10.17.8.103] (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_uri_callback] (6): Constructed uri 'ldaps://ldap.example.com/' (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_rootdse_send] (9): Getting rootdse (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(objectclass=*)][]. (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [*] (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [altServer] (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [namingContexts] (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [supportedControl] (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [supportedExtension] (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [supportedFeatures] (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [supportedLDAPVersion] (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [supportedSASLMechanisms] (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [defaultNamingContext] (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [lastUSN] (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [highestCommittedUSN] (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_ldap_connect_callback_add] (9): New LDAP connection to [ldaps:// ldap.example.com:636] with fd [25]. (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (3): ldap_search_ext failed: Can't contact LDAP server (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (3): Connection error: (null) (Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [fo_set_port_status] (4): Marking port 636 of server 'ldap.example.com' as 'not working'
Please also see the following sssd.conf:
[sssd] config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30 services = nss, pam #services = pam
domains = default [nss] filter_groups = root filter_users = root reconnection_retries = 3
[pam] reconnection_retries = 3
[domain/default] ldap_tls_reqcert = never auth_provider = ldap ldap_id_use_start_tls = False chpass_provider = ldap enumerate = True cache_credentials = True ldap_group_search_base = ou=posixGroups,dc=example,dc=com ldap_user_search_base = ou=People,dc=example,dc=com ldap_default_authtok_type = password ldap_search_base = dc=example,dc=com debug_level = 20 id_provider = ldap ldap_default_bind_dn = uid=binduser,ou=Special Users,dc=example,dc=com ldap_user_gecos = cn ldap_uri = ldaps://ldap.example.com/ ldap_default_authtok = password ldap_tls_cacertdir = /etc/ssl/certs
This is the very same config we use on RHEL6 with sssd 1.2. I also tried porting the older sssd build onto this machine and got the same results.
Please note that TLS is not an option in our case because we are performing an ssl offload on a hardware load balancer that cannot handle TLS.
This mailing list has been extremely helpful in the past and i hope it is so again. Thank you
Brandon
On Mon, Nov 21, 2011 at 05:15:57PM -0500, sssd help wrote:
Hi List,
Any help here would be appreciated.
We've been using SSSD (1.2) on RHEL6 for a while without issue. We are trying to make the move to RHEL6.1 and newer packages of SSSD (1.5.1) and we are running into some problems.
What exact version are you running now? 1.5.1-34 ?
Thanks for the response Jakub,
I meant to update this last night. In my testing I installed openldap-clients and attempted to do manual ldap searches. LDAPS lookups were failing but LDAP lookups were fine. I noticed that our RHEL6 machines were running a different version of openldap than our 6.1 machines. RHEL6 was running openldap-2.4.19 and RHEL6.1 was running openldap-2.4.34. That turned out to be the issue. I rolled back the version of openldap and SSSD 1.5.1-34 started working brilliantly.
I dont know if this is a known issue or not. It doesnt seem like a problem with SSSD, seems more like a problem with openldap, and there's a slight chance it is a custom package because this is actually Oracle Enterprise Linux 6.1 (aka rebranded RHEL6.1).
Sorry to make added noise in the mailing list but at least this will be on the tubes if anyone else runs into this issue.
Thanks again,
Brandon
On Tue, Nov 22, 2011 at 6:32 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Mon, Nov 21, 2011 at 05:15:57PM -0500, sssd help wrote:
Hi List,
Any help here would be appreciated.
We've been using SSSD (1.2) on RHEL6 for a while without issue. We are trying to make the move to RHEL6.1 and newer packages of SSSD (1.5.1)
and
we are running into some problems.
What exact version are you running now? 1.5.1-34 ? _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Tue, 22 Nov 2011, sssd help wrote:
Thanks for the response Jakub,
I meant to update this last night. In my testing I installed openldap-clients and attempted to do manual ldap searches. LDAPS lookups were failing but LDAP lookups were fine. I noticed that our RHEL6 machines were running a different version of openldap than our 6.1 machines. RHEL6 was running openldap-2.4.19 and RHEL6.1 was running openldap-2.4.34. That turned out to be the issue. I rolled back the version of openldap and SSSD 1.5.1-34 started working brilliantly.
I dont know if this is a known issue or not. It doesnt seem like a problem with SSSD, seems more like a problem with openldap, and there's a slight chance it is a custom package because this is actually Oracle Enterprise Linux 6.1 (aka rebranded RHEL6.1).
Sorry to make added noise in the mailing list but at least this will be on the tubes if anyone else runs into this issue.
Personally I wouldn't choose to run 2.4.19. Problems I was having with sssd turned out to be OpenLDAP bugs that were fixed by 2.4.23 (I /thought/ that was the release that fixed it anyway, that's what I'm running).
jh
On Tue, 2011-11-22 at 10:14 -0500, sssd help wrote:
Thanks for the response Jakub,
I meant to update this last night. In my testing I installed openldap-clients and attempted to do manual ldap searches. LDAPS lookups were failing but LDAP lookups were fine. I noticed that our RHEL6 machines were running a different version of openldap than our 6.1 machines. RHEL6 was running openldap-2.4.19 and RHEL6.1 was running openldap-2.4.34. That turned out to be the issue. I rolled back the version of openldap and SSSD 1.5.1-34 started working brilliantly.
I dont know if this is a known issue or not. It doesnt seem like a problem with SSSD, seems more like a problem with openldap, and there's a slight chance it is a custom package because this is actually Oracle Enterprise Linux 6.1 (aka rebranded RHEL6.1).
Sorry to make added noise in the mailing list but at least this will be on the tubes if anyone else runs into this issue.
RHEL 6.0 shipped with a copy of openldap that was linked against openssl. The version in RHEL 6.1 is now linked against Mozilla NSS (for certification reasons). There were a few bugs with certificate validation in early versions of 6.1, but I believe they were fixed in either the final release or errata. I'm not sure if OEL's version carries those fixes or not.
sssd-devel@lists.fedorahosted.org