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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users