I can confirm now that using ldapsearch to perform lookups against the
target directory works as long as -ZZ is not enabled.
so:
ldapsearch -H ldaps://..... works perfectly fine over 636, while
/etc/openldap/ldap.conf has its tls_cacertdir set to the same directory as
the ldap_tls_cacertdir directory in sssd.conf.
It seems pretty clear that in our case executing start_tls is causing
problems. Is there any way to make sure that it does not run?
Brandon
On Fri, Feb 11, 2011 at 12:23 PM, sssd help <sssdhelp(a)gmail.com> wrote:
Thank you for the taking a look Sumit.
I am testing with ldapsearch now. My first searches are returning:
ldap_start_tls: Connect error (-11)
which i guess is what we would expect since we cant do tls against our load
balancers. I will continue testing and let you know if I come up with
something different.
Brandon
On Fri, Feb 11, 2011 at 7:37 AM, Sumit Bose <sbose(a)redhat.com> wrote:
> On Fri, Feb 11, 2011 at 07:27:36AM -0500, Stephen Gallagher wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 02/10/2011 06:08 PM, sssd help wrote:
> > > Hey Stephen, Just a little more information incase this helps in
> > > troubleshooting. After talking to my group i was reminded that the
> reason we
> > > cant use TLS is because we are using hardware loadbalancers to handle
> the
> > > ssl offload and proxy between multiple ldap servers.
> > >
> > > Is there any reason you can think of that using a loadbalancer in this
> case
> > > would cause an initial ldaps connection to fail?
> >
> > It's possible that a faulty SSL load balancer might be resulting in
> > sending back invalid data. But I'd assume you'd be seeing that in all
> > your clients, not just SSSD. It's worth investigating, though. It's
> > possible that the load balancers are adding something to the message
> > that SSSD is not expecting (but should be). It's hard to debug over SSL,
> > though.
> >
> > > I noticed in the logs that even though i explicitly request sssd to
> not use
> > > start_tls, it still runs:
> > >
> > > "Executing START_TLS"
> > >
> > > is there any way to stop this behavior?
> >
> > Are you seeing that START_TLS message when you have an ldaps:// URI
> > specified? That sounds like a bug, if so. (Shouldn't be happening; we
> > check for whether an encrypted channel is already available before we
> > call that function)
>
> I've just checked, we call START_TLS on every authentication and do not
> check if TLS is already active due to ldaps. Maybe Sun DSEE does not
> like the double encryption. Can you check if
>
> ldapsearch -ZZ -H ldaps://....
>
> works with your LDAP server?
>
> bye,
> Sumit
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/sssd-devel
>