Hi Stephen,

It was indeed the unencrypted channel that was the culprit. We tried authenticating against a system with LDAP+GSSAPI and it worked like a charm !

Thanks !

cheers,
Andy

2010/8/30 Stephen Gallagher <sgallagh@redhat.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/30/2010 09:52 AM, Andy Kannberg wrote:
> Hi all,
>
> In our setup, we run into the following problem: When sssd is
> configured, the authentication against ldap fails, but succeeds against
> kerberos/AD. Our ldap/edirectory guru has, as far as he is concerned,
> pinned the problem down due to the fact that ldap authentication fails
> with the logging saying "password failed":

Please include your [sanitized] sssd.conf.


>
> Now, browsing through the options that can be set, we sat that we were
> able to set an ldap_default_authtok_type. However, the only possible
> option here is "password". However, the object "password" is unknown in
> eDirectory. All other options can be set/remapped to other attributes,
> and this particular one cannot. Is there a work around for this that
> anyone knows of ?
>

This is not an ldap attribute. It's a type identifier so that SSSD knows
that the authentication credentials are a password (as opposed to a
certificate, which we intend to support eventually). We don't use the
user's password attribute directly.

The way the authentication works in SSSD is by attempting to perform a
simple bind against the LDAP user, where the bind DN is the user's full
distinguished name and the bind password is the user's password. If this
simple bind succeeds, then we treat the user as authenticated.

One thing you may be encountering is that SSSD will deny any
authentication that attempts to occur over an unencrypted channel. You
must be using one of
 * LDAP+TLS
 * LDAPS
 * LDAP+GSSAPI
to encrypt the channel for authentication to succeed. I'd need to see
more of your logs than what you included here to tell you if this is the
problem. You included only the logs for the user lookup, and not for the
user authentication.

If you don't see any requests for the user authentication in the log,
then your problem is with your client's PAM configuration, and not SSSD.

It would be a good idea to also include your /etc/pam.d/system-auth file.

- --
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkx7ufoACgkQeiVVYja6o6Mm7QCcC9wxGcFH6TLsjLpync8K0fxl
OWsAmwQ3682fawZh0XQX7gwAxKxe900q
=APu9
-----END PGP SIGNATURE-----
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel