Organized

Microsoft software is so widespread in the enterprise environment that it's easy to forget that Windows played a minimal role on the server operating system market back in the 1990s. The market was dominated by Novell NetWare, mainframe solutions, and Unix systems in part. Although Windows theoretically had everything it needed for deployment as a server operating system when NT 4.0 was introduced, it was not until Windows 2000 appeared with Active Directory services that the Windows server operating system really became enterprise-capable.

Just like the Novell Directory Services and their successor eDirectory, Active Directory is based on LDAP. A directory service maps the physical enterprise structure on the intranet, which offers huge benefits in terms of administrative overhead. Administrators have the ability to manage all network resources and user authentication centrally. To allow this to happen, all of the network resources – including users, groups, services, servers, workstations, shares, and devices – are managed in a database [1].

Family Tree

The great-grandfather of all directory services is the Lightweight Directory Access Protocol (LDAP), which dates back to 1993. LDAP is basically a protocol that – at the time – supported standardized access to a DAP database; in other words, it was a front end for the X.500 directory service. Because X.500 is implemented as a complete OSI stack across all seven layers, widespread implementation of the X.500 directory service was impossible. In contrast to X.500, LDAP is based on TCP/IP, which has established itself as the standard protocol on intranets.

LDAP acts more or less as a proxy that mediates between X.500 and DAP. Through the years, LDAP has established itself in its own right, becoming the foundation of all modern directory services. The common ground between all directory services is that they save information in a hierarchical structure and that LDAP uses object-oriented data models as a descendent of X.500. This is why LDAP follows object-oriented programming-like rules in terms of objects and classes, as well as mechanisms such as inheritance and polymorphy.

Objects and Relations

The central task that any directory service performs is that of mapping the objects in the LDAP directory tree and thus allowing relationships between objects to be established. An object in the LDAP directory tree is a directory entry with a unique name (DN) in the Directory Information Tree (DIT).

LDAP distinguishes between object types such as the Organizational Unit (OU) and leaf objects. The former are used to structure the tree and referred to as container objects; other objects can be created inside a container object. Leaf objects are used to manage the resources in the DIT and include the User ID (UID) or Common Name (CN). The designations are derived from the predefined object classes and schemas. An object is a resource that needs to be managed in the DIT.

Different types of resources, such as containers, users, or groups, each have special attributes that describe the properties of the objects. Schemas group the object classes, and LDAP uses a number of standard schemas. LDIF files are used to insert objects into the DIT; these files contain the object classes and attributes with their values for an object to be added to the directory. LDIF files let you create multiple objects at the same time; the ldapadd tool inserts LDAP files into the DIT.

With an OpenLDAP installation on Linux, the administrator can choose from a number of standard schemas out of the box, such as a schema for managing users and groups for POSIX accounts, users and groups for Samba accounts, or mail aliases for Postfix. In many cases, LDAP is also used to authenticate users, for example, against an IMAP server or for protected areas of a web server. It can also handle single sign-on in combination with Kerberos.

The Story Thus Far

In the Microsoft universe, the terms "domain" and "domain controller" play a central role. The domain, as Microsoft understands it, has nothing at all to do with a DNS domain but is an organizational unit on a Windows network that replaces the simple workgroup by a secure resource management concept in Windows NT.

In the Microsoft definition, the domain thus has local security scope with centralized resource management, which at the same time represents an administrative boundary. A domain controller (DC) is a server used to centralize user and computer authentication and authorization on the network. On a network with a domain controller, computers that use the Windows NT operating system and its successors (including clients with XP, Vista, and 7) can be grouped in a domain.

Centralized

In contrast to workgroups in Windows 9x, administrators define users and groups centrally on the domain controller [2]. Each change applies to all computers that are members of the domain. Windows NT always had a single primary domain controller (PDC) that had exclusive write privileges for the domain. It would optionally replicate its database to one or multiple backup domain controllers (BDCs), which had a read-only backup copy of the user and login data and regularly received updates from the PDC.

BDCs were not only useful if you needed to promote a BDC to a PDC in a failover case; they also acted as full-fledged domain controllers for requests that didn't need anything more than read privileges. This fairly simple structure with a single primary domain controller per domain led to uncontrollable domain growth in larger networks and gave the administrator no choice but to go for a flat structure. In most cases, enterprises were unable to map their typically hierarchical structure with the network.

Enterprises with multiple locations or subsidiaries had the option of creating trust relationships between domains, but the resulting structure looked more like a spider's web than a well-organized directory tree of the style that LDAP or Active Directory uses. Today, Active Directory handles far more tasks than LDAP typically did in most Unix environments. Besides user accounts and authentication data, Active Directory also stores the properties and attributes of one or multiple domains.

With the introduction of Active Directory in Windows 2000, Windows administrators finally had the ability to create a hierarchical structure – one that used the Domain Name Service (DNS). Active Directory is capable of scaling to reflect the enterprise hierarchy and network structure, although it is still not based on a cluster architecture. Instead, it's based on intelligent replication mechanisms between various types of domain controllers that understand structuring features, such as the network topology including its subnets or locations.

From an organizational point of view, Active Directory comprises three elements: schemas, configurations, and domains. As in LDAP, the schema is a template for all Active Directory entries (users, components, and printers) and defines object types along with their classes and properties. It also defines the attribute syntax, which is applied in the same way by all domain controllers.

Administrators can define new object types to specify the objects that are available in Active Directory; if needed, you can define a new schema – just as with LDAP – containing the required objects and properties. In Microsoft-speak, configuration means the structure of the Active Directory forest with all of its trees. Finally, the domain stores the information that relates to the objects created in the domain. In terms of replication, note that only schemas and configurations are replicated between all the domain controllers. The border for a full domain replica is the domain itself.

In contrast to Windows NT, only one global catalog plays an important role in Active Directory. The global catalog is the set of all objects in an Active Directory forest. A global catalog server is a domain controller that has a complete copy of all the objects in the directory for the matching host domain and a write-protected partial copy of all the objects in all other domains in the forest. Windows 2000 had an issue with schema updates always triggering a re-initialization of the global catalog. In contrast to Windows NT, all of the domain controllers in Active Directory as of Windows 2000 store a writable copy of the Active Directory database.

When a property is changed on one of the DCs, the change is replicated at regular intervals to all other DCs so that all DCs, except the single master functions, have the same status. In Microsoft-speak, Flexible Single Master Operations (FSMO) are special tasks performed by domain controllers that can be distributed over different servers but are not available simultaneously on multiple servers. In Active Directory, the failure of a DC is non-critical for the Active Directory database because redundancy mechanisms prevent any information loss. It is only when a single master fails that the administrator needs to assign the FSMO roles to one or multiple other DCs as quickly as possible.

Windows servers are not the only servers capable of providing Active Directory services; a Linux server with Samba 4 can also handle this task. As of Microsoft Windows Server 2008, Microsoft additionally introduced the concept of the read-only domain controller (RODC), which is very reminiscent of the backup domain controller in Windows NT. The RODC is a domain controller without write privileges and security-relevant data, which can thus be deployed at a potentially insecure location.

Hierarchy

The Active Directory database hierarchy uses a different structure from LDAP. In AD, the root of the directory service is the Active Directory Forest, a structure that organizes all of the objects in the Active Directory, including properties, rules, and containers. The forest can contain multiple transitively linked trees, each of which can manage one or multiple domains in a directory, which in turn are transitively linked [3].

Active Directory uses the DNS system's defined namespace for domain naming. Within the domain, organizational units (OUs) exist – container objects for grouping other objects in Active Directory. An OU can contain both leaf objects and other OUs. Locations are another organizational feature in Active Directory; they map to physical groups of multiple logical IP subnets. Locations in Active Directory mainly exist to optimize replication because they map to different enterprise locations, which may be linked by slow network technologies such as WAN or VPN. Domains can contain locations, and locations can contain domains.

The way you plan the Active Directory structure is decisive for how well the directory service works, especially considering that retrospective changes can entail substantial overhead. Best practices suggest organizing Active Directory by geographical location, tasks, IT roles, or a combination of these models.

Other Elements

Active Directory is based not just on LDAP and DNS but also on CIFS and Kerberos. CIFS is a print and file service protocol that is implemented by Samba in the Unix world. Kerberos is used for authentication by Active Directory and issues Ticket Granting Tickets (TGT) to this end. A TGT authorizes a user to receive a service ticket for a network service. The complete authentication process takes place in the background after prompting the user to enter their password once only.

Microsoft's DNS implementation uses SRV records. The SRV service (Service Resource Records) makes it possible to use DNS to communicate which IP-based services are offered in a domain. At the same time, the SRV record for a service provides additional information, like the name of the server in question.

