NSS not communicating with SSSD?

[Andrew Wygle]

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. 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 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 

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.

[Jakub Hrozek]

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(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.

>  
>  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.

[Andrew Wygle]

On Fri, 14 Dec 2012 10:24:31 +0100, Jakub Hrozek <jhrozek(a)redhat.com&gt;
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

[Jakub Hrozek]

On Fri, Dec 14, 2012 at 10:21:27AM -0800, Andrew Wygle wrote:
>  > 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
>   
"Connection refused" would indicate that there is nobody listening on
the other end. pam_sss is mostly just a proxy, which marshalls the incoming
request in a format the sssd_pam process expects and sends it over a
UNIX pipe to sssd_pam.

You said before that you may have misconfigured the SSSD while building
it, is there any chance that the pam_sss module is talking to a pipe that
doesn't exist? The default pipe path is "\"VARDIR\"/lib/sss/pipes"
while
VARDIR is expanded from the value of --localstatedir during configure. I
guess that "grep ^localstatedir Makefile" is a quick way to check what
the localstatedir was configured as if you still have the sources
around.

Is the sssd_pam process running? I expect there is no sign of an
incoming request in the pam log? (/var/log/sssd/sssd_pam.log)

>  
>  
>  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
>   
The PAM config files look good to me. I think they are, indeed,
generated by authconfig.

>  >> 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? 
If the sssd_be process crashed while there was a login in progress,
then the sssd_pam process wouldn't reconnect correctly and all further
connection attempts would hang.

But given that you also see connection refused with accounts that you
can resolve with getent or id now, I no longer think the patch would be
a solution to that.

[Andrew Wygle]

I was able to resolve this issue by rebuilding the libraries and copying
them over from the .libs directory. Seems they didn't get rebuilt last time
(I must have forgotten to run make clean or something). 

Now logins work with SELinux disabled (hooray!), and when it's enabled I'm
seeing those AVC denials you mentioned. I can probably figure them out
given time, but if you happen to know the solution right off the top of
your head, the error log created in /var/log/audit/audit.log is below:

  1 type=AVC msg=audit(1355522996.845:355): avc:  denied  { write } for 
pid=22039 comm="sshd" name="nss" dev=dm-0 ino=157542
scontext=system_u:system_r:sshd_t:s0 s0:c0.c1023 tcontext=unconfin   
ed_u:object_r:usr_t:s0 tclass=sock_file
  2 type=SYSCALL msg=audit(1355522996.845:355): arch=c000003e syscall=42
success=no exit=-13 a0=6 a1=7fff8463f710 a2=6e a3=7fff8463f3d0 items=0
ppid=1089 pid=22039 auid=4294967295 uid=0 gid=0     euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
key=(null)
  3 type=CRYPTO_KEY_USER msg=audit(1355522996.852:356): user pid=22040
uid=0 auid=4294967295 ses=4294967295
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server
fp=0c:6b:5a    :ef:71:df:1e:93:b3:71:b2:07:2c:8a:b4:77 direction=?
spid=22040 suid=0  exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1
terminal=? res=success'
  4 type=CRYPTO_KEY_USER msg=audit(1355522996.852:357): user pid=22040
uid=0 auid=4294967295 ses=4294967295
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server
fp=e5:97:d7    :29:ee:6c:08:9b:b3:b7:bf:9e:6c:6b:6f:58 direction=?
spid=22040 suid=0  exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1
terminal=? res=success'
  5 type=CRYPTO_SESSION msg=audit(1355522996.853:358): user pid=22039
uid=0 auid=4294967295 ses=4294967295
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=start
direction=from-client ciph    er=aes128-ctr ksize=128 spid=22040 suid=74
rport=60885 laddr=127.0.0.1 lport=22  exe="/usr/sbin/sshd" hostname=?
addr=127.0.0.1 terminal=? res=success'
  6 type=CRYPTO_SESSION msg=audit(1355522996.854:359): user pid=22039
uid=0 auid=4294967295 ses=4294967295
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=start
direction=from-server ciph    er=aes128-ctr ksize=128 spid=22040 suid=74
rport=60885 laddr=127.0.0.1 lport=22  exe="/usr/sbin/sshd" hostname=?
addr=127.0.0.1 terminal=? res=success'
  7 type=AVC msg=audit(1355522996.917:360): avc:  denied  { write } for 
pid=22039 comm="sshd" name="nss" dev=dm-0 ino=157542
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfin   
ed_u:object_r:usr_t:s0 tclass=sock_file
  8 type=SYSCALL msg=audit(1355522996.917:360): arch=c000003e syscall=42
success=no exit=-13 a0=4 a1=7fff8463f5c0 a2=6e a3=9 items=0 ppid=1089
pid=22039 auid=4294967295 uid=0 gid=0 euid=0 suid    =0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
  9 type=USER_LOGIN msg=audit(1355522996.918:361): user pid=22039 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
msg='op=login acct=28756E6B6E6F776E207573657    229 exe="/usr/sbin/sshd"
hostname=? addr=127.0.0.1 terminal=ssh res=failed'
 10 type=AVC msg=audit(1355523000.252:362): avc:  denied  { write } for 
pid=22039 comm="sshd" name="nss" dev=dm-0 ino=157542
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfin   
ed_u:object_r:usr_t:s0 tclass=sock_file
 11 type=SYSCALL msg=audit(1355523000.252:362): arch=c000003e syscall=42
success=no exit=-13 a0=4 a1=7fff8463f490 a2=6e a3=9 items=0 ppid=1089
pid=22039 auid=4294967295 uid=0 gid=0 euid=0 suid    =0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
 12 type=AVC msg=audit(1355523000.264:363): avc:  denied  { write } for 
pid=22039 comm="sshd" name="nss" dev=dm-0 ino=157542
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfin   
ed_u:object_r:usr_t:s0 tclass=sock_file
 13 type=SYSCALL msg=audit(1355523000.264:363): arch=c000003e syscall=42
success=no exit=-13 a0=4 a1=7fff8463f2f0 a2=6e a3=9 items=0 ppid=1089
pid=22039 auid=4294967295 uid=0 gid=0 euid=0 suid    =0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
 14 type=AVC msg=audit(1355523000.264:364): avc:  denied  { write } for 
pid=22039 comm="sshd" name="nss" dev=dm-0 ino=157542
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfin   
ed_u:object_r:usr_t:s0 tclass=sock_file
 15 type=SYSCALL msg=audit(1355523000.264:364): arch=c000003e syscall=42
success=no exit=-13 a0=4 a1=7fff8463f340 a2=6e a3=9 items=0 ppid=1089
pid=22039 auid=4294967295 uid=0 gid=0 euid=0 suid    =0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
 16 type=AVC msg=audit(1355523000.266:365): avc:  denied  { write } for 
pid=22039 comm="sshd" name="nss" dev=dm-0 ino=157542
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfin   
ed_u:object_r:usr_t:s0 tclass=sock_file
 17 type=SYSCALL msg=audit(1355523000.266:365): arch=c000003e syscall=42
success=no exit=-13 a0=8 a1=7fff8463f400 a2=6e a3=9 items=0 ppid=1089
pid=22039 auid=4294967295 uid=0 gid=0 euid=0 suid    =0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

Thanks so much for all your help.


On Fri, 14 Dec 2012 20:06:39 +0100, Jakub Hrozek <jhrozek(a)redhat.com&gt;
wrote:
>  On Fri, Dec 14, 2012 at 10:21:27AM -0800, Andrew Wygle wrote:
> > > 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
> > 
>  
>  "Connection refused" would indicate that there is nobody listening on
>  the other end. pam_sss is mostly just a proxy, which marshalls the 
incoming
>  request in a format the sssd_pam process expects and sends it over a
>  UNIX pipe to sssd_pam.
>  
>  You said before that you may have misconfigured the SSSD while building
>  it, is there any chance that the pam_sss module is talking to a pipe 
that
>  doesn't exist? The default pipe path is
> "\"VARDIR\"/lib/sss/pipes" while
>  VARDIR is expanded from the value of --localstatedir during configure. I
>  guess that "grep ^localstatedir Makefile" is a quick way to check what
>  the localstatedir was configured as if you still have the sources
>  around.
>  
>  Is the sssd_pam process running? I expect there is no sign of an
>  incoming request in the pam log? (/var/log/sssd/sssd_pam.log)
>  
> > 
> > 
> > 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
> > 
>  
>  The PAM config files look good to me. I think they are, indeed,
>  generated by authconfig.
>  
> > >> 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?
>  
>  If the sssd_be process crashed while there was a login in progress,
>  then the sssd_pam process wouldn't reconnect correctly and all further
>  connection attempts would hang.
>  
>  But given that you also see connection refused with accounts that you
>  can resolve with getent or id now, I no longer think the patch would be
>  a solution to that.
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Andrew Wygle]

