[SSSD] new ldap users inconsistently able to auth on existing servers

Stephen Gallagher sgallagh at redhat.com
Mon Jun 20 12:35:22 UTC 2011


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110620/de059a44/attachment.sig>


More information about the sssd-devel mailing list