[SSSD] LDAPS Connection error

sssd help sssdhelp at gmail.com
Mon Nov 21 22:15:57 UTC 2011


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20111121/2bed8755/attachment.html>


More information about the sssd-devel mailing list