RE: [ActiveDir] LDAP in Multi-domain environments

[Fuller, Stuart]

Mark,   I had a similar situation with the LDAP implementation in the PeopleSoft v8 Portal.    Solved it by configuring the PeopleSoft LDAP request to point at the Global Catalog port (3268) instead of the normal LDAP port (389).  Also configured the LDAP target server to be the PDC FSMO role holder in the forest root domain.    As I understand it....  A LDAP search to the AD LDAP port will only return the objects for the domain of the DC and not the forest.  Since the Global Catalog literally knows about every object in the forest, then a LDAP search on the GC will return any object even across domains.    The one caveat is that with the GC, you only get a subset of attributes for the object and not the full list.  See MS article 256938 and 229662 for information about what attributes are in included in the GC and how to add to that list.   -Stuart Fuller State of Montana     From: Creamer, Mark [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2003 2:18 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] LDAP in Multi-domain environments We have some apps that make LDAP queries to allow a user to log in. Picture an "empty" root with two sub-domains. If the app is to be used only in a single sub-domain, i.e. dc=domain1,dc=company,dc=com, it works fine. If it needs to cross over to the other domain we have, though, i.e. dc=domain2,dc=company,dc=com, we're out of luck. We can't make the root dc=company,dc=com LDAP query search BOTH sub-domains for the user. Is this a limitation of LDAP, or of the apps that are trying to use it? I suspect it's the apps, but maybe there's a global (middleware?) fix someone can suggest?   If any of you are using an app called Kintana and have conquered this problem, I'd especially like to hear from you.   Thanks!   Mark Creamer Systems Engineer Cintas Corporation http://www.cintas.com Honesty and Integrity in Everything We Do