Thanks joe, I almost forgot about this post.  I found a draft of what I was originally going to submit which has more specifics in it, but I'm finding that your description below is actually right on in terms of the base specified (root) and scope (subtree).  Only difference was that the query was for the name of user in a second child domain.
 
Yes, in the trace I could see the referrals for all the other NCs, and I guess I wondered why the one for the child domain wasn't followed.  I suppose that would mean all of the other ones would have to be followed as well, and as you mentioned, perhaps it is by design because it's probably not what the calling user intended - and possibly the calling user has just learned a little bit more about the referral logic in the process!
 
-DaveC


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Tuesday, July 11, 2006 11:15 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] LDAP Referrals - just curious

Could you give specifics on what exactly you did, i.e. the exact query?
 
The code for adfind by default follows the Windows LDAP lib's default for following referrals which is on. However I think that is limited capability and I specifically chose not to add manual referral chasing code because you will find that many queries that involve the root domain as the base return referrals if you look at the traces. In most cases those referrals are worthless to chase and would simply slow the application down.
 
For instance, let's say you have a directory laid out like
 
domain.com
child.domain.com
 
then you query a DC of child.domain.com with
 
Base: domain.com
Scope: subtree
Query: name=someuser (which is a user object in domain.com)
 
So adfind will go to the DC you specify and issue the query, that DC will throw back a referral to go to a DC of domain.com, the LDAP client software will automatically chase this referral (adfind didn't do anything but let wldap32.dll do what it wanted to do). It will find the object and return it but also it will return referrals for dc=ForestDnsZones,dc=domain,dc=com, dc=DomainDnsZones,dc=domain,dc=com, dc=child,dc=domain,dc=com, and cn=configuration,dc=domain,dc=com which really aren't what the person wanted here most likely.
 
 
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm 
 
Do not read this worthless blog entry on Defending Security Infrastructures -
http://blog.joeware.net/2006/07/11/445/ ---  I'm serious, you will learn absolutely
nothing about Defending Security Infrastructures.


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Cliffe
Sent: Thursday, June 29, 2006 5:43 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] LDAP Referrals - just curious

Hi,
 
    I was curious to watch some LDAP referral traces (OK, so it's been a quiet day) and am seeing some results I don't understand among different tools.  The queries are issued from within a child domain to a DC in that same domain, searching for an object in another child domain (root + two child domains total).  Not using the GC.
 
    LDP chases a referral (if I turn that option on) and returns an object from the other child domain in the forest.  Search call type tested was ASYNC.
 
    DSQuery, after getting an initial  referral to the other domain, reissues the query to a root DC but includes the LDAP_SERVER_DOMAIN_SCOPE_OID control in that search, so then it gets no more referrals to the other child domain.  Not sure why it does that?
 
    ADFind starts off looking good but unbinds and ends the session after getting referral references for the other NCs.  Not sure why it doesn't continue to chase.
 
    I realize I should be providing more info and/or traces.  I will be glad to, but just wanted to save some space first and make sure I wasn't missing something obvious?
 
-DaveC


To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.


To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

Reply via email to