I'm sorry, I posted the wrong log (that one happened when I mistyped the
password). Here is the correct log.


type=AVC msg=audit(1355523501.987:486): avc:  denied  { write } for 
pid=22109 comm="sshd" name="nss" dev=dm-0 ino=157542
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:usr_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1355523501.987:486): arch=c000003e syscall=42
success=no exit=-13 a0=6 a1=7fff48f503d0 a2=6e a3=7fff48f50090 items=0
ppid=1089 pid=22109 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
key=(null)
type=CRYPTO_KEY_USER msg=audit(1355523501.994:487): user pid=22110 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
msg='op=destroy kind=server
fp=0c:6b:5a:ef:71:df:1e:93:b3:71:b2:07:2c:8a:b4:77 direction=? spid=22110
suid=0  exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=?
res=success'
type=CRYPTO_KEY_USER msg=audit(1355523501.994:488): user pid=22110 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
msg='op=destroy kind=server
fp=e5:97:d7:29:ee:6c:08:9b:b3:b7:bf:9e:6c:6b:6f:58 direction=? spid=22110
suid=0  exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=?
res=success'
type=CRYPTO_SESSION msg=audit(1355523501.995:489): user pid=22109 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
msg='op=start direction=from-client cipher=aes128-ctr ksize=128 spid=22110
suid=74 rport=60904 laddr=127.0.0.1 lport=22  exe="/usr/sbin/sshd"
hostname=? addr=127.0.0.1 terminal=? res=success'
type=CRYPTO_SESSION msg=audit(1355523501.996:490): user pid=22109 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
msg='op=start direction=from-server cipher=aes128-ctr ksize=128 spid=22110
suid=74 rport=60904 laddr=127.0.0.1 lport=22  exe="/usr/sbin/sshd"
hostname=? addr=127.0.0.1 terminal=? res=success'
type=AVC msg=audit(1355523505.099:491): avc:  denied  { write } for 
pid=22109 comm="sshd" name="nss" dev=dm-0 ino=157542
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:usr_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1355523505.099:491): arch=c000003e syscall=42
success=no exit=-13 a0=4 a1=7fff48f50150 a2=6e a3=9 items=0 ppid=1089
pid=22109 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1355523505.514:492): avc:  denied  { getattr } for 
pid=22109 comm="sshd" path="/usr/var/lib/sss/pipes/private/pam"
dev=dm-0
ino=157546 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:usr_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1355523505.514:492): arch=c000003e syscall=4
success=no exit=-13 a0=7f758004de28 a1=7fff48f501b0 a2=7fff48f501b0 a3=0
items=0 ppid=1089 pid=22109 auid=4294967295 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
key=(null)
type=USER_ACCT msg=audit(1355523505.514:493): user pid=22109 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
msg='op=PAM:accounting acct="bob" exe="/usr/sbin/sshd"
hostname=REDACTED.domain.net addr=127.0.0.1 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1355523505.517:494): user pid=22109 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
msg='op=password acct="bob" exe="/usr/sbin/sshd" hostname=?
addr=127.0.0.1
terminal=ssh res=failed'
type=CRYPTO_KEY_USER msg=audit(1355523505.517:495): user pid=22109 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
msg='op=destroy kind=session fp=? direction=both spid=22110 suid=74
rport=60904 laddr=127.0.0.1 lport=22  exe="/usr/sbin/sshd" hostname=?
addr=127.0.0.1 terminal=? res=success'
type=CRYPTO_KEY_USER msg=audit(1355523505.518:496): user pid=22109 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
msg='op=destroy kind=server
fp=0c:6b:5a:ef:71:df:1e:93:b3:71:b2:07:2c:8a:b4:77 direction=? spid=22109
suid=0  exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=?
res=success'
type=CRYPTO_KEY_USER msg=audit(1355523505.518:497): user pid=22109 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
msg='op=destroy kind=server
fp=e5:97:d7:29:ee:6c:08:9b:b3:b7:bf:9e:6c:6b:6f:58 direction=? spid=22109
suid=0  exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=?
res=success'
type=USER_LOGIN msg=audit(1355523505.518:498): user pid=22109 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
msg='op=login acct="bob" exe="/usr/sbin/sshd" hostname=?
addr=127.0.0.1
terminal=ssh res=failed'

