Most Windows networks reach a point where local accounts stop scaling. Every machine has its own user database, passwords are managed individually, and there is no way to enforce a consistent security baseline across the environment without touching every device. Active Directory Domain Services (AD DS) is Microsoft’s answer – and understanding what is active directory, how it works, and where the first deployment decisions go wrong is the prerequisite for everything that follows.
This article covers what is active directory from an architecture and operational standpoint – the components, how authentication works, and the decisions that are difficult to undo after the fact. The installation procedure is in How to Install Active Directory on Windows Server 2025.
- Active Directory Domain Services is Microsoft’s on-premises directory, authentication, authorization, and policy platform for Windows-centric networks
- Kerberos handles authentication and LDAP handles directory queries – both depend on internal DNS that can resolve the AD namespace; DNS failures break new authentication, domain joins, and Group Policy retrieval, though cached logons and existing tickets can keep working temporarily
- The AD database (NTDS.dit), transaction logs, and SYSVOL must stay on NTFS – Microsoft explicitly instructs administrators not to store these paths on ReFS
- A single domain controller is a single point of failure – production domains need at least two DCs, ideally on separate failure domains, plus tested system-state backups
- Domain name choice is hard to change later – a dedicated subdomain like
ad.company.comis usually simpler to operate than reusing your public domain name
What Is Active Directory Domain Services (AD DS)?
Active Directory Domain Services is Microsoft’s directory service for Windows environments. It provides a centralized store for network objects – user accounts, computer accounts, security groups, printers, and policies – and handles the authentication and authorization that connects those objects to resources. Introduced with Windows 2000 Server and consistently extended through Windows Server 2025, AD DS has been the dominant identity platform for on-premises Windows infrastructure for over two decades. Microsoft’s official overview is available on Microsoft Learn: Active Directory Domain Services Overview.
When someone asks what is active directory, the short answer is: a hierarchical database of network objects combined with the authentication infrastructure that controls access to those objects. The longer answer is that AD DS is simultaneously an identity store, a Kerberos authentication service, an LDAP directory, a Group Policy distribution mechanism, and a DNS-dependent replication system. Treating active directory as “just a user database” is one of the first and most expensive misconceptions in Windows administration – it leads to misdiagnosis when something breaks.
What active directory manages:
- User accounts and credentials
- Computer accounts – every domain-joined machine has one
- Security groups and distribution groups
- Organizational Units (containers for delegation and GPO targeting)
- Group Policy Objects (configuration pushed at logon and refresh – commonly used to point devices to WSUS for patch management, though WSUS is deprecated and many environments now use Windows Update for Business, Intune, or Autopatch instead)
- Trust relationships between domains and forests
How Active Directory Works
Understanding what is active directory at a technical level starts with the authentication flow – the sequence that runs the moment a user submits credentials at a domain-joined machine:
- The workstation queries DNS for a Domain Controller SRV record
- DNS returns the DC address – if this step fails, discovery has nothing to work from
- The workstation contacts the Domain Controller
- The client performs a Kerberos exchange with the Key Distribution Center (KDC) service on the DC; if authentication succeeds, the KDC issues a Ticket Granting Ticket (TGT)
- When the user accesses a resource, the TGT is exchanged for a service ticket
- Group membership is evaluated against the resource’s ACL – access granted or denied
This happens in under a second on a healthy network. The step that most documentation buries in a footnote: step 1 is DNS. Reliable internal DNS is foundational to normal AD operation – initial DC discovery and service location depend on it, and DNS failures can break domain join, new authentication, Group Policy retrieval, and replication. Clients cache discovered DC information and reuse Kerberos tickets, though, so not every resource access triggers a fresh DNS lookup – DNS failure doesn’t always look like an instant, total outage.
The most common cause of authentication failures after an AD deployment is DNS misconfiguration. Domain members need to use internal DNS servers that are authoritative for, or can correctly resolve, the AD namespace – in most environments that means DNS running on the domain controllers themselves. Never point domain-joined machines at a router, ISP resolver, or public DNS service for AD name resolution. When a machine cannot resolve the domain’s SRV records (_ldap._tcp.<domain>, _kerberos._tcp.<domain>), it cannot locate a DC, and logon fails with generic credential errors that look like account problems. Always verify DNS before anything else.
Kerberos and LDAP
Kerberos handles authentication – proving identity. LDAP (Lightweight Directory Access Protocol) handles directory queries – looking up users, groups, attributes, and object properties. Both run through the Domain Controller. Kerberos has been the default authentication protocol since Windows 2000. NTLM is the legacy fallback; it should be treated as a protocol to restrict, not rely on. The Kerberos authentication model is documented at Microsoft Learn: Kerberos Authentication Overview.
Single Sign-On in Practice
Once the active directory Kerberos service issues a TGT at logon, that ticket is reused across resource access for its lifetime – 10 hours by default and configurable through Kerberos policy. A user authenticates once at the workstation and accesses file shares, printers, intranet applications, and Exchange without re-entering credentials. This is what single sign-on means in an active directory environment: not a separate product, just Kerberos working as designed.
Core Components of Active Directory
What is active directory made of at a technical level? Five interdependent components that must all function correctly for the service to work.
Domain Controllers
A Domain Controller (DC) is a Windows Server with the AD DS role installed and promoted. It hosts a writable copy of the AD database, processes authentication requests, stores and serves Group Policy and SYSVOL content, and replicates changes to other DCs. Every domain needs at least one – every production environment needs at least two. Group Policy settings are actually applied on domain members through client-side extensions; the DC’s job is storing and distributing the policy, not enforcing it directly.
If the only domain controller in a domain becomes unavailable, the domain loses all online directory, Kerberos, LDAP, DNS-hosted-on-that-DC, and Group Policy retrieval services. Cached interactive logons and already-issued Kerberos tickets may continue working temporarily, but password changes, domain joins, new uncached authentication, policy refresh, and many directory-dependent applications fail. Service account logons without cached credentials fail immediately. Treat a single-DC deployment as an unacceptable production single point of failure – not a degraded state you can plan around.
The AD Database: NTDS.dit
The active directory database is stored in a file called NTDS.dit. By default it lives at C:\Windows\NTDS\, alongside its transaction log files (edb*.log). This is not a file administrators interact with directly – it is managed entirely by the AD DS service through the ESE (Extensible Storage Engine) database engine. The database file, log paths, and SYSVOL location are documented in Microsoft Learn: Move the Active Directory database.
Filesystem requirement: NTFS only. The NTDS.dit database, its transaction logs, and the SYSVOL replication folder must reside on NTFS-formatted volumes. Microsoft explicitly instructs administrators not to store these paths on ReFS as of Windows Server 2025 – this is a function of the ESE engine and DFSR replication behavior, not a preference. Verify the target volume format before running the AD DS promotion wizard.
Schema
The active directory schema defines what object types AD can store and what attributes those objects have. A User object has attributes for display name, UPN, SID, department, and hundreds of others because the schema defines them. Schema extensions – Exchange Server adds mailbox attributes, SCCM adds device management attributes – apply forest-wide and cannot be reversed. Extending the schema is a one-way commitment.
Global Catalog
The Global Catalog is a partial-attribute replica of every object in the entire forest. It enables cross-domain searches and assists with logon when Universal Group membership must be evaluated. In multi-domain forests, logon and universal-group evaluation can fail or become WAN-dependent when no Global Catalog is reachable and membership caching is unavailable or stale. In most production sites, making at least one local DC a Global Catalog is the simplest design. For bandwidth-constrained remote sites, Universal Group Membership Caching can reduce or remove the need for a local GC – the right choice depends on WAN reliability, the applications in use, and whether Exchange is part of the environment.
| Component | Function | Failure Impact |
|---|---|---|
| Domain Controller | Hosts AD DS, processes authentication, replicates changes | New authentication and GPO retrieval fail if no DC is reachable |
| NTDS.dit | The AD database file – ESE engine, NTFS only | Corruption or loss requires DC restore or rebuild |
| Schema | Defines all object types and attributes forest-wide | Extensions irreversible; corruption requires forest recovery |
| Global Catalog | Partial forest-wide replica for cross-domain queries | Universal Group logon delays or failures in multi-domain forests |
| SYSVOL | Replicates GPO files and scripts via DFSR – NTFS only | Group Policy fails to apply; SYSVOL replication issues compound |
The Active Directory Hierarchy: Forest, Domain, and OU
What is active directory’s logical structure built from? It organizes objects into a three-level logical hierarchy. Understanding the boundaries each level creates is important before making any deployment decisions.
Forest is the outermost security boundary. All domains in a forest share a common schema, a common Global Catalog, and implicit two-way Kerberos trusts. A forest contains one or more domains. The schema is forest-wide – extending it affects every domain in the forest.
Domain is the administrative and replication boundary. Objects within a domain share a common database and common policy scope. Most organizations – including most SMB environments – operate a single domain. Domains within the same forest get automatic, transitive two-way Kerberos trusts, so that part isn’t extra work by itself. What multiple domains actually add is more DNS zones, replication topology, Group Policy scope, delegation boundaries, and Global Catalog planning to maintain – complexity that is rarely justified below large enterprise scale.
Organizational Unit (OU) is a container within a domain. OUs organize objects for three purposes: delegation of administrative control, Group Policy Object scope, and visual organization. OUs do not create security or replication boundaries – they are an administrative construct. Designing OU structure before deployment avoids the GPO application issues that come from objects sitting in the wrong containers.
A typical single-domain structure for an SMB environment:
The structure and delegation model are covered in depth in Active Directory Structure Explained, with OU-specific GPO inheritance implications covered separately later in this article.
Active Directory vs Local Accounts
What is active directory’s value over local accounts? The decision most SMB operators face: does this environment actually need a domain?
| Feature | Local Accounts | Active Directory |
|---|---|---|
| Centralized management | No – each machine is a separate account silo | Yes – single console, single account database |
| Single sign-on | No – per-machine credential prompts | Yes – Kerberos-based SSO across resources |
| Policy enforcement | Manual – configurations drift over time | Built-in via Group Policy, applied at logon and refresh |
| Multi-site support | Not scalable | Sites and Services replication topology control |
| Administrative delegation | Not available | OU-level granular delegation |
| Password policy | Per-machine, inconsistent | Domain-wide, enforced – Fine-Grained Password Policies for exceptions |
Local accounts are sufficient for isolated machines with no shared resources. Once a file server, shared printers, or application access enters the picture, per-machine account management becomes the operational bottleneck. In practice, the decision is driven less by a fixed device count than by shared-resource, policy, audit, delegation, and lifecycle requirements – a small environment can justify centralized identity early if those needs exist, while a larger cloud-native shop may run entirely on Entra ID and Intune without traditional AD DS at all. Traditional Windows file servers that need centralized Windows authentication are a strong AD DS use case, though NAS, workgroup, and cloud-native alternatives also exist.
Is Active Directory Still Relevant in 2026?
What is active directory’s status in 2026? Yes, actively used – and the question is worth addressing directly because of the widespread confusion between Active Directory and Entra ID (formerly Azure Active Directory).
AD DS remains the dominant identity platform for on-premises Windows infrastructure. It runs Group Policy, Kerberos authentication, and domain joins for hundreds of millions of Windows devices. The vast majority of organizations with Windows file servers, domain-joined workstations, or on-premises applications are running AD DS today.
Microsoft Entra ID can genuinely replace the need for traditional AD DS in cloud-native environments built around Entra Join, Conditional Access, Intune, and SaaS authentication. What it isn’t is a drop-in protocol replacement for infrastructure that depends on LDAP, classic Kerberos or NTLM domain services, traditional Group Policy, or AD-integrated server applications. Organizations with those dependencies can’t simply move to Entra ID and remove AD DS. The common production pattern is hybrid: AD DS on-premises, with selected identities synchronized to Entra ID through Microsoft Entra Cloud Sync or Microsoft Entra Connect Sync – Microsoft has been shifting the primary sync direction toward Cloud Sync, so it’s worth checking current Entra documentation before choosing between the two for a new deployment. Hybrid gives users a single identity that works for both on-premises resources and Microsoft 365.
AD DS remains the standard foundation whenever Windows Server workloads need centralized Windows authentication, Kerberos, LDAP, Group Policy, gMSA, trusts, or AD-integrated applications. Windows Server itself doesn’t automatically require a domain – but most infrastructure built around it ends up needing one anyway.
Common Active Directory Misconceptions
Most operators who ask what is active directory get a technically accurate but operationally incomplete answer. The gaps show up during deployment and troubleshooting.
Placing NTDS.dit, AD transaction logs, or SYSVOL on a ReFS volume is an unsupported configuration – Microsoft explicitly instructs administrators not to store these paths on ReFS. If you are building a new DC on Windows Server 2025, verify the target volume is NTFS before running the AD DS promotion wizard. If an unsupported path is discovered after promotion, stop and follow Microsoft’s documented procedure for moving the AD database and logs with ntdsutil; SYSVOL relocation is a separate and more involved procedure. For a newly promoted replica DC, demoting and re-promoting onto the correct volume can be simpler and safer than an in-place move.
“Active directory is just a user database.”
AD DS is authentication infrastructure, Group Policy distribution, Kerberos ticket issuance, LDAP query handling, DNS-integrated name resolution, and a multi-master replication service. Users are stored in it – but that is not what active directory does. This distinction matters operationally: when something breaks, knowing which layer failed (authentication, replication, DNS, policy application, or schema) determines the diagnostic path. Treating AD as a flat user store leads to misdiagnosis. The tools are different, the log locations are different, and the recovery procedures are different depending on which layer is broken.
“Active directory runs fine on a single server.”
It runs. It is not fine. A single DC is a single point of failure for authentication, Group Policy, and all five FSMO roles. When it goes offline – for maintenance, hardware failure, or a bad update – cached credentials allow already logged-in sessions to keep working temporarily. New logons from devices without cached credentials fail. Service account logons fail on the spot. Password changes and domain joins are blocked. If that single DC is permanently lost, there is no surviving replica to seize FSMO roles onto – recovery depends on a valid system-state backup or a full domain rebuild. That’s why a second DC and tested backups are treated as two separate, non-substitutable requirements, not one solving for the other.
“Any filesystem works for the AD database.”
NTDS.dit, its transaction logs, and the SYSVOL replication folder must reside on NTFS volumes. The NTFS requirement comes from the ESE database engine and DFSR replication behavior. Microsoft explicitly instructs against using ReFS for any of these paths on Windows Server 2025.
Common First Deployment Mistakes
Knowing what is active directory architecturally does not prevent the common operational mistakes made during first deployments.
Choosing the wrong domain name.
The domain name chosen during forest creation is the hardest decision to reverse. company.local is the most common mistake. The .local suffix conflicts with mDNS (Multicast DNS) – the zero-configuration protocol used by macOS, Linux, and most network printers. On those platforms, .local is reserved for local network discovery, and the collision causes DNS resolution failures for Apple and Linux clients in AD environments. Beyond mDNS conflicts, .local cannot appear in publicly trusted certificates, which creates SAN problems for any internal HTTPS service authenticating with AD credentials.
The correct choice for most environments: a dedicated subdomain of your registered public DNS name, such as ad.company.com or corp.company.com. It’s simpler to operate day to day and sidesteps mDNS conflicts entirely. Using the same name internally and externally – company.com for both – is also a supported design, but it requires deliberate split-brain DNS and careful record management, which is more operational overhead than most SMB teams want to take on. Active Directory does support a controlled domain-rename procedure using rendom, netdom, and gpfixup, so a rename doesn’t automatically mean disjoining and rejoining every machine by hand – but it is a high-risk project that Exchange and many third-party integrations can block or complicate. In practice, most organizations that deployed with .local live with it rather than attempt a rename.
Setting functional levels without a plan.
The Forest Functional Level and Domain Functional Level control which DC operating systems can join the domain and which AD features are available. Treat a functional-level increase as effectively irreversible – Microsoft documents it as a one-way operation in the general case, with only narrow, feature-specific exceptions. The mistake is raising levels before decommissioning older DCs and then needing to add one back. Choose the highest level supported by every DC you actually intend to run: for a new all-Windows Server 2025 forest, that means evaluating the Windows Server 2025 functional level itself – it unlocks 2025-specific capabilities like the Database 32k Pages feature – rather than defaulting to Windows Server 2016 out of habit. Stay on 2016 only when compatibility with older DC operating systems is a real, current requirement.
Deploying a single Domain Controller.
Already covered in misconceptions. The practical response to “we only have one physical server”: deploy a second DC as a VM on the same host. A second DC VM on the same physical host provides some protection against a single guest reboot or guest-specific configuration failure – it does not provide host, storage, power, or hypervisor redundancy, since a shared-storage or host failure still takes both VMs down together. If the environment has any budget for a second physical server, a low-spec machine running Windows Server Core with just the AD DS and DNS roles is enough. It does not need to be matched hardware.
Skipping OU design before joining machines.
Objects placed in the default Computers and Users containers are outside standard GPO scope. These are not OUs – they are legacy containers with different Group Policy inheritance behavior. Machines joined to the domain before OUs exist end up in Computers, and GPOs linked to production OUs do not apply to them. Moving objects later and cleaning up applied policy requires more work than designing the OU structure before the first domain join – a pattern that repeats in every active directory environment that skips this step. The OU design approach is covered in Active Directory OU Design.
Quick Verification with PowerShell
After promoting the first domain controller, a handful of PowerShell commands confirm that the forest, domain, and domain-controller objects are present – the fastest way to check what is active directory reporting about its own state right after promotion. These are covered fully in the Active Directory Post-Install Checklist – the versions here are for a quick sanity check immediately after promotion:
# Forest configuration: forest mode, domains, FSMO role holders
Get-ADForest
# Domain configuration: functional level, current FSMO role assignments
Get-ADDomain
# Confirm DC registration in the directory
Get-ADDomainController -Filter *
# Schema version - Get-ADForest does not return this; query the schema object directly
$schemaNC = (Get-ADRootDSE).schemaNamingContext
Get-ADObject -Identity $schemaNC -Properties objectVersionGet-ADForest returns the forest object itself – forest mode, the list of domains, Global Catalog servers, and the Schema Master and Domain Naming Master role holders – not the schema version, which needs the separate query above against the schema naming context. Get-ADDomain shows the domain functional level and current FSMO role assignments. Get-ADDomainController -Filter * lists every DC object the directory contains.
None of that proves the new DC is healthy on the network – it only confirms the objects exist in the directory. For real operational confidence, follow up with dcdiag and repadmin, plus a direct check that SYSVOL and NETLOGON are actually being served and that DNS is resolving the DC’s SRV records:
dcdiag /test:Advertising /test:DNS /test:Replications /test:SysVolCheck /test:DFSREvent /v
repadmin /showrepl * /errorsonlyTest-Path '\\NEWDC\SYSVOL'
Test-Path '\\NEWDC\NETLOGON'
Resolve-DnsName '_ldap._tcp.dc._msdcs.contoso.com' -Type SRVA newly promoted DC that is missing from Get-ADDomainController, failing dcdiag’s Advertising or SysVolCheck tests, or not resolving in DNS has a registration, replication, or SYSVOL issue that needs resolving before the environment is considered healthy.
Frequently Asked Questions
What is the difference between Active Directory and a domain controller?
What is active directory vs what is a domain controller: active directory is the directory service – the database, the authentication framework, the policy mechanism. A domain controller is the Windows Server that hosts and runs active directory. AD is the software and its data; the domain controller is the machine. You need at least one domain controller for an AD DS domain to function – in practice, at least two.
Is Active Directory still used in 2026?
Yes. AD DS is the dominant on-premises Windows identity platform and is not being retired. Microsoft Entra ID (formerly Azure AD) can fully replace it for cloud-native environments, but it’s not a drop-in substitute where Group Policy, classic Kerberos/LDAP, or AD-integrated applications and file servers are still in use. Most mid-size organizations run hybrid: AD DS on-premises, with selected identities synchronized to Entra ID through Microsoft Entra Cloud Sync or Microsoft Entra Connect Sync.
What is the difference between a domain and a forest in Active Directory?
A forest is the outermost boundary – one schema, one Global Catalog, one set of implicit trusts. A domain is an administrative and replication boundary within the forest. Most organizations run a single forest with a single domain. Multiple domains are justified by specific security isolation or administrative separation requirements – rarely needed in SMB environments.
Does Active Directory require DNS?
Yes, functionally. DC location, Kerberos ticket requests, and AD replication all rely on DNS queries for SRV records. When DNS can’t resolve to correct DC addresses, new authentication, domain joins, and policy refresh break – though cached logons and already-issued tickets can keep working for a while. The promotion wizard commonly installs the DNS Server role on the first DC when no suitable DNS infrastructure already exists, reflecting how fundamental the dependency is, though AD DS can also integrate with existing supported DNS infrastructure instead. Pointing domain-joined machines at a router or upstream resolver instead of internal AD-aware DNS is one of the most reliable ways to break authentication.
Can Active Directory run on a single server?
Technically yes. Should not be the permanent state. A single DC means a single point of failure for authentication, Group Policy, and all FSMO roles. Two DCs are the minimum for any environment where unplanned downtime is unacceptable. The second DC can be a VM on the same physical host – this handles the common cases of reboots and configuration errors, but not a shared-storage, host, or power failure, which would take both VMs down together.
What filesystem does Active Directory require?
NTFS. The NTDS.dit database file, all AD transaction logs, and SYSVOL must reside on NTFS volumes. Microsoft explicitly instructs against ReFS for any of these paths on Windows Server 2025. Verify volume format before running the AD DS promotion wizard.
What is the NTDS.dit file?
NTDS.dit is the active directory database file – the physical store of everything active directory contains – every user, computer, group, OU, and their attributes live in it. Default location: C:\Windows\NTDS\ on every DC. It is managed exclusively by the AD DS service and should never be modified directly. Backing up AD means backing up the System State, which includes NTDS.dit and SYSVOL. A corrupted or lost NTDS.dit requires either a DC restore from System State backup or a metadata cleanup followed by re-promotion from scratch.
Final Thoughts
What is active directory in practice? The identity and policy foundation for Windows infrastructure since Windows 2000. The core architecture – Kerberos authentication, LDAP directory, forest and domain hierarchy, Group Policy distribution – has remained consistent across every Windows Server version since. That stability is why understanding what active directory is and how it works translates directly to operational competence across the entire Windows Server ecosystem.
The decisions that matter most happen before installation: domain naming, filesystem verification, and the commitment to run at least two DCs on separate failure domains where possible. These are not configuration preferences – they are architectural commitments with operational consequences that compound over time. The environments that avoid the most remediation work are the ones where these decisions were made deliberately before the first domain controller was promoted.
The next step: How to Install Active Directory on Windows Server 2025.
Active Directory Series
16 articles — Windows Server 2025 · Forest & Domain · FSMO · GPO · Replication · DNS · Backup & Recovery