[SSSD] NSS not communicating with SSSD?

Jakub Hrozek jhrozek at redhat.com
Fri Dec 14 09:24:31 UTC 2012


On Thu, Dec 13, 2012 at 05:10:45PM -0800, Andrew Wygle wrote:
> 
> 
> Hello, 
> 
> I am trying to use sssd to authenticate against an Active
> Directory server. As far as I can tell (verified using Wireshark when sssd
> tries to enumerate the domain), LDAP binds are working just fine over SASL,
> and Kerberos is more-or-less happy, but whenever I do getent -s sss passwd,
> nothing is returned.>

Let's dissect the nss problem step-by-step:

getent -s sss passwd<enter> searches for all users in the whole
directory. That is not enabled by default in the SSSD, you need to set
enumerate=true in the config file to be able to enumerate all users. I'd
suggest to try getent -s sss passwd $username. Also, chances are that
the SSSD is broken in 1.9.3 wrt enumeration, see upstream ticket
https://fedorahosted.org/sssd/ticket/1702

1) if you're using 1.9.3 on 6.3, chances are that you are running into
SELinux problems due to the new memcache feature. Can you check logs for
AVC denials or temporarily switch SELinux to permissive and test again?

2) I assume your nsswitch.conf contains an sss module on lines starting
with "passwd" and "group".

3) if you strace getent -s sss passwd $username, do you see the nss_sss
module being opened. strace -e open would help narrow down the output.

4) If you search for a user (maybe for one that can't be cached, even a
nonexisting one), do you see DEBUG messages in the NSS log
(/var/log/sssd/sss_nss.log)? If so, and the user is definitely not
cached, do you also see requests propagating to the domain log?
(/var/log/sssd/sssd_$domain.log)

Hopefully we'll be able to see what's going on with the above info.

> Wireshark shows no attempts to communicate with, well,
> anything. There are no reports in the sssd_domain log or sssd_nss log. When
> I attempt to log in via ssh using a username that doesn't exist locally, I
> see the following in /var/log/secure: 
> 
> sshd[1381]: Invalid user bob from
> 127.0.0.1
> sshd[1382]: input_userauth_request: invalid user bob
> sshd[1381]:
> pam_unix(sshd:auth): check pass; user unknown
> sshd[1381]:
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh
> ruser= rhost=client.domain.net
> sshd[1381]: pam_succeed_if(sshd:auth): error
> retrieving information about user bob
> sshd[1381]: Failed password for
> invalid user bob from 127.0.0.1 port 56849 ssh2
> sshd[1382]: Connection
> closed by 127.0.0.1 
> 

I would like to fix the NSS issue first, chances are it's causing the
above error messages from PAM as well. Did you configure your PAM stack
manually or using authconfig? Do you see pam_sss being contacted in
/var/log/secure at all?

> I also see a Kerberos AS-REQ for krbtgt/DOMAIN.NET
> (which is odd because the cache contains krbtgt/DOMAIN.NET at DOMAIN.NET and
> ldap/dc.domain.net at DOMAIN.NET already), which is rejected with a KRB-ERR
> claiming principal not found. 
> 
> Finally, I occasionally (not sure exactly
> when, but it seems to be when I try to log in with users that DO exist
> locally) see the following in /var/log/secure: 
> 
> pam_sss(sshd:session):
> Request to sssd failed. Connection refused 

Simo just posted a patch for this issue. The title of the patch is
"[PATCH] Fix pam responder handling of coalesced requests". If you could
give it a go, it would be awesome.

> 
> sssd IS running. 
> 
> This is all
> running on a Centos 6.3 machine using sssd 1.9.3, built from source. The
> 1.8.0 that ships with Centos was installed originally but has since been
> removed. All other packages are Centos latest, so probably at least a year
> out of date. 
> 
> Are there any suggestions for debugging? It almost seems
> like nss is not even bothing to ask sssd for credentials, or like sssd is
> rejecting said requests silently, or that dbus is failing to send the
> messages, or.. something. Though I do see pings for both nss and pam in the
> sssd logs, so the dbus explanation seems unlikely. 
> 
> Thank you for your
> time.



More information about the sssd-devel mailing list