Networking Basics: Part 9 – Active Directory Information

How objects are stored in the Active Directory

In the last few parts of this article series, I talked a lot about what the Active Directory is, and how it works in regards to your network’s domain controllers. You already know from the previous articles in this series that the Active Directory is essentially a database containing various objects such as user accounts and computer accounts. In this article, I want to continue the discussion by showing you how the Active Directory is structured.

If you have ever used Microsoft Access or SQL Server, then you are probably used to being able to open the database and view it in its entirety. However, none of the primary administrative tools used for managing the Active Directory will allow you to see the entire Active Directory database. Instead, Microsoft provides you with a variety of management tools that each focus on a specific area of the database. As a new administrator, the administrative tool that you will probably use the most often is the Active Directory Users and Computers console.

You can access the Active Directory Users and Computers console from any Windows Server 2003 domain controller by selecting the Active Directory Users and Computers command from the server’s Start / All Programs / Administrative Tools menu.  The console itself looks something like what you see in Figure A

Figure A: The Active Directory Users and Computers console is the primary administrative tool for managing Active Directory objects.

I will later discuss the process of creating or editing Active Directory objects, meanwhile I wanted to go ahead and show you this console because it reveals a little bit the structure of the Active Directory.  If you look at Figure A, you will notice that there are a number of containers, each of which correspond to a specific object type.  Every object in the entire Active Directory is assigned an object type (known as an object class).  Each object also has a number of attributes associated with it.  The specific attributes vary depending on the object type.

For example, the Users container is filled with user accounts, which are all classified as user objects as shown in Figure B. If you were to right click on one of these user objects and choose the Properties command from the resulting shortcut menu, you would see the user objects’ properties sheet, as shown in Figure C.

Figure B: The Users container is filled with user accounts, which are all classified as user objects.

Figure C: When you right click on a user object and select the Properties command from the resulting shortcut menu, you will see the user’s properties sheet.

If you look at figure C, you will see that there are fields for various pieces of information such as first name, last name, telephone number, etc.  Each of these fields corresponds to a specific attribute of the individual object.  Although the majority of the fields shown in the figure are not populated, in a real life situation these fields could be used to create a corporate directory.  In fact, many applications are designed to extract information directly from the Active Directory. For example, Microsoft Exchange Server (Microsoft’s e-mail server product) creates a global address list that is based on the contents of the Active Directory. This global address list is used when sending e-mail messages to other users in the company.

If you look at Figure D, you can see a screen in which I performed a search on the name Hershey (my cat’s name in case you are wondering), and Outlook returned all of the Global Address List entries that contain the name Hershey. Not surprisingly there is only one result. If you look at the results portion of the window though, you can see where Outlook would display the user’s title, business phone number, and location had these fields been populated. All of this information was extracted from the Active Directory.

Figure D

If you wanted to see even more information about the user, you could right click on the user’s name and choose the Properties command from the resulting menu. Doing so would display the screen shown in Figure E. Keep in mind that this is not an administrative screen. This is a screen that any user in the company can access directly through Outlook 2007 in order to find information about other employees.

Figure E: You can view Active Directory information directly through Microsoft Outlook.

It is easy to dismiss the significance of what I just showed you. After all, Outlook is a Microsoft product, so it only makes sense that Outlook would be able to extract information from the Active Directory which is a part of another Microsoft product.

What a lot of people do not realize though, is that it is fairly easy for anyone with the appropriate permissions to extract information from the Active Directory.  In fact, there are countless third party products that are designed to interact with the Active Directory. Some are even capable of storing data in dedicated Active Directory partitions.

The reason why it is possible for you or for third party software vendors to interact with the Active Directory is because the Active Directory is based on a well known standard. The Active Directory is based on a standard called X.500. The X.500 standard is basically just a common way of implementing a directory service. Microsoft is not the only company to create a directory service based on this service. Novell originally created the NetWare Directory Service based on this standard.

There is also a standard way of accessing directory service information. In an Active Directory environment, accessing directory information involves using the Lightweight Directory Access Protocol, otherwise known as LDAP. The LDAP protocol runs on top of the TCP/IP protocol.

The first thing that you need to know about the LDAP protocol is that whoever named it must have been on crack, because there is nothing lightweight about it (although it is more lightweight than the original directory access protocol, which was not designed to take advantage of the TCP/IP protocol stack). Entire books have been written on LDAP, and an in depth discussion is not really appropriate at this point in the article series.

What I will tell you is that every object in the Active Directory is refered to by a distinguished name (often abbreviated as DN). The distinguished name is based on the object’s position within the directory hierarchy. There are many different components that can go into a distinguished name, but some of the more common ones are a common name (abbreviated as CN) and a domain name (abbreviated as DC). For example, suppose that the Contoso.com domain contained an account named User1, and the account was located in the Users container. In such a situation, the distinguished name for the user account would be:

CN=User1, CN=Users, DC=Contoso, DC=com

In this article, I have explained that information stored in the Active Directory can be used by external applications through the use of the LDAP protocol. In the next article in this series, I will continue the discussion of distinguished names as they relate to the Active Directory.