Hi,
I am new to LDAP. The company's IT own LDAP server, I tried to configure openldap client but failed. My OS is CentOS 7, openldap is 2.4.39.
I configured ldap and ldaps. I can use ldapsearch to find out full ldap info of my LDAP account. I configured with authconfig-tui. I also modified /etc/pam.d/system-auth and password-auth, change pam_sss.so to pam_ldap.so. While when I tried getent passwd, I can only find local users. I cannot su to my LDAP account. Why?
I google online it looks like CentOS 7 has problem to configure ldap client. Cent0S 7 does not have pam_ldap module. But I can find pam_ldap.so in the system. What should I do to fix it? Switch to CentOS 6.6?
Your help is really appreciated! Thank you!
Yingbo
On Tue, Apr 28, 2015 at 07:49:07PM +0000, Yingbo Li wrote:
I am new to LDAP. The company’s IT own LDAP server, I tried to configure openldap client but failed. My OS is CentOS 7, openldap is 2.4.39.
I configured ldap and ldaps. I can use ldapsearch to find out full ldap info of my LDAP account. I configured with authconfig-tui. I also modified /etc/pam.d/ system-auth and password-auth, change pam_sss.so to pam_ldap.so. While when I tried getent passwd, I can only find local users. I cannot su to my LDAP account. Why?
You have probably messed up the config by making those changes. CentOS 7 expects to use SSSD to access LDAP: it provides useful services and isolates system processes from the LDAP service so you should not try to bypass it.
Lots of useful information here:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm...
Rather than editing config files directly, try to get a basic system running by using the authconfig command. This should make sure that you have a consistent setup. Better still, select LDAP authentication when you install the system and let the install wizard help you through the process.
If your LDAP service places size limits or restrictive access-control on the data you may need to create an account for SSSD to bind with so that it can bypass the limits.
This is not really an OpenLDAP problem, so you are likely to get more detailed help on a Red Hat or CentOS mailing list or forum.
Andrew
Findlay,
Thanks for your help! But the problem is not addressed. On centOS 6 and 7 I test "getent passwd yli28". The same result, no ouput. On my own ldap client server env, both cnetos 6.6, it works. I started sssd on client. It did not work. Then I start nscd. It still not work.
I would like to list all my configurations here: /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.91.96.141 LVD-LDAP-C6IT hostname 10.91.96.142 LDV-LDAP-CENT6
/etc/openldap/ldap.conf # # LDAP Defaults #
# See ldap.conf(5) for details # This file should be world readable but not world writable.
BASE ou=people,dc=ra-int,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 URI ldap://usmkemsi107.ra-int.com #URI 10.91.96.142 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never
TLS_CACERTDIR /etc/openldap/cacerts
/etc/nsswitch.conf (All sss were replaced by ldap. Both did not work)
passwd: files ldap shadow: files ldap group: files ldap
#hosts: db files nisplus nis dns hosts: files dns
# Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files
bootparams: nisplus [NOTFOUND=return] files
ethers: files netmasks: files networks: files protocols: files rpc: files services: files ldap
netgroup: files ldap
publickey: nisplus
automount: files ldap aliases: files nisplus
/etc/sssd/sssd.conf [domain/default]
autofs_provider = ldap cache_credentials = True ldap_search_base = ou=people,dc=ra-int,dc=com krb5_realm = EXAMPLE.COM krb5_server = kerberos.example.com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://usmkemsi107.ra-int.com ldap_id_use_start_tls = False ldap_tls_cacertdir = /etc/openldap/cacerts [sssd] services = nss, pam, autofs config_file_version = 2 enumerate = true
domains = default [nss] homedir_substring = /home
[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
/etc/pam.d/system-auth
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
/etc/pam.d/password-auth
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
Yesterday, I configured LDAP authentication on Artifactory (a repository software) on centos 7. It works. I use ldapsearch -x -D binddn_username -w password "samaccount=yli28". It works.
I really do not know what else can I do to make getent work. Then I can su yli28.
If you find anything wrong, please let me know. I can only configure the client side, the LDAP server controlled by IT.
Thank you! Yingbo
-----Original Message----- From: Andrew Findlay [mailto:andrew.findlay@skills-1st.co.uk] Sent: Wednesday, April 29, 2015 4:39 AM To: Yingbo Li Cc: openldap-technical@openldap.org Subject: Re: getent passwd only catch local user passwd
On Tue, Apr 28, 2015 at 07:49:07PM +0000, Yingbo Li wrote:
I am new to LDAP. The company’s IT own LDAP server, I tried to configure openldap client but failed. My OS is CentOS 7, openldap is 2.4.39.
I configured ldap and ldaps. I can use ldapsearch to find out full ldap info of my LDAP account. I configured with authconfig-tui. I also modified /etc/pam.d/ system-auth and password-auth, change pam_sss.so to pam_ldap.so. While when I tried getent passwd, I can only find local users. I cannot su to my LDAP account. Why?
You have probably messed up the config by making those changes. CentOS 7 expects to use SSSD to access LDAP: it provides useful services and isolates system processes from the LDAP service so you should not try to bypass it.
Lots of useful information here:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm...
Rather than editing config files directly, try to get a basic system running by using the authconfig command. This should make sure that you have a consistent setup. Better still, select LDAP authentication when you install the system and let the install wizard help you through the process.
If your LDAP service places size limits or restrictive access-control on the data you may need to create an account for SSSD to bind with so that it can bypass the limits.
This is not really an OpenLDAP problem, so you are likely to get more detailed help on a Red Hat or CentOS mailing list or forum.
Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
On 30/04/2015 02:06, Yingbo Li wrote:
/etc/nsswitch.conf (All sss were replaced by ldap. Both did not work)
passwd: files ldap shadow: files ldap group: files ldap
If you're using sssd then this is definitely wrong, replace 'ldap' with 'sss' again.
Are you sure that sssd is running?
On Thu, Apr 30, 2015 at 01:06:54AM +0000, Yingbo Li wrote:
If you find anything wrong, please let me know. I can only configure the client side, the LDAP server controlled by IT.
You need to find out what each component in the stack is doing. If you have access to the LDAP server logs, try looking there to see what operations are performed. If not, consider setting up your own LDAP server so that you can run it at a high log-level.
Another way to check LDAP operations is to use tcpdump and/or wireshark to capture and analyse network traffic. You will need to disable TLS for that to be useful.
There is a fair amount of advice about debugging SSSD issues on the web, e.g.:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm... https://fedoraproject.org/wiki/How_to_debug_SSSD_problems
I would advise turning OFF nscd. It is not helpful when sssd is in use, and can cause great confusion and problems of its own.
Andrew
On 30.04.2015 13:56, Andrew Findlay wrote:
On Thu, Apr 30, 2015 at 01:06:54AM +0000, Yingbo Li wrote:
If you find anything wrong, please let me know. I can only configure the client side, the LDAP server controlled by IT.
You need to find out what each component in the stack is doing. If you have access to the LDAP server logs, try looking there to see what operations are performed. If not, consider setting up your own LDAP server so that you can run it at a high log-level.
Another way to check LDAP operations is to use tcpdump and/or wireshark to capture and analyse network traffic. You will need to disable TLS for that to be useful.
There is a fair amount of advice about debugging SSSD issues on the web, e.g.:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm... https://fedoraproject.org/wiki/How_to_debug_SSSD_problems
There's also (fairly recent) https://fedorahosted.org/sssd/wiki/Troubleshooting
Either way, I suspect this thread is off-topic for this list. The sssd-users list might be a better match: https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I would advise turning OFF nscd. It is not helpful when sssd is in use, and can cause great confusion and problems of its own.
Andrew
Thanks for the instructions. In nsswitch.conf I switched back from ladp to sss and restared sssd. No nscd started. In sssd.conf, I add debug_level=4 in each section. I ran "getent passwd yli28". Still not output.
Here are the error messages from sssd log files /var/log/sssd/sssd_default.log
(Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=yli28] (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level t o [4] (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'usmkemsi107.ra-int. com' as 'working' (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server 'usmkemsi107.ra-int.com' a s 'working' (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap: Operations error(1), 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed o n the connection., data 0, v1db1 (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_get_generic_done] (0x0100): sdap_get_generic_ext_recv failed [5]: Input/ output error (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_get_users_done] (0x0040): Failed to retrieve users (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level t o [4] (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'usmkemsi107.ra-int. com' as 'working' (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server 'usmkemsi107.ra-int.com' a s 'working' (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap: Operations error(1), 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed o n the connection., data 0, v1db1 (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_get_generic_done] (0x0100): sdap_get_generic_ext_recv failed [5]: Input/ output error (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_get_users_done] (0x0040): Failed to retrieve users (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,5,User lookup fail ed ::::::::::::::
/var/log/sssd/sssd_nss.log
(Thu Apr 30 10:17:56 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [yli28] from [<ALL>] (Thu Apr 30 10:17:56 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [yli28@default] (Thu Apr 30 10:17:56 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider Error: 3, 5, User lookup failed Will try to return what we have in cache
It looks like binddn and bindpw should be set. It seems that IT LDAP server request for binddn and bindpw for getent operation. In my local test env, ldap server did request binddn and bindpw from ladp client getent operation. It works. But Howard Chu said in OpenLDAP, ldap.conf file cannot set binddn and bindpw. Ldapsearch I can use -D -w to set binddn and bindpw. What else can I do to make getent work?
Thanks, Yingbo
-----Original Message----- From: Andrew Findlay [mailto:andrew.findlay@skills-1st.co.uk] Sent: Thursday, April 30, 2015 6:56 AM To: Yingbo Li Cc: openldap-technical@openldap.org Subject: Re: getent passwd only catch local user passwd
On Thu, Apr 30, 2015 at 01:06:54AM +0000, Yingbo Li wrote:
If you find anything wrong, please let me know. I can only configure the client side, the LDAP server controlled by IT.
You need to find out what each component in the stack is doing. If you have access to the LDAP server logs, try looking there to see what operations are performed. If not, consider setting up your own LDAP server so that you can run it at a high log-level.
Another way to check LDAP operations is to use tcpdump and/or wireshark to capture and analyse network traffic. You will need to disable TLS for that to be useful.
There is a fair amount of advice about debugging SSSD issues on the web, e.g.:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm... https://fedoraproject.org/wiki/How_to_debug_SSSD_problems
I would advise turning OFF nscd. It is not helpful when sssd is in use, and can cause great confusion and problems of its own.
Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
On 30/04/2015 17:09, Yingbo Li wrote:
It looks like binddn and bindpw should be set. It seems that IT LDAP server request for binddn and bindpw for getent operation. In my local test env, ldap server did request binddn and bindpw from ladp client getent operation. It works. But Howard Chu said in OpenLDAP, ldap.conf file cannot set binddn and bindpw. Ldapsearch I can use -D -w to set binddn and bindpw. What else can I do to make getent work?
ldap.conf doesn't come into it. You need to tell sssd how to bind to your LDAP server.
Use the following three directives in sssd.conf within your [domain/default] section:
ldap_default_bind_dn = <dn to bind as> ldap_default_authtok_type = password ldap_default_authtok = <dn password>
Look at the man page for sssd.conf for more information about these.
Liam Gretton wrote:
On 30/04/2015 17:09, Yingbo Li wrote:
It looks like binddn and bindpw should be set. It seems that IT LDAP server request for binddn and bindpw for getent operation. In my local test env, ldap server did request binddn and bindpw from ladp client getent operation. It works. But Howard Chu said in OpenLDAP, ldap.conf file cannot set binddn and bindpw. Ldapsearch I can use -D -w to set binddn and bindpw. What else can I do to make getent work?
ldap.conf doesn't come into it. You need to tell sssd how to bind to your LDAP server.
Use the following three directives in sssd.conf within your [domain/default] section:
ldap_default_bind_dn = <dn to bind as> ldap_default_authtok_type = password ldap_default_authtok = <dn password>
Look at the man page for sssd.conf for more information about these.
And on that note - please direct further discussion to an SSSD-oriented forum.
On Thu, Apr 30, 2015 at 04:09:23PM +0000, Yingbo Li wrote:
(Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap: Operations error(1), 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed o n the connection., data 0, v1db1 (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_get_generic_done] (0x0100): sdap_get_generic_ext_recv failed [5]: Input/ output error
It looks like binddn and bindpw should be set.
Exactly.
But Howard Chu said in OpenLDAP, ldap.conf file cannot set binddn and bindpw. Ldapsearch I can use -D -w to set binddn and bindpw. What else can I do to make getent work?
It is SSSD that is making the LDAP connection, so you should be setting the DN and password in sssd.conf - look for the domain/default section and set values for:
ldap_default_bind_dn ldap_default_authtok
You should check first with ldapsearch to make sure that the DN and password are valid and that they allow you to do the searches that SSSD will need.
Andrew
Liam, Andrew,
After I set the binddn and bindpw in sssd.conf and restart sssd. It still cannot find anything, but the Return code is 0,0,success.
ldap_default_bind_dn = <dn to bind as> ldap_default_authtok_type = password ldap_default_authtok = <dn password>
It return 0, 0. But still can find nothing.
/var/log/sssd/sssd_default.log
(Thu Apr 30 11:51:53 2015) [sssd[be[default]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Thu Apr 30 11:51:53 2015) [sssd[be[default]]] [simple_bind_send] (0x0100): Executing simple bind as: svc_na_lvd_cont_int (Thu Apr 30 11:51:53 2015) [sssd[be[default]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'usmkemsi107.ra-int. com' as 'working' (Thu Apr 30 11:51:53 2015) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server 'usmkemsi107.ra-int.com' a s 'working' (Thu Apr 30 11:51:53 2015) [sssd[be[default]]] [sdap_get_users_done] (0x0040): Failed to retrieve users (Thu Apr 30 11:51:53 2015) [sssd[be[default]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu Apr 30 11:56:20 2015) [sssd[be[default]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=yingbo li] (Thu Apr 30 11:56:20 2015) [sssd[be[default]]] [sdap_get_users_done] (0x0040): Failed to retrieve users (Thu Apr 30 11:56:20 2015) [sssd[be[default]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu Apr 30 11:56:28 2015) [sssd[be[default]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=yingbo] (Thu Apr 30 11:56:28 2015) [sssd[be[default]]] [sdap_get_users_done] (0x0040): Failed to retrieve users (Thu Apr 30 11:56:28 2015) [sssd[be[default]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu Apr 30 11:57:39 2015) [sssd[be[default]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=Yingbo Li] (Thu Apr 30 11:57:39 2015) [sssd[be[default]]] [sdap_get_users_done] (0x0040): Failed to retrieve users (Thu Apr 30 11:57:39 2015) [sssd[be[default]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success
/var/log/sssd_nss.log
(Thu Apr 30 12:22:26 2015) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success (Thu Apr 30 12:22:26 2015) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/default/givenna me=yingbo] (Thu Apr 30 12:22:26 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [givenname=yingbo@default] (Thu Apr 30 12:22:26 2015) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1a36330
(Thu Apr 30 12:22:26 2015) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1a363e0
(Thu Apr 30 12:22:26 2015) [sssd[nss]] [ldb] (0x4000): Running timer event 0x1a36330 "ltdb_callback"
(Thu Apr 30 12:22:26 2015) [sssd[nss]] [ldb] (0x4000): Destroying timer event 0x1a363e0 "ltdb_timeout"
(Thu Apr 30 12:22:26 2015) [sssd[nss]] [ldb] (0x4000): Ending timer event 0x1a36330 "ltdb_callback"
I tried "getent passwd name", here the name I tried Yingbo, Yingbo Li, Yingbo, givenname=yingbo, yli28. All cannot find any result. If I use getent passwd, I can find a lot of local users even I did not choose local sufficient at authconfig-tui. Strang! But ldapsearch -x -D binddn -w bindpw "givenname=Yingbo" or "samaccountname=yli28" find everything.
Do you think IT set something on LDAP server side?
Thanks, Yingbo
-----Original Message----- From: Andrew Findlay [mailto:andrew.findlay@skills-1st.co.uk] Sent: Thursday, April 30, 2015 12:00 PM To: Yingbo Li Cc: openldap-technical@openldap.org Subject: Re: getent passwd only catch local user passwd
On Thu, Apr 30, 2015 at 04:09:23PM +0000, Yingbo Li wrote:
(Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap: Operations error(1), 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed o n the connection., data 0, v1db1 (Thu Apr 30 10:17:56 2015) [sssd[be[default]]] [sdap_get_generic_done] (0x0100): sdap_get_generic_ext_recv failed [5]: Input/ output error
It looks like binddn and bindpw should be set.
Exactly.
But Howard Chu said in OpenLDAP, ldap.conf file cannot set binddn and bindpw. Ldapsearch I can use -D -w to set binddn and bindpw. What else can I do to make getent work?
It is SSSD that is making the LDAP connection, so you should be setting the DN and password in sssd.conf - look for the domain/default section and set values for:
ldap_default_bind_dn ldap_default_authtok
You should check first with ldapsearch to make sure that the DN and password are valid and that they allow you to do the searches that SSSD will need.
Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
openldap-technical@openldap.org