Many administrators today are finding it increasingly difficult to manage their company’s infrastructure as the network and systems continue to grow. If you’re like many admins, you’ve probably been avoiding Active Directory as well, either because you have heard that it is too complex and difficult to administer or because you believe you lack the resources to implement it throughout your organization. All the while, management has been pressuring you to improve network security, asset management, and reduce system administration costs. If this sounds like your working environment, don’t put off the inevitable — it’s time to tackle an Active Directory implementation.
Active Directory was officially rolled out in February 2000 as part of Windows 2000 Server. It has been embraced by the system administration community because it allows for administering Windows 2000 and other Microsoft applications from a single point, which can translate into significant reductions in IT overhead headaches.
Given that some type of Windows server is likely to be in your near-term future, let us delve into the murky details of Active Directory. We will start with how it began and then move on to a detailed look at key AD concepts. Once you gain a solid understanding of the intricacies of Active Directory, you will be able to architect a system properly and deploy it in your organization with confidence.
Active Directory Genesis
Active Directory (AD) was originally created to address the needs of the Microsoft-based user and administrator communities, which desperately needed a comprehensive unified identity management system. It interoperates with and supports key features from several major network protocols — X.500 (sales people initially called Active Directory “X.500-like”), LDAP (Lightweight Directory Access Protocol), and DNS (Domain Name System). This allows AD to interoperate with all the major directory services available, but unfortunately, as is common with many Microsoft implementations of standards-based applications, AD has also taken advantage of minor but significant proprietary differences in several of the protocols — DNS being the most notable.
To best understand Active Directory, we will explain some of the key concepts, starting with the smallest component — an object — and working up to the largest modules — Global Catalogs. Each of the components builds on the smaller one below it.
Objects, Attributes, Object Classes
The basic unit in AD is an Object. Objects are entities that use or are visible on the network, including (but not limited to) users, printers, network devices, computers, applications, and other directories. Attributes are object characteristics. For example, an employee object could have the attribute’s name, e-mail, telephone number, etc. A powerful feature of Active Directory is attribute-level access control. This capability makes it possible for an administrator to be assigned a limited number of attributes to manage, allowing secure distribution of responsibility throughout the organization. A set of objects that share a common set of attributes and are logically grouped together is an object class. Attributes can be shared across multiple classes.
Active directory stores the sets of objects classes in a schema. The schema has a special identifier for each object called an OID — object identifier. Though the schema can be extended for special purpose applications, it is generally recommended to stick with existing Active Directory objects.
An Active Directory container is an object repository that includes objects. Once a container is defined, it can be used for defining the scope replication and access control, including access policies. Containers and the objects within them are hierarchically organized. For example:
My Directory for The Mythical Company People Garfield Lemay Groups Managers Applications Spreadsheets Other
Or in AD vernacular:
O=mythical.com Ou=People Cn=Garfield lemay (other attributes left out like uid, sn, etc.) Ou=Groups Ou=Managers Ou=Applications Ou=Spreadsheets Ou=Other
The above directory has four containers: People, Groups, Applications, and Other. All directory entries for this company must reside in one of these containers. Container names typically start with ou= (or organization unit) — a concept inherited from LDAP/X.500.
Active Directory’s performance is heavily dependent on network topology. A site is a logical group of network subnets with fast and dependable connectivity. The connection between two sites is called the site link. Using site links optimizes Active Directory network traffic. Traffic on site links is usually reserved for directory replication and queries.
Domains are logical hierarchical groupings of containers. Administration, security policies, and replication do not span domains. If administration delegation needs to be done, it must be assigned at the OU level. Site structure is not always directly related to domain structure — there may be multiple sites per domain and multiple domains per site.
The Domain Controllers (DCs) are one or more Windows 2000 servers managing the Active Directory function for a given domain. Each controller contains the entire directory for one domain and only that domain. This means that domain controllers are multi-mastered. Domain Controllers manage the network logon process, directory searches, and other domain operations.
Domain Trees are logical hierarchical groupings of domains forming a contiguous namespace. All domains in the tree have the same schema, domain controller, global catalog, and two-way transitive trust relationship. You can have multiple trees that form disjoint namespaces (i.e. non-sharing) and that support a centralized or decentralized set of domains. The first domain created in the domain tree is the domain root.
Forests are logical hierarchical groupings of domain trees and are the highest level of directory structure. Forests have a common schema, a global catalog, Kerberos trusts to provide an area of absolute trust, and ideally their own corresponding site configuration.
The first domain created in the forest is called the forest root and is also where the forest name is specified. All domain trees in a forest share the same forest root. Two-way transitive trusts are established at the domain root level across domain trees. Each forest is its own disjoint namespace. Typically only one exists in a company directory unless the company is very large or complex.
One way to ensure that forests can be part of a larger global directory is to create a tight coupling between Active Directory and DNS domains. In fact, they must share identical names. The example below shows a possible domain tree namespace:
Dc=com DC=tonight OU=product lines OU=gizmo
Here we can see how the DNS domain of tonight.com would be stored by Active Directory. Note that DC stands for Domain Component and not Domain Controller.
There may be times when you want to create multiple forests for some special situations — for example, when multiple groups want to control their own schema; when multiple groups want to limit who they can trust; or when multiple organizations are responsible for user, network, or peripheral management. Be careful, as introducing multiple forests can increase the level of complexity and administrative overhead.
Domain Controllers often contain global catalogs (GCs) for desktop administration. GCs may be found at the site, domain, and organization unit levels and are always created for the first domain in a forest (the domain root). They contain the entire directory for its domain and a partial directory of other domains in that forest. Because of this cross-connectivity feature, they can quickly find any object in the forest and also provide account information when a user tries to log on to the network via the domain controller.
This tutorial has offered only a small taste of the powerful concepts and utilities built into Active Directory. It is a potent tool for managing large networks of systems across WANs and LANs, but it can be complex to understand and administer. Once you have a good understanding of the inner workings, you will be able to create a robust and flexible architecture that will address your company’s needs now and in the future.
With the basics for AD down, the next step is to gain more in-depth knowledge. The resources listed below provide a wealth of information on intermediate and advanced Active Directory topics.
Official Microsoft Active Directory homepage. Lots of great information and software utilities.
Active Directory Operations Guide. “In the trenches” advice to get you started administering Active Directory. There are many other planning and deploying guides on the Microsoft AD web site as well.
Provides Microsoft and non-Microsoft ADSI links.
Step-by-step guides for performing many Active Directory operations.
Windows Server 2003 resources including Active Directory.
Beth Cohen is president of Luth Computer Specialists, Inc., a consulting practice specializing in IT infrastructure for smaller companies. She has been in the trenches supporting company IT infrastructure for over 20 years in a number of different fields including architecture, construction, engineering, software, telecommunications, and research. She is currently writing a book about IT for the small enterprise and pursuing an Information Age MBA from Bentley College.
Hallett German is an IT consultant who is experienced in implementing stable IT infrastructures with an emphasis on electronic messaging and directories. He is the founder of the Northeast SAS Users Group and former President of the REXX Language Association. He is the author of three books on scripting languages. He is currently seeking challenging opportunities that will expand his directory, networking, and security skills.