On Mon, Mar 24, 2014 at 05:46:47PM +0100, Lukas Slebodnik wrote:
On (24/03/14 12:04), kevin sullivan wrote:
>Thanks for the response Jakub!
>
>I couldn't run your command exactly because I don't use the start_tls
>command, I run everything over ldaps. I was able to bind anonymously using
>this command:
>
># ldapsearch -H "ldaps://test-server/" -b
>"uid=jharden,ou=Users,dc=example,dc=com"
>
>I can even bind as the user using this command:
>
># ldapsearch -H "ldaps://test-server/" -b
>"uid=jharden,ou=Users,dc=example,dc=com" -D
>"uid=jharden,ou=Users,dc=example,dc=com" -W
>
>I remade my CA, my server certificate, and my client certificate to make
>sure that I wasn't screwing something up with the certificates. Things
>still work with ldapsearch, but not with sssd.
I checked source code of libldap (which is used by sssd)
and return code 49 (0x31 LDAP_INVALID_CREDENTIALS) is return only if there is
problem with certificate.
sh-4.2$ grep -RniI -B2 LDAP_INVALID_CREDENTIALS
openldap-2.4.39/include/ldap.h-607-#define LDAP_X_PROXY_AUTHZ_FAILURE 0x2F /* LDAPv3
proxy authorization */
openldap-2.4.39/include/ldap.h-608-#define LDAP_INAPPROPRIATE_AUTH 0x30
openldap-2.4.39/include/ldap.h:609:#define LDAP_INVALID_CREDENTIALS 0x31
--
openldap-2.4.39/libraries/libldap/error.c-71-
openldap-2.4.39/libraries/libldap/error.c-72- C(LDAP_INAPPROPRIATE_AUTH,
N_("Inappropriate authentication"));
openldap-2.4.39/libraries/libldap/error.c:73: C(LDAP_INVALID_CREDENTIALS,
N_("Invalid credentials"));
--
openldap-2.4.39/libraries/libldap/tls_m.c-2744-
openldap-2.4.39/libraries/libldap/tls_m.c-2745- cert = SSL_LocalCertificate( s );
openldap-2.4.39/libraries/libldap/tls_m.c:2746: if (!cert) return
LDAP_INVALID_CREDENTIALS;
--
openldap-2.4.39/libraries/libldap/tls_m.c-2759-
openldap-2.4.39/libraries/libldap/tls_m.c-2760- cert = SSL_PeerCertificate( s );
openldap-2.4.39/libraries/libldap/tls_m.c:2761: if (!cert) return
LDAP_INVALID_CREDENTIALS;
--
openldap-2.4.39/libraries/libldap_r/error.c-71-
openldap-2.4.39/libraries/libldap_r/error.c-72- C(LDAP_INAPPROPRIATE_AUTH,
N_("Inappropriate authentication"));
openldap-2.4.39/libraries/libldap_r/error.c:73: C(LDAP_INVALID_CREDENTIALS,
N_("Invalid credentials"));
--
openldap-2.4.39/libraries/libldap_r/tls_m.c-2744-
openldap-2.4.39/libraries/libldap_r/tls_m.c-2745- cert = SSL_LocalCertificate( s
);
openldap-2.4.39/libraries/libldap_r/tls_m.c:2746: if (!cert) return
LDAP_INVALID_CREDENTIALS;
--
openldap-2.4.39/libraries/libldap_r/tls_m.c-2759-
openldap-2.4.39/libraries/libldap_r/tls_m.c-2760- cert = SSL_PeerCertificate( s );
openldap-2.4.39/libraries/libldap_r/tls_m.c:2761: if (!cert) return
LDAP_INVALID_CREDENTIALS;
The server can return LDAP_INVALID_CREDENTIALS as well. I think there
might be an issue with the password. According to the logs your password
has 13 characters, does this make sense?
You PAM configuration is a bit unusual, because you have pam_sss first
and the pam_unix. Can you try to switch the order?
On my system it looks a bit like:
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
If this works there might be an issue when SSSD is first in the stack
and has to read the password.
HTH
bye,
Sumit
LS
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users