Latest response

I have been working on an issue with LDAP in our environment and wanted to pose a couple of questions about getting LDAP working properly on RHEL7 hosts.

We currently have a functional LDAP environment for some Unix/Solaris hosts that has been working for a while. However; at this point we do not have it running over SSL. All of the traffic is internal - and I realize this is not optimal.

However; when attempting to implement LDAP on Linux 7, I have been running into numerous issues. We had a scripted install, somewhat based off of the configuration of the other Unix/Solaris hosts.

At this point - I have one main question.. will unsecured LDAP even work with RHEL7 at all?

One of the main reasons I ask this (aside from the issues we are having) is this article I found:


The resolution for this specifc issue is: "In RHEL7 /etc/pam_ldap.conf has been deprecated. Instead of /etc/pam_ldap.conf use SSSD."

But this doesn't specifically say that 'SSSD' is required for LDAP to function, although it does lead me to suspect that it is. Even when I add "ldap_tls_reqcert = never" to the SSSD.CONF file, the logs still complain about TLS.

From the journal:

sssd[be[default]][16401]: Could not start TLS encryption. error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

sssd[be[default]][16401]: Backend is offline

And in sssd_nss.log:
[sssd[nss]] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]

I am attempting to troubleshoot this on an Oracle Enterprise Linux 7 server, although the problem is pretty much identical on our RedHat 7 hosts. I suspect the fix will be the same for both of them.

At this point - my primary question is if LDAP will work without TLS/SSL on RHEL7



Even back in the RHEL 6 days, I followed the docs and used SSSD for LDAP (which was a pretty hard transition from the non-SSSD world) - but it worked fine without SSL.

There are many parameters related to LDAP in sssd.conf; make sure none of them are asking for SSL - so make sure port 636 isn't specified, an "ldaps;//hostname..." URL/URI isn't being used. I think there is a "UseStartTLS" param, which should be set to "no".

Our environment is entirely on SSL/TLS now, but it was only switched over a couple of years ago - we definitely had RHEL 7 hosts using LDAP via SSSD and not using SSL (using both Sun/iPlanet 5.x & now Red Hat DS 10 for the LDAP server side).

Our setup is a little weird, in that we still use a legacy MIT Kerb5 realm for authentication (instead of just using the corporate Active Directory, like the rest of the world...). But "id_provider", "auth_provider" and "access_provider" are all neatly organized in sssd.conf. Here's a lightly edited version of what we run:

config_file_version = 2
reconnection_retries = 3

sbus_timeout = 30
services = nss, pam

domains = default
filter_groups = root
filter_users = root
reconnection_retries = 3

reconnection_retries = 3
enumerate = False

ldap_schema = rfc2307
ldap_rfc2307_fallback_to_local_users = True
id_provider = ldap
# this assumes a load-balancer or other HA setup; we used to use a comma-separated list of LDAP servers here:
ldap_uri = ldap://ldap.example.com
ldap_id_use_start_tls = False
# I _think_ you can skip this next line for non-SSL usage?
ldap_tls_reqcert = allow
# not necessary for non-SSL/TLS:
ldap_tls_cacertdir = /etc/openldap/certs
cache_credentials = True
ldap_default_bind_dn = uid=PosixBind,ou=Special Users,dc=example,dc=com
ldap_default_authtok = ********
ldap_search_base = ou=People,dc=example,dc=com
ldap_group_search_base = ou=groups,ou=Servers,dc=example,dc=com
ldap_group_search_scope = sub
ldap_netgroup_search_base = ou=netgroups,ou=Servers,dc=example,dc=com
chpass_provider = none
auth_provider = krb5
krb5_realm = KERB.EXAMPLE.COM
krb5_server = kerberos.example.com
# this is old: there are better ways in RHEL 7, involving the per-user /run/* directories:
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc%U_XXXXXX
krb5_auth_timeout = 15
access_provider = ldap
# only let in users "foo" or "bar": (pretty cheesy; "memberOf" is much more useful if you have it set up)
ldap_access_filter = (|(uid=foo)(uid=bar)
# this fixes some weird cases where all of the "Enumerate=False" settings seem to be ignored:
ldap_user_object_class = shadowaccount
# this really hurts, size-wise, but is the only way to log the actual LDAP queries and replies for debugging:
debug_level = 10
enumerate = False
min_id = 10

Thanks for the information! Did you point your nsswitch.conf to the SSSD or LDAP database?

nsswitch.conf points to "files sssd" for users, groups, netgroups...and maybe one other thing I've forgotten about.

"SSSD always uses an encrypted channel for authentication, which ensures that passwords are never sent over the network unencrypted."


I did eventually find that out! I was able to work around this with 'ssl=off' in the nsswitch.conf file and a few other things. It's been a while since I have had to look at this.

On another note, I have managed to make this an 'issue' - and we will be looking at implementing an encryption solution of some sort. I would agree that plain text is a bad idea.. :)

Thank You for the response and link, that will be a little more ammo to push my evil agenda of securing our authentication traffic!

Hello Robert,

I'm in the same situation, what files did you modify to make it work for you?


Hi Robert,

What sssd services do you have running besides sssd.service and what files did you modify to make your RHEL7 host communicate with old LDAP services?