Issue 9178 - Re-connection on lost connection is not propagating LDAP_OPT_REFERRALS option set to off
Summary: Re-connection on lost connection is not propagating LDAP_OPT_REFERRALS option...
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-05 16:50 UTC by laurent.sabourin.74@gmail.com
Modified: 2020-03-10 14:58 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description laurent.sabourin.74@gmail.com 2020-03-05 16:50:36 UTC
Full_Name: Laurent Sabourin
Version: openldap-2.4.48
OS: Windows
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (216.218.42.174)


I am using OpenLDAP libraries within my software for my LDAP client
implementation.

For the LDAP session handles where I set the option LDAP_OPT_REFERRALS to
LDAP_OPT_OFF, it seems that that option is not being propagated when OpenLDAP
reconnects after the server dropped the initial connection. Because of that, all
subsequent searches start following referrals even though the option was turned
off initially.

How to reproduce:
1- Make a LDAP search to LDAP server that returns referrals (Windows AD in my
case) with referrals turned off. The search doesn't follow referrals.
2- Drop the connection with the LDAP server (I used SysInternals TCPView to
force the connection to close)
3- Make the same LDAP search using the same LDAP session handle used in step 1.
OpenLDAP reconnects, but the search unexpectedly follows the referrals.

Expected behavior:
I would expect the LDAP session handle to retain original options even when it
reconnects drop connections.
Comment 1 laurent.sabourin.74@gmail.com 2020-03-10 14:14:52 UTC
Hello,

Please disregard, the issue was in our implementation. You can close this
issue. Sorry about that!

Laurent

On Thu, 5 Mar 2020 at 11:50, <openldap-its@openldap.org> wrote:

>
> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***
>
> Thanks for your report to the OpenLDAP Issue Tracking System.  Your
> report has been assigned the tracking number ITS#9178.
>
> One of our support engineers will look at your report in due course.
> Note that this may take some time because our support engineers
> are volunteers.  They only work on OpenLDAP when they have spare
> time.
>
> If you need to provide additional information in regards to your
> issue report, you may do so by replying to this message.  Note that
> any mail sent to openldap-its@openldap.org with (ITS#9178)
> in the subject will automatically be attached to the issue report.
>
>         mailto:openldap-its@openldap.org?subject=(ITS#9178)
>
> You may follow the progress of this report by loading the following
> URL in a web browser:
>     http://www.OpenLDAP.org/its/index.cgi?findid=9178
>
> Please remember to retain your issue tracking number (ITS#9178)
> on any further messages you send to us regarding this report.  If
> you don't then you'll just waste our time and yours because we
> won't be able to properly track the report.
>
> Please note that the Issue Tracking System is not intended to
> be used to seek help in the proper use of OpenLDAP Software.
> Such requests will be closed.
>
> OpenLDAP Software is user supported.
>         http://www.OpenLDAP.org/support/
>
> --------------
> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.
>
>
Comment 2 Quanah Gibson-Mount 2020-03-10 14:58:23 UTC
changed state Open to Closed