On Mon, 2011-10-03 at 22:47 +0200, Andy Kannberg wrote:
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
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
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
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
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.