From the author of

From the author of

If you are a typical user, even a so-called power user, you might understand that your organization has a domain that you log into. In fact, you might know that your computer is connected to that domain by permission and that when you hit Ctrl+Alt+Delete you are, in effect, getting the attention of your servers (also known as domain controllers), which look at your credentials (for example, your username and password) and give you access to the network. What you might not know is that your credentials are part of a database that, in the Windows world, is called Active Directory.

NOTE

Active Directory is based off of a standardized directory service called Lightweight Directory Access Protocol (LDAP). LDAP evolved from the X.500 standards and a protocol called Directory Access Protocol (DAP). With the revised, lighter version of DAP came LDAP, which serves as both the service and protocol. Active Directory relies on the same naming structure as DNS (hence primatech.com, which should be registered for the Internet community at large, but the internal DNS doesn’t need to be).

So, besides being a database with your company usernames and passwords, what is Active Directory? First introduced to us with Windows Server 2000, Active Directoryin the most basic of comparisonsmight be likened to a telephone directory, which is information about individuals that is based upon various fields (name, address, telephone number, and so forth). However, in Active Directory, there is identity management, which allows for more advanced control than simply looking up a person to locate their number.

Active Directory allows you to create objects (user accounts, groups, computers, and so forth) that you can then define attributes toward (such as name, address, and department) and utilize within a network to determine login settings, grant permissions for access to resources, computer behavioral auditing, impose policy settings toward, and much, much more. It goes beyond a simple, static directory and is much more dynamic, or active, in its functionality (thus the name) (Figures
1, 2 and 3).

Active Directory was designed to take into consideration the physical and logical sides to a network environment. Consider two users who work in the same building on the same floor for what appears to be the same company. These two users might sit only a few feet apart from each other, but they might have completely different physical and logical Active Directory features.

What Does Active Directory Look Like?

From a physical perspective, Active Directory allows you to group computers (both workstations and servers) into sites. A site typically includes a single subnet or subnets all located within the same physical area. So you might have two offices, one in New York, one in Los Angeles. You should, by rights, have two different sites. But going beyond that, you might have multiple subnets in New York due to the size of that location. You can break that physical location into multiple sites as well (or keep them under one site). Active Directory has been designed to allow for that level of flexibility so that the final design decisions aren’t forced upon the administrative team.

Those sites are helpful because they curtail the amount of replication that occurs between those sites and that gives you the ability to control the amount of bandwidth that is utilized for replication traffic that might be caused by Active Directory itself.

Beyond the physical side, however, there is also the logical side, which allows for even more flexibility in your design of Active Directory objects. Forests, domains, Organizational Unitsthis is the lingo of logical Active Directory.

A forest contains trees, of course (Figure
4). You can see in Figure
4 that in this case, a tree is called a domain. There is a parent domain and there can be sub-domains, called child domains. So you might have a forest with a single domain tree (albeit this would be a very small forest) or you might have multiple domains with multiple child domains all interconnected by transitive two-way trusts.

You can see in Figure 4 that there is an RODC (Read-Only Domain Controller), which provides a readable copy of the database so users can log-in through the RODC but it cannot be used to add new objects to the domain.

Of course, you next question is, "What is a transitive two-way trust?" Well… with domains of the same forest, there might be resources (printers, file servers, and so forth). If a user wants to access a resource in another domain within the same forest, she would obviously need permission to do so. But the ‘trust’ is automatic between domains. One might liken it to two countries which allow individuals to pass back and forth between the countries without a specific visa to do so. So, while a United States citizen might need a passport to enter Canada, he isn't required to obtain a visa the way another country might require of him. The trust is already in place to that extent.

You might wonder why you would create multiple domains. Is it due to locations or departments? Actually, it could be for many different reasons. A parent domain like primatech.com (note the DNS naming structure) might have a research division that is top secret. That research division might want to have special security in place and thus require its own domain. So, you might create the research.primatech.com domain.

Beyond domains being used to create reasonable security or departmental divisions there are Organizational Units (OUs) that are simply containers that hold objects (like Users, Groups, Printers, Computers) for the establishment of policies or administrative control.

So, that pretty much explains the structure from the physical and logical side. You have sites based upon IP subnets, which help to control replication. You have forests, domains, and Organizational Units, which help to logically control your objects (which are users, groups, computers, printers, and so forth).

Is that all? Well…not quite. We haven’t delved deep into the world of LDAP, Kerberos, and DNS, which are all essential aspects to Active Directory. And then there is Group Policy, which has entire books written about it.

Why Did We Tell You All of This?

Some folks want to know what is happening behind the scenes on their network. They don’t understand when they cannot access something or they might not know how it all works (and they would like to). Active Directory is a huge part to understanding the basics of how your organization is put together. Your system has permission to access the services on the domain but you still need to log-in with a registered account. At that point, you get a token that is then your ‘passport’ to accessing other items. It is all controlled and all traceable. Thanks to Active Directory.