Hi again,

After a few hours of trial and error, I've figured it out and got it working. Well, partly that is.
We use LDAP(Novell eDirectory) primary as identity vault and Kerberos(AD) for primary authentication source and LDAP as fallback authentication source.
So, I've disabled Kerberos in SSSD, as our develop and test systems are not known by the KDC (no keytab file)
Secondly, I thought I had TLS disabled, as eDirectory doesn't have TLS enabled. 
However, as I still had a parameter pointing to the CA directory, SSSD apparantly thought it needed TLS. Once this was commented out and SSSD was restarted, 
I was able to login. 

To get Kerberos in the loop again I need to pull some strings in the organisation or build a new Kerberos realm for development purposes only. Anyway...For now, SSSD is working. 
I

cheers and thanks for all the input so far !

Andy



2011/10/3 Jan Zelený <jzeleny@redhat.com>
> Hi,
>
> I've put the log level to 9, which gives a LOT of logging in
> sssd_default.log. These are [ldb] and [sdap]  entries.
> sssd.log itself only shows the message:
>
> (Mon Oct  3 11:48:24 2011) [sssd] [monitor_quit] (0): Monitor received
> Terminated: terminating children
> (Mon Oct  3 12:04:49 2011) [sssd] [monitor_quit] (0): Monitor received
> Terminated: terminating children
> (Mon Oct  3 12:08:33 2011) [sssd] [monitor_quit] (0): Monitor received
> Terminated: terminating children
> (Mon Oct  3 12:28:33 2011) [sssd] [monitor_quit] (0): Monitor received
> Terminated: terminating children
>
> I rebooted the system, and when I checked the log of the sssd_default.log,
> I saw this:
>
> (Mon Oct  3 13:02:19 2011) [sssd[be[default]]] [sbus_dispatch] (9): dbus
> conn: 964780
> (Mon Oct  3 13:02:19 2011) [sssd[be[default]]] [sbus_dispatch] (3):
> Connection is not open for dispatching.
> (Mon Oct  3 13:02:19 2011) [sssd[be[default]]] [be_client_destructor] (4):
> Removed NSS client
> (Mon Oct  3 13:02:19 2011) [sssd[be[default]]] [remove_krb5_info_files]
> (5): Could not remove [/var/lib/sss/pubconf/kdcinfo.WBI.NXP.COM], [2][No
> such file or directory]
> (Mon Oct  3 13:02:19 2011) [sssd[be[default]]] [remove_krb5_info_files]
> (5): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.WBI.NXP.COM],
> [2][No such file or directory]
> (Mon Oct  3 13:02:19 2011) [sssd[be[default]]] [sdap_handle_release] (8):
> Trace: sh[0x9695d0], connected[1], ops[(nil)], ldap[0x9698d0],
> destructor_lock[0], release_memory[0]
> (Mon Oct  3 13:02:19 2011) [sssd[be[default]]] [remove_connection_callback]
> (9): Successfully removed connection callback.
>
> Don't know if it is related to this problem however.
>
> I'm kinda stuck right now.

Try setting the debug level to every section in the config file, that will
produce logs for both responders as well. I'm particularly interested in the
nss provider. It seems like there is some sbus communication problem. Could
you also paste a little more complete log (without sensitive information)
somewhere?

Thanks
Jan

>
> 2011/10/3 Jan Zelený <jzeleny@redhat.com>
>
> > > Hi Stephen,
> > >
> > > /etc/pam.d/sshd didn't include system-auth. Fixed that, but still not
> >
> > able
> >
> > > to login.
> > > Errors in /var/log/secure:
> > >
> > > Oct  3 12:29:14 tst0030 login: pam_sss(login:auth): authentication
> >
> > failure;
> >
> > > logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost= user=XXX1111
> > > Oct  3 12:29:14 tst0030 login: pam_sss(login:auth): received for
> > > user XXX1111: 4 (System error)
> > > Oct  3 12:29:15 tst0030 login: FAILED LOGIN 2 FROM (null) FOR XXX1111,
> > > Authentication failure
> >
> > What do sssd logs say? Anything interesting? Based on the config you
> > pasted earlier, I suggest raising the log level to at least 4 or 5
> > before you try logging in again.
> >
> > > Logging in on the local console gives the same error.
> > >
> > > cheers,
> > > Andy
> > >
> > >
> > >
> > > 2011/9/30 Stephen Gallagher <sgallagh@redhat.com>
> > >
> > > > This log doesn't show any attempt to authenticate with pam_sss.so.
> > > > Can you make sure that your /etc/pam.d/sshd is actually importing
> > > > system-auth. Also, make sure that /etc/ssh/sshd_config has "UsePAM
> > > > yes"
> > > >
> > > > Also, try logging into the local console (non-graphical). If that
> >
> > works,
> >
> > > > then it's an SSH issue, not an SSSD issue.
> >
> > Jan

--
Thank you
Jan Zeleny

Red Hat Software Engineer
Brno, Czech Republic