closing this thread...
Thank you Howard for the assistance.
My system was behaving some inconsistent way (running the same search repeatedly, sometimes it worked as i expected and others not), so i've removed every ldap package and reinstalled them, recompiled my code, and with the ldap_set_option using the "LDAP *" from my init call, it is now consistently not trying to follow the REFERRALS.
Also, i've found out how the "ldap_set_rebind_proc" works, and so i have a second alternative (that i think, is the most correct), that's follow the "REFERRALS" and bind the referred url's with the correct/expected credentials and not anonymously.
regards, -wm
On 08/03/2014, at 20:16, Werner M wxxx333@gmail.com wrote:
On 08/03/2014, at 18:31, Howard Chu hyc@symas.com wrote:
Werner - Google wrote:
Hi, After doing some more research and lot's of tcpdumping, i got some more info, but still don't know how to solve my problem.
As i mentioned, i'm doing the search agains an Active Directory service. I do the serch with the code showed above, and with the tcpdump's i seems to show that when i do it with ldap_search_ext_s(), i get after the found item, a list of referals, like:
dap://ForestDnsZones.example.dc/DC=ForestDnsZones,DC=example,DC=dc ldap://DomainDnsZones.example.dc/DC=DomainDnsZones,DC=example,DC=dc ldap://example.dc/CN=Configuration,DC=example,DC=dc
and ldap_search_ext_s() tries to follow those referrals. On this attempt it tries the bind without the credentials, and than i get rejected by the server of sometimes i'm even unable to reach the mentioned server.
I've tried adding to my test code,
int referals = LDAP_OPT_OFF; /* before the init */ ldap_set_option( NULL, LDAP_OPT_REFERRALS, &referals);
as it seems to have no effect, i still get my test code trying to 'follow' the referals, i did try also put it as:
/* after the ldap_init , using the returned LDAP* */ ldap_set_option( ld, LDAP_OPT_REFERRALS, &referals);
but still no effect.
Sounds like you're not using OpenLDAP's libldap. What version of LDAP library are you actually using?
I'm sorry, forgot to include the information..
I'm running it on a ubuntu 13.10 with openldap version:
$ slapd -V @(#) $OpenLDAP: slapd (Ubuntu) (Oct 8 2013 20:51:43) $ buildd@akateko:/build/buildd/openldap-2.4.31/debian/build/servers/slapd
$ ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch (Ubuntu) (Oct 8 2013 20:50:56) $ buildd@akateko:/build/buildd/openldap-2.4.31/debian/build/clients/tools (LDAP library: OpenLDAP 20431)
I've also tried/tested on a mac osx mountain lion, openldap version: dap $ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.28 (Jul 4 2013 21:48:28) $ root@b1026.apple.com:/private/var/tmp/OpenLDAP/OpenLDAP-208.5~1/clients/tools (LDAP library: OpenLDAP 20428)
Both the same result (at least up to where i can see/follow).
Are i'm understanding it wrong that after setting LDAP_OPT_REFERRALS to OFF, ldap_search_ext_s() should NOT try follow the referrals?
thx
And doing the same tcpdumping and running ldapsearch -d ... , it appears that ldapsearch, using the same search parameters as my test code, does NOT try to follow the referrals, even getting them back from the server the same as my test code.
As additional info, the wireshark summary of the search return packet is something like: No. Time Source Destination Protocol Length Info 97 4.810369000 9.9.9.9 5.5.5.5 LDAP 405 searchResEntry(2) "CN=Alonso.Vega,OU=Users,OU=Country,DC=example,DC=dc" | searchResDone(2) Unknown result(9) (Referral: dap://ForestDnsZones.example.dc/DC=ForestDnsZones,DC=example,DC=dc ldap://DomainDnsZones.example.dc/DC=DomainDnsZones,DC=example,DC=dc ldap://example.dc/CN=Configuration,DC=example,DC=dc) [1 result]
Any suggestion/help very appreciated on how i could avoid that the search tries to follow the referrals?
Copy the code that the ldapsearch tool uses. You're using obsolete APIs in your code.
I'm looking into the code of the mod_ldap (from the proftpd software) to use the asynchronous methodology, but found it will be a little more challenging for my little "c" and openldap knowledge.
but if i don't find a way of avoiding that the synchronous functions (mostly search_ext_s() ) do NOT try follow the referrals, i'll have to try rewriting the code.
thx -werner
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/