[Jakub Hrozek]

On Fri, Dec 14, 2012 at 02:21:53PM -0800, Andrew Wygle wrote:
>  I'm sorry, I posted the wrong log (that one happened when I
> mistyped the
>  password). Here is the correct log.
>  
>  
>  type=AVC msg=audit(1355523501.987:486): avc:  denied  { write } for 
>  pid=22109 comm="sshd" name="nss" dev=dm-0 ino=157542
>  scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  tcontext=unconfined_u:object_r:usr_t:s0 tclass=sock_file
>  type=SYSCALL msg=audit(1355523501.987:486): arch=c000003e syscall=42
>  success=no exit=-13 a0=6 a1=7fff48f503d0 a2=6e a3=7fff48f50090 items=0
>  ppid=1089 pid=22109 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
>  egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
>  exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  key=(null) 
I would try running restorecon -Rv /var/lib/sss to check if that makes
the socket_file related denials go away.

For the record, our QE is not seeing any avc denials on 6.4 with the 6.4
selinux-policy.

>  type=CRYPTO_KEY_USER msg=audit(1355523501.994:487): user pid=22110
> uid=0
>  auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  msg='op=destroy kind=server
>  fp=0c:6b:5a:ef:71:df:1e:93:b3:71:b2:07:2c:8a:b4:77 direction=? spid=22110
>  suid=0  exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=?
>  res=success'
>  type=CRYPTO_KEY_USER msg=audit(1355523501.994:488): user pid=22110 uid=0
>  auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  msg='op=destroy kind=server
>  fp=e5:97:d7:29:ee:6c:08:9b:b3:b7:bf:9e:6c:6b:6f:58 direction=? spid=22110
>  suid=0  exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=?
>  res=success'
>  type=CRYPTO_SESSION msg=audit(1355523501.995:489): user pid=22109 uid=0
>  auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  msg='op=start direction=from-client cipher=aes128-ctr ksize=128 spid=22110
>  suid=74 rport=60904 laddr=127.0.0.1 lport=22  exe="/usr/sbin/sshd"
>  hostname=? addr=127.0.0.1 terminal=? res=success'
>  type=CRYPTO_SESSION msg=audit(1355523501.996:490): user pid=22109 uid=0
>  auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  msg='op=start direction=from-server cipher=aes128-ctr ksize=128 spid=22110
>  suid=74 rport=60904 laddr=127.0.0.1 lport=22  exe="/usr/sbin/sshd"
>  hostname=? addr=127.0.0.1 terminal=? res=success'
>  type=AVC msg=audit(1355523505.099:491): avc:  denied  { write } for 
>  pid=22109 comm="sshd" name="nss" dev=dm-0 ino=157542
>  scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  tcontext=unconfined_u:object_r:usr_t:s0 tclass=sock_file
>  type=SYSCALL msg=audit(1355523505.099:491): arch=c000003e syscall=42
>  success=no exit=-13 a0=4 a1=7fff48f50150 a2=6e a3=9 items=0 ppid=1089
>  pid=22109 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>  fsgid=0 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
>  subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
>  type=AVC msg=audit(1355523505.514:492): avc:  denied  { getattr } for 
>  pid=22109 comm="sshd" path="/usr/var/lib/sss/pipes/private/pam"
> dev=dm-0
>  ino=157546 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  tcontext=unconfined_u:object_r:usr_t:s0 tclass=sock_file
>  type=SYSCALL msg=audit(1355523505.514:492): arch=c000003e syscall=4
>  success=no exit=-13 a0=7f758004de28 a1=7fff48f501b0 a2=7fff48f501b0 a3=0
>  items=0 ppid=1089 pid=22109 auid=4294967295 uid=0 gid=0 euid=0 suid=0
>  fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
>  exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  key=(null)
>  type=USER_ACCT msg=audit(1355523505.514:493): user pid=22109 uid=0
>  auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  msg='op=PAM:accounting acct="bob" exe="/usr/sbin/sshd"
>  hostname=REDACTED.domain.net addr=127.0.0.1 terminal=ssh res=failed'
>  type=USER_AUTH msg=audit(1355523505.517:494): user pid=22109 uid=0
>  auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  msg='op=password acct="bob" exe="/usr/sbin/sshd" hostname=?
> addr=127.0.0.1
>  terminal=ssh res=failed'
>  type=CRYPTO_KEY_USER msg=audit(1355523505.517:495): user pid=22109 uid=0
>  auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  msg='op=destroy kind=session fp=? direction=both spid=22110 suid=74
>  rport=60904 laddr=127.0.0.1 lport=22  exe="/usr/sbin/sshd" hostname=?
>  addr=127.0.0.1 terminal=? res=success'
>  type=CRYPTO_KEY_USER msg=audit(1355523505.518:496): user pid=22109 uid=0
>  auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  msg='op=destroy kind=server
>  fp=0c:6b:5a:ef:71:df:1e:93:b3:71:b2:07:2c:8a:b4:77 direction=? spid=22109
>  suid=0  exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=?
>  res=success'
>  type=CRYPTO_KEY_USER msg=audit(1355523505.518:497): user pid=22109 uid=0
>  auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  msg='op=destroy kind=server
>  fp=e5:97:d7:29:ee:6c:08:9b:b3:b7:bf:9e:6c:6b:6f:58 direction=? spid=22109
>  suid=0  exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=?
>  res=success'
>  type=USER_LOGIN msg=audit(1355523505.518:498): user pid=22109 uid=0
>  auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>  msg='op=login acct="bob" exe="/usr/sbin/sshd" hostname=?
> addr=127.0.0.1
>  terminal=ssh res=failed'
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-devel