SM-AD solution approach: LDAP proxies act as the single entry point SC/SM needs and it doesn’t matter if that’s an open source or a commercial proxy like AD LDS.
In a multi domain/forest on the basis of Microsoft AD there is an additional solution http://technet.microsoft.com/en-us/library/how-global-catalog-servers-work(WS.10).aspx
2 way Trust relationship between the current forest or domain (CROWN) and each target forest or domain, have the user name and password for an account with access to each target forest or domain.
LDAP uses a tree structure to search sub-trees or sub-nodes. That is, say you have a root dir of A, there are two children of A called B and C, B and C each have two children (D & E under B and F & G under C). If you set the LDAP base directory to point at B, you may only search on sub-nodes below it (B, D, and E). You will not be searching the C (and F & G children) in your queries. To search B and C (and all children) you have to set the base directory to the most common parent directory above all sub-nodes to be searched.
You can specify one directory and it searches all sub-nodes. This is what I meant by "one base directory" and not being able to search "different base directories".
If you would like to connect and use multiple LDAP sources with different bind requirements, please take a look on the following article: http://support.openview.hp.com/selfsolve/document/KM184786
Set up Global catalog server to query the LDAP server at the root (domain) level and access child domains, use the Global Catalog port of 3268 instead of the domain port of 389 which will allow the query from that LDAP server root level and down.
Next action item: To configure TCP port 3268 so that SM sends the queries to Global Catalog instead of LDAP referral.
To configure, please go to System Navigator -> System Administration -> Ongoing Maintenance -> System -> LDAP Mapping -> Search for operator -> Change the LDAP Port to 3269 as indicated below in screenshots.
How do we direct the query to the global catalog? Rather than relying on the default connection port of 389 simply send the query to TCP port 3268 (or 3269 if SSL encrypted) explicitly in your connection. Here's a MSDN link which goes over this in detail.