Active Directory

Active Directory (AD) or Active Directory Domain Services is a directory service developed by Microsoft for Windows domain networks. It uses a structured data store to hierarchically organize domain objects, which typically includes shared resources such as servers, volumes, printers, and the network user and computer accounts. AD also includes a set of rules called the schema, a global catalog of information about every object regardless of which domain in the directory actually contains the data, a query and index mechanism, and a replication service for any change to directory data.

Domain controllers, computers running Windows Server and on which AD is set up, store domain-wide directory data (such as system security policies and user authentication data) and manage user-domain interactions, including user logon processes, authentication, and directory searches.

Development

Windows NT 4.0 allows network management using either peer-to-peer ("workgroup") networking and Microsoft domain networks. Under the latter, logins and user information would be centralized to a single Primary Domain Controller (PDC) and one or Backup Domain Controllers (BDCs). The Windows Internet Name Service (WINS) was used to map computer NetBIOS names to IP addresses. WINS, a Microsoft-centric naming scheme, is inconsistent with Internet standards. NetBEUI, a non-routable technology was the networking solution, not TCP/IP, the Internet standard.

Windows NT 4.0/4.0.1175.1 Setup Server Type window. Before Active Directory, this was the only point a server type could be changed.

Other issues were limited scalability and lack of flexibility. To illustrate the last point, wiping out a system and reinstalling was needed to demote a PDC to a standalone server. Security Account Manager (SAM) account names are not hierarchical. Because SAM names are flat, each one must be unique in the domain.

Cairo

An internal March 1993 Windows Cairo Product Planning document (later offered as a Plaintiff's exhibit and admitted in court for the antitrust case Comes v. Microsoft) described a feature called "Directory Service" in page 5 (or page 8 of the PDF):

Directory Service. Cairo leverages the DFS to provide a Directory Service (DS) data base describing the various resources on the network. The DS does away with the other naming schemes such as drive letters, E-Mail names, disk directories, file shares, printers, or network domains (C:, John Doe@Host, \WINDOWS\SYSTEM, \MTKG\PUBLIC, LPT2:, or “Building 5”), The DS enables administrators to locate, monitor, and manage all information on the entire networked system, including foreign networks.

— Greg Lobdell, I. Product Overview,

A more detailed discussion of "Directory Service" appears in pages 43-45 (46-48 in the PDF) of the planning document:

This is the distributed database used by Cairo to publish. discover, select, and locate network resources.

Goals

The DS provides a means for resources of all types (e.g. users, printers, disk volumes, groups, domains) to be created and published so that all machines in the Cairo distributed system can discover and use them. It provides for interoperability with heterogeneous other directory services, so that Cairo machines can discover and ask to use arbitrary foreign resources as easily as Cairo-provided resources.

Benchmark

CCITT X.500 Directory Services spec (1988 and 1992 editions) is the standard which most DS manufacturers wish to approximate, though virtually nobody wants to follow X.500 exactly due to vague definitions, inefficient protocols, and hard-to-use APIs.

Novell NetWare 4.0 Directory Service is likely to be a de facto standard by the time Cairo ships, and has a large subset of the features that Cairo DS has. It is likely to be the main competition. It is scheduled to ship around March 1993.

Banyan StreetTalk and StreetTalk Directory Assistance were the most widely respected and most functional directory service for PC networks as of 1992. Their very simple design has not prevented them from being very useful.

Unix White Pages and Yellow Pages (aka Network Naming Service) offer a small subset of what Cairo DS needs to offer, and are gradually becoming outdated.

OSF DCE Directory Service is a two-level thing: the upper level is X.500 (see above); the lower part is the Cell Directory Service (CDS), which is shipping today and makes a good RPC name service. (One version of CDS is also known as DEC DNS.)

Features

• Integration with Cairo. The Cairo DS imposes minimal overhead on the system. the programmer, the administrator, and the user, because the DS is simply a use of Cairo itself, not a separate service. DS objects are OFS files and can be manipulated with ordinary file APIs and Cairo storage interfaces. DS query is OFS query. DS wire protocol is the OFS version of Server Message Block (SMB) protocol.

• MAPI address book. Cairo DS also exposes full MAPI 1.0 address book functionality, for compatibility with mail client applications. It is also possible to build MAPI address book providers on downlevel client systems that talk to the Cairo DS, although the Cairo group is not building these.

• DFS features. Cairo DS uses the Cairo Distributed Filesystem to store its data. Therefore the features provided by DFS can be used not only on users’ files but also on DS objects (e.g. users, printers, etc.). A few of the key features are: Hierarchical namespace. Each object in the namespace can have many properties {thanks to OFS). Queries are supported.
• Same namespace for files and services. Because DS objects live in the DFS, the user can browse a single namespace to find both files and other types of resources.

• DS objects cached on workstations. Objects representing services appear not only on the domain controller, but also on the machine that provides the service. This allows machines to access DS objects describing their own local services even when they are off the network.

• Support for email. Cairo DS provides a superset of the major features of the Touchdown directory service being worked on by Microsoft Workgroup Applications. This allows the Touchdown message transfer agent (mail server) to be ported easily to Cairo.

• Global query support. Cairo DS maintains a catalog called the global catalog, which describes most or all of the DS objects from the entire Cairo distributed system in a single list. Thus queries such as “show me all the printers” or “show me all the users named Bill” can be answered quickly and efficiently. The global catalog can be replicated to ensure its availability at all sites on the network.

• Locally stored address books. Workstations can hold a local copy of a subset of the global catalog, e.g. a list of all users and their email addresses.

• Publication of Cairo resources. Cairo DS provides standard and simple means for any Cairo service in the network to give itself a name and describe itself. Once in the DS, the resource can be accessed by name or queried for.

• Publication of foreign resources. With assistance from other tools or administrators, Cairo DS can create listings for resources published by non-Cairo machines Once listed, these resources can be found and used just like Cairo resources. The global catalog can also be configured to include objects which are manually created by the administrator — e.g., entries representing people who do not have computer accounts but whose names and phone numbers are of interest.

• Junction with other directory services. Cairo DS allows the creation of junction points to incorporate other manufacturers’ entire directory services as part of the DS namespace — in effect extending the DFS namespace to engulf additional namespaces. At a minimum Cairo ships with support for junction points to Novell's NetWare 4.x directory service.

• RPC Name Service provider. Cairo DS is a repository where RPC servers can register their existence so RPC clients can connect to them without knowing their address (e.g. by naming them or querying for them), or even without knowing their name (by querying for them).

• X500-like. Cairo DS uses a conceptual model resembling the X.500 DS standard: a tree-structured namespace where every node is an object with a class and one or more properties.

• Flexible administration. The DS provides a single site of administration for many aspects of the Cairo network. Since DS uses flexible, ACL-based security, the network may have anything from a single administrator to many different administrators for many different things. And since the DS is uniformly accessible from all Cairo machines on the network, network administration can be done remotely from any Cairo machine on the network.

Benefits

(See also the benefits in the Distributed Filesystem section.)

Users can browse or query a single place to find resources of any type (e.g. documents, users, printers, disk volumes, groups, domains). All of the facilities provided by DFS (e.g. query and summary catalogs) can be used on all types of resource. This allows for significant simplification of the UI: e.g., finding a user to send email to is no different than finding a printer or a spreadsheet. Administration is simplified on Cairo since the administrative UI (e.g. creating a user) is merged with the Cairo shell (which already supports things like creating a document), and administrative security (e.g. permission to delete a printer) is merged with DFS security (e.g. permission to delete a document).

Resources provided by foreign network operating systems are accessible as seamlessly as Cairo resources: the user need not know that the printer he is sending a job to is on a Novell server, or that the user he is sending an email to is a PROFS email user. Services get a well-defined, standard place to store their configuration information: the file that describes them in the DS. And services no longer need to send out broadcasts to announce their existence, since clients can now find them by asking the DS. For example, the LANMan/WFW browser and the RPC Locator are now obsolete (but are retained for downlevel compatibility).

Disconnected operation is supported by the ability to have a locally stored address book and the ability to have DS data describing local resources and accounts stored on the local workstation.

Cairo DS's conceptual similarity to X.500 eases the future creation of gateways between Cairo DS and other directory services. Special-purpose system databases such as Security Accounts Manager (SAM) are no longer needed because the DS serves as a generic database for system resources.

Compatibility

Cairo DS does not use the API, wire protocol, or on-disk representation of any other manufacturer's directory service. Gateways are provided to allow Cairo DS to incorporate resources from Novell NetWare 3.11, Novell NetWare 4.0, and possibly Banyan Vines and DCE networks. It does use the same API, wire protocol, and on-disk representation as the Cairo components it is based on: OFS, DFS, and catalogs.

Since the DS is used to find RPC servers, mechanisms are provided to make the Cairo DS interoperate with the NT 3.1 RPC Locator. Since the DS is used to find file/print servers, mechanisms are provided to make the Cairo DS incorporate information from the Windows for Workgroups NetBIOS Browser.

Non goal

The first Cairo release will not support non-Microsoft machines accessing the Cairo DS. (The protocols are unique, and no inbound gateways are scheduled to be created.) Workgroup Apps writers might want to do this gateway work in the Cairo timeframe, especially for Macintosh.

Under consideration

It's not clear what tools we will provide to assist in listing foreign resources in the DS, or how automated this process will be - especially for foreign systems other than Novell.

It's not clear whether Cairo DS will be used as a name service by network transports (e.g. an IP address server).

— Aaron Contorer, Directory Service (DS),

Windows 2000

AD was developed by the team of David Thompson, vice president of the Windows Server Product Group at Microsoft. The feature was first publicly demonstrated at Professional Developers Conference (PDC) in 1996. AD was based on the Platinum message store of Exchange Server, designed to be NT's first true directory service, and released with Windows 2000 Server.

As a preview of AD, Microsoft released a beta version of Directory Services Toolkit for Windows NT 4.0. A new version was released on February 1997, called Active Directory Services Interface (ADSI) toolkit. This allowed developers to write applications for AD, Novell Directory Services (NDS), and any Lightweight Directory Access Protocol (LDAP) directory.

According to Thompson, AD was first adopted by their team, then by the Windows team, and then in the Microsoft campus in Redmond, Washington, United States of America, four months before the release of Beta 1 of what was then called Windows NT 5.0. AD in Beta 1, distributed on 20 September 1997 during the PDC, was described as "broken or nowhere to be seen". Despite the feature creep and the Microsoft directive to do what had to be done to ship NT 5.0, the NT team insisted on AD's retention since AD was the reason for customers to upgrade, although the work to be done was difficult:

Making [Active Directory] work is not terribly hard, but having all the infrastructure around the Active Directory--having it be scalable over machines that are different in power by factors of thousands, having it be scalable across companies that are very different in the number of objects they are trying to manage in the Active Directory by a factor of 10--these are tremendous design goals

— Ed Muth, NT group product manager,

Interim build 1773 contains a new user interface and security subsystem for AD. At the NetWorld+Interop keynote address in May 1998, Microsoft Vice President Jim Allchin said that policy-based management in Active Directory was a key element of NT 5.0. AD was finalized in May 1998, along with a one-way Microsoft Directory Synchronization Services (MSDSS) tool that would link the service to NDS. A second beta released on 8 October 1999 allowed two-way synchronization. AD was earlier demoed by Brian Valentine, vice president of Microsoft's personal and business systems group, during TechEd in late May 1999.

Microsoft described AD in Windows 2000 using three perspectives:

• As a store. AD hierarchically stores information about network objects and makes this information available to administrators, users, and applications.

• As a structure. Using AD, the network and its objects are organized by constructs such as domains, trees, forests, trust relationships, organizational units (OUs), and sites.

• Inter-communicate. Because AD is based on standard directory access protocols, it can interoperate with other directory services and can be accessed by third-party applications that follow these protocols.

With the integration of DNS and AD, DNS domains and AD domains use identical domain names. To illustrate, microsoft.com is a DNS domain and an AD domain. However, DNS and AD are different namespaces. DNS stores its zones and resource records; AD stores its domains and domain objects.

AD Domain Controllers (AD DCs) function as peers, replacing the superior/subordinate roles played by PDC/BDC in Windows NT 4.0. Before AD, only the PDC has a read-and-write copy of the directory; the PDC replicates a read-only copy of directory information to the BDCs. With AD DCs supporting multimaster replication, administrators can make updates to AD on any Windows 2000 AD DC in the domain. AD DCs that can be demoted to and promoted from standalone servers at will using the Active Directory Installation wizard (accessed from Configure Your Server), without reinstalling the system.

AD also supports LDAP versions 2 and 3, which is used to find or enumerate directory objects, to query or administer AD, and to enable interoperability with other LDAP-compatible client applications.

AD domain controllers can provide authentication for non-Windows 2000 client systems using RFC-1510 Kerberos, and Windows 2000-based user and computer accounts can be used as Kerberos principals for Unix-based services. UNIX clients and servers with Active Directory accounts can obtain authentication from a domain controller in a Windows 2000 domain.

An AD domain controller can provide authentication for client systems running implementations of RFC-1510 Kerberos, including clients running an operating system other than Windows 2000. Windows 2000-based user and computer accounts can have AD accounts and therefore obtain authentication from a domain controller. A Kerberos principal would be mapped to a Windows 2000 user or computer account in this case.

For backwards compatibility with Windows NT 3.1, Windows NT 3.5, 3.5.1 and 4.0, Windows 2000 installs by default in a mixed-mode network configuration, which supports computers running both Windows NT and Windows 2000 domain controllers. AD supports the Windows NT LAN Manager (NTLM) authentication protocol used by NT, allowing authorized NT users and computers can log on to and access resources in a Windows 2000 domain. A Windows 2000 domain appears to be a Windows NT Server 4.0 domain to Windows NT clients and Windows 95 or 98 clients that are not running Active Directory client software. Support for SAM names is retained as "User logon name (pre-Windows 2000)."

The AD Users and Groups snap-in allows a shared folder to be published as a volume object in AD (also called a shared folder object). The shared folder can easily and quickly be queried in AD.

Microsoft described the following benefits for AD:

The introduction of Active Directory in the Windows 2000 operating system provides the following benefits:

• Integration with DNS. Active Directory uses the Domain Name System (DNS). DNS is an Internet standard service that translates human-readable computer names (such as mycomputer.microsoft.com) to computer-readable numeric Internet Protocol (IP) addresses (four numbers separated by periods). This lets processes running on computers in TCP/IP networks identify and connect to one another.

• Flexible querying. Users and administrators can use the Search command on the Start menu, the My Network Places icon on the desktop, or the Active Directory Users and Computers snap-in to quickly find an object on the network using object properties. For example, you can find a user by first name, last name, e-mail name, office location, or other properties of that person's user account. Finding information is optimized by use of the global catalog.

• Extensibility. Active Directory is extensible, which means that administrators can add new classes of objects to the schema and can add new attributes to existing classes of objects. The schema contains a definition of each object class, and each object class's attributes, that can be stored in the directory. For example, you could add a Purchase Authority attribute to the User object and then store each user's purchase authority limit as part of the user's account.

• Policy-based administration. Group Policies are configuration settings applied to computers or users as they are initialized. All Group Policy settings are contained in Group Policy Objects (GPOs) applied to Active Directory sites, domains, or organizational units. GPO settings determine access to directory objects and domain resources, what domain resources (such as applications) are available to users, and how these domain resources are configured for use.

• Scalability. Active Directory includes one or more domains, each with one or more domain controllers, enabling you to scale the directory to meet any network requirements. Multiple domains can be combined into a domain tree and multiple domain trees can be combined into a forest. In the simplest structure, a single-domain network is simultaneously a single tree and a single forest.

• Information Replication. Active Directory uses multimaster replication, which lets you update the directory at any domain controller. Deploying multiple domain controllers in one domain provides fault tolerance and load balancing. If one domain controller within a domain slows, stops, or fails, other domain controllers within the same domain can provide necessary directory access, since they contain the same directory data.

• Information security. Management of user authentication and access control, both fully integrated with Active Directory, are key security features in the Windows 2000 operating system. Active Directory centralizes authentication. Access control can be defined not only on each object in the directory, but also on each property of each object. In addition, Active Directory provides both the store and the scope of application for security policies. (For more about Active Directory logon authentication and access control, see the "For More Information" section at the end of this paper.)

• Interoperability. Because Active Directory is based on standard directory access protocols, such as Lightweight Directory Access Protocol (LDAP), it can interoperate with other directory services employing these protocols. Several application programming interfaces (APIs) —such as Active Directory Service Interfaces (ADSI)—give developers access to these protocols.

— Microsoft, Active Directory Architecture,

To administer AD, available on the Windows 2000 Server Administrative Tools menu of all Windows 2000 domain controllers are these snap-ins hosted on the Microsoft Management Console:

• Active Directory Users and Computers
• Active Directory Domains and Trusts
• Active Directory Sites and Services
• Active Directory Schema
• Group Policy: for AD management of users, computers, and groups

These standard tools replace the functions of the User Manager, Server Manager, and System Policy Editor from previous versions of NT. Custom tools may be created for single management tasks or individual administrators with specific administrative responsibilities.

Post-Windows 2000

Windows Server 2003 Beta 1 introduced the Domain Controller Upgrade Wizard, allowing administrators to back up the AD database to removable media, and then use that backup to restore it to a new machine. Beta 2 added non-transitive cross-forest trust, allowing companies that merge with or acquire other companies to add those directory structures to their enterprise and link them through one-way or two-way trust. Cross-forest authentication and authorization was also added, along with various deployment and configuration enhancements. Beta 3 added an AD Domain Rename feature that retains Global Unique Identifiers (GUIDs) and Security IDs (SIDs). AD in Beta 3 also allows renaming the root domain, although a sub-domain cannot be made the root domain. Certain classes and attributes may also be deactivated in the AD schema, allowing the development of in-house applications that extend the AD schema without creating schema conflicts. Finally, the Trust Wizard was streamlined, giving administrators one-click access to cross-forest synchronization.

Microsoft revised it to extend functionality and improve administration. Active Directory support was also added to Windows 95, Windows 98, and Windows NT 4.0 via patch, with some unsupported features.

In Windows Server 2008, Microsoft added further services to Active Directory, such as Active Directory Federation Services. The part of the directory in charge of managing domains, which was a core part of the operating system, was renamed Active Directory Domain Services (ADDS) and became a server role like others. "Active Directory" became the umbrella title of a broader range of directory-based services. According to Byron Hynes, everything related to identity was brought under Active Directory's banner.

Active Directory Services

Active Directory Services consist of multiple directory services. The best known is Active Directory Domain Services, commonly abbreviated as AD DS or simply AD.

Domain Services

Active Directory Domain Services (AD DS) is the foundation of every Windows domain network. It stores information about domain members, including devices and users, verifies their credentials, and defines their access rights. The server running this service is called a domain controller. A domain controller is contacted when a user logs into a device, accesses another device across the network, or runs a line-of-business Metro-style app sideloaded into a machine.

Other Active Directory services (excluding LDS, as described below) and most Microsoft server technologies rely on or use Domain Services; examples include Group Policy, Encrypting File System, BitLocker, Domain Name Services, Remote Desktop Services, Exchange Server, and SharePoint Server.

The self-managed Active Directory DS must be distinct from managed Azure AD DS, a cloud product.

Lightweight Directory Services

Active Directory Lightweight Directory Services (AD LDS), previously called Active Directory Application Mode (ADAM), implements the LDAP protocol for AD DS. It runs as a service on Windows Server and offers the same functionality as AD DS, including an equal API. However, AD LDS does not require the creation of domains or domain controllers. It provides a Data Store for storing directory data and a Directory Service with an LDAP Directory Service Interface. Unlike AD DS, multiple AD LDS instances can operate on the same server.

Certificate Services

Active Directory Certificate Services (AD CS) establishes an on-premises public key infrastructure. It can create, validate, revoke and perform other similar actions, public key certificates for internal uses of an organization. These certificates can be used to encrypt files (when used with Encrypting File System), emails (per S/MIME standard), and network traffic (when used by virtual private networks, Transport Layer Security protocol or IPSec protocol).

AD CS predates Windows Server 2008, but its name was simply Certificate Services.

AD CS requires an AD DS infrastructure.

Federation Services

Main article: Active Directory Federation Services

Active Directory Federation Services (AD FS) is a single sign-on service. With an AD FS infrastructure in place, users may use several web-based services (e.g. internet forum, blog, online shopping, webmail) or network resources using only one set of credentials stored at a central location, as opposed to having to be granted a dedicated set of credentials for each service. AD FS uses many popular open standards to pass token credentials such as SAML, OAuth or OpenID Connect. AD FS supports encryption and signing of SAML assertions. AD FS's purpose is an extension of that of AD DS: The latter enables users to authenticate with and use the devices that are part of the same network, using one set of credentials. The former enables them to use the same set of credentials in a different network.

As the name suggests, AD FS works based on the concept of federated identity.

AD FS requires an AD DS infrastructure, although its federation partner may not.

Rights Management Services

Main article: Active Directory Rights Management Services

Active Directory Rights Management Services (AD RMS), previously known as Rights Management Services or RMS before Windows Server 2008, is server software that allows for information rights management, included with Windows Server. It uses encryption and selective denial to restrict access to various documents, such as corporate e-mails, Microsoft Word documents, and web pages. It also limits the operations authorized users can perform on them, such as viewing, editing, copying, saving, or printing. IT administrators can create pre-set templates for end users for convenience, but end users can still define who can access the content and what actions they can take.

Logical structure

Active Directory is a service comprising a database and executable code. It is responsible for managing requests and maintaining the database. The Directory System Agent is the executable part, a set of Windows services and processes that run on Windows 2000 and later. Accessing the objects in Active Directory databases is possible through various interfaces such as LDAP, ADSI, messaging API, and Security Accounts Manager services.

Objects used

File:Publishing Company Network Diagram.png

A simplified example of a publishing company's internal network. The company has four groups with varying permissions to the three shared folders on the network.

Active Directory structures consist of information about objects classified into two categories: resources (such as printers) and security principals (which include user or computer accounts and groups). Each security principal is assigned a unique security identifier (SID). An object represents a single entity, such as a user, computer, printer, or group, along with its attributes. Some objects may even contain other objects within them. Each object has a unique name, and its definition is a set of characteristics and information by a schema, which determines the storage in the Active Directory.

Administrators can extend or modify the schema using the schema object when needed. However, because each schema object is integral to the definition of Active Directory objects, deactivating or changing them can fundamentally alter or disrupt a deployment. Modifying the schema affects the entire system automatically, and new objects cannot be deleted, only deactivated. Changing the schema usually requires planning.

Forests, trees, and domains

In an Active Directory network, the framework that holds objects has different levels: the forest, tree, and domain. Domains within a deployment contain objects stored in a single replicable database, and the DNS name structure identifies their domains, the namespace. A domain is a logical group of network objects such as computers, users, and devices that share the same Active Directory database.

On the other hand, a tree is a collection of domains and domain trees in a contiguous namespace linked in a transitive trust hierarchy. The forest is at the top of the structure, a collection of trees with a standard global catalog, directory schema, logical structure, and directory configuration. The forest is a secure boundary that limits access to users, computers, groups, and other objects.

File:Icons-mini-page url.gif Domain-Boston     File:Icons-mini-page url.gif Domain-New York     File:Icons-mini-page url.gif Domain-Philly   File:Icons-mini-page tree.gif Tree-Southern     File:Icons-mini-page url.gif Domain-Atlanta     File:Icons-mini-page url.gif Domain-Dallas	File:Icons-mini-page url.gif Domain-Dallas   File:Icons-mini-folder.gif OU-Marketing     File:Icons-mini-icon user.gif Hewitt     File:Icons-mini-icon user.gif Aon     File:Icons-mini-icon user.gif Steve   File:Icons-mini-folder.gif OU-Sales     File:Icons-mini-icon user.gif Bill     File:Icons-mini-icon user.gif Ralph
Example of the geographical organizing of zones of interest within trees and domains.

Organizational units

The objects held within a domain can be grouped into organizational units (OUs). OUs can provide hierarchy to a domain, ease its administration, and can resemble the organization's structure in managerial or geographical terms. OUs can contain other OUs—domains are containers in this sense. Microsoft recommends using OUs rather than domains for structure and simplifying the implementation of policies and administration. The OU is the recommended level at which to apply group policies, which are Active Directory objects formally named group policy objects (GPOs), although policies can also be applied to domains or sites (see below). The OU is the level at which administrative powers are commonly delegated, but delegation can be performed on individual objects or attributes as well.

Organizational units do not each have a separate namespace. As a consequence, for compatibility with Legacy NetBios implementations, user accounts with an identical sAMAccountName are not allowed within the same domain even if the accounts objects are in separate OUs. This is because sAMAccountName, a user object attribute, must be unique within the domain. However, two users in different OUs can have the same common name (CN), the name under which they are stored in the directory itself such as "fred.staff-ou.domain" and "fred.student-ou.domain", where "staff-ou" and "student-ou" are the OUs.

In general, the reason for this lack of allowance for duplicate names through hierarchical directory placement is that Microsoft primarily relies on the principles of NetBIOS, which is a flat-namespace method of network object management that, for Microsoft software, goes all the way back to Windows NT 3.1 and MS-DOS LAN Manager. Allowing for duplication of object names in the directory, or completely removing the use of NetBIOS names, would prevent backward compatibility with legacy software and equipment. However, disallowing duplicate object names in this way is a violation of the LDAP RFCs on which Active Directory is supposedly based.

As the number of users in a domain increases, conventions such as "first initial, middle initial, last name" (Western order) or the reverse (Eastern order) fail for common family names like Li (李), Smith or Garcia. Workarounds include adding a digit to the end of the username. Alternatives include creating a separate ID system of unique employee/student ID numbers to use as account names in place of actual users' names and allowing users to nominate their preferred word sequence within an acceptable use policy.

Because duplicate usernames cannot exist within a domain, account name generation poses a significant challenge for large organizations that cannot be easily subdivided into separate domains, such as students in a public school system or university who must be able to use any computer across the network.

Shadow groups

File:Active directory - OUs can not be given rights to objects.png

In Active Directory, organizational units (OUs) cannot be assigned as owners or trustees. Only groups are selectable, and members of OUs cannot be collectively assigned rights to directory objects.

In Microsoft's Active Directory, OUs do not confer access permissions, and objects placed within OUs are not automatically assigned access privileges based on their containing OU. It represents a design limitation specific to Active Directory, and other competing directories, such as Novell NDS, can set access privileges through object placement within an OU.

Active Directory requires a separate step for an administrator to assign an object in an OU as a group member also within that OU. Using only the OU location to determine access permissions is unreliable since the entity might not have been assigned to the group object for that OU yet.

A common workaround for an Active Directory administrator is to write a custom PowerShell or Visual Basic script to automatically create and maintain a user group for each OU in their Directory. The scripts run periodically to update the group to match the OU's account membership. However, they cannot instantly update the security groups anytime the directory changes, as occurs in competing directories, as security is directly implemented into the Directory. Such groups are known as shadow groups. Once created, these shadow groups are selectable in place of the OU in the administrative tools. Microsoft's Server 2008 Reference documentation mentions shadow groups but does not provide instructions on creating them. Additionally, there are no available server methods or console snap-ins for managing these groups.

An organization must determine the structure of its information infrastructure by dividing it into one or more domains and top-level OUs. This decision is critical and can base on various models such as business units, geographical locations, IT service, object type, or a combination of these models. The immediate purpose of organizing OUs is to simplify administrative delegation and, secondarily, to apply group policies. It's important to note that while OUs serve as an administrative boundary, the forest itself is the only security boundary. All other domains must trust any administrator in the forest domain in the forest to maintain security.

Partitions

The Active Directory database is organized in partitions, each holding specific object types and following a particular replication pattern. Microsoft often refers to these partitions as 'naming contexts. The 'Schema' partition defines object classes and attributes within the forest. The 'Configuration' partition contains information on the physical structure and configuration of the forest (such as the site topology). Both replicate all domains in the forest. The 'Domain' partition holds all objects created in that domain and replicates only within it.

Physical structure

Sites are physical (rather than logical) groupings defined by one or more IP subnets. AD also defines connections, distinguishing low-speed (e.g., WAN, VPN) from high-speed (e.g., LAN) links. Site definitions are independent of the domain and OU structure and are shared across the forest. Sites play a crucial role in managing network traffic created by replication and directing clients to their nearest domain controllers (DCs). Microsoft Exchange Server 2007 uses the site topology for mail routing. Administrators can also define policies at the site level.

The Active Directory information is physically held on one or more peer domain controllers, replacing the NT PDC/BDC model. Each DC has a copy of the Active Directory. Member servers joined to Active Directory that are not domain controllers are called Member Servers. In the domain partition, a group of objects acts as copies of domain controllers set up as global catalogs. These global catalog servers offer a comprehensive list of all objects located in the forest.

Global Catalog servers replicate all objects from all domains to themselves, providing an international listing of entities in the forest. However, to minimize replication traffic and keep the GC's database small, only selected attributes of each object are replicated, called the partial attribute set (PAS). The PAS can be modified by modifying the schema and marking features for replication to the GC. Earlier versions of Windows used NetBIOS to communicate. Active Directory is fully integrated with DNS and requires TCP/IP—DNS. To fully operate, the DNS server must support SRV resource records, also known as service records.

Replication

Active Directory uses multi-master replication to synchronize changes, meaning replicas pull changes from the server where the change occurred rather than being pushed to them. The Knowledge Consistency Checker (KCC) uses defined sites to manage traffic and create a replication topology of site links. Intra-site replication occurs frequently and automatically due to change notifications, which prompt peers to begin a pull replication cycle. Replication intervals between different sites are usually less consistent and don't usually use change notifications. However, it's possible to set it up to be the same as replication between locations on the same network if needed.

Each DS3, T1, and ISDN link can have a cost, and the KCC alters the site link topology accordingly. Replication may occur transitively through several site links on same-protocol site link bridges if the price is low. However, KCC automatically costs a direct site-to-site link lower than transitive connections. A bridgehead server in each zone can send updates to other DCs in the exact location to replicate changes between sites. To configure replication for Active Directory zones, activate DNS in the domain based on the site.

To replicate Active Directory, Remote Procedure Calls (RPC) over IP (RPC/IP) are used. SMTP is used to replicate between sites but only for modifications in the Schema, Configuration, or Partial Attribute Set (Global Catalog) GCs. It's not suitable for reproducing the default Domain partition.

Implementation

Generally, a network utilizing Active Directory has more than one licensed Windows server computer. Backup and restore of Active Directory are possible for a network with a single domain controller. However, Microsoft recommends more than one domain controller to provide automatic failover protection of the directory. Domain controllers are ideally single-purpose for directory operations only and should not run any other software or role.

Since certain Microsoft products, like SQL Server and Exchange, can interfere with the operation of a domain controller, isolation of these products on additional Windows servers is advised. Combining them can complicate the configuration and troubleshooting of the domain controller or the other installed software more complex. If planning to implement Active Directory, a business should purchase multiple Windows server licenses to have at least two separate domain controllers. Administrators should consider additional domain controllers for performance or redundancy and individual servers for tasks like file storage, Exchange, and SQL Server since this will guarantee that all server roles are adequately supported.

One way to lower the physical hardware costs is by using virtualization. However, for proper failover protection, Microsoft recommends not running multiple virtualized domain controllers on the same physical hardware.

Database

The Active-Directory database, the directory store, in Windows 2000 Server uses the JET Blue-based Extensible Storage Engine (ESE98). Each domain controller's database is limited to 16 terabytes and 2 billion objects (but only 1 billion security principals). Microsoft has created NTDS databases with more than 2 billion objects. NT4's Security Account Manager could support up to 40,000 objects. It has two main tables: the data table and the link table. Windows Server 2003 added a third main table for security descriptor single instancing.

Programs may access the features of Active Directory via the COM interfaces provided by Active Directory Service Interfaces.

Trusting

To allow users in one domain to access resources in another, Active Directory uses trusts.

Trusts inside a forest are automatically created when domains are created. The forest sets the default boundaries of trust, and implicit, transitive trust is automatic for all domains within a forest.

Terminology

One-way trust

One domain allows access to users on another domain, but the other domain does not allow access to users on the first domain.

Two-way trust

Two domains allow access to users on both domains.

Trusted domain

The domain that is trusted; whose users have access to the trusting domain.

Transitive trust

A trust that can extend beyond two domains to other trusted domains in the forest.

Intransitive trust

A one way trust that does not extend beyond two domains.

Explicit trust

A trust that an admin creates. It is not transitive and is one way only.

Cross-link trust

An explicit trust between domains in different trees or the same tree when a descendant/ancestor (child/parent) relationship does not exist between the two domains.

Shortcut

Joins two domains in different trees, transitive, one- or two-way.

Forest trust

Applies to the entire forest. Transitive, one- or two-way.

Realm

Can be transitive or nontransitive (intransitive), one- or two-way.

External

Connect to other forests or non-Active Directory domains. Nontransitive, one- or two-way.

PAM trust

A one-way trust used by Microsoft Identity Manager from a (possibly low-level) production forest to a (Windows Server 2016 functionality level) 'bastion' forest, which issues time-limited group memberships.

Management tools

Microsoft Active Directory management tools include:

• Active Directory Administrative Center (Introduced with Windows Server 2012 and above),
• Active Directory Users and Computers,
• Active Directory Domains and Trusts,
• Active Directory Sites and Services,
• ADSI Edit,
• Local Users and Groups,
• Active Directory Schema snap-ins for Microsoft Management Console (MMC),
• SysInternals ADExplorer

These management tools may not provide enough functionality for efficient workflow in large environments. Some third-party tools extend the administration and management capabilities. They provide essential features for a more convenient administration process, such as automation, reports, integration with other services, etc.

Unix integration

Varying levels of interoperability with Active Directory can be achieved on most Unix-like operating systems (including Unix, Linux, Mac OS X or Java and Unix-based programs) through standards-compliant LDAP clients, but these systems usually do not interpret many attributes associated with Windows components, such as Group Policy and support for one-way trusts.

Third parties offer Active Directory integration for Unix-like platforms, including:

• PowerBroker Identity Services, formerly Likewise (BeyondTrust, formerly Likewise Software) – Allows a non-Windows client to join Active Directory
• ADmitMac (Thursby Software Systems)
• Samba (free software under GPLv3) – Can act as a domain controller

The schema additions shipped with Windows Server 2003 R2 include attributes that map closely enough to RFC 2307 to be generally usable. The reference implementation of RFC 2307, nss_ldap and pam_ldap provided by PADL.com, support these attributes directly. The default schema for group membership complies with RFC 2307bis (proposed). Windows Server 2003 R2 includes a Microsoft Management Console snap-in that creates and edits the attributes.

An alternative option is to use another directory service as non-Windows clients authenticate to this while Windows Clients authenticate to Active Directory. Non-Windows clients include 389 Directory Server (formerly Fedora Directory Server, FDS), ViewDS v7.2 XML Enabled Directory, and Sun Microsystems Sun Java System Directory Server. The latter two are both able to perform two-way synchronization with Active Directory and thus provide a "deflected" integration.

Another option is to use OpenLDAP with its translucent overlay, which can extend entries in any remote LDAP server with additional attributes stored in a local database. Clients pointed at the local database see entries containing both the remote and local attributes, while the remote database remains completely untouched.

Administration (querying, modifying, and monitoring) of Active Directory can be achieved via many scripting languages, including PowerShell, VBScript, JScript/JavaScript, Perl, Python, and Ruby. Free and non-free Active Directory administration tools can help to simplify and possibly automate Active Directory management tasks.

Since October 2017 Amazon AWS offers integration with Microsoft Active Directory.

See also

BetaArchive forums

• [OFFER] Windows NT Server "Cairo" (the real one!) 4.00.1175
• What became of Windows Cairo

External links

• Active Directory on Wikipedia. This BetaArchive Wiki article began as a fork from its Wikipedia counterpart with revision date of 7 September 2023.
• Microsoft Technet: Detailed description of Active Directory on Windows Server 2003
• Microsoft MSDN Library: [MS-ADTS]: Active Directory Technical Specification (part of the Microsoft Open Specification Promise)
• Active Directory Application Mode (ADAM)
• Microsoft MSDN: [AD-LDS]: Active Directory Lightweight Directory Services
• Microsoft TechNet: [AD-LDS]: Active Directory Lightweight Directory Services
• Microsoft MSDN: Active Directory Schema
• Microsoft TechNet: Understanding Schema
• Microsoft TechNet Magazine: Extending the Active Directory Schema
• Microsoft MSDN: Active Directory Certificate Services
• Microsoft TechNet: Active Directory Certificate Services

Windows 2000

• Microsoft (on the WayBack Machine)
  • Active Directory Architecutre, 12 October 1999 - Full paper on Microsoft Technet (Single technical document that gives an overview about Active Directory.)
  • Active Directory Service Interfaces, 19 April 1999
  • Active Directory Display Specifiers, 19 April 1999
  • Active Directory Service Interfaces Overview, 5 May 1999
  • Active Directory Glossary, 20 July 1999
  • Active Directory Users, Computers, and Groups, 29 February 2000
  • Active Directory Interoperability and Metadirectory Overview, 3 March 2000
  • Active Directory Migration Tool Overview, 10 March 2000
  • Understanding LDAP, 20 September 2000
  • Integrating Applications with Windows 2000 and Active Directory, 1 November 2000
• Paul Thurrott's SuperSite for Windows (on the WayBack Machine)
  • Windows 2000 Server Beta 3 Reviewed
  • The Road to Gold: The development of Windows 2000 Reviewed, December 1999
  • A guide to Active Directory resources, A Windows 2000 technology showcase, updated 6 March 2000
  • Windows 2000 Service Pack 1 Reviewed
  • Part 2: Developing Windows - with discussion on Active Directory rollout in Microsoft before Windows 2000 Beta 1
• IT Pro Today
  • Active Directory (on the WayBack Machine, 14 June 2004)
  • Active Directory in Windows 2000, by Darren Mar-elia, 21 October 1999 (on the WayBack Machine, live version)
  • Planning for Active Directory, by Darren Mar-elia, September 2000 (on the WayBack Machine)
  • Active Directory Sizer by Darren Mar-elia, September 2000 (on the WayBack Machine)