- 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
Utilizing Active Directory for the Henderson Environment
Okay, this is all great! A progressive company, ensuring that it can have continued growth with its parent company well into the future. But how does this all fit together to make an article worth reading? Patience my reader, patience.
As part of the global rollout, Henderson wanted to be able to effectively bring staff together from around the globe with an intranet—but not just any old intranet. This one was a little special; it needed to be available 24/7 (global focus now!) and housed in Sydney, Australia. It also had to provide the users at their desktops with the power of a number of features, including a "People Directory" that not only held contact information for all staff around the globe, but also a photograph to ensure that they saw who they were talking to on the other side of the world.
"Okay," KCI said. "We can do that." However, all the functional areas within the intranet needed to be secure, so that a comedian staff member could not just change the CEO's picture to, say, one of Bill Gates.
Simple enough. Let's create groups within AD, and add the users to those groups. If the user has access rights, they can do what they need to do. But we had one little issue: The users were held in not only AD, but also within a SQL Server database. Now, how do we match the users in the SQL Server DB with those in the AD?
After some research, it was discovered that the users (and in fact all objects) in AD were all uniquely identified with a common attribute called a Global Unique Identifier (GUID). This means that no matter where a user (or object) exists within AD (that is, wherever they are in the forest), we can find it via their GUID.
Okay, very cool. We shall just use some ADSI (Active Directory Scripting Interface) to find the user via their GUID, and match them up with SQL Server.
Except, of course, when you bind to an object with ADSI, it will use LDAP queries to go to the object's domain to get the information. With all of the production servers based in Sydney, Australia and a 2MB link to the United Kingdom, you can imagine that this did not scale very well!
Okay, time for Plan B, I thought. What can we do now? So, in comes the Global Catalog (GC) and ActiveX Data Objects (ADO) 2.6.