<div dir="ltr">Thanks. <br><br>Maybe such behavior should be mentioned in the documentation? 
Right now it does not mention anything about referral objects and only states
 (dn, attrs) is (str, dict) tuple. </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 27, 2014 at 2:47 AM, Michael Ströder <span dir="ltr"><<a href="mailto:michael@stroeder.com" target="_blank">michael@stroeder.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Richard Li wrote:<br>
> I'm working with some code that does LDAP authentication against<br>
> ActiveDirectory, and I'm tracking an error down to a strange behavior in<br>
> the search_s() of LDAPObject:<br>
><br>
> It seems when a referral reference is returned with search results and<br>
> referral reference couldn't be reached, search_s() leaves the them in the<br>
> returned result list as a tuple (None, ['ldap://referral_uri'])<br>
><br>
> Is that an intended behavior of search_s() ?<br>
<br>
</div></div>Yes, that's correct. Otherwise you would'nt receive search continuations. You<br>
should simply sort them out.<br>
<br>
BTW: You could configure your application to use the global catalog. No search<br>
continuations are returned by AD in this case. The caveat is that not all user<br>
entry attributes are available there.<br>
<br>
Ciao, Michael.<br>
<br>
<br>
</blockquote></div><br></div>