On Fri, 2011-06-17 at 17:12 -0400, Johnny Tan wrote:
I recently setup sssd (sssd-1.2.1-39.el5) in our environment. We
have
an LDAP server running openldap-servers-2.3.43-12.el5_5.2.x86_64.
It seems that certain users can't authenticate to certain servers. All
servers have identical sssd.conf, nsswitch.conf, and system-auth-ac
files (pushed by puppet). I haven't yet found a pattern as to which
users and which servers, as it seems to be random.
I've included a couple config files.
== sssd.conf begin ==
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = LDAP
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
reconnection_retries = 3
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307
ldap_uri = ldap://xxxxxxxxxxx/
ldap_search_base = dc=renttherunway,dc=com
ldap_id_use_start_tls = true
ldap_tls_reqcert = never
cache_credentials = true
enumerate = true
== sssd.conf end ==
...
My own hypothesis is that the successful auth is using cached
credentials (since jt has logged in previously), but the failed one is
from a user that has not successfully logged into the server. But if
I'm correct, what I don't get is why sssd cannot pull information from
the LDAP provider. It's online and serving out requests, and the
failed user on this machine has successfully logged in for the first
time on a couple other servers in the same timeframe.
Unfortunately, these logs aren't sufficient to track down the problem.
We need the sssd_LDAP.log to see what's going on. sssd_pam.log only
shows the activity in the PAM responder (which is agnostic of the
auth_provider implemented).
(Fri Jun 17 21:07:25 2011)
[sssd[pam]][sysdb_cache_auth_get_attrs_done](4): Cached credentials not
available.
This indicates that your hypothesis is probably correct. For one reason
or another, the SSSD is operating in offline mode, and because the user
has not previously logged in, they are not being granted access via
cached credentials. sssd_LDAP.log will allow us to see why the
connection is being considered offline.