1

I'm new to SSSD but I think I've configured it correctly considering id {ldap user} returns the expected uid and gid values for multiple test users. I'm using two CentOS 6.4 servers as test machines. One running ApacheDS and the other SSSD. However, when I attempt to login via ssh or directly on the console, using any one of those users, I get access denied. I've spent the last few days pouring over the SSSD logs and I'm not sure where else to look. Rather than include all of the config files I'll just say for now that I ran the following authconfig --enablesssd --enablesssdauth --enablelocauthorize --update on the client server. Check below for my SSSD config and here for SSSD_Default log. Let me know what additional logs you would like to see and I'll pull them ASAP.

Thanks for your help!

cat /etc/sssd/sssd.conf

[sssd]

config_file_version = 2
services = nss, pam
domains = default

debug_level = 4

[nss]

filter_users = root

debug_level = 4

[pam]

debug_level = 4

[domain/default]

debug_level = 4

ldap_tls_reqcert = never
auth_provider = ldap
ldap_schema = rfc2307
ldap_search_base = dc=example,dc=net
#ldap_group_member = memberUid
id_provider = ldap
ldap_id_use_start_tls = True
chpass_provider = ldap
ldap_uri = ldap://sea-ldap-01.app.example.net:10389
cache_credentials = False
ldap_tls_cacertdir = /etc/openldap/certs
ldap_tls_cacert = /etc/openldap/certs/sea-ldap-01.pem
entry_cache_timeout = 600
ldap_network_timeout = 3
#ldap_access_filter =
ldap_user_search_base = ou=people,dc=example,dc=net
ldap_group_search_base = ou=groups,dc=example,dc=net
james8562
  • 23
  • 1
  • 3
  • Thats the problem, even at 10 I can't see any errors. Thanks for the response though. Here is [default @ debug 10](http://pastebin.com/HUdYu5qA) – james8562 Jun 21 '13 at 23:06
  • The contents of `/var/log/secure` would help too. – Dennis Kaarsemaker Jun 25 '13 at 13:19
  • I dont see any errors in the pastebin.. can you set the debug level to 10 (under seed/domain) and capture the logs? – Najmuddin Jun 21 '13 at 19:12
  • @james8562 Do you see any sssd segfaults during login process, I can see PAM_AUTHENTICATE is called but no progress/errors in the logs, it is possible that SSSD (sss_pam) crashed.. Please check your /var/log/messages and see if any crashes reported. – Najmuddin Jun 24 '13 at 08:25
  • `service sssd status` reports that sssd is still running. I ran `grep -i sss /var/log/messages` and a few other combinations of strings and locations looking for crashes/errors but returned nothing. I'm wondering if I should try swapping out ApacheDS for something more common like OpenLDAP and seeing what happens. That would be a lot of work though... – james8562 Jun 24 '13 at 18:05

1 Answers1

2

According to that log, it looks like SSSD's LDAP provider crashed and had to be restarted. That's why you got access-denied.

See specifically:

(Fri Jun 21 22:42:46 2013) [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_BIND]
(Fri Jun 21 22:42:46 2013) [sssd[be[default]]] [simple_bind_done] (0x2000): Server returned control [1.3.6.1.4.1.42.2.27.8.5.1].

and then it goes to

(Fri Jun 21 22:42:46 2013) [sssd[be[default]]] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb
(Fri Jun 21 22:42:46 2013) [sssd[be[default]]] [recreate_ares_channel] (0x0100): Initializing new c-ares channel
(Fri Jun 21 22:42:46 2013) [sssd[be[default]]] [resolv_get_family_order] (0x1000): Lookup order: ipv4_first

Those lines indicate that the server is starting up again. At a guess, I'd say something went wrong while processing the ldap password policy on the client, since the last thing before it crashed was a reference to the LDAP code for the ldap_pwd_exop.

Check /var/log/messages for indications of a crash and file a bug with CentOS. Ideally, install the debuginfo for the sssd, openldap and ding-libs packages, then attach to the sssd_be process with gdb and get a backtrace of the crash to include in the bug report.

StephenGallagher
  • 36
  • 2
  • Turns out this was an issue with ApacheDS. After reading your post I decided to try swapping out the back-end and sure enough, changing to openldap allowed my test users to log in. I'll post a bug with ApacheDS. Thanks everyone for helping me get to the bottom of this! – james8562 Jun 26 '13 at 23:33