SSSD on RHEL6 problems

[Andy Kannberg]

Hi all,

I'm running into problems on a RHEL6 machine with configuring sssd.
I keep getting errors like this:

Sep 30 14:11:26 tst0030 sshd[7512]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=somehost.domain.com user=XXX
Sep 30 14:11:27 tst0030 sshd[7512]: Failed password for XXX21358 from
12.34.56.78 port 32950 ssh2
Sep 30 14:11:33 tst0030 sshd[7512]: Failed password for XXX21358
from 12.34.56.78 port 32950 ssh2



However, I can perform a ldapsearch succesfully. So LDAP is available.

I've copied the configuration from a working RHEL5 machine(which runs just
fine, I can login with the same credentials I try on the RHEL6 box), but it
appears to be a no-go for now. sssd.conf looks like this:

[sssd]
config_file_version = 2

# Number of times services should attempt to reconnect in the
# event of a crash or restart before they give up
reconnection_retries = 3

# If a back end is particularly slow you can raise this timeout here
sbus_timeout = 30
services = nss, pam

# SSSD will not start if you do not configure any domains.
# Add new domain configurations as [domain/<NAME>] sections, and
# then add the list of domains (in the order you want them to be
# queried) to the "domains" attribute below and uncomment it.
domains = default

[nss]
# The following prevents SSSD from searching for the root user/group in
# all domains (you can add here a comma-separated list of system accounts
that
# are always going to be /etc/passwd users, or that you want to filter out).
filter_groups = root
filter_users = root
reconnection_retries = 3

# The entry_cache_timeout indicates the number of seconds to retain an
# entry in cache before it is considered stale and must block to refresh.
# The entry_cache_nowait_timeout indicates the number of seconds to
# wait before updating the cache out-of-band. (NSS requests will still
# be returned from cache until the full entry_cache_timeout). Setting this
# value to 0 turns this feature off (default).
; entry_cache_timeout = 600
; entry_cache_nowait_timeout = 300

[pam]
reconnection_retries = 3
#offline_credentials_expiration = 0
#offline_failed_login_attempts = 5
#offline_failed_login_delays = 15

[domain/default]
ldap_id_use_start_tls = False
cache_credentials = True
ldap_search_base = ou=TST_EMEA_NL-TST01,ou=Locations,ou=NXDI,o=NXP
ldap_user_search_base = ou=People,ou=NXDI,o=NXP
ldap_user_object_class = NxpUserAuxClass
ldap_user_principal = krbForeignPrincipalName
ldap_force_upper_case_realm = True
ldap_user_fullname = fullName
ldap_user_member_of = groupMembership
ldap_group_search_base = ou=Group,ou=NXDI,o=NXP
ldap_group_object_class = NxpGroupAuxClass
ldap_group_gid_number = gidNumber
ldap_schema = rfc2307bis
enumerate = True
krb5_realm = WBI.NXP.COM
chpass_provider = krb5
krb5_kdcserver = wbi.nxp.com
id_provider = ldap
auth_provider = krb5
debug_level = 0
ldap_uri = ldap://dtc0001.dtq.nl-htc01.nxp.com,ldap://
dtc0002.dtq.nl-htc01.nxp.com
krb5_kpasswd = wbi.nxp.com
ldap_tls_cacertdir = /etc/openldap/cacerts


I've modified nsswitch.conf to use sss, and also the system-auth to use the
sssd-pam library. These look like:

auth        required      pam_env.so
auth        sufficient    pam_unix.so likeauth nullok
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
#account     required      pam_access.so
accessfile=/etc/security/access.netgroup.conf

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so nullok use_authtok md5 shadow
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

#session     required      pam_limits.so
session     required      pam_unix.so
session      required      pam_keyinit.so revoke
session     optional      pam_sss.so

Anyone who can help me out with this ? I'm kinda stuck. Google didn't show
up any useful results.

cheers,
Andy

[Nalin Dahyabhai]

On Fri, Sep 30, 2011 at 02:26:46PM +0200, Andy Kannberg wrote:
>     I've modified nsswitch.conf to use sss, and also the
> system-auth to use
>     the sssd-pam library. These look like:
>  
>     auth        required      pam_env.so
>     auth        sufficient    pam_unix.so likeauth nullok
>     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
>     #account     required      pam_access.so
>     accessfile=/etc/security/access.netgroup.conf
>     password    requisite     pam_cracklib.so try_first_pass retry=3
>     password    sufficient    pam_unix.so nullok use_authtok md5 shadow
>     password    sufficient    pam_sss.so use_authtok
>     password    required      pam_deny.so
>     #session     required      pam_limits.so
>     session     required      pam_unix.so
>     session      required      pam_keyinit.so revoke
>     session     optional      pam_sss.so
>  
>     Anyone who can help me out with this ? I'm kinda stuck. Google didn't
>     show up any useful results. 
On my EL6 systems, /etc/pam.d/sshd (which is what sshd uses) is
referencing /etc/pam.d/password-auth rather than /etc/pam.d/system-auth,
which is a change since EL5.  Did you update /etc/pam.d/password-auth as
well?

