On Fri, 14 Dec 2012 10:24:31 +0100, Jakub Hrozek <jhrozek(a)redhat.com>
wrote:
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
This is the only thing you might be interested in besides the solution
(below). Enumerate is on, and it actually seems to be working fine. There
are no errors in the log, sssd_nss doesn't die, Wireshark shows a happy
ldap search with Kerberos authentication. Maybe this has to do with using
SASL instead of a standard bind with an authtok - at any rate, you'll deal
with this or not, it's not directly relevant to my problem..
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?
SELinux is in permissive mode. I'll eventually want to get this working in
enforcing mode but for testing I turned it off. A quick summary of the
kinds of issues I'm likely to run into would be extremely helpful.
2) I assume your nsswitch.conf contains an sss module on lines
starting
with "passwd" and "group".
Yes, I should have specified that, sorry.
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.
This was a great idea, I can't believe I didn't think of strace before.
libnss_sss.so.2 was being opened, but looking in /usr/local/var/lib/sss/
for the mc/passwd and pipes/nss files, then erroring out with connection
refused due to a bad file descriptor because those files didn't exist. I
built sssd twice, once with --prefix=/usr (the build I'm actually using),
so I guess I copied the wrong version of libnss_sss over. getent now
performs as expected.
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 am still seeing this problem, however, and now it's actually a problem.
When I try to log in over ssh I successfully log in and then the connection
is immediately closed, with a /var/log/secure footprint that looks ilke
this:
sshd[2070]: pam_sss(sshd:account): Request to sssd failed. Connection
refused
sshd[2071]: fatal: Access denied for user bob by PAM account configuration
sshd[2070]: Failed password for bob from 127.0.0.1 port 57093 ssh2
I thought it might be the same problem as nss so I made doublesure to copy
the correct versions of the pam_sss library, but that didn't improve things
(though since there's really no way to restart pam, I'm not exactly sure
when library changes would get incorporated). I have tried configuring PAM
several dozen different ways over the course of this project, so I'm not
sure what's going on right now, but I believe it was last configured with
authconfig. My /etc/pam.d/password-auth-ac and system-auth-ac are below:
password-auth-ac:
#%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 optional pam_mkhomedir.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
system-auth-ac:
#%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 optional pam_mkhomedir.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
> I also see a Kerberos AS-REQ for
krbtgt/DOMAIN.NET
> (which is odd because the cache contains krbtgt/DOMAIN.NET(a)DOMAIN.NET
and
> ldap/dc.domain.net(a)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.
I am unlikely to be able to sell my boss on running code that isn't some
released version (I had enough trouble getting him to move to 1.9.3), but
I'll see what I can do. Is this a real problem that will impede
functionality, or just an annoyance?
>
> 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.
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel