User bind is failing with error LDAP_REFERRAL with ldap_simple_bind API call when LDAP_OPT_REFERRALS=ON in OpenLDAP C SDK 2.6.7

venugopal chinnakotla <[email protected]> Thu, 4 Jun 2026 15:41:50 +0530
Newsgroups gmane.network.openldap.technical,gmane.network.openldap.devel
Message-ID <CAJCMw6v9N9gZ7Rpe8nE-8Wt_4Bjc10UuzG6VFJh9-WzNC984rw@mail.gmail.com>
--0000000000008b089106536ac6bc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Team,

We are working on migration of nsldap C sdk to OpenLDAP C sdk for our
application client code.

We are using OpenLDAP 2.6.7.

As part of this migration, we are facing one issue related to LDAP
Referrals when LDAP_OPT_REFERRALS=3DON (which means SDK will handle Referra=
ls
internally)


While testing our application which makes use of OpenLDAP sdk , we see a
difference in the referral handling when LDAP_OPT_REFERRALS=3DON when
compared with NSLDAP C SDK with user bind
We are testing with Oracle Unified Directory, referrals is enabled at
server.

*With OpenLDAP C SDK:*
When our application follows the bind(synchronous) request for the users
which is present in another server (where chase should happen)
    ldap_bind_s =E2=86=92
       - Which internally calls ldap_sasl_bind_s =E2=86=92 ldap_sasl_bind +
ldap_result

     able to succeed the bind (LDAP_SUCCESS).

And When our application follows the bind(asynchronous) request for the
users which is present in another server (where chase should happen)
    ldap_simple_bind ->
        - which internally calls ldap_sasl_bind

    failed to bind and returned (LDAP_REFERRAL) instead.


On further analysis of OpenLDAP code *result.c* (line# 728)  we observed,
there is exclusion for bind request *tag !=3D LDAP_RES_BIND*, which is
preventing to chase the referral internally.













*    /* Do we need to check for referrals? */            if ( tag !=3D
LDAP_RES_BIND &&                ( LDAP_BOOL_GET(&ld->ld_options,
LDAP_BOOL_REFERRALS) ||                    lr->lr_parent !=3D NULL ))
    {                char        **refs =3D NULL;                ber_len_t
len;                /* Check if V3 referral */                if (
ber_peek_tag( &tmpber, &len ) =3D=3D LDAP_TAG_REFERRAL ) {
...                    /* Chase the referral */
refer_cnt =3D ldap_chase_v3referrals( ld, lr, refs, ... );*



However, we don't see such exclusion with NSLDAP C SDK specifically for
bind requests. We would like to understand the limitation for asynchronous
bind when handling referral internally.
Are there any known issues/limitations with this use case when OpenLDAP C
SDK handles referrals?
Is there any way (like any flag/option) to make automatic referrals work
with asynchronous bind calls  ldap_simple_bind?

Please note that, the ldap_search succeeds with when LDAP_OPT_REFERRALS=3DO=
N,
no issue observed.

--0000000000008b089106536ac6bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Team,</div><div><br></div><div>We are working on m=
igration of nsldap C sdk to OpenLDAP C sdk for our application client code.=
</div><div><div><br>We are using OpenLDAP 2.6.7.</div><div><br></div><div>A=
s part of this migration, we are facing one issue related to LDAP Referrals=
 when LDAP_OPT_REFERRALS=3DON (which means SDK will handle Referrals intern=
ally)</div><div><br></div><div><br></div><div>While testing our application=
 which makes use of OpenLDAP sdk , we see a difference in the referral hand=
ling when LDAP_OPT_REFERRALS=3DON when compared with NSLDAP C SDK with user=
 bind</div><div>We are testing with Oracle Unified Directory, referrals is =
enabled at server.<br><b><br></b></div><div><b>With OpenLDAP C SDK:</b><br>=
When our application follows the bind(synchronous) request for the users wh=
ich is present in another server (where chase should happen)<br>=C2=A0 =C2=
=A0 ldap_bind_s =E2=86=92 <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0- Which internally=
 calls ldap_sasl_bind_s =E2=86=92 ldap_sasl_bind + ldap_result<br>=C2=A0<br=
>=C2=A0 =C2=A0 =C2=A0able to succeed the bind (LDAP_SUCCESS).<br>=C2=A0<br>=
And When our application follows the bind(asynchronous) request for the use=
rs which is present in another server (where chase should happen)<br>=C2=A0=
 =C2=A0 ldap_simple_bind -&gt;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - which inter=
nally calls ldap_sasl_bind</div><div><br></div><div>=C2=A0 =C2=A0 failed to=
 bind and returned (LDAP_REFERRAL) instead.<br>=C2=A0 =C2=A0 <br><br>On fur=
ther analysis of OpenLDAP code <b>result.c</b> (line# 728) =C2=A0we observe=
d, there is exclusion for bind request <b>tag !=3D LDAP_RES_BIND</b>, which=
 is preventing to chase the referral internally.<br><br><br><i>=C2=A0 =C2=
=A0 /* Do we need to check for referrals? */<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 if ( tag !=3D LDAP_RES_BIND &amp;&amp;<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ( LDAP_BOOL_GET(&amp;ld-&gt;ld_optio=
ns, LDAP_BOOL_REFERRALS) ||<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 lr-&gt;lr_parent !=3D NULL ))<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 char =C2=A0 =C2=A0 =C2=A0 =C2=A0**refs =3D NULL;<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ber_len_t =C2=A0 len;<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Check if V3 refe=
rral */<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( ber=
_peek_tag( &amp;tmpber, &amp;len ) =3D=3D LDAP_TAG_REFERRAL ) {<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Chase=
 the referral */<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 refer_cnt =3D ldap_chase_v3referrals( ld, lr, refs, ... );</=
i><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
<br><br>However, we don&#39;t see such exclusion with NSLDAP C SDK specific=
ally for bind requests. We would like to understand the limitation for asyn=
chronous bind when handling referral internally.</div><div>Are there any kn=
own issues/limitations with this use case when OpenLDAP C SDK handles refer=
rals?</div><div>Is there any way (like any flag/option) to make automatic r=
eferrals work with asynchronous bind calls=C2=A0

ldap_simple_bind?<br><br>Please note that, the ldap_search succeeds with wh=
en LDAP_OPT_REFERRALS=3DON, no issue observed.</div><div><br></div><div><br=
></div></div></div>

--0000000000008b089106536ac6bc--