HTH,

Nalin

[Stephen Gallagher]

On Fri, 2011-09-30 at 14:26 +0200, Andy Kannberg wrote:
>  Hi all,
>  
>  
>  I'm running into problems on a RHEL6 machine with configuring sssd. 
>  I keep getting errors like this:
>  
>  
>  Sep 30 14:11:26 tst0030 sshd[7512]: pam_unix(sshd:auth):
>  authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
>  rhost=somehost.domain.com  user=XXX
>  Sep 30 14:11:27 tst0030 sshd[7512]: Failed password for XXX21358 from
>  12.34.56.78 port 32950 ssh2
>  Sep 30 14:11:33 tst0030 sshd[7512]: Failed password for XXX21358
>  from 12.34.56.78 port 32950 ssh2 

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.

[Andy Kannberg]

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


Logging in on the local console gives the same error.

cheers,
Andy



2011/9/30 Stephen Gallagher <sgallagh(a)redhat.com&gt;

>  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.
>
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/sssd-devel
>
>

[Jan Zelený]

>  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(a)redhat.com&gt;
>  
>  > 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

[Andy Kannberg]

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.

2011/10/3 Jan Zelený <jzeleny(a)redhat.com&gt;

>  > 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(a)redhat.com&gt;
>  >
>  > > 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
>

[Jakub Hrozek]

On Mon, Oct 03, 2011 at 01:09:34PM +0200, Andy Kannberg wrote:
>     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:  
sssd_default.log and sssd_pam.log would be the most interesting for us
in this case.

[Jan Zelený]

>  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(a)redhat.com&gt;
>  
>  > > 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(a)redhat.com&gt;
>  > > 
>  > > > 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

[Andy Kannberg]

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(a)redhat.com&gt;

>  > 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(a)redhat.com&gt;
>  >
>  > > > 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(a)redhat.com&gt;
>  > > >
>  > > > > 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
>

[Stephen Gallagher]

On Mon, 2011-10-03 at 22:47 +0200, Andy Kannberg wrote:
>  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) 
This should be irrelevant. You shouldn't need a keytab file to talk to
kerberos for user authentication (though without one you won't gain
GSSAPI single-sign-on for SSH).

So I'd really like to know more about your setup. If you could send us a
complete (sanitized) sssd_default.log at debug_level=7, we could better
identify the issue.

>  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.  
SSSD will not perform an LDAP authentication over an insecure
connection. It will always requires either TLS or LDAPS for this
function. This is because the LDAP protocol sends simple bind requests
with the password in the clear, so in order to protect users' passwords,
SSSD will not permit an authentication attempt to be sent over an
unencrypted channel. So if you're using an ldap:// URI, we will always
attempt START_TLS, and if that fails we will deny the auth attempt.

So I suspect what was happening is that your CA directory was pointing
at the wrong location, and by commenting it out, SSSD switched back to
the default, which worked.

If you were to look at your SSSD debug logs or LDAP server logs, you'd
see a START_TLS request go across before the LDAP bind for
authentication.

>  
>  
>  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.  
See above. You shouldn't need this for simple authentication.

[Simo Sorce]

On Mon, 2011-10-03 at 16:57 -0400, Stephen Gallagher wrote:
>  On Mon, 2011-10-03 at 22:47 +0200, Andy Kannberg wrote:
>  > 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)
>  
>  This should be irrelevant. You shouldn't need a keytab file to talk to
>  kerberos for user authentication (though without one you won't gain
>  GSSAPI single-sign-on for SSH). 
We do validation by default, so a keytab is needed.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Stephen Gallagher]

On Mon, 2011-10-03 at 17:27 -0400, Simo Sorce wrote:
>  On Mon, 2011-10-03 at 16:57 -0400, Stephen Gallagher wrote:
>  > On Mon, 2011-10-03 at 22:47 +0200, Andy Kannberg wrote:
>  > > 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)
>  > 
>  > This should be irrelevant. You shouldn't need a keytab file to talk to
>  > kerberos for user authentication (though without one you won't gain
>  > GSSAPI single-sign-on for SSH).
>  
>  We do validation by default, so a keytab is needed.
>  
>  Simo.
>   
We only validate by default in the IPA provider. Validation is disabled
by default when using only the krb5 provider (because there is no
guarantee of a keytab).