Active Directory stores all of this information in a JET Blue database, which is supported by the Microsoft Jet Engine, a transaction-oriented relational RDBMS that uses write-ahead logging. The database file NTDS.DIT contains three main tables: schema table for storing schemas, link table for the object structure, and data table for the data proper. The ESE98 (Extensible Storage Engine) database engine converts the hierarchical Active Directory data into a relational data model.

Setting Up Active Directory

You can set up an Active Directory domain by installing a domain controller, which happens when you either install the Windows server or promote a member server using the dcpromo.exe tool (Figure 1). After creating the domain, you cannot rename the server or the domain. If you want to change the server name, you first have to demote the server using dcpromo.exe; under Windows 2000, this process entails losing all of the existing settings and user accounts.

If you are installing a new Windows server, you can simply select a server role to create a working basic structure automatically for Active Directory. The XP, Vista, and Windows 7 desktop operating systems support Active Directory logins. Incidentally, Microsoft's directory service is officially called Active Directory Domain Services (ADDS) as of Windows Server 2008. On the server side, the current Windows Server 2008 offers the following roles for Active Directory (Figure 2):

• Active Directory Domain Services (ADDS): The current version of what was originally dubbed Active Directory plays a central role in managing Microsoft domains and resources.
• Active Directory Lightweight Directory Services (ADLDS): A feature-stripped version of ADDS for integrating applications or services that rely on LDAP-compliant information from the directory. This role was introduced in Windows Server 2003 and was originally named Active Directory Application Mode (ADAM).
• Active Directory Federation Services (ADFS): Windows Server 2008 uses ADFS for web-based authentication of users outside of the ADDS infrastructure.
• Active Directory Rights Management Services (ADRMS): Provides cryptographic methods to protect Active Directory resources.
• Active Directory Certificate Services (ADCS): Provides a public key infrastructure.

Up to Windows Server 2003, the Microsoft Management Console (MMC) was used to manage the schema attributes. Windows Server 2008 R2 saw Microsoft introduce the AD management center, a more powerful tool that is better equipped to handle management tasks in enterprise environments with multiple domains. Additionally, Microsoft's PowerShell scripting language has become more important – also in terms of Active Directory cooperation – so that many powerful command-line tools exist for PowerShell today. Additionally, administrators all over the world have developed many scripts and external tools [4].

Through the Years

Microsoft equipped its directory service with a couple of interesting features that are not directly related to the core technology right from the outset. They include group policy objects (GPOs), which can be linked to locations, domains, and organizational units in Active Directory. As of Windows 2000, group policies are the keystone of user-friendly privilege management and replace the combination of accounts and system policies under Windows NT. The latter were only applicable at the domain level, and the settings were stored permanently in the user or computer profile and, thus, in the registry. This meant that system policies didn't support policy tattooing; the registry entries were permanent fixtures. Not even deleting ntconfig.pol would change this, because the entries existed in the registry for the object in question.

System policies are always applied to users, security groups, and computers; they were considered insecure because any user with registry access could modify them. Group policies provide a convenient approach to managing servers and clients, partly because they take the hardware, system role, and user type into consideration. The release of Windows Server 2003 saw Microsoft introduce a powerful Group Policy Management Tool (Figure 3).

Microsoft Active Directory saw some major developments up to Windows Server 2008 R2, with experience from deployment in large enterprises flowing into the product. For example, groups in Windows 2000 could contain a maximum of 5,000 members because the replication mechanism wasn't powerful enough for use in a large environment. The reason for the size restriction was that a Windows 2000 domain controller always replicated all groups at the same time, thus causing a peak load on the database.

Windows Server 2003 introduced linked value replication in which the DC only replicates the changes. Additionally, Server 2003 contained a number of improvements in the algorithm used to compute the replication topology. Now Windows Server 2003 no longer needed to store all of its security settings in every Active Directory object; instead, it relied on intelligent links, thus minimizing the size of the Active Directory database. Additionally, Windows Server 2003 introduced cross-tree trusts, or forest trusts.

Windows Server 2003 also replicated DNS names independently of domain borders. To facilitate administration, Windows Server 2003 introduced new command-line tools, such as DSquery or DGet, and supported store queries in the Active Directory Users and Computers MMC module.

Windows Server 2008 was based on SP1 when released so that the service pack for the Vista client released previously could hit the streets at the same time. In terms of Active Directory, this only meant some improvement to details such as the read-only domain controllers (RODCs) referred before. The RODC only replicates changes made locally and doesn't pass them on. Additionally, it only stores a local copy of Active Directory without user and computer passwords.

Windows Server 2008 was also the first version to support different password policies for different user groups (fine-grained password policies). Also, Windows Server 2008 let you set up and manage Active Directory in the revamped and improved server manager, just like any other server role. For the first time, Active Directory snap-ins supported snapshots of the Active Directory. Administrators were then able to use these snapshots to compare settings or document changes. Microsoft also implemented substantial PowerShell-based management functions in Windows Server 2008, but the real highlight was the Group Policy Management Console (GPMC) for centralized client and server management as a core operating system element.

Windows Server 2008 also included a bonus for companies who were unable to do without the legacy WINS service for local name resolution. The reworked DNS version in Windows Server 2008 uses global name zones to support cross-zone resolution of short names.

Windows Server 2008 R2

The current Windows Server 2008 R2 version comes with a number of interesting and useful functions for the admin's daily grind, including some that relate to Active Directory, such as the new Active Directory Management Center (Figure 4), the trash can for Active Directory objects, and offline domain joining.

The highlight is the new Active Directory Management Center, which is independent of the Management Console and an independent application based on PowerShell script underpinnings. The most important thing to mention here is the intuitive and flexible navigation area to the left that lets administrators quickly navigate the Active Directory structure.

The old MMC Active Directory Users and Computers module always took the administrator to the domain node, thus effectively reducing its usability to a single domain. The new Active Directory Management Center lets you freely define the navigation starting point anywhere in the tree. The navigation area also supports two different views. In addition to the traditional console view, where you can click and point to hide and display nodes, you also have the option of a list view.

But the biggest advantage has to be that the GUI application is no longer restricted to a single domain; instead, it takes the whole Active Directory structure into consideration. On top of this, the developers have worked on making searching and browsing in very large directories more efficient. The global search now exclusively references navigation nodes that are displayed in the navigation window. Any objects you find can be modified by multiple selection across domain boundaries. Administrators also have the option of restricting the view in the detail area by applying task-specific filters.

Trash

Another new feature in Windows Server 2008 R2 is the trash can for Active Directory objects, which administrators of older versions sorely missed. This tool lets you restore deleted ("tombstoned") objects. With the new trash can for Active Directory, the Windows server doesn't tag the object as tombstoned but keeps it in the trash can for a default period of 180 days. The server doesn't remove the backlinks until after the tombstone lifetime elapses. That said, however, the trash can is not visible in the GUIs of the available graphical Active Directory tools and is only supported by the RestoreADObject cmdlet.

Offline domain joining is another new feature in Active Directory 2008 R2. Up to this point, a network connection was mandatory for a client to log into an Active Directory domain. This approach was particularly annoying if you wanted to let Windows Vista or Windows 7 join the domain during the install without having configured the network previously. Offline domain joining means that you can postpone the domain join process to the first boot and continue to install the client; this tells the djoin.exe to create a configuration file for the client and create metadata for a computer account in Active Directory. Besides this significant change, the Active Directory PowerShell module has a large number of new cmdlets.

Typing the following gives you an overview:

Get-Command *-AD*

If you are interested in an overview of all the new Active Directory functions in Windows Server 2008 R2, check out the step-by-step guides on Microsoft TechNet [5]. They include hands-on examples of the new functions.

Conclusions

A directory service is indispensable for managing resources on large-scale networks. Although OpenLDAP gives administrators almost infinite flexibility in the open source environment, most distributions actually use only LDAP to authenticate POSIX, Cyrus, or Samba users – and very occasionally computer accounts. One Linux distribution that draws heavily on LDAP and includes a domain concept with matching server and client roles is Univention Corporate Server [6].

Microsoft's server operating system relies on the concept of the domain to manage all of the resources on the enterprise intranet; it would have been difficult to use plain vanilla LDAP for this at the time. Active Directory has developed substantially since Windows 2000 and has achieved notable maturity in its current ADDS guise in Windows Server 2008 R2, thus supporting the management of hundreds of thousands of objects.

The graphical management tools are particularly impressive, although Microsoft has rediscovered the utility value of the command line just recently and promoted the new PowerShell to a central tool in what is the most advanced directory service today.