LDAP Dialect and search - multi domain?
Gerry Hickman
We have multiple domains. I can issue GetObject() against all of them
WITHOUT specifying a domain name before the DN part of the string. e.g.
oUser = GetObject("LDAP://CN=John Smith, OU=Sales, DC=Company, DC=com")
oUser = GetObject("LDAP://CN=Jeff Smith, OU=Sales, DC=Child, DC=Company,
DC=com")
oUser = GetObject("LDAP://CN=Jane Jones, OU=Sales, DC=NewCompany, DC=com")
BUT
When performing a search for the objects above (using LDAP dialect), I have
to specify the domain for anything that's not rootDSE
<"LDAP://OU=Sales, DC=Company, DC=com">
<"LDAP://child.company.com/OU=Sales, DC=Child, DC=Company, DC=com">
<"LDAP://newcompany.com/OU=Sales, DC=NewCompany, DC=com">
Is there some way I can perform the searches of specific OUs in other
domains without having to insert the domain string after the LDAP:// prefix?
The domain is identified by the DN so I'm not sure why it's needed twice?
Thanks.
--
Gerry Hickman
London (UK)
Joe Kaplan
this, but if there is, enable referral chasing on your search. The reason
you are able to go from domain to domain using serverless binding with
GetObject is likely because referrals are being chased so you should be able
to use that same behavior in a search.
The GC option is probably best though.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Gerry Hickman" <gerry...@newsgroup.nospam> wrote in message
news:eV68OMcQ...@TK2MSFTNGP06.phx.gbl...
Richard Mueller [MVP]
Const ADS_CHASE_REFERRALS_SUBORDINATE = &H20
Set adoCommand = CreateObject("ADODB.Command")
Set adoConnection = CreateObject("ADODB.Connection")
adoConnection.Provider = "ADsDSOObject"
adoConnection.Open = "Active Directory Provider"
Set adoCommand.ActiveConnection = adoConnection
adoCommand.Properties("Page Size") = 100
adoCommand.Properties("Timeout") = 30
adoCommand.Properties("Cache Results") = False
adoCommand.Properties("Chase Referrals") = _
ADS_CHASE_REFERRALS_SUBORDINATE
--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--
"Joe Kaplan" <joseph....@removethis.accenture.com> wrote in message
news:O0sPjDdQ...@TK2MSFTNGP04.phx.gbl...
Gerry Hickman
message news:u%23w3bCeQ...@TK2MSFTNGP05.phx.gbl...
> Using ADO in VBScript I have seen:
>
> Const ADS_CHASE_REFERRALS_SUBORDINATE = &H20
I tried this and it did NOT find objects in the child domain, but after
changing it to ADS_CHASE_REFERRALS_EXTERNAL it works. I tried with and
without the "Page Size" property being set and also with and without "Cache
Results".
Strange?
But more interesting is that the external version also works with the
NewCompany domain, which is in a different forest! Performance seems fast
for all target OUs.
The reason I'd never used "Chase Referrals" in the past was that I assumed
it would be very inefficient.
Joe Kaplan
credentials. Essentially, one directory is sending you to a different
directory to look for an object. To get into that other directory, you will
likely need to authenticate. If you are able to use the same credentials to
authenticate that you used with the initial search, you then need to have
adequate permissions to view results.
The miracle of Windows authentication and trusts actually makes this
potentially possible in directories requiring authentication (like AD).
Otherwise, it turns into a mess quickly. You do still need the appropriate
read permissions in the foreign forest to find the objects you are looking
for.
It can be a useful technique, but you also want to be careful with it and
keep these things in mind.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Gerry Hickman" <gerry...@newsgroup.nospam> wrote in message
news:uUnso4qQ...@TK2MSFTNGP05.phx.gbl...
Gerry Hickman
> The other problem with referral chasing you can run into is with
> credentials. Essentially, one directory is sending you to a different
> directory to look for an object. To get into that other directory, you
> will likely need to authenticate. If you are able to use the same
> credentials to authenticate that you used with the initial search, you
> then need to have adequate permissions to view results.
Thanks Joe,
Yes, I now see there's more to it. When working with three different domains
in two forests, I have to be careful about where the caller code resides and
it's security context. My searches and binds are working (perhaps) because
the two parent domains trust each other and I'm an admin in both. I have a
better understanding of how referrals work now. I now need to plan properly
how my ADSI will work in this new environment.
Gerry Hickman
news:O0sPjDdQ...@TK2MSFTNGP04.phx.gbl...
> this, but if there is, enable referral chasing on your search. The reason
> you are able to go from domain to domain using serverless binding with
> GetObject is likely because referrals are being chased so you should be
> able to use that same behavior in a search.
>
> The GC option is probably best though.
I've now tested the GC option. I didn't know you can specify OU and DC
information for a Global Catalog search - it seems you can! It also find
objects in the child domains.
However, trying to filter on certain attributes did not work. This query
against the GC found 0 computers
"(&(objectCategory=computer)(operatingSystem=*))"
I'm guessing it's because not all attributes exist in the GC?
I then noticed it can't search multiple forests, but after enabling
ADS_CHASE_REFERRALS_EXTERNAL it started working.
I then noticed some very strange behavior when combining these features:
1. GC search over 3 domains in 2 forests
2. "(&(objectCategory=computer)(operatingSystem=*))"
3. ADS_CHASE_REFERRALS_EXTERNAL
What happens here, is that it doesn't find any computers in the forest from
which we are running the code, BUT it finds computers from the two domains
in the other forest! It's as though it's doing a GC search in the initial
forest, but (after chasing referrals) it's doing an LDAP search!
Anyway, I think I now have enough options to get the job done. Essentially,
all I'm trying to do is find an easy way to manage users and computers with
ADSI, regardless of which forest or domain they reside in...
Richard Mueller [MVP]
can tell which attributes are in the GC by looking at the attribute objects
in the Schema container. If the isMemberOfPartialAttributeSet property of
the attribute object is True, the attribute is replicated to the GC.
--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--
"Gerry Hickman" <gerry...@newsgroup.nospam> wrote in message
news:eTQioY1...@TK2MSFTNGP02.phx.gbl...
Joe Kaplan
that and don't know what to expect. It appears that the GC for one forest
is issuing normal LDAP referrals back to the domain in the other forest and
thus you find the objects only in referred to domain for the reason Richard
stated.
I guess I would have expected the GC to issue a referral to the GC in
another forest instead of a domain partition, but I guess I can see why it
might work the other way instead.
All I can say here is "be even more careful". :)
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Richard Mueller [MVP]" <rlmuelle...@ameritech.nospam.net> wrote in
message news:uiil4N3Q...@TK2MSFTNGP02.phx.gbl...
Gerry Hickman
After a lot of multi-forest testing, I decided to abandon the GC and
things like unqualified /rootDSE. What I ended up doing was creating a
set of data structures for all the domains and sub-domains, and then use
these are search bases for subsequent operations. This has the advantage
the the ADsPath of returned objects always has the correct domain string
LDAP://correct.domain/CN=SomeThing,OU=...
Joe Kaplan wrote:
> In regards to combining GC with referral chasing, I've never actually
> done that and don't know what to expect. It appears that the GC for one
> forest is issuing normal LDAP referrals back to the domain in the other
> forest and thus you find the objects only in referred to domain for the
> reason Richard stated.
>
> I guess I would have expected the GC to issue a referral to the GC in
> another forest instead of a domain partition, but I guess I can see why
> it might work the other way instead.
>
> All I can say here is "be even more careful". :)
>
--
Gerry Hickman (London UK)