Category: Directory Services

Active Directory

Also known as: AD, Active Directory Domain Services, AD DS

Simply put

Active Directory is a directory service developed by Microsoft that stores information about the users, devices, and other objects on a network and makes that information available to users and administrators. It helps organizations manage who can sign in and what network resources they are allowed to reach. It is most commonly used in on-premises Windows domain networks.

Formal definition

Active Directory (AD) is Microsoft's directory service; its core role, Active Directory Domain Services (AD DS), stores directory data about network objects (such as users, groups, computers, and other resources) and makes that data available to network users and administrators. In typical on-premises Windows domain deployments, AD supports both authentication (verifying the identity of a principal) and authorization (determining the resources a principal may access), though the specific mechanisms and integrations vary by deployment and configuration. This entry describes AD DS as a directory service and does not, based on the evidence provided, detail specific protocols, schema, or federation components; those are out of scope here.

Why it matters

Active Directory sits at the center of identity in most on-premises Windows environments, acting as the authoritative store of users, groups, computers, and other network objects. Because it commonly underpins both authentication (verifying who a principal is) and authorization (determining which resources that principal may reach) across a domain, its availability and integrity directly shape whether an organization's workforce can access the systems they need. When AD is healthy, sign-in and resource access flow smoothly; when it is degraded or compromised, the impact tends to cascade across the many services that depend on it.

For the same reason that AD is operationally central, it is also a high-value target and a critical governance concern. A directory that connects users with network resources concentrates significant privilege and trust in one place, so misconfiguration, stale accounts, or excessive group memberships can translate into broad exposure. Security architects and identity governance leads therefore treat AD as foundational infrastructure that warrants careful lifecycle management, monitoring, and access review, rather than as a set-and-forget component.

It is worth noting what this entry does not cover: the specific protocols, schema, replication mechanics, and federation components that AD deployments may involve are out of scope here. The evidence supports describing AD as a directory service and its role in managing authentication and authorization in on-premises domains, but readers evaluating a particular deployment should confirm the exact mechanisms and integrations in use, since these vary by configuration.

Who it's relevant to

IAM Engineers and System Administrators

Administrators rely on AD DS as the central store for users, groups, computers, and other objects, and use it to manage who can sign in and what network resources they can reach. Day-to-day tasks such as managing devices, users, domains, and objects typically run through the directory, making it core operational infrastructure.

Security Architects

Because AD commonly underpins both authentication and authorization across on-premises domains, architects treat it as foundational to identity design. Its central role means decisions about its availability, integrity, and access model influence the broader security posture of the environment.

Identity Governance Leads

AD holds the accounts, group memberships, and object relationships that govern access to network resources, so it is a key data source for provisioning, access reviews, and certification activities. Keeping this directory data accurate and free of stale or excessive access is central to governance over on-premises identities.

Compliance and Audit Teams

As the authoritative directory connecting users with network resources, AD is often a focal point for demonstrating who has access to what within on-premises Windows environments. Its records of users, groups, and objects support the evidence auditors expect when reviewing access controls, though the specific controls in scope depend on the deployment.

Inside AD

Domain Services (AD DS)

The core directory service role that stores identity data (users, groups, computers) and handles authentication and directory queries within a domain, typically using LDAP for directory access and Kerberos as the primary authentication protocol with NTLM as a legacy fallback.

Domain Controllers

Servers running AD DS that host a replica of the directory database (NTDS.dit), respond to authentication requests, and participate in multi-master replication. Depending on deployment, controllers may hold specialized single-master roles (FSMO roles).

Forest, Trees, and Domains

The hierarchical logical structure: a domain is an administrative and replication boundary, a tree is a set of domains sharing a contiguous namespace, and a forest is the outermost security boundary containing one or more trees that share a common schema and configuration.

Organizational Units (OUs)

Container objects used to organize directory objects for delegated administration and for the application of Group Policy, distinct from security groups used for authorization.

Group Policy

A mechanism for centrally configuring settings on domain-joined users and computers. Group Policy addresses configuration management and is separate from the authentication and authorization decisions AD makes at access time.

Schema

The forest-wide definition of object classes and attributes that the directory can store. Schema changes apply across the entire forest.

Kerberos and Tickets

Kerberos is the default authentication protocol in most AD deployments, issuing ticket-granting tickets and service tickets that verify who a principal is. Authorization decisions are typically made separately by the resource using group membership and other attributes.

Trusts

Configured relationships between domains or forests that allow authentication (and, depending on configuration, access to resources) across boundaries. Trust direction and transitivity vary by trust type.

Common questions

Answers to the questions practitioners most commonly ask about AD.

Is Active Directory the same thing as an LDAP directory?

Not exactly. Active Directory (AD) is Microsoft's directory service that exposes an LDAP-compatible interface, but it is more than a bare LDAP directory. In most deployments it bundles a directory store with authentication protocols (typically Kerberos, and NTLM in legacy scenarios), group policy, DNS integration, and replication. You can query and modify AD over LDAP, but treating AD as merely "an LDAP server" understates the additional services it provides. The precise relationship is that LDAP is one access protocol AD supports, not a synonym for AD itself.

Does Active Directory handle both authentication and authorization?

It is important to keep these separate. AD primarily handles identification and authentication, verifying who a principal is, typically via Kerberos in modern domains. Authorization (determining what an authenticated principal may do) is largely delegated to the resources and applications that consume AD identities and group memberships. AD supplies identity data and group membership that authorization decisions can be based on, but the enforcement of what a user may access generally happens at the target system, not within AD's authentication exchange itself. Conflating the two misrepresents where access decisions are actually made.

How do applications typically integrate with Active Directory for sign-in?

The integration approach depends on the application. Domain-joined Windows systems and services commonly authenticate against AD directly using Kerberos. Applications that speak LDAP may bind against AD to validate credentials or read directory attributes. For web SSO and federation across boundaries, organizations often place a federation layer in front of AD (for example, an identity provider that issues SAML 2.0 or OpenID Connect tokens) rather than exposing AD protocols directly. The right method varies by application type, network topology, and whether the client is domain-joined.

What should I consider when provisioning and deprovisioning accounts in Active Directory?

Account lifecycle in AD is an identity governance and administration concern, distinct from runtime authentication. In most deployments, provisioning, attribute updates, group assignments, and deprovisioning are driven by an IGA or HR-driven process rather than manual edits. Because AD group membership frequently feeds downstream authorization decisions, timely deprovisioning and periodic access reviews matter for reducing standing access. Note that AD itself does not perform access certification or segregation-of-duties analysis; those functions typically come from an IGA platform layered on top.

How does replication affect changes made in Active Directory?

AD is a distributed, multi-domain-controller service, so changes such as password resets, group membership updates, or account disablement propagate through replication and are not necessarily instantaneous across all domain controllers. Depending on configuration, topology, and site links, there can be a delay before a change is consistent everywhere. This matters for security-sensitive operations: a disabled account or revoked group membership may still be honored by a domain controller that has not yet received the update. Plan operational procedures with replication behavior in mind.

How can Active Directory identities be extended to cloud and SaaS applications?

Because native AD protocols such as Kerberos are generally suited to on-premises, domain-joined environments, extending AD identities to cloud and SaaS applications typically involves an intermediary. Common patterns include federating through an identity provider that issues SAML 2.0 or OpenID Connect tokens sourced from AD, and synchronizing or provisioning identities to cloud directories, sometimes using SCIM for provisioning where supported. The specific mechanism depends on the target application's supported standards and your directory synchronization strategy; AD alone does not directly perform modern web federation without such a layer.

Common misconceptions

Active Directory is the same thing as Azure AD (Entra ID).

They are distinct products with different architectures. On-premises Active Directory Domain Services is primarily an LDAP-based directory using Kerberos/NTLM, while Microsoft Entra ID (formerly Azure AD) is a cloud identity service that speaks protocols such as SAML 2.0, OAuth 2.0, and OpenID Connect. They can be integrated but are not interchangeable, and behavior depends on the specific configuration.

Membership in an AD group means a user is authorized to do something.

Group membership is an attribute established during identification and carried through authentication; it does not by itself grant access. Authorization is a separate step performed by the resource or application evaluating that membership (and possibly other attributes) against its own access rules, so AD group-based access typically resembles an RBAC approach only when resources are configured to honor those groups.

Domain controllers use a primary/backup model where one server is authoritative.

In most deployments AD DS uses multi-master replication, so writable domain controllers can each accept directory changes. Certain operations are handled by single-master FSMO roles, but this is not a general primary/backup topology.

Best practices

Treat the forest as your security boundary and design trust relationships deliberately, reviewing trust direction and transitivity rather than assuming cross-domain access is safe by default.

Separate administrative tiers and use dedicated privileged accounts, keeping Domain Admin and comparable high-privilege groups tightly scoped and regularly certified through access reviews.

Use OUs and Group Policy for configuration management and delegated administration, but keep authorization decisions resource-side and validate that groups actually map to intended access.

Protect and monitor domain controllers as high-value assets, including securing the NTDS.dit database, restricting logon rights, and auditing authentication and replication activity.

Prefer Kerberos where possible and reduce reliance on legacy NTLM, since fallback behavior depends on configuration and can weaken authentication assurance.

Periodically reconcile directory contents through provisioning and deprovisioning workflows and segregation-of-duties checks so stale accounts and orphaned group memberships do not accumulate.