Active Directory
Active Directory
Main page
A

Active Directory

logo
Community Hub0 subscribers
Read side by side
Active Directory
View on Wikipedia
from Wikipedia

Active Directory (AD) is a directory service developed by Microsoft for Windows domain networks. Windows Server operating systems include it as a set of processes and services.[1][2] Originally, only centralized domain management used Active Directory. However, it ultimately became an umbrella title for various directory-based identity-related services.[3]

A domain controller is a server running the Active Directory Domain Services (AD DS) role. It authenticates and authorizes all users and computers in a Windows domain-type network, assigning and enforcing security policies for all computers and installing or updating software. For example, when a user logs into a computer which is part of a Windows domain, Active Directory checks the submitted username and password and determines whether the user is a system administrator or a non-admin user.[4] Furthermore, it allows the management and storage of information, provides authentication and authorization mechanisms, and establishes a framework to deploy other related services: Certificate Services, Active Directory Federation Services, Lightweight Directory Services, and Rights Management Services.[5]

Active Directory uses Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Microsoft's version of Kerberos,[6] and DNS.[7]

Robert R. King defined it in the following way:[8]

"A domain represents a database. That database holds records about network services-things like computers, users, groups and other things that use, support, or exist on a network. The domain database is, in effect, Active Directory."

History

[edit]

Like many information-technology efforts, Active Directory originated out of a democratization of design using Requests for Comments (RFCs). The Internet Engineering Task Force (IETF) oversees the RFC process and has accepted numerous RFCs initiated by widespread participants. For example, LDAP underpins Active Directory. Also, X.500 directories and the Organizational Unit preceded the Active Directory concept that uses those methods. The LDAP concept began to emerge even before the founding of Microsoft in April 1975, with RFCs as early as 1971. RFCs contributing to LDAP include RFC 1823 (on the LDAP API, August 1995),[9] RFC 2307, RFC 3062, and RFC 4533.[10][11][12]

Microsoft previewed Active Directory in 1999, released it first with Windows 2000 Server edition, and revised it to extend functionality and improve administration in Windows Server 2003. Active Directory support was also added to Windows 95, Windows 98, and Windows NT 4.0 via patch, with some unsupported features.[13][14] Additional improvements came with subsequent versions of Windows Server. In Windows Server 2008, Microsoft added further services to Active Directory, such as Active Directory Federation Services.[15] The part of the directory in charge of managing domains, which was a core part of the operating system,[15] was renamed Active Directory Domain Services (ADDS) and became a server role like others.[3] "Active Directory" became the umbrella title of a broader range of directory-based services.[16] According to Byron Hynes, everything related to identity was brought under Active Directory's banner.[3]

Active Directory Services

[edit]

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

[edit]

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.[17]

Lightweight Directory Services

[edit]

Active Directory Lightweight Directory Services (AD LDS), previously called Active Directory Application Mode (ADAM),[18] implements the LDAP protocol for AD DS.[19] 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

[edit]

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.[20]

AD CS requires an AD DS infrastructure.[21]

Federation Services

[edit]
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.[22] AD FS supports encryption and signing of SAML assertions.[23] 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.[24]

Rights Management Services

[edit]
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.[25]

Logical structure

[edit]

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.[1] Accessing the objects in Active Directory databases is possible through various interfaces such as LDAP, ADSI, messaging API, and Security Accounts Manager services.[2]

Objects used

[edit]
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.[26]

Forests, trees, and domains

[edit]

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.

    Domain-Boston
    Domain-New York
    Domain-Philly
  Tree-Southern
    Domain-Atlanta
    Domain-Dallas
Domain-Dallas
  OU-Marketing
    Hewitt
    Aon
    Steve
  OU-Sales
    Bill
    Ralph
Example of the geographical organizing of zones of interest within trees and domains

Organizational units

[edit]

The objects held within a domain can be grouped into organizational units (OUs).[27] 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.[28] 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
[edit]
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.[29]

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. 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 to maintain security.[30]

Partitions

[edit]

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.[31] 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

[edit]

Sites are physical (rather than logical) groupings defined by one or more IP subnets.[32] 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.[33] 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 in the forest.[34][35]

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.[36] 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

[edit]

Active Directory uses multi-master replication to synchronize changes,[37] meaning replicas pull changes from the server where the change occurred rather than being pushed to them.[38] 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.[39]

Implementation

[edit]

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.[40] However, Microsoft recommends more than one domain controller to provide automatic failover protection of the directory.[41] Domain controllers are ideally single-purpose for directory operations only and should not run any other software or role.[42]

Since certain Microsoft products, like SQL Server[43][44] and Exchange,[45] 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.[46] 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[47] 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.[48]

Database

[edit]

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.[49] 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.[49]

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

Trusting

[edit]

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

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

[edit]
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.[53]
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.[54][55]

Management tools

[edit]

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

[edit]

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:

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).[59] 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.[citation needed]

Administration (querying, modifying, and monitoring) of Active Directory can be achieved via many scripting languages, including PowerShell, VBScript, JScript/JavaScript, Perl, Python, and Ruby.[60][61][62][63] 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.[64]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Active Directory

View on Grokipedia
from Grokipedia
Active Directory (AD) is a directory service suite developed by Microsoft for Windows domain networks, providing centralized management of users, computers, and other network resources through authentication, authorization, and policy enforcement.[1] At its core, AD Domain Services (AD DS) stores directory data in a hierarchical, database-driven structure that organizes objects like user accounts, groups, and devices, making them accessible via standards such as Lightweight Directory Access Protocol (LDAP) and Kerberos for secure logon and access control.[2] This enables administrators to implement single sign-on, group policies, and resource delegation across environments ranging from small offices to global enterprises.[2] First previewed in 1999, Active Directory was officially released on February 17, 2000, as a key feature of Windows 2000 Server, marking a shift from earlier Windows NT domain models to a more scalable, LDAP-compliant system influenced by internet standards like X.500.[3] Over the years, it has evolved through integrations with subsequent Windows Server versions, incorporating enhancements for security, replication, and hybrid cloud compatibility, while maintaining backward compatibility with legacy systems.[2] Today, AD remains foundational for on-premises identity management, supporting over 90% of Fortune 1000 organizations as of 2020 despite the rise of cloud alternatives.[4] The suite comprises several interoperable services beyond AD DS: Active Directory Federation Services (AD FS) facilitates secure cross-organization authentication and single sign-on; Active Directory Certificate Services (AD CS) manages public key infrastructure for encryption and digital signatures; Active Directory Lightweight Directory Services (AD LDS) offers a simplified directory for line-of-business applications without full domain overhead; and Active Directory Rights Management Services (AD RMS) enforces persistent data protection policies.[1] Key operational elements include domain controllers for data replication, the global catalog for efficient querying across forests, and a flexible schema that defines object attributes and relationships.[2] These components ensure high availability, fault tolerance, and extensibility, with replication mechanisms distributing updates multimaster-style to prevent single points of failure.[2]

History

Origins and Early Development

The development of Active Directory originated from Microsoft's efforts to create a robust directory service influenced by international standards for directory systems. In the late 1980s, the foundational concepts began at 3Com as an X.500-like directory service using a C-Tree database on OS/2, which was transferred to Microsoft in 1991 through a technology deal.[5] By the mid-1990s, Microsoft integrated these ideas into broader networking initiatives, drawing heavily from the ITU-T X.500 standards established in 1988, which defined a hierarchical model for directory services, and the Lightweight Directory Access Protocol (LDAP), developed in the early 1990s as a simplified access method to X.500 directories.[2] The design process aligned with evolving IETF Requests for Comments (RFCs) in 1996 and 1997, particularly the LDAPv3 specification series (RFCs 2250–2256), which standardized directory access and schema definitions that Microsoft adopted to ensure interoperability. In 1996, following the release of Exchange Server 4.0, Microsoft's Exchange Directory Service team adapted existing directory sources for the Windows platform, incorporating enhancements like a MAPI RPC interface and query engine, laying the groundwork for Active Directory.[5] Active Directory was developed as a core component of Windows 2000, marking a shift from the flat domain model of Windows NT to a scalable, hierarchical structure. This evolution replaced the limitations of NT domains, which relied on primary domain controllers, with a multi-master replication model inspired by X.500's directory information tree.[2] The service was officially released on February 17, 2000, alongside Windows 2000 Server, after years of internal development that began accelerating in the mid-1990s under projects like Cairo before pivoting to Windows NT successor efforts.[3] The initial goals of Active Directory centered on providing centralized authentication and resource management within enterprise networks, while ensuring seamless integration with the Domain Name System (DNS) for location services. It incorporated Kerberos version 5 (as defined in RFC 1510) for secure authentication, enabling single sign-on across domains and replacing NTLM as the primary protocol.[2] This integration with DNS allowed Active Directory to leverage existing internet standards for name resolution, facilitating easier deployment in heterogeneous environments.[6] Key milestones included beta releases in 1999, starting with Beta 3 in April, which introduced early Active Directory functionality for testing, followed by additional betas in October that added features like two-way synchronization.[7] These previews enabled administrators to evaluate the service's hierarchical model and Kerberos integration ahead of the full launch.[5]

Evolution Through Windows Server Versions

Active Directory (AD) has undergone progressive enhancements across Windows Server versions, focusing on improved security, scalability, manageability, and hybrid cloud integration to address evolving enterprise needs. Windows Server 2003 introduced domain and forest functional levels, enabling administrators to unlock advanced AD features—such as renameable domains and forest trusts—once all domain controllers in the environment were upgraded to this version.[8] These levels provided a mechanism to phase in capabilities without disrupting mixed environments, marking a shift toward more flexible AD deployments.[9] With Windows Server 2008, AD gained read-only domain controllers (RODCs) for secure deployment in branch offices, where physical security might be limited, as RODCs replicate only necessary data and support credential caching policies.[10] Fine-grained password policies allowed multiple password and account lockout settings within a single domain via Password Settings Objects, eliminating the need for subdomains.[11] The Active Directory Recycling Bin enabled recovery of deleted objects without restoring from backups, reducing downtime from accidental deletions.[11] Windows Server 2012 emphasized virtualization support, allowing virtual domain controllers to operate without unique identifiers and enabling safe deployment in Hyper-V environments with features like virtual DC cloning. In Windows Server 2016, privileged access management (PAM) was introduced through Microsoft Identity Manager, supporting just-in-time administration to grant temporary elevated privileges and mitigate risks from standing administrator accounts, along with Credential Guard for isolating NTLM hashes and Kerberos tickets in a secure process to mitigate pass-the-hash attacks.[12] [13] Azure AD Connect, launched in 2014 and refined in these versions, facilitated hybrid identity synchronization between on-premises AD and Azure AD (now Microsoft Entra ID), enabling seamless single sign-on and password hash sync for cloud workloads.[14] Windows Server 2019 and 2022 built on prior security foundations with further enhancements against pass-the-hash attacks, such as expanded use of Credential Guard and just-in-time administration principles integrated via PowerShell Just Enough Administration (JEA), allowing constrained endpoints for delegated tasks without full privileges.[13][15] These versions also improved hybrid capabilities, with tighter Entra ID integration for conditional access and multifactor authentication in mixed environments. Released on November 1, 2024, Windows Server 2025 extends the AD schema through new files—sch89.ldf, sch90.ldf, and sch91.ldf—adding attributes for enhanced object management and compatibility with modern workloads.[16] It introduces a new domain functional level (level 10). Schema extensions provide improved replication efficiency through features like adjustable replication priorities for specific naming contexts and optimized LDAP queries, along with reduced database overhead via the Database 32k Pages feature, supporting larger-scale deployments.[9][17][16] DTrace integration provides advanced diagnostics for troubleshooting replication and performance issues without external tools.[18] Security is bolstered with randomized default machine account passwords to counter legacy vulnerabilities, such as those exploited in 2020s attacks like pass-the-hash in unpatched environments.[16] Over these versions, AD has adapted to cloud-native paradigms through hybrid models with Microsoft Entra ID, addressing 25-year-old legacy issues like weak credential storage and replication exposures that fueled attacks in the 2020s, such as those targeting Kerberos delegation flaws.[19] This evolution prioritizes zero-trust principles, with features like Protected Users (from 2012 R2 onward) limiting credential reuse to thwart theft vectors.[20]

Overview

Definition and Core Functionality

Active Directory is a directory service developed by Microsoft for Windows domain networks, functioning as a hierarchical, distributed database that stores and manages information about network resources and objects, such as users, computers, groups, printers, and shared folders.[2][21] This structure allows administrators to organize and locate directory data efficiently, providing a centralized repository for identity and resource management in enterprise environments.[22] At its core, Active Directory provides authentication mechanisms using protocols like Kerberos version 5 as the primary method, with NTLM serving as a fallback for compatibility in certain scenarios.[23][24] It supports authorization through Group Policy Objects (GPOs), which enable administrators to define and enforce security settings, software deployment, and configuration policies across users and computers.[25] Additionally, Active Directory facilitates single sign-on (SSO) via Kerberos tickets, allowing authenticated users to access multiple permitted resources within a domain or forest without repeated credential prompts.[23] In Windows environments, Active Directory centralizes user and device identities, streamlining administration by integrating with domain controllers to verify credentials and apply policies consistently.[2] It enforces security policies to control access to resources, such as file shares and applications, while enabling efficient resource sharing through directory-based queries and permissions.[21] This integration ensures secure, scalable management of networked systems in organizations relying on Microsoft infrastructure.[22] Active Directory builds upon the LDAP version 3 standard as its primary access protocol but incorporates Windows-specific extensions, including support for the Security Account Manager Remote (SAMR) protocol for replicating account data across domain controllers.[26][27] These enhancements enable seamless integration with Windows authentication and policy systems, distinguishing it from generic LDAP implementations.[28]

Key Benefits and Use Cases

Active Directory Domain Services (AD DS) provides centralized management capabilities that significantly reduce administrative overhead in enterprise environments by allowing administrators to configure and enforce policies across multiple systems from a single console. Through Group Policy Objects (GPOs), organizations can standardize user and computer configurations, such as security settings and software deployment, streamlining operations and ensuring consistency without manual intervention on individual machines.[25][29] The service's scalability supports large networks, enabling the management of millions of directory objects through partitioning and replication mechanisms that distribute data across domain controllers. Each domain controller can handle nearly 2.15 billion objects over its lifetime, making it suitable for global enterprises with extensive user bases and resources. In Windows Server 2025, updates such as the optional 32k database page size enhance this scalability by increasing support for multivalued attributes up to 3,200 per object, improving performance for large-scale deployments while requiring forest-wide compatibility.[30][16] Security benefits include role-based access control (RBAC) implemented via security groups and delegation, which enforces least-privilege principles to limit administrative access and mitigate risks. Auditing features track changes to directory objects, providing detailed logs for compliance and threat detection, with recommendations for enabling object access auditing to monitor sensitive operations.[19][31][32] In enterprise identity management, Active Directory serves as a central repository for user authentication and authorization, facilitating secure access to on-premises resources like file shares and printers. For on-premises network authentication, it integrates with Kerberos and NTLM protocols to verify user identities across domain-joined devices. In hybrid cloud setups, it enables single sign-on (SSO) across applications by synchronizing with Microsoft Entra ID, allowing seamless access to both on-premises and cloud services without repeated credential entry.[2][33][34]

Services

Domain Services

Active Directory Domain Services (AD DS) is the core component of Active Directory, functioning as a directory service that stores and manages information about network resources and objects, such as users, computers, groups, and printers, in a secure, hierarchical structure. It enables centralized identity management by providing authentication mechanisms like Kerberos and NTLM, as well as authorization through access control lists and group policies, allowing administrators to enforce security and configuration across an enterprise network. AD DS operates as a distributed database, ensuring data availability and consistency through domain controllers that host replicas of the directory.[2][35][2] The primary storage mechanism for AD DS is the directory store, implemented as the NTDS.dit file, which contains the Extensible Storage Engine (ESE)-based database holding all directory objects and attributes. This file is located by default in the %SystemRoot%\NTDS folder on each domain controller and supports multimaster replication to maintain synchronization in environments with multiple domain controllers. The replication service in AD DS facilitates the distribution of directory updates across domain controllers using a pull-based model, where changes are propagated via remote procedure calls over RPC, ensuring fault tolerance and load balancing without delving into site-specific topologies.[30][36][2] AD DS supports domain and forest functional levels, which define the available features and schema capabilities based on the lowest version of Windows Server running on domain controllers in the environment. For instance, the Windows Server 2025 functional level builds on prior versions by introducing enhanced security features, such as randomly generated 120-character machine account passwords and new schema attributes for advanced local administrator password management via Windows LAPS, enabling rollback detection and automatic password rotation. Raising the functional level requires all domain controllers to support the target version and is irreversible, ensuring compatibility while unlocking schema extensions for modern workloads.[9][16][18] A key prerequisite for AD DS deployment is integration with Domain Name System (DNS), as it relies on DNS for service location and name resolution to enable clients to discover domain controllers and resolve names like SRV records for authentication services. Without proper DNS configuration, such as Active Directory-integrated zones, domain joins and logons will fail, making DNS a foundational element often hosted on the same domain controllers for seamless operation. For non-domain scenarios, Active Directory Lightweight Directory Services (AD LDS) offers a simplified variant without full authentication overhead.[6][37]

Lightweight Directory Services

Active Directory Lightweight Directory Services (AD LDS) is a directory service implementation that enables organizations to deploy standalone LDAP directories tailored for specific applications, without requiring integration into a full Active Directory Domain Services (AD DS) domain or forest.[38] It originated from Active Directory Application Mode (ADAM), introduced in Windows Server 2003, and evolved into a core Windows Server role starting with Windows Server 2008, supported in Windows Server 2025, with enhancements introduced in this version.[39][16] AD LDS provides a data store and access mechanisms using standard protocols like LDAP, allowing applications to store and retrieve directory data efficiently while minimizing administrative overhead.[40] Key features of AD LDS include the ability to host multiple independent instances on a single server, each with its own configuration set, port assignments, and schema, which supports customized data structures for diverse applications.[41] Schema extensions are managed per instance, permitting organizations to define object classes and attributes without affecting a global schema, thus enabling flexible data modeling for application-specific needs.[39] Replication is supported between AD LDS instances, allowing data synchronization across servers using the same mechanisms as AD DS, such as multi-master replication, to ensure consistency in distributed environments.[39] Unlike full AD DS, AD LDS does not enforce domain-based authentication by default, though it can optionally leverage AD DS for security principals if integrated in a shared configuration.[38] In contrast to AD DS, which manages enterprise-wide identity and access through structured domains and forests, AD LDS operates without these hierarchical elements, resulting in a smaller resource footprint and simpler deployment on member servers or standalone systems.[40] It avoids the complexities of domain controller promotion and forest-wide policies, focusing instead on application-centric directories that can be installed, restarted, or removed without rebooting the host system or impacting existing AD DS environments.[41] This independence makes AD LDS suitable for scenarios where full domain infrastructure would introduce unnecessary overhead or security risks.[38] Common use cases for AD LDS include integrating legacy applications that rely on LDAP directories but do not require domain authentication, such as custom enterprise software or third-party tools needing partitioned data stores.[41] It is particularly valuable for scalability in large deployments, where multiple isolated instances prevent schema conflicts and allow targeted replication for high-availability application data.[39] For example, organizations use AD LDS to support directory-enabled web applications or messaging systems without exposing the core AD DS schema.[41]

Certificate Services

Active Directory Certificate Services (AD CS) is a role service in Windows Server that enables organizations to build and manage a scalable public key infrastructure (PKI) for issuing and managing digital certificates. It allows the creation, distribution, and revocation of X.509 certificates used for authentication, secure email, secure web access, and other cryptographic operations within an enterprise environment.[42] AD CS supports automated certificate lifecycle management, including issuance, renewal, and revocation, to ensure secure identity verification and data protection across networked systems.[42] The core component of AD CS is the Certification Authority (CA), which acts as the trusted root for certificate issuance. Enterprise CAs integrate directly with Active Directory Domain Services (AD DS) to leverage directory information for certificate templates, auto-enrollment, and policy enforcement, making them suitable for domain-joined environments.[42] In contrast, standalone CAs operate independently without requiring AD integration, offering flexibility for non-domain scenarios but lacking automated features like group policy-based enrollment.[42] Another key component is the Online Responder, which provides Online Certificate Status Protocol (OCSP) services to deliver real-time revocation status checks for certificates, reducing reliance on Certificate Revocation Lists (CRLs) and improving performance in large-scale deployments.[42] AD CS deeply integrates with Active Directory to publish certificates and certificate revocation lists (CRLs) directly to user and computer objects in the directory, enabling seamless access for authentication processes.[42] This integration supports auto-enrollment through Group Policy, where eligible users and devices automatically request and receive certificates without manual intervention, enhancing security for scenarios like smart card logon.[42] For example, smart card authentication uses AD-published certificates to verify user identities at logon, providing strong two-factor protection tied to physical tokens.[42] In Windows Server 2025, AD CS benefits from Active Directory schema extensions introduced via three new log database files (sch89.ldf, sch90.ldf, and sch91.ldf), which expand the schema to support advanced features including improved certificate attribute handling in hybrid environments.[16] These updates enhance compatibility for certificate-based authentication in mixed on-premises and cloud setups, such as with Microsoft Entra ID, by allowing richer attribute storage and retrieval.[16] Additionally, security hardening measures, like stronger certificate binding enforcement via KB5014754, mitigate risks in certificate-based authentication on domain controllers.[43]

Federation Services

Active Directory Federation Services (AD FS) is a Microsoft service that enables secure identity federation and single sign-on (SSO) across organizational boundaries by implementing claims-based authentication.[44] It allows organizations to share digital identities and entitlements without exposing sensitive authentication data, extending SSO capabilities to Internet-facing applications and services.[44] AD FS supports key protocols such as WS-Federation for passive requestor profiles, SAML 2.0 for web browser SSO, and OAuth 2.0 for modern authorization scenarios, facilitating interoperable claims issuance and validation.[45] The core components of AD FS include federation servers, which are Windows Servers configured to issue security tokens and manage the federation service configuration database.[45] Federation server proxies provide secure external access by acting as intermediaries between Internet clients and internal federation servers, relaying authentication requests without direct exposure of the internal infrastructure.[45] Relying party trusts define the relationships with external applications or partners, specifying identifiers, endpoints, and claims rules to enforce secure token consumption.[45] Common use cases for AD FS involve enabling SSO for cloud-based applications, such as Microsoft 365 (formerly Office 365), where users authenticate once against on-premises Active Directory and gain seamless access to cloud resources.[46] It also supports partner extranets by establishing federated trusts that allow controlled access to shared resources without requiring separate credentials or directory synchronization.[44] AD FS supports enhancements for zero-trust models, including extended protection for token validation to mitigate man-in-the-middle attacks and the use of hardware security modules (HSMs) for securing token signing certificates, ensuring continuous verification of identities and entitlements. Note that the Windows Internal Database (WID), used by default for AD FS configuration, is deprecated in Windows Server 2025 and scheduled for removal in a future release; Microsoft recommends using SQL Server as an alternative.[47][48] These improvements align with broader security best practices, such as enforcing multifactor authentication (MFA) for extranet access and integrating with monitoring tools for real-time token activity oversight.[47]

Rights Management Services

Active Directory Rights Management Services (AD RMS) is a server role in Windows Server that enables organizations to protect sensitive digital information through Information Rights Management (IRM) technology, applying persistent usage policies to documents, emails, and other files regardless of their location.[49] These policies use encryption and digital rights management to enforce restrictions such as preventing printing, copying, or editing, ensuring that access is tied to user identities authenticated via Active Directory (AD).[50] By embedding rights directly into the content, AD RMS provides ongoing protection even when files are shared outside the organization's network.[51] The core components of AD RMS include the server infrastructure, which consists of a root certification cluster for issuing certificates and a licensing cluster for distributing use licenses, both hosted on Windows Server and relying on a SQL Server database to store configuration data, policy templates, and licensing information.[52] The client component, available on Windows operating systems from Vista onward, uses libraries like Msdrm.dll to encrypt content, request publishing licenses from the server, and acquire end-user licenses to decrypt and enforce rights.[51] For administrative recovery, AD RMS features a Super Users Group—a configurable mail-enabled distribution group in AD—that grants designated members full access to all protected content, enabling decryption for purposes such as eDiscovery, auditing, or data recovery without needing individual publisher permissions.[53] AD RMS policies are defined through customizable templates stored on the server and distributed via Group Policy or direct download, allowing administrators to specify granular restrictions based on AD security groups, such as permitting view-only access, revoking edit rights, or setting expiration dates for content usage.[52] These templates integrate seamlessly with AD for user and group validation, ensuring that rights are dynamically evaluated against the directory's identity store during license issuance.[49] Integration with other Microsoft services enhances AD RMS functionality; for instance, it works with Microsoft Exchange Server to apply IRM protections to emails, automatically encrypting messages based on predefined templates and enabling features like transport decryption for compliance scanning.[54] Similarly, Microsoft Office applications support AD RMS natively, allowing users to protect Word documents, Excel spreadsheets, and PowerPoint presentations by applying rights policies during creation or sharing.[51] For cross-organization scenarios, AD RMS can briefly reference federation through Active Directory Federation Services (AD FS) to extend protections to external users without detailed cross-realm configurations. Note that the Windows Internal Database (WID), used by default for AD RMS configuration, is deprecated in Windows Server 2025 and scheduled for removal in a future release; Microsoft recommends using SQL Server as an alternative.[48]

Logical Structure

Directory Objects and Schema

Active Directory directory objects serve as the fundamental units of data storage and management within the directory service, representing entities such as users, groups, computers, and contacts. Each object is an instance of one or more predefined classes and possesses a set of attributes that describe its properties, such as the sAMAccountName for unique logon identification and the distinguishedName for hierarchical positioning.[55][56][57] The Active Directory schema provides the formal definitions for these object classes and attributes, ensuring consistency across the forest. It consists of classSchema objects that categorize objects with shared characteristics—for instance, the user class defines attributes like name and email—and attributeSchema objects that specify data types, constraints, and whether attributes are mandatory or optional for each class.[55][56] The schema utilizes a fixed set of syntaxes for attribute values, such as strings or integers, and supports extensibility through updates that add new classes or attributes without altering existing ones.[56][55] Naming conventions in Active Directory follow LDAP standards to uniquely identify objects within the directory hierarchy. The distinguished name (DN) is a full path comprising a sequence of relative distinguished names (RDNs) separated by commas, where each RDN is derived from a naming attribute of the object, such as the common name (CN).[58] For example, a user's DN might be "CN=John Doe,OU=Users,DC=example,DC=com," with "CN=John Doe" as the RDN.[58] The Global Catalog maintains a partial replica of all objects across the forest to facilitate efficient cross-domain queries, storing a subset of attributes for each object rather than the full set.[59] This includes essential attributes like object class and sAMAccountName, enabling universal group membership lookups and authentication without full replication.[60] These objects are organized within the logical hierarchy of domains and organizational units, as detailed in subsequent sections.[21]

Forests, Trees, Domains, and Organizational Units

Active Directory organizes its logical structure hierarchically, beginning with the forest as the highest-level container. A forest serves as the top-level security boundary, encompassing one or more domain trees that share a common schema, configuration, and global catalog, enabling unified management and forest-wide searches.[21] Within a forest, all domains are connected by default two-way, transitive trust relationships, allowing authentication and resource access across the entire structure while maintaining security isolation between forests.[21] A tree within a forest is a hierarchical arrangement of one or more domains that share a contiguous namespace based on DNS conventions, such as a parent domain like example.com and child domains like sub.example.com.[21] This structure facilitates organized naming and administration for related domains, with automatic transitive trusts linking all domains in the tree to support seamless user authentication and policy enforcement across them.[21] Multiple trees can exist in a single forest if their namespaces are distinct, but they all inherit the shared forest-wide attributes like schema and configuration.[21] At the core of this hierarchy is the domain, which functions as a logical security unit and the primary partition for managing user identities, authentication, and authorization.[21] Each domain maintains its own security boundary, supported by domain controllers that handle authentication requests and enforce domain-specific policies, such as Group Policy Objects for configuring users and computers.[21] Domains form the building blocks of trees and forests, with the first domain in a forest automatically establishing it, and additional domains added for scalability, such as regional divisions to accommodate up to 100,000 users per domain based on network capacity.[61] Microsoft recommends limiting forests to no more than 10 domains for optimal manageability.[61] Organizational units (OUs) provide sub-containers within a domain to logically group objects such as users, groups, computers, and resources, enabling targeted administration without creating additional domains.[21] OUs support delegation of administrative authority through access control lists (ACLs), allowing OU owners to manage their subtree independently while the forest owner retains overarching control to address issues like ACL errors.[62] They are essential for applying Group Policy Objects to specific sets of objects, enhancing policy granularity and organizational autonomy within the domain structure.[62] OU design emphasizes delegation needs, object visibility limits, and clear ownership documentation, typically dividing into account OUs for identities and resource OUs for managed assets.[62]

Partitions and Global Catalog

Active Directory divides its directory data into logical partitions to enable efficient storage, management, and replication of information across the forest. These partitions, also known as naming contexts, segment the data based on scope and purpose, ensuring that only relevant information is replicated to the appropriate domain controllers. The primary partitions include the domain partition, configuration partition, schema partition, and application partitions.[63] The domain partition holds the core directory objects specific to a single domain, such as user accounts, computer objects, and group policies, allowing for domain-specific management and authentication. This partition is replicated only among domain controllers within the same domain, preventing unnecessary data propagation to other domains in the forest. In contrast, the configuration partition stores forest-wide settings, including details on sites, services, and replication topology, and is replicated to every domain controller across the entire forest for consistent global configuration.[63][21][63] The schema partition defines the structure of all objects in the directory by containing classSchema and attributeSchema objects that specify allowable classes and attributes throughout the forest. Like the configuration partition, it replicates forest-wide to all domain controllers, ensuring a uniform schema across the environment. Additionally, application partitions, introduced in Windows Server 2003, allow administrators to store custom application-specific data with flexible replication scopes, enabling replicas to be placed only where needed rather than domain- or forest-wide.[63][64] To support forest-wide queries and authentication without requiring access to every domain controller, Active Directory uses the Global Catalog (GC), which maintains a multi-master replicated partial replica of key attributes from all objects across every domain in the forest. This partial replica includes essential attributes like object names, email addresses, and security identifiers, facilitating quick searches and universal group membership checks during logon processes. GC servers respond to queries over TCP port 3268 using LDAP, with port 3269 for secure LDAPS connections, optimizing performance for cross-domain operations.[65][65][66]

Physical Structure

Sites, Subnets, and Domain Controllers

Active Directory organizes its physical infrastructure through sites, which serve as logical representations of an organization's physical network topology, typically aligned with geographic locations or IP subnets to optimize authentication and replication traffic. Sites help minimize wide-area network (WAN) usage by directing clients to the nearest domain controller (DC) and controlling inter-site replication schedules, ensuring efficient performance in distributed environments. For instance, a multinational company might define separate sites for its headquarters in New York and a branch office in London, each encompassing local subnets to route traffic locally rather than across costly links. Subnets are IP address ranges associated with specific sites, enabling Active Directory to determine client location and affinity for the closest DC during logon and service requests. When a client authenticates, it queries DNS to locate a DC in its assigned site based on the subnet mask, such as associating 192.168.1.0/24 with the "New York Site" to prevent cross-site queries unless necessary. This mapping is crucial for load balancing and fault tolerance, as multiple subnets can link to one site while a single subnet cannot span multiple sites. Domain controllers are Windows Server instances that host the Active Directory Domain Services (AD DS) database, handling authentication, authorization, and directory queries for users and computers within a domain. Each DC maintains a writable copy of the directory partition for its domain, with additional roles such as Global Catalog (GC) servers that index objects across the forest for faster cross-domain searches, or Flexible Single Master Operations (FSMO) roles like the Schema Master, which uniquely manages schema updates forest-wide. DCs can be promoted from member servers using the Active Directory Domain Services Configuration Wizard in Server Manager or PowerShell cmdlets such as Install-ADDSDomainController.[67] They use Kerberos for secure communication. Read-only domain controllers (RODCs) extend AD DS to less secure locations like branch offices by providing a one-way, read-only replica of the directory partition, reducing exposure to physical threats or credential theft. RODCs cache a filtered subset of credentials for authorized users, pulling updates from writable DCs via replication, and they support features like password replication policy to control which accounts are cached locally. This design enhances security in perimeter networks, as RODCs cannot process certain operations like password changes and log suspicious activities for auditing.

Replication Processes

Active Directory Domain Services (AD DS) employs a multi-master replication model, where updates can originate from any writable domain controller, ensuring loose consistency with eventual convergence across the directory.[68] This approach allows for high availability and flexibility, as changes propagate asynchronously without requiring a single authoritative source, though it relies on mechanisms to resolve conflicts through timestamps and versioning.[69] Replication operates in two modes differentiated by site boundaries: intra-site replication, which occurs frequently (default every 15 seconds to 3 minutes) within the same site using low-cost, uncompressed RPC over IP for rapid synchronization among nearby domain controllers; and inter-site replication, which is scheduled based on site link configurations (default every 180 minutes) and uses compressed RPC over IP to minimize bandwidth usage across slower WAN links.[36][70] Intra-site replication assumes high-speed, reliable connections, enabling immediate notifications of changes via Remote Procedure Call (RPC), while inter-site replication bridges sites defined in AD topology to optimize for cost and latency.[71] The Knowledge Consistency Checker (KCC) automates the generation and maintenance of the replication topology by creating connection objects that define inbound and outbound replication partners for each domain controller.[72] Running periodically on each domain controller, the KCC generates a spanning tree for intra-site replication and a least-cost topology for inter-site links, ensuring fault-tolerant paths while avoiding loops and over-replication.[36] Administrators can override KCC-generated connections manually if needed, but the tool reduces administrative overhead by dynamically adapting to changes in the environment, such as adding or removing domain controllers.[73] Update Sequence Numbers (USNs) track changes for efficient replication by assigning a unique, monotonically increasing 64-bit integer to each update on a domain controller's database.[74] During replication, a source domain controller sends only changes with USNs higher than the last received by the destination, enabling pull-based notifications and preventing redundant transfers.[75] This mechanism supports up-to-dateness vectors, which maintain the highest USN from each partner per naming context, allowing domain controllers to request only delta changes and detect issues like USN rollbacks from non-authoritative restores.[76]

Database

Engine and File Structure

Active Directory utilizes the Extensible Storage Engine (ESE), also known as JET Blue or ESENT, as its underlying database engine for managing directory data. This engine, an indexed sequential access method (ISAM) technology developed by Microsoft, originated from the JET database engine introduced in 1992 for Microsoft Access and has since evolved into a robust, transacted system optimized for high-performance operations in server environments. ESE enables efficient storage, retrieval, and maintenance of hierarchical data structures through B-tree indexing and supports transactional consistency to ensure data integrity during updates. In Windows Server 2025, ESE supports an optional 32k page size for new Active Directory Domain Services (AD DS) and Lightweight Directory Services (AD LDS) installations, improving scalability by allowing up to approximately 3,200 values in multi-valued attributes (compared to 1,200 in the traditional 8k page format) and enhancing overall database performance; this feature requires forest-wide adoption across all domain controllers.[77][78] The primary database file in Active Directory is NTDS.dit, which serves as the Extensible Storage Engine database containing all directory objects, attributes, and schema definitions. This file stores the entire directory information tree (DIT) in a single, extensible format, with a maximum size limit of 16 terabytes to accommodate large-scale deployments. Supporting this core file are transaction log files, such as Edb.log, which record all database modifications before they are committed to NTDS.dit, enabling recovery from failures by replaying logged operations. Additionally, the Edb.chk file acts as a checkpoint marker, indicating the progress of transaction commits from logs to the main database, facilitating efficient recovery processes. The schema, defining object classes and attributes, is integrated directly within the NTDS.dit file as part of the configuration partition. To optimize storage efficiency, Active Directory implements single-instance storage for repeated attributes, particularly security descriptors and access control lists (ACLs), where identical values are stored only once and referenced across multiple objects, significantly reducing the overall database size in environments with common permissions.

Maintenance and Backup

Active Directory maintenance involves routine operations to ensure the database remains efficient and intact. The Active Directory database undergoes automatic online defragmentation as part of its garbage collection process, which runs every 12 hours by default on each domain controller to reclaim space from deleted objects without interrupting service.[79] For more thorough optimization, administrators can perform offline defragmentation using the Ntdsutil tool, which requires booting the domain controller into Directory Services Restore Mode (DSRM) and compacts the NTDS.dit file by creating a temporary copy, potentially reducing its size significantly while preserving data integrity.[79] Integrity checks are essential for verifying the database's health; Ntdsutil's files integrity command performs a physical Jet database check, while the semantic database analysis option in Ntdsutil conducts a logical validation to detect inconsistencies in object attributes and references.[80][81] Backup procedures for Active Directory focus on capturing the System State, which encompasses the NTDS.dit database file, registry hives, and SYSVOL contents critical to domain operations.[82] The recommended tool is Windows Server Backup, which leverages the Volume Shadow Copy Service (VSS) to create consistent shadow copies of the System State without quiescing the database, ensuring minimal disruption during the process.[82][83] Authoritative restore is available for specific scenarios, such as recovering deleted objects or undoing bulk changes, where restored items are marked with an elevated version number to replicate as authoritative to other domain controllers.[84] Recovery options distinguish between non-authoritative and authoritative methods to align with the distributed nature of Active Directory replication. In a non-authoritative recovery, the domain controller is restored from a System State backup and then receives updates from replication partners to synchronize with the latest forest state, suitable for most hardware failures or single-server issues. Conversely, an authoritative recovery is used when changes on the restored server should propagate to others, such as restoring a deleted organizational unit, and requires marking objects as authoritative post-restore.[84] A key limitation in recovery is the tombstone lifetime, defaulting to 180 days, after which deleted objects are permanently removed during garbage collection, preventing restoration from older backups to avoid lingering object conflicts.[85] Administrators must ensure backups are no older than this period for viable recovery.[84]

Trusts

Trust Types and Relationships

In Active Directory Domain Services (AD DS), trust relationships enable secure authentication and resource access across domains and forests by establishing defined security boundaries. Trusts can be classified by direction as one-way or two-way: a one-way trust allows users from the trusted domain to access resources in the trusting domain, while a two-way trust permits mutual access between both domains.[86] Additionally, trusts are categorized as transitive or intransitive; transitive trusts extend authentication privileges through intermediary domains, whereas intransitive trusts limit access strictly to the directly connected domains.[86] Parent-child trusts form automatically within a tree structure when a new child domain is created under a parent domain, establishing a two-way, transitive relationship that facilitates seamless authentication across the hierarchy without manual intervention.[87] Forest trusts, on the other hand, create a one-way or two-way transitive link between the root domains of two separate forests, enabling cross-forest resource sharing; these support selective authentication, a security option introduced in Windows Server 2003 that restricts incoming authentication to only those computers explicitly granted the "Allowed to Authenticate" permission, enhancing control in multi-forest environments.[86][88] External trusts provide a one-way or two-way, intransitive connection between domains in different forests, often used for legacy or non-Windows domains outside the current AD DS environment to enable targeted resource access without broader transitivity.[87][89] Shortcut trusts, also known as cross-link trusts, are manual one-way or two-way, intransitive relationships between non-adjacent domains in the same forest, designed to optimize authentication paths and reduce referral traffic in large, deep domain hierarchies.[87][89] SID filtering serves as a default security mechanism on external and forest trusts, stripping unauthorized security identifiers (SIDs) from access tokens to prevent attackers from exploiting SID history for privilege escalation across trust boundaries; it is enforced automatically on new trusts created in Windows Server 2003 and later, though it can be disabled for specific scenarios like migrations with caution.[90][91] Trusts are primarily configured using the Active Directory Domains and Trusts snap-in, where administrators can create, validate, and modify relationships by right-clicking a domain and selecting "Properties" to access the Trusts tab, specifying type, direction, and authentication scope as needed.[92][93]

Terminology and Configuration

In Active Directory trusts, the Trusted Domain Object (TDO) is a critical directory object stored in the System container of a domain, representing each trusted domain or forest and containing essential attributes such as the DNS domain name, domain Security Identifier (SID), trust type, transitivity, and—for forest trusts—trusted namespaces including domain tree names, User Principal Name (UPN) suffixes, Service Principal Name (SPN) suffixes, and SID namespaces.[86] The TDO facilitates authentication referrals and SID resolution across trusts by maintaining trust passwords, which are automatically updated every 30 days by the Primary Domain Controller (PDC) emulator in the trusting domain.[86] The Netlogon secure channel establishes and maintains an authenticated Remote Procedure Call (RPC) connection between domain controllers or computers and domain controllers, essential for trust operations including setup, authentication referrals, domain controller location, pass-through authentication validation, and Privilege Attribute Certificate (PAC) verification in Kerberos scenarios.[86] This secure channel supports trust paths across forests, ensuring encrypted communication for Forest Trust Information (FTInfo) records and preventing unauthorized access during cross-domain interactions.[86] SIDHistory is a multi-valued attribute on user and group objects that stores the original SIDs from a source domain during migrations, allowing migrated accounts to retain access to resources authorized by the old SIDs without immediate permission reconfiguration.[94] In inter-forest migrations using tools like the Active Directory Migration Tool (ADMT), SIDHistory enables seamless authorization by appending source SIDs to the target account's access token, but it introduces security risks if not managed, as attackers could exploit it for privilege escalation.[95] To configure trusts, administrators must first validate the topology by ensuring proper DNS resolution across domains—using conditional forwarders, secondary zones, or a single root DNS server—and confirming network connectivity, firewall ports (e.g., TCP 135 for RPC, UDP 389/636 for LDAP), and site/subnet definitions align with physical locations to avoid replication or referral failures.[86] Trusts are then established via the Active Directory Domains and Trusts console: right-click the domain, select Properties, navigate to the Trusts tab, choose New Trust, specify the target domain or forest root, select the trust type (e.g., external, forest), direction (one-way or two-way), and provide credentials from both sides to complete validation and activation.[93] Post-setup testing involves commands like nltest /dsgetdc:targetdomain to verify domain controller location and secure channel connectivity across the trust, ensuring referrals and authentication succeed without errors.[96] For security in trust configurations, the Protected Users group applies strict Kerberos policies to members, limiting Ticket Granting Tickets (TGTs) to a 4-hour initial lifetime (renewable only once for another 4 hours), prohibiting delegation (constrained or unconstrained), and blocking weak encryption like NTLM or RC4 to mitigate credential theft and replay attacks in cross-trust scenarios.[20] Administrators should add privileged accounts (e.g., service principals involved in trusts) to this group and enforce Authentication Policies via Fine-Grained Password Policies to further restrict TGT renewals and delegation, reducing exposure in multi-domain environments.[97] Quotas on TGT issuance are implicitly managed through these policies and domain-wide Kerberos settings, such as maximum ticket lifetimes and renewal limits, to prevent abuse in trust paths.[20] In Windows Server 2025, Active Directory Domain Services includes Kerberos enhancements such as cryptographic agility for PKINIT and disabling of RC4 encryption for Ticket Granting Tickets, along with improved domain controller location algorithms and Name/SID resolution. These features support hybrid cloud environments through integration with Azure Arc.[16]

Implementation

Planning and Deployment Steps

Planning an Active Directory deployment begins with a thorough assessment of the organization's network size and requirements to ensure scalability and performance. For environments with fewer than 100,000 users and up to 1,000 sites, a single forest with multiple domains often suffices, while larger or more complex setups may require consulting experts experienced in Active Directory Domain Services (AD DS) deployments. Minimum network connectivity should be at least 28.8 Kbps, though higher speeds are recommended for efficient replication.[98] Key considerations include defining the forest and domain model to align with organizational structure, such as using a single forest for centralized management or multiple forests for isolation between divisions. DNS integration is essential, as AD DS relies on DNS for name resolution; the DNS service must be configured prior to deployment, typically installing it alongside AD DS on the first domain controller to support the forest root domain.[99] Deployment steps involve installing the AD DS role on a Windows Server instance, followed by promoting the server to a domain controller. Using Server Manager, select Manage > Add Roles and Features, choose Role-based installation, and select Active Directory Domain Services, including management tools; this process may prompt promotion during installation. Alternatively, via PowerShell, run Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools to install the role. To promote the first server as a domain controller for a new forest, use the Server Manager wizard by selecting "Add a new forest" and specifying the root domain name (e.g., contoso.com), or in PowerShell, execute Install-ADDSForest -DomainName "contoso.com" -InstallDns, providing a Directory Services Restore Mode (DSRM) password. Note that legacy tools like dcpromo.exe and ntdsutil are deprecated in favor of these modern methods. After promotion, configure sites using Active Directory Sites and Services to map physical network topology, assigning domain controllers to appropriate sites for optimized replication; during promotion, select the site on the "Domain Controller Options" page, or use PowerShell with the -SiteName parameter (e.g., -SiteName "Default-First-Site-Name").[67] Best practices emphasize redundancy and security from the outset to mitigate risks. Deploy at least two domain controllers per domain for fault tolerance, placing them in different physical locations if possible, and ensure physical security in data centers or branches. Secure the initial setup by disabling insecure protocols such as SMBv1, applying the latest patches, and deploying antivirus software on all domain controllers; use Group Policy Objects (GPOs) to enforce security baselines across the environment. Implement least-privilege access and avoid running non-administrative software on domain controllers to prevent vulnerabilities.[19] In 2025, with Windows Server 2025, virtual domain controllers continue to be fully supported for deployment in virtualized environments like Hyper-V, providing flexibility for testing and production without dedicated hardware. Preparation for new features involves extending the AD schema using updated LDF files such as sch89.ldf, sch90.ldf, and sch91.ldf, which add attributes for enhancements like Windows Local Administrator Password Solution (LAPS) and a 32k database page size option for improved performance; run the Update-LapsADSchema cmdlet or adprep.exe to apply these before enabling related features. New functional levels, DomainLevel 10 and ForestLevel 10, support these updates and require Windows Server 2016 or later domain controllers.[16][17]

Functional Levels and Upgrades

Active Directory functional levels define the set of features and capabilities available in an Active Directory Domain Services (AD DS) environment, determining which Windows Server operating systems can run on domain controllers and enabling specific enhancements to authentication, replication, and schema management.[9] There are separate domain functional levels, which apply to individual domains, and forest functional levels, which encompass the entire forest and must be at or below the lowest domain level within it.[9] Raising these levels unlocks advanced functionality but requires all domain controllers to support the target level, ensuring compatibility across the infrastructure; intermediate forest functional level raises are not required when upgrading from Windows Server 2003 to 2016, as direct raises to 2016 are possible when all domain controllers qualify, with incremental raises used only for phased domain controller modernizations.[100] The available functional levels correspond to Windows Server versions, starting from legacy levels like Windows Server 2003 up to the latest Windows Server 2025. For instance, the Windows Server 2008 functional level introduces support for partial attribute sets in global catalog replication, allowing more efficient querying of non-domain objects by including a predefined subset of attributes for universal group membership.[101] At higher levels, such as Windows Server 2016, features like device authentication restrictions and improved Kerberos authentication with PKINIT freshness are enabled to enhance security.[9] The Windows Server 2025 level builds on these by adding schema extensions through update files like sch89.ldf, sch90.ldf, and sch91.ldf, which support expanded attribute storage and a 32k database page size option for handling up to 3,200 multivalued attributes per object.[16]
Functional LevelMinimum Supported DCsKey Features Introduced or Enabled
Windows Server 2008Windows Server 2008 or laterPartial attribute sets for global catalogs, read-only domain controllers (RODCs)
Windows Server 2016Windows Server 2016 or laterDevice-restricted NTLM, privileged access management
Windows Server 2025Windows Server 2025 (DCs must be 2016+)32k database pages, enhanced schema for multivalued attributes, object repair tools
Upgrading to a higher functional level is a one-way process, irreversible without full forest recovery, and should be tested in a lab environment to verify application compatibility and replication health.[100] Prerequisites include ensuring no replication errors exist, backing up domain controllers holding Flexible Single Master Operations (FSMO) roles, and confirming all domain controllers run an operating system compatible with the target level— for example, Windows Server 2025 requires at least Windows Server 2016 DCs.[100] The upgrade process begins with schema preparation using the ADPrep tool, located in the \support\adprep folder of Windows Server installation media, to extend the Active Directory schema for new features.[102] Run adprep /forestprep once per forest as a member of the Schema Admins and Enterprise Admins groups to update the schema forest-wide, followed by adprep /domainprep once per domain as a Domain Admins member to prepare security groups and permissions.[102] After preparation, raise the levels using the Active Directory Domains and Trusts console: right-click the domain and select "Raise Domain Functional Level," then choose the desired level; repeat for the forest by right-clicking the console root and selecting "Raise Forest Functional Level."[100] Alternatively, use PowerShell cmdlets—Set-ADDomainMode -Identity <DomainName> -DomainMode <Level> for domains (e.g., Windows2025Domain) and Set-ADForestMode -Identity <ForestName> -ForestMode <Level> for forests (e.g., after raising domain functional levels to Windows Server 2016 or higher and meeting prerequisites, Set-ADForestMode -Identity yourforest.com -ForestMode Windows2016Forest from a domain controller holding the Schema Master role)—requiring the Active Directory module and appropriate administrative privileges.[103][104] Backward compatibility is maintained for clients and member servers, which are unaffected by functional level changes, but domain controllers must be upgraded or replaced to match the new level, often by promoting new servers running the target Windows Server version and demoting legacy ones.[102] This approach minimizes disruption, as in-place upgrades are possible but riskier due to potential schema conflicts, emphasizing the preferred method of adding modern domain controllers first.[102]

Management

Built-in Administrative Tools

Active Directory provides several built-in administrative tools integrated into Windows Server and available through Remote Server Administration Tools (RSAT) for remote management. These tools enable administrators to perform day-to-day tasks such as managing users, configuring trusts, optimizing replication, scripting operations, and handling group policies without requiring third-party software.[105] They are primarily Microsoft Management Console (MMC) snap-ins and PowerShell modules, accessible via command-line invocations or graphical interfaces. The Active Directory Users and Computers (ADUC) tool, invoked via dsa.msc, serves as the primary interface for managing security principals and organizational structures in Active Directory Domain Services (AD DS). It allows administrators to create, modify, delete, and organize user accounts, group accounts, computer accounts, and organizational units (OUs) within the directory hierarchy. Key functions include resetting passwords, enabling or disabling accounts, assigning group memberships, and configuring account properties such as profiles and logon hours through a tabbed interface for detailed attribute editing. Enabling "Advanced Features" in the View menu provides additional tabs, such as the Attribute Editor and Security tabs, essential for advanced troubleshooting of object modification errors.[106] Domain Admins and Enterprise Admins hold full management permissions, while Account Operators can handle user-specific tasks.[107] Active Directory Domains and Trusts, accessed via domain.msc, focuses on configuring and maintaining trust relationships between domains and forests to facilitate secure resource access across AD environments. This MMC snap-in supports the creation, validation, and removal of various trust types, including one-way, two-way, transitive, and forest trusts, ensuring seamless authentication and authorization in multi-domain setups. Administrators use it to manage trust properties, such as transitivity and direction, which are essential for scaling AD deployments while controlling security boundaries.[86] For network topology management, Active Directory Sites and Services, launched with dssite.msc, enables the definition and optimization of sites, subnets, and replication connections to align AD with physical network infrastructure. It allows mapping of IP subnets to sites, configuration of site links for inter-site replication costs and schedules, and manual creation of connection objects to fine-tune data synchronization between domain controllers. This tool is crucial for minimizing replication traffic and improving logon performance in distributed environments by associating domain controllers with appropriate sites.[108] PowerShell integration via the Active Directory module extends administrative capabilities with scripting for automated and bulk operations on AD objects. This module, part of RSAT, includes over 140 cmdlets for querying, creating, modifying, and deleting domain, user, group, and computer objects across AD DS and Active Directory Lightweight Directory Services (AD LDS) instances. For example, the New-ADUser cmdlet creates new user accounts with specified attributes like name, path, and account name, while Get-ADObject retrieves objects based on filters such as object class or attributes, supporting complex searches like Get-ADObject -Filter 'ObjectClass -eq "user"'. It requires RSAT installation and is invoked with Import-Module ActiveDirectory for elevated sessions.[109] The Group Policy Management Console (GPMC) provides centralized control over Group Policy Objects (GPOs) to enforce configuration settings across AD-managed systems. As an MMC-based tool included in RSAT, it supports linking GPOs to sites, domains, or OUs; editing permissions and WMI filters; and simulating policy application through Group Policy Modeling. Features include backup and restore of GPOs, HTML-based reporting for Resultant Set of Policy (RSoP) analysis, and migration tools for cross-forest transfers, ensuring consistent security and compliance enforcement. Administrators need permissions like "Edit settings, delete, and modify security" to fully utilize it.[110] RSAT tools for AD support Feature on Demand installation on Windows clients and servers, improving remote administration efficiency without full server role deployment. These updates include streamlined PowerShell module integration and MMC snap-in compatibility for managing AD DS and AD LDS from Windows 10/11 Pro/Enterprise or Server editions, with prerequisites like administrative privileges and network access to target domain controllers. This facilitates secure, remote task execution, such as object management and policy configuration, reducing the need for on-site console access.[105]

Monitoring and Auditing Tools

Active Directory provides several built-in tools for monitoring system health, performance, and security events to ensure reliable operation and detect potential issues. Event Viewer is a primary tool for examining logs related to directory services and security activities. The Directory Service log captures events specific to Active Directory operations, such as replication successes or failures, while the Security log records authentication and authorization events, including user account creations (Event ID 4720) and modifications.[111][112] For example, administrators can filter these logs to track Event ID 4728, which indicates a member added to a security-enabled global group, aiding in oversight of privilege escalations.[113] Performance Monitor complements Event Viewer by offering real-time and historical data through performance counters tailored to Active Directory. Key counters include those under the NTDS object, such as DRA Pending Replication Synchronizations, which measures the number of outstanding replication operations, and replication latency metrics to identify delays in data synchronization across domain controllers.[111] These counters help diagnose bottlenecks in data synchronization across domain controllers. Auditing in Active Directory is configured through Group Policy to log detailed changes and access attempts, enhancing security posture. The Advanced Audit Policy Configuration, accessible via Group Policy Management Console, allows granular enabling of subcategories like Audit Directory Service Changes and Audit Directory Service Access, which track modifications to objects such as users, groups, and organizational units.[114] For instance, enabling Audit Directory Service Access generates events when users interact with objects that have a System Access Control List (SACL) defined, capturing both successes and failures in the Security log.[112] This setup requires applying the policy to domain controllers via the Domain Controllers Organizational Unit to avoid conflicts with basic audit policies.[115] In Windows Server 2025, DTrace integration provides advanced tracing capabilities for troubleshooting complex issues like replication failures. As a native command-line tool, DTrace enables dynamic probing of kernel and user-mode events, allowing administrators to script custom traces for Active Directory components, such as monitoring replication traffic or diagnosing synchronization delays without relying solely on logs.[16][116] For replication troubleshooting, DTrace can capture Event Tracing for Windows (ETW) events related to NTDS replication threads, offering low-overhead insights into latency causes like network interruptions or schema mismatches.[117] This feature builds on prior diagnostic tools, providing more flexible, real-time analysis for enterprise environments.

Third-Party and Advanced Management and Security Tools (2025–2026)

While Active Directory offers comprehensive built-in tools for administration, monitoring, and auditing, many organizations employ third-party solutions and additional Microsoft services to address advanced requirements in automation, detailed auditing, compliance reporting, and threat detection. As of February 2026, according to user reviews in PeerSpot's Active Directory Management category, the top-rated solutions include:
  • Netwrix Auditor (9.5/10, 8 reviews): Highest-rated overall, excelling in auditing, change tracking, monitoring, real-time alerts on modifications and suspicious activities, compliance support, and detailed reporting.[118]
  • ManageEngine ADAudit Plus (9.3/10, 15 reviews): Strong for real-time auditing, monitoring of critical network resources including Domain Controllers, compliance reporting, detailed event-specific GUI reports, and email alerts.[118]
  • Change Auditor for Active Directory (9.0/10, 2 reviews): Excels in real-time change tracking, tamper-proof auditing independent of native logs, threat monitoring, and detection of indicators of compromise in on-premises and hybrid Active Directory environments.[118][119]
  • One Identity Active Roles (8.5/10, 31 reviews, mindshare 12.2%): Highly regarded for enhanced security, automation of group, account, and directory management, fine-grained delegation of administrative tasks, and unified management across hybrid Active Directory and Entra ID environments. It holds the highest mindshare among solutions in the category.[118]
  • Microsoft Active Directory (8.5/10, 47 reviews): The core native tool for directory services management, providing structured, hierarchical organization of network objects, resources, and users.[118]
Additionally, ManageEngine ADManager Plus receives positive reviews on TrustRadius for simplifying identity management, user lifecycle automation (including provisioning and deprovisioning), bulk operations, and extensive reporting capabilities.[120] While G2 lacks a dedicated Active Directory management category, it features related tools focused on auditing and reporting. Other notable advanced tools include:
  • Microsoft Defender for Identity: A cloud-based service for identity threat detection and response, identifying advanced targeted attacks, privilege escalations, and insider threats in on-premises and hybrid Active Directory environments.[121]
Rankings vary by source (such as PeerSpot and TrustRadius) and depend on specific organizational needs, such as scale, hybrid integration, or regulatory compliance. These tools provide capabilities beyond built-in options for enhanced security, automation, and operational efficiency.

Security Best Practices

Active Directory (AD) is a critical component of Windows-based networks, and securing it is essential to prevent domain compromise, credential theft, ransomware, and lateral movement attacks. Key best practices include:
  • Harden Domain Controllers: Prompt patching of OS, applications, and firmware; up-to-date antivirus with tamper monitoring; restrict physical/logical access; disable unnecessary services (e.g., Print Spooler); block legacy protocols like SMBv1 and minimize NTLM in favor of Kerberos; use secure admin hosts/jump servers.
  • Enforce Least Privilege and Tiered Administration: Limit membership in privileged groups (Domain Admins, Enterprise Admins); implement administrative tiering (Tier 0 for AD core, Tier 1 for servers, Tier 2 for workstations); use Privileged Access Management (PAM) or Just-In-Time access; separate admin accounts from regular user accounts; regularly audit group memberships.
  • Strengthen Authentication: Enforce strong password policies (14+ characters minimum, complexity, history) via Default Domain Policy and Fine-Grained Password Policies; mandate MFA for privileged accounts (via Microsoft Entra ID Conditional Access in hybrid setups); secure service accounts with gMSAs; disable legacy auth; adopt passwordless where possible; use Protected Users group and Credential Guard.
  • Maintain AD Hygiene: Remove inactive/stale accounts, orphaned objects; audit and secure GPOs; minimize permission delegation (avoid unconstrained delegation); eliminate excessive/shadow permissions.
  • Monitoring and Detection: Enable comprehensive auditing (logon, privilege use, DS changes); monitor for attack indicators (DCSync, Kerberoasting, Golden/Silver Tickets); use tools like Microsoft Defender for Identity; implement attack path analysis.
  • Zero Trust Principles: Verify identity/device/context for access; micro-segment critical assets; continuous risk assessment.
  • Backup and Recovery: Regular tested AD backups (System State); immutable/air-gapped storage; documented forest recovery plan. \n\n### Risks of Poor Active Directory Hygiene\n\nPoor hygiene in Active Directory environments—characterized by infrequent auditing, accumulation of stale objects, lax permission management, and outdated configurations—significantly elevates security and operational risks. As AD serves as the core identity provider in Windows networks, neglect creates exploitable weaknesses that attackers frequently target, contributing to a high percentage of successful breaches.\n\nKey risks include:\n\n- Stale or Orphaned Accounts and Objects: Inactive user or computer accounts from departed employees, decommissioned devices, or unused service accounts remain exploitable. Attackers can use these for initial access via credential stuffing, brute force, or password spraying, especially if passwords are weak, reused, or set to never expire. Such accounts expand the attack surface and can retain privileges, facilitating lateral movement.\n\n- Overprivileged Accounts and Privilege Creep: Accounts or groups with excessive permissions (e.g., unnecessary Domain Admin membership) allow privilege escalation if compromised. Techniques like Kerberoasting target service accounts with static passwords, enabling hash extraction and impersonation.\n\n- Poor Group Management: Issues such as heavily nested groups, circular memberships, empty groups, stale groups, missing owners, or excessive memberships complicate access control, lead to token bloat (slowing authentication), and obscure effective permissions. Attackers exploit nesting to gain unintended access to sensitive resources.\n\n- Weak Authentication Practices: Absence of MFA for admins, legacy protocols, unconstrained delegation, or weak password policies increase vulnerability to credential theft (e.g., via Mimikatz) and persistence.\n\n- Misconfigurations: Improper ACLs, unmanaged service accounts, or insecure hybrid trusts broaden attack paths, potentially allowing domain takeover.\n\nConsequences extend beyond security:\n\n- Operational Impact: Bloated directories slow logons, group policy processing, and replication, causing delays, application errors, or outages.\n\n- Compliance and Financial Risks: Violations of standards like GDPR, HIPAA, or SOC 2 due to inadequate access controls; breaches lead to fines, ransom payments, recovery costs, and reputational damage.\n\nRegular hygiene practices—such as automated removal of inactive objects, least-privilege enforcement, auditing, and monitoring—mitigate these risks and align with zero-trust principles. Tools like Microsoft Defender for Identity aid in identifying and remediating hygiene issues proactively.\n\n
These align with Microsoft guidance (e.g., "Best practices for securing Active Directory" on Microsoft Learn) and industry standards (CIS, NIST). Regular assessments, red-teaming, and updates are essential for ongoing security.

Multi-Factor Authentication Support and Limitations

On-premises Active Directory Domain Services (AD DS) does not natively support multi-factor authentication (MFA) for standard authentication protocols such as Kerberos or NTLM, which are used for domain logons, RDP, file shares, and most on-premises resources. Native support is limited to certificate-based authentication (e.g., smart cards), which can serve as a stronger single factor but does not constitute true MFA in most scenarios. To implement robust MFA, organizations rely on additional layers:
  • Active Directory Federation Services (AD FS) for federated/web-based scenarios, supporting MFA adapters including the built-in Microsoft Entra MFA adapter (Windows Server 2016+).
  • Network Policy Server (NPS) extension for Azure MFA in hybrid environments (requires Entra ID sync and P1/P2 licensing), useful for remote access like VPN or RD Gateway.
  • Third-party solutions (e.g., Duo Security, Okta, Silverfort, miniOrange) for agent-based or agentless MFA on Windows logons, RDP, and privileged access.
  • Endpoint-level tools like Windows Hello for Business (biometrics/PIN) via Group Policy.
In pure on-premises setups, MFA often fails to cover direct domain controller authentications or legacy protocols without extra enforcement, creating potential bypass risks (e.g., NTLM relay). Hybrid environments bridging to Microsoft Entra ID extend cloud MFA to some scenarios but require careful configuration to avoid gaps in on-premises access.

Integration

Unix and Linux Systems

Integrating Unix and Linux systems with Active Directory (AD) enables centralized authentication and identity management, allowing these non-Windows environments to leverage AD's directory services for user access and resource sharing. One primary method involves using the System Security Services Daemon (SSSD), an open-source component that facilitates direct domain joining by caching credentials and handling authentication requests on behalf of the local system. SSSD acts as a mediator between the Linux client and AD domain controllers, supporting features like offline authentication through credential caching and integration with Pluggable Authentication Modules (PAM) for login processes.[122] Another approach is employing Samba, an open-source implementation of the Server Message Block (SMB) protocol, to emulate an AD domain controller on Unix or Linux systems. This configuration allows Samba to provide AD-compatible services, including user authentication and group policy enforcement, making it suitable for environments where a Linux-based controller is preferred over Windows Server. Samba supports provisioning a new AD domain or joining existing ones, ensuring compatibility with Windows clients while extending AD functionality to Unix file sharing and printing.[123] Key protocols underpinning these integrations include Kerberos for secure ticket-based authentication and Lightweight Directory Access Protocol (LDAP) for directory queries. Kerberos enables single sign-on (SSO) by issuing time-limited tickets that authenticate users across systems without repeated password entry, while LDAP allows clients to retrieve user attributes, group memberships, and other directory information from AD. Additionally, PowerBroker Identity Services (PBIS), provided by BeyondTrust, offers an alternative for SSO and domain joining on Unix and Linux, bridging AD with local services through agent-based installation that simplifies policy application and credential management.[124] Despite these methods, challenges arise in mapping user identifiers between AD's Security Identifiers (SIDs) and Unix/Linux's User IDs (UIDs) and Group IDs (GIDs). AD uses SIDs for unique identification, but Linux relies on numeric UIDs and GIDs for file permissions and process ownership; mismatches can lead to access denials or inconsistent behaviors, particularly in shared file systems. SSSD addresses this via ID mapping rules, such as the ad provider, which generates consistent UIDs/GIDs from SIDs using algorithms like RFC 2307 schema extensions, though manual configuration may be required for legacy environments.[122] Similarly, NFSv4 ID mapping introduces complexities when integrating with AD, as it requires domain-wide consistency in name-to-ID translations; discrepancies in idmapd configurations or multi-domain setups can cause permission errors on NFS shares, necessitating synchronized domain names and Kerberos realms across clients and servers.[125] To streamline the joining process, tools like realmd and adcli are commonly used. Realmd automates domain discovery and configuration by interacting with SSSD or Winbind, detecting available realms via DNS SRV records and prompting for join credentials, which simplifies setup compared to manual editing of configuration files. Adcli, a command-line tool, handles low-level operations such as joining computers to the domain, generating machine account keys, and querying AD attributes, often invoked by realmd but usable independently for scripted deployments. These tools ensure secure enrollment, with adcli supporting Kerberos ticket acquisition for authentication during the join.[126][127]

Hybrid and Cloud Environments

In hybrid environments, Active Directory (AD) integrates with Microsoft Entra ID (formerly Azure AD) to enable a unified identity across on-premises and cloud resources, allowing organizations to synchronize user identities, groups, and attributes while maintaining compatibility with legacy systems.[128] This hybrid model addresses the need for seamless authentication and authorization in mixed infrastructures, where on-premises AD serves as the primary source of authority for certain objects, and Entra ID extends identity management to cloud services like Microsoft 365 and Azure.[129] The core tool for this integration is Microsoft Entra Connect, an on-premises application that synchronizes directory data between AD and Entra ID, supporting features such as delta synchronization to handle incremental changes efficiently.[130] Key authentication methods in hybrid setups include password hash synchronization (PHS), pass-through authentication (PTA), and federation using Active Directory Federation Services (AD FS). PHS securely hashes and synchronizes user passwords from AD to Entra ID, enabling cloud authentication without storing plaintext credentials in the cloud, which simplifies management and supports self-service password reset.[131] PTA validates user credentials directly against on-premises AD during cloud sign-ins by deploying lightweight agents, preserving existing password policies and multi-factor authentication without requiring password changes.[132] Federation with AD FS allows organizations to use on-premises identity providers for cloud access, implementing advanced access controls like claims-based authentication, though it requires additional infrastructure maintenance compared to PHS or PTA.[133] Seamless single sign-on (SSO) enhances these methods by automatically signing users into cloud applications using Kerberos tickets from domain-joined devices, reducing prompts and improving user experience when combined with PHS or PTA.[33] As of 2025, Microsoft has introduced enhancements to hybrid capabilities, including granular permissions for UserAuthenticationMethod APIs in Entra ID, which allow fine-tuned control over authentication methods for AD-synced objects, improving security in hybrid scenarios.[134] Zero-trust extensions, such as jailbreak detection for mobile devices, block Entra credentials on compromised endpoints starting February 2026, integrating with hybrid AD environments to enforce conditional access policies.[134] Additionally, features like Group Source of Authority (SOA) conversion enable transferring group management authority from AD to Entra ID via Entra Connect Sync, facilitating gradual modernization without full migration.[134] Migrating from hybrid AD to a cloud-only Entra ID model, often termed "lifting and shifting," involves careful planning to address dependencies on on-premises resources such as Group Policy Objects and legacy applications.[135] Key considerations include converting synced users and groups to cloud-managed objects using tools like Entra Connect's SOA features, ensuring compatibility for domain-joined devices through hybrid join transitions to cloud-only join, and mitigating risks to applications reliant on LDAP or Kerberos by adopting Entra Domain Services or alternatives.[135] This shift prioritizes a cloud-first identity strategy, reducing on-premises footprint while maintaining security through Entra ID's built-in governance and monitoring.[135] In multi-OS hybrid setups, Unix and Linux systems can leverage Entra Connect alongside tools like SSSD for integrated authentication.[129]

References

  1. Active Directory documentation - Windows Server - Microsoft Learn
  2. Active Directory Domain Services overview | Microsoft Learn
  3. Microsoft Releases Windows 2000 to Manufacturing - Source
  4. https://www.frost.com/growth-opportunity-news/active-directory-holds-the-keys-to-your-kingdom-but-is-it-secure/
  5. Celebrating 25 Years of Active Directory | Practical365
  6. DNS and AD DS | Microsoft Learn
  7. Microsoft Releases Windows 2000 Beta 3 - Source
  8. How to raise Active Directory domain and forest functional levels
  9. Active Directory Domain Services Functional Levels | Microsoft Learn
  10. Read-Only DCs and the Active Directory Schema - Win32 apps
  11. [PDF] Windows Server 2008 Active Directory Feature Components
  12. Privileged Access Management for Active Directory Domain Services
  13. Credential Guard overview - Microsoft Learn
  14. Microsoft Entra Connect: Version release history
  15. Just Enough and Just in Time Administration in Windows Server 2016
  16. What's new in Windows Server 2025 | Microsoft Learn
  17. Schema updates in Windows Server - Microsoft Learn
  18. Active Directory improvements in Windows Server 2025
  19. Microsoft guidance
  20. Protected Users Security Group in Windows Server | Microsoft Learn
  21. Understanding the Active Directory Logical Model - Microsoft Learn
  22. Overview of Active Directory Domain Services | Microsoft Learn
  23. Kerberos authentication overview in Windows Server - Microsoft Learn
  24. NTLM overview in Windows Server - Microsoft Learn
  25. Group Policy overview for Windows Server | Microsoft Learn
  26. [MS-ADTS]: Glossary | Microsoft Learn
  27. [MS-SAMR]: Relationship to Other Protocols - Microsoft Learn
  28. [MS-ADOD]: Protocol Summary - Microsoft Learn
  29. How can Windows Server be used to manage and centralize user ...
  30. Active Directory Domain Services Maximum Limits and Scalability
  31. Active Directory Security Groups | Microsoft Learn
  32. Monitoring Active Directory for Signs of Compromise - Microsoft Learn
  33. Microsoft Entra Connect: Seamless single sign-on
  34. Integrate On-Premises Active Directory Domains With Microsoft ...
  35. Active Directory Domain Services - Win32 apps | Microsoft Learn
  36. Active Directory Replication Concepts | Microsoft Learn
  37. Active Directory-Integrated DNS Zones | Microsoft Learn
  38. What Is Active Directory Lightweight Directory Services
  39. [MS-ADTS]: Introduction - Microsoft Learn
  40. Active Directory Lightweight Directory Services Overview
  41. Why Use Active Directory Lightweight Directory Services
  42. What is Active Directory Certificate Services in Windows Server?
  43. KB5014754: Certificate-based authentication changes on Windows ...
  44. Active Directory Federation Services Overview | Microsoft Learn
  45. Understanding Key AD FS Concepts - Microsoft Learn
  46. Supported scenarios to set up single sign-on in Microsoft 365, Azure ...
  47. Best Practices for securing AD FS and Web Application Proxy
  48. https://learn.microsoft.com/en-us/windows-server/get-started/removed-deprecated-features-windows-server
  49. Active Directory Rights Management Services Overview
  50. [MS-WPO]: Rights Management Services - Microsoft Learn
  51. AD RMS Overview | Microsoft Learn
  52. How AD RMS Works
  53. Add the Federation Mailbox to the AD RMS Super Users Group
  54. Information Rights Management in Exchange Server - Microsoft Learn
  55. Active Directory Schema (AD Schema) - Win32 apps | Microsoft Learn
  56. [MS-ADTS]: Active Directory Schema - Microsoft Learn
  57. Tutorial Overview ADSI with Visual Basic - Win32 apps
  58. Distinguished Names - Microsoft Learn
  59. Global Catalog - Win32 apps - Microsoft Learn
  60. Including Attributes in the Global Catalog - Win32 apps
  61. Determining the Number of Domains Required - Microsoft Learn
  62. Creating an Organizational Unit Design - Microsoft Learn
  63. Naming Contexts and Directory Partitions - Win32 apps
  64. About Application Directory Partitions - Win32 apps - Microsoft Learn
  65. Planning Global Catalog Server Placement | Microsoft Learn
  66. Service overview and network port requirements - Windows Server
  67. Install Active Directory Domain Services on Windows Server
  68. Features of the Replication Model for Active Directory Domain ...
  69. Active Directory FSMO roles in Windows - Microsoft Learn
  70. Theory question on AD replication - Microsoft Q&A
  71. Creating a Site Link Design | Microsoft Learn
  72. Knowledge Consistency Checker - MS-ADTS - Microsoft Learn
  73. Prevent KCC from creating replication topology - Windows Server
  74. How do I find out what changes are going on in my Active Directory?
  75. How to detect and recover from a USN rollback in a Windows Server ...
  76. Get-ADReplicationUpToDatenessVectorTable (ActiveDirectory)
  77. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/32k-pages-optional-feature
  78. Extensible Storage Engine - Win32 apps - Microsoft Learn
  79. Offline defragmentation of Active Directory database - Windows Server
  80. How to complete a semantic database analysis for the Active ...
  81. Error when you start your Windows-based domain controller
  82. AD Forest Recovery - Backing up the System State data
  83. VSS Backup and Restore of the Active Directory - Win32 apps
  84. Back up and restore Active Directory using Azure Backup
  85. Restore a virtualized domain controller in Windows Server
  86. How trust relationships work for forests in Active Directory
  87. TrustType Enum (System.DirectoryServices.ActiveDirectory)
  88. Forest.GetSelectiveAuthenticationStatus(String) Method
  89. Create an Active Directory Domain Service Resource Forest in Azure
  90. Forest.SetSidFilteringStatus(String, Boolean) Method - Microsoft Learn
  91. [MS-ADTS]: trustAttributes - Microsoft Learn
  92. Trust between two domains - Microsoft Q&A
  93. Tutorial - Create a forest trust in Microsoft Entra Domain Services
  94. Security assessment: Unsecure SID History attributes - Microsoft Learn
  95. How to troubleshoot inter-forest sIDHistory migration with ADMTv2
  96. Nltest | Microsoft Learn
  97. Guidance about how to configure protected accounts - Microsoft Learn
  98. AD DS Design and Planning | Microsoft Learn
  99. AD DS Deployment Requirements | Microsoft Learn
  100. Raise Domain and Forest Functional Levels in AD DS on Windows ...
  101. Is-Member-Of-Partial-Attribute-Set attribute - Win32 - Microsoft Learn
  102. Upgrade domain controllers to a newer version of Windows Server
  103. Set-ADDomainMode (ActiveDirectory) - Microsoft Learn
  104. https://learn.microsoft.com/en-us/powershell/module/activedirectory/set-adforestmode?view=windowsserver2022-ps
  105. Install and Manage Remote Server Administration Tools in Windows
  106. Multiple tabs of user properties are missing
  107. Manage User Accounts in Active Directory Users and Computers
  108. Understanding Active Directory Site Topology - Microsoft Learn
  109. ActiveDirectory Module - Microsoft Learn
  110. Group Policy Management Console in Windows | Microsoft Learn
  111. Appendix L - Events to Monitor | Microsoft Learn
  112. How to enable Audit Active Directory objects - Windows Server
  113. Audit Security Group Management - Windows 10 | Microsoft Learn
  114. Advanced Audit Policy Configuration settings | Microsoft Learn
  115. System Audit Policy recommendations - Microsoft Learn
  116. DTrace on Windows - Windows drivers | Microsoft Learn
  117. DTrace ETW - Windows drivers | Microsoft Learn
  118. Best Active Directory Management Solutions for 2026 - PeerSpot
  119. Change Auditor for Active Directory
  120. ManageEngine ADManager Plus Reviews on TrustRadius
  121. Microsoft Defender for Identity documentation
  122. Integrating RHEL systems directly with Windows Active Directory | 9
  123. Setting up Samba as an Active Directory Domain Controller
  124. Active Directory (AD) Bridge - BeyondTrust
  125. NFSv4 id mapping issues in a multi-domain environment involving ...
  126. How to join RHEL to Active Directory using realmd
  127. How to set up SSSD with Active Directory - Ubuntu documentation
  128. What is hybrid identity with Microsoft Entra ID?
  129. Hybrid identity documentation - Microsoft Entra ID
  130. What is Microsoft Entra Connect and Connect Health. - Microsoft Learn
  131. Implement password hash synchronization with Microsoft Entra ...
  132. Microsoft Entra Connect: Pass-through Authentication
  133. What is federation with Microsoft Entra ID?
  134. Microsoft Entra releases and announcements
  135. Road to the cloud - Microsoft Entra - Microsoft Learn
User Avatar
No comments yet.