We are using Sun DSEE 6. Would errors regarding certificate failures be in the same /var/log/sssd/sssd_default.log or one of the others.

Thanks.

On Thu, Feb 10, 2011 at 2:52 PM, Stephen Gallagher <sgallagh@redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/10/2011 02:39 PM, sssd help wrote:
> Stephen, I installed the packages you sent me. Here is the new log output:
>
> (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [simple_bind_send] (4):
> Executing simple bind as: uid=testuser,ou=people,dc=mydomain,dc=com
> (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [simple_bind_send] (8): ldap
> simple bind sent, msgid = 2
> (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_process_result] (8):
> Trace: sh[0x8f6900], connected[1], ops[0xe3b510], ldap[0xc3b000]
> (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_process_result] (4):
> ldap_result gave -1, something bad happened!
> (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_process_result] (4):
> ldap_result failed: [(null)]
> (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_handle_release] (8):
> Trace: sh[0x8f6900], connected[1], ops[0xe3b510], ldap[0xc3b000],
> destructor_lock[0], release_memory[0]
> (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [remove_connection_callback]
> (9): Successfully removed connection callback.
>
> To get authentication to work with sssd I found that i have to edit
> sssd.conf in a couple of places. One, change the ldap_uri to
> ldap.mydomain.com and Two, change ldap_tls_reqcert to "never". When
> ldap_tls_reqcert is set to default (hard/demand) authentication fails. I
> decided to tail access logs on our ldap server to look at the difference in
> a request from my test machine that works (over 389/ldap) and one that fails
> (over 686/ldaps)

Authentication fails when it's set to hard/demand? That would suggest
that your CA certificate is not being read (or is not the correct CA
certificate). There should be a log message when this fails that
explains why it failed.

>
> Failed request:
>
> [10/Feb/2011:14:23:05 -0500] conn=581553 op=9 msgId=11 - SRCH
> base="ou=people,dc=mydomain,dc=com" scope=2
> filter="(&(uid=testuser)(objectClass=posixAccount))" attrs="objectClass uid
> userPassword uidNumber gidNumber gecos homeDirectory loginShell
> krbprincipalname cn modifyTimestamp shadowLastChange shadowMin shadowMax
> shadowWarning shadowInactive shadowExpire shadowFlag krblastpwdchange
> krbpasswordexpiration pwdAttribute"
> [10/Feb/2011:14:23:05 -0500] conn=581553 op=9 msgId=11 - RESULT err=0
> tag=101 nentries=1 etime=0
>
>
> Successful request:
>
> [10/Feb/2011:14:33:43 -0500] conn=581558 op=27 msgId=29 - SRCH
> base="ou=people,dc=mydomain,dc=com" scope=2
> filter="(&(uid=testuser)(objectClass=posixAccount))" attrs="objectClass uid
> userPassword uidNumber gidNumber gecos homeDirectory loginShell
> krbprincipalname cn modifyTimestamp shadowLastChange shadowMin shadowMax
> shadowWarning shadowInactive shadowExpire shadowFlag krblastpwdchange
> krbpasswordexpiration pwdAttribute"
> [10/Feb/2011:14:33:43 -0500] conn=581558 op=27 msgId=29 - RESULT err=0
> tag=101 nentries=1 etime=0
>
> The requests seem to yeild the same results so im confused as to why one is
> failing and the other is not.
>
> I should note that in the ssl cert directory i am using the same cert that
> we use on all of the other systems in our environment (mostly RHEL5.3) and i
> have run cacertdir_rehash on the directory as it says in the sssd-ldap(5)
> man page.
>
> Any suggestions? Thank you for your help so far.


Yeah, this isn't a certificate issue here (though I'm concerned that you
have to set ldap_tls_reqcert = allow. If you have a valid CA cert, you
should be able to use that. Maybe you should try ldap_tls_cacert =
/path/to/actual/cert

Something's wrong with ldap_result (which is how the openldap libraries
process the response from the server). And as we've unfortunately proven
here, there's no actual error message to tell us what it was.
("ldap_result failed: [(null)]")

The implication here is that the LDAP server sent us a badly-formatted
result packet. So I'm wondering if the issue might be on the server (but
that seems unlikely if you have other tools using LDAPS successfully).

What LDAP server are you using, by the way?

- --
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.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1UQhMACgkQeiVVYja6o6PSgQCgj/FwDZfopizSg1qy28qqj21l
J+EAn0ZoSskCetuU2cS2Hcg/9CZF+CqD
=1Rji
-----END PGP SIGNATURE-----
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel