Understanding Active Directory, part 1

To fully understand Windows 2000, you need to have a good grasp on Active Directory. Follow Jim Boyce's series of Daily Drill Downs to learn more about Active Directory and how it fits into your organization's network structure.

Active Directory (AD) is by far the most significant new feature in Windows 2000, entwining itself in one way or another around a good portion of the other new features. You can’t set up a Windows 2000 server or even log in to a Windows 2000 domain without AD. Understanding AD is, therefore, an important step in fully understanding Windows 2000 and its implications for your organization. This article begins a series of Daily Drill Downs on AD, its features, and how it can fit into your organization’s network structure.

What’s a directory service, and why do you need it?
In perhaps the simplest terms, a directory service is a container that provides a hierarchical structure in which to store objects for quick and easy access and manipulation. In some ways, a directory service is a little like an electronic phone directory that lets you query a subscriber’s name and retrieve the subscriber’s phone number, address, or other information without knowing where that person lives. In actual practice, a directory service—particularly AD—is much more than that.

Before directory services, network resources were organized primarily by computer name, workgroup, or domain. If you needed a specific file, for example, you needed to know not only the name of the file but also the server on which it was stored and the path to its folder. If you needed to print to a specific printer, you needed to know the name of the server that managed the printer’s queue. On a small network, this type of structure works fine. As the network grows, however, finding and managing resources can be a challenge, particularly for inexperienced or casual users. A directory service like Active Directory is designed to simplify resource access and management.

A directory service provides a means for users and administrators to locate resources regardless of where those resources are located. Whether the object is a folder, file, printer, or service, such as DNS, the directory service makes it possible for you to use the object without any knowledge of where the object is physically located. You simply look in the directory, which organizes the resources in a logical way, to locate and use the resource you need. The resource’s location is transparent to you, and that’s OK—you don’t need to know that a particular file is located in a particular folder on a particular server in a particular division of the company. You just need to be able to use it.

Active Directory is Microsoft’s answer to directory services, and it does a lot more than let you use folders and files without knowing their physical location. AD is the foundation for Windows 2000’s domain security and most other higher-level services. If you’re planning to implement Windows 2000 Servers in your enterprise, you need to fully understand AD, its function, and its uses.

Distributed security
Even in small networks, a typical user could have more than one user account or password, and the number grows as the network grows and expands beyond the boundary of the user’s immediate vicinity. Perhaps you have one account for your domain, another on a NetWare server, another for your e-mail account, and so on. Keeping all of those accounts and passwords straight can be a headache as the number grows. It’s hardly a unified system.

Windows 2000 and AD address the problem by using Kerberos authentication and single sign-on (SSO) as the default authentication mechanism. Kerberos originated at MIT in the UNIX realm and is now a de facto standard supported by a wide range of operating system vendors including Microsoft, Apple, Sun, and Novell. SSO refers to Kerberos’ ability to provide a user with one set of credentials and grant them access across a range of resources and services with that same set of credentials. Kerberos authenticates the credentials and issues the user a ticket with which the user gains access to the resources and services that support Kerberos.

No longer must you use multiple accounts to access the resources in your enterprise—a single account suffices when all of the servers support Kerberos. AD doesn’t provide SSO by itself, though, but rather stores the user information required to support Kerberos in a single repository. AD, therefore, works in conjunction with Kerberos and SSO to offer much-simplified and distributed security.

User management
Simplified user management is another important benefit of AD. Different services often require different user credentials or related user information, which often is stored in various places—the domain, member servers, the e-mail server, the voice mail system, and so on. In addition, effective management means applying appropriate restrictions to the tasks a user can perform. Because the typical business environment is dynamic, changes to user policies can occur often.

AD simplifies user management by acting as a single repository for all of this user- and computer-related information. Rather than manage user credentials in several locations, you manage the credentials in one place—AD. Group policies that determine the rights and restrictions that apply to a user are also stored in AD, giving you a one-stop shop for administration. As you’ll learn later, AD’s structure provides a great deal of flexibility in the way you manage users and assign policies.

Distributed administration
As a network grows in size, the ability of one person to manage all aspects of the LAN quickly diminishes. While AD centralizes information about resources, users, and computers, it decentralizes administration. AD’s structure is hierarchical and compartmentalized, which means specific services can be stored in their own containers or in containers with related objects. You can apply permissions to these containers within AD to define which administrators have access and their levels of access. In Windows NT it’s nearly impossible to segregate administrative functions; in Windows 2000 it’s a snap, thanks to AD. You simply apply permissions, as needed, to different administrative functions and effectively decentralize administration. One group can be fully responsible for mail services, another for user management, another for DNS servers, another for Web services, and so on, without having any permissions in the other administrative groups.

What about X.500 and LDAP?
Directory services are not a new technology development. The precursor to today’s directory services is the X.500 specification that emerged from the International Telecommunications Union, formerly the CCITT. The X.500 specification was intended as an open standard for developing an open and cross-platform distributed directory service. X.500 sits at the Application layer in the OSI model, the structure that defines the majority of today’s network technology. X.500 comprises several component databases that act together as a single entity. The primary element of the X.500 composite database is the Directory Information Base (DIB), which stores information about the objects in the directory and serves essentially as the key for objects in the directory service.

Like any new technology, X.500 had its limitations, particularly its lack of integration with the Internet Protocol (IP). The protocol in the X.500 specification that enabled services to access information stored in the directory was Directory Access Protocol, or DAP. DAP offered more functionality than necessary for implementing directory services, so a pared-down version called Lightweight Directory Access Protocol (LDAP) soon became the next contender for king of the directory service hill. LDAP has been adopted as a standard by the Internet Engineering Task Force (IETF) and offers several improvements over its predecessor.

First, LDAP relies on the TCP/IP stack rather than the OSI stack, integrating with IP and enabling IP clients to use LDAP to query LDAP-compliant directory services. Second, LDAP can perform hyper-searches, giving one directory the ability to defer to another to provide requested data. In effect, the directories are hyperlinked. Third, LDAP’s API is C-based, making it easily accessible and strongly supported by the majority of developers interested in tying into or expanding directory services.

Like X.500, LDAP uses an inverted-tree hierarchical structure (you’ll learn more about AD’s structure shortly). LDAP supports Kerberos authentication, Simple Authentication Security Layer (SASL), and Secure Sockets Layer (SSL).

Microsoft’s Active Directory is not X.500-based but naturally models some of its structure from X.500. AD uses LDAP as its access protocol, essentially making it open to all platforms (at least those that support LDAP). As you’ll learn later, AD also relies on DNS as its locator service, enabling clients to locate domain controllers through DNS queries.
Now that you have some background in directory service history and purpose, you’re ready for a look at the Windows 2000 AD in particular. For the rest of this article, we’ll look at some of AD’s naming conventions, its reliance on DNS, and some basics about AD objects, databases, and schema.
Naming conventions
As mentioned, AD is a repository of information about objects in your enterprise. These objects can represent computers, users, printers, services, or other related objects or resources. As I’ll explain in more detail later, AD functions as a container with nested containers holding other containers or objects. These containers and objects need names in order for them to be managed and queried, so AD must support some type of naming scheme. In fact, AD supports several.

The first naming scheme, and the one you’ll probably find most familiar, complies with the RFC 822 specification. While that specification name probably doesn’t ring a bell, you know it as the format used by Internet e-mail addresses and other Internet services. These names are also referred to as User Principal Names, or UPN. They take the form user@domain. A typical UPN would be something like

As you delve deeper into AD, setting up domains and user accounts, you’ll find that login names in a Windows 2000 domain take the same UPN form. An example of a valid Windows 2000 domain login name would be

While the domain portion of the name typically references the user’s login domain, it doesn’t have to. For example, you might choose the user’s e-mail address to use as their UPN if the login domain is different from the user’s e-mail domain. This simplifies login for the user, as he then only needs to remember his e-mail address. In terms of AD, this sample name would actually be referenced as; LDAP converts the name as needed.

LDAP names are used to query AD. LDAP names are attributed names, which specify the name attributes of the object in question. These attributes come from the path of AD containers in which the object is stored. The full name of an object is called the distinguished name, or DN. Like a Fully Qualified Domain Name (FQDN) in the DNS system, the DN uniquely identifies the AD object, as no two objects in AD can have the same DN. AD supports LDAP v2 and v3 naming conventions but drops c=country and replaces the o=organization component with dc=domain component, as in the following:
cn=common name
ou=organizational unit

Using the previous name as an example and making an assumption that the person works in the support department, you could query AD through the following URL:

In most cases, you won’t concern yourself with naming conventions when you’re managing objects in AD since the various management tools interact with the underlying AD mechanisms to present objects in a more user-friendly way. Even so, it’s good to understand some of the underlying structure, particularly if you will be using LDAP to query AD or if you will be creating custom applications to extract information from AD.

DNS reliance
If you’re not using DNS now, you will be when you implement Windows 2000 Server and the Active Directory. That’s why I prefaced this series on AD with an in-depth look at Windows 2000 DNS. You can install DNS prior to, during, or after AD installation. You’re not necessarily forced to use Windows 2000 DNS to use AD, but the DNS service you use must support service resource (SRV) records. The service must additionally support the dynamic update protocol specified by RFC 2136. Windows 2000 DNS provides both capabilities in addition to other benefits, such as AD integration of DNS zones for replication and security, so it is generally your best bet.

To be completely accurate, AD relies on DNS as its primary locator service, but that doesn’t mean DNS is the only mechanism for locating domain controllers (DCs). Such reliance would address neither the needs of Windows NT/Windows 9x systems that also belong in the domain, nor networks in which TCP/IP is unavailable (such as NetBEUI-only LANs). Therefore, the domain controller locator that runs in the context of the Net Logon service can use either DNS or NetBIOS to locate DCs. This is why even though Windows 2000 computers use their DNS names for identification, they must still have NetBIOS names.

When a Windows 2000 DC starts, it registers both its DNS name and NetBIOS name. It uses DDNS to register LDAP-specific SRV records in DNS to enable LDAP clients to locate DCs through LDAP queries. The DC also registers Kerberos v5 authentication protocol-specific SRV records to enable clients to locate servers running the Kerberos Key Distribution Center (KDC) service. (These records aren’t readily apparent because they are buried deep within the zone structure, but you’ll find them if you try.) Finally, each DC also registers an A record that enables clients that don’t support SRV records to locate the DC through a simple host record lookup.

In some cases, however, registration of the A record could cause problems. For example, a Web server in your domain might register the same domain name as an AD domain, causing problems when clients attempt to connect to the Web server and get the IP address of the DC instead. So, Windows 2000 provides a way to disable automatic registration of the A record for DCs. Open the Registry Editor and locate the key HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\Netlogon\Parameters. If the entry DnsRegisterARecords exists, set it to 0. If the entry doesn’t exist, create it as a DWORD value in the specified key and set it to 0.

For now, understand that when you begin implementing AD, you’ll either have your DNS servers ready to accommodate AD’s needs or will implement the DNS service in conjunction with your AD rollout. Plan accordingly.

Active Directory as a database
You might have already realized that like DNS, AD is a distributed database. What’s more, AD represents a database management system because it provides a means of managing, viewing, and manipulating the data contained in AD. This database is designed in several layers that include the Core Directory Service Agent (DSA), Database Layer (DB), and Extensible Storage Engine (ESE). Above those layers lie the Security Account Manager (SAM), LDAP interface, and Replication layers, as shown in Figure A.

Figure A
These are Active Directory’s layers.

The ESE comprises two tables that define the structure of the directory and is essentially invisible to clients. The Database Layer includes three tables that define the contents of AD:
  • Schema table—This table defines the types of objects that can be created in the directory, how those objects relate to one another, and the mandatory and optional attributes of each object. In short, this table stores the directory’s schema (more on that later).
  • Link table—This table stores the data that defines how objects relate to one another in the database.
  • Data table—While the Schema table defines object structure, this table contains the object data. This includes such things as user accounts (names, login names, passwords, etc.), groups, application data, and so on.

While you don’t need to be a database programmer to use or manage AD, understanding that it is a database will help you understand the objects it can contain, which I discuss next.

Active Directory objects
Earlier you read that a directory service is essentially a container that can contain other containers. This is certainly true of AD. Objects in AD can be either containers for other objects or they can be leaf objects, which do not serve as containers. A user object is an example of a leaf object because it stores user data but does not contain other objects.

A good analogy for AD's structure in terms of its objects is the DNS name space and a typical file system. Both are object trees that have a root, and both have a hierarchical structure underneath the root. Using the file system analogy, container objects in AD are like folders in the file system—they can contain other folders or can contain files. The difference is that in AD an object can contain other containers or can contain leaf objects, but not both. This is similar to a folder that can contain either subfolders or files, but not both.

Objects in AD have attributes, and these attributes not only define the object but also store data. For example, a user object would have a password property that stores the user’s password. The user’s first name would be another property, as would be phone number. The name of a domain is one of the domain object’s properties, and so on. Some attributes are mandatory, while others are optional.

One attribute that is mandatory is the globally unique identifier, or GUID. AD assigns a GUID, which is a 128-bit number, to an object when it is created. No two objects in AD have the same GUID. If an object is moved within AD, it retains its GUID, which enables it to be located even if it moves.

Like objects in the NTFS file system, registry keys and other Windows 2000 objects in AD are protected by Access Control Lists (ACLs). This provides for distributed administration by enabling you to assign permissions on objects to restrict the actions that individual users or groups can take on those objects. In order to administer a given DNS zone, for example, you must have the necessary permissions to do so. Those permissions are defined by the ACLs associated with that DNS zone object in AD.

Active Directory schema
A key element of AD is the schema. AD’s schema is the set of rules that define AD and the objects it contains. When you create objects in AD, those objects must conform to the schema, or they can’t be added. For example, you must provide those object properties that are defined as mandatory by a given object when you create it.

Object properties are just one aspect of the schema, however. The schema controls naming structure, data types, object types, and so on. The schema is not an inflexible set of rules laid down when you install AD. Rather, the schema is not only fluid but also extensible—you can modify the schema or extend it to add additional object classes. However, objects in AD must still conform to the new schema. In general, this type of manipulation of AD requires programming, but most administrators won’t delve into AD that deeply. Nevertheless, understanding the structure the schema imposes on objects and object classes will help you understand how to structure your AD and domains when the time comes.

What’s next?
Up to this point, I’ve primarily discussed the history and inner structure of Active Directory to give you a background for putting AD into place and designing your directory according to your organization’s needs. In the next Daily Drill Down, I’ll switch gears and start looking at the topics you’ll deal with as you begin designing your domain structure.

Jim Boyce is a former contributing editor and monthly columnist for WINDOWS Magazine. Jim has authored and co-authored over 40 books about computer software and hardware. He has been involved with computers since the late 1970s as a programmer and systems manager in a variety of capacities. He has a wide range of experience in the MS-DOS, Windows, Windows NT, Windows 2000, and UNIX environments. In addition to a full-time writing career, Jim is a founding partner and vice president of Minnesota Webworks, a Midwest-based Web development firm.

The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox