- Active Directory Overview
- Active Directory in a Real-Life Global Organization
- Utilizing Active Directory for the Henderson Environment
- Getting the Most Out of the Global Catalog
- Some Hints and Tips for Accessing the Global Catalog within Active Directory
- What You Should Watch Out For!
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Some Hints and Tips for Accessing the Global Catalog within Active Directory
Okay, so by now you have an overview of what KCI did at Henderson and how to access the GC with ADO. Now, we will take a look at some of the best practices when accessing the GC within AD.
Boy, it's lucky for you, my reader, that I have been through this already. Here are some of the things I learned from the work that was completed for Henderson.
Use ADO to get records back from AD; these are lighter weight than the ADSI objects for reading, and generally tend to be faster under load (sometimes up to 2 seconds per instantiation!).
Don't expect to get all of the attributes from the GC about a user. Things such as the sAMAccountName and password are replicated around the forest (although you can't get a user's password from AD), but unless they belong to Universal groups, their group information is not replicated around the forest.
Be careful with your queries. Like SQL Server you should bring back only the attributes that you really need.
Watch out for special attributes, such as the objectGUID. These are stored in formats that you don't quite expect, and can really throw you!
Use the GC for your queries rather than LDAP queries. GC queries will go to the server(s) closest to the server that issued the request, whereas LDAP will tend to go to the source server.
Microsoft's recommendation is that you go to the root of the forest to retrieve information from the GC, unless you bind to specific server. Why? Well, Microsoft won't guarantee the results of the information in other domains within your forest unless you bind to a specific server.
Don't use AD to store all your general user data. Even if AD will store all sorts of attributes—such as pictures, addresses, phone numbers, and so on—it is designed as a write-once, read-many type database. Information such as addresses that can regularly change (especially in a large organization) will kill your performance. It is better to abstract these attributes out to a SQL Server Database, and "link" AD to SQL Server via the user's GUID.