Active Directory Domain Services (AD DS) is Microsoft’s on-premises directory service for centrally managing users, computers, authentication, authorization, and policy in Windows networks. It stores directory objects on domain controllers and uses technologies such as DNS, Kerberos, LDAP, and Group Policy to connect users and devices to network resources.
This guide covers what is Active Directory and how it works, along with what it’s used for. Deployment and post-installation procedures are covered separately in How to Install Active Directory on Windows Server 2025.
- AD DS centralizes users, computers, groups, authentication, authorization, and policy
- Domain controllers host the directory and provide authentication/directory services
- DNS helps clients locate AD services and domain controllers
- Kerberos handles most domain authentication; LDAP is used to query directory data
- Group Policy centrally configures domain users and computers
- Forests, domains, OUs, and sites organize the logical and physical AD environment
What Is Active Directory Domain Services (AD DS)?
AD DS provides the centralized identity layer behind a traditional Windows domain. It stores directory objects such as users, computers, groups, and service accounts, authenticates users and devices, and provides the policy and authorization framework used by domain resources. Microsoft’s own overview is available on Microsoft Learn: Active Directory Domain Services Overview.
AD DS does more than store user accounts. It also functions as an identity store, a Kerberos authentication service, an LDAP directory, and a Group Policy distribution mechanism. Treating it as “just a user database” is a common misconception, and it can send troubleshooting in the wrong direction because authentication, replication, DNS, and policy application are separate layers with different failure modes.
What Is Active Directory Used For?
- Centralized user and account management
- Computer and domain membership
- Authentication of users and devices
- Authorization through security groups
- Single sign-on across domain resources
- Group Policy configuration at scale
- Centralized administration and delegation
- Access to Windows-based resources and AD-integrated applications
What Is Active Directory and How It Works
The core sequence, from credential entry to resource access:
- A domain-joined client uses DNS to locate an appropriate domain controller.
- The client contacts the DC.
- Kerberos authenticates the user or computer.
- The KDC issues a Ticket Granting Ticket (TGT) when authentication succeeds.
- The client requests service tickets for resources.
- The resource evaluates the user’s authorization context against its permissions.
- Group Policy and directory lookups use AD services as needed.
This normally completes in under a second on a healthy network.
Domain Controllers
A Domain Controller (DC) is a Windows Server with the AD DS role installed and promoted to a domain controller. It hosts a copy of the AD database, processes authentication requests, serves LDAP queries, stores and distributes Group Policy and SYSVOL content, and replicates directory data with other DCs. Standard writable DCs can accept directory changes; Read-Only Domain Controllers (RODCs) host read-only replicas. Production domains normally use multiple DCs for redundancy.
DNS and Domain Controller Discovery
Clients locate domain controllers through DNS SRV records, so domain members need DNS servers that can correctly resolve the AD DNS zones and SRV records. Pointing clients only at a router, ISP resolver, or public DNS service prevents normal AD service discovery unless that resolver can resolve the internal AD namespace. DNS problems can break DC discovery, domain join, new authentication, and Group Policy retrieval, though cached logons and existing Kerberos tickets can keep working for a while after DNS resolution fails.
Kerberos Authentication
Kerberos handles authentication – proving identity – and has been the default protocol since Windows 2000. NTLM exists as a legacy fallback and should be restricted rather than relied on. Once the KDC issues a Ticket Granting Ticket (TGT) at logon, the client can use that TGT to request service tickets for domain resources without asking the user to re-enter credentials. That is the basis of Kerberos single sign-on in an AD environment, not a separate product. Microsoft documents the model at Microsoft Learn: Kerberos Authentication Overview.
LDAP Directory Queries
LDAP (Lightweight Directory Access Protocol) is the directory access protocol used by applications and administrative tools to search, read, and work with directory objects and attributes. Kerberos proves identity; LDAP provides access to directory data.
Authorization and Security Groups
Authentication and authorization are different steps. Authentication confirms identity; authorization decides what that identity can access. Once a user has a service ticket, the resource evaluates the security identifiers in the user’s authorization context – typically the user’s own SID and relevant security-group SIDs – against its access control list to grant or deny access.
Group Policy
Group Policy Objects (GPOs) centrally configure domain users and computers. GPO metadata is stored in Active Directory, file-based policy content is stored in SYSVOL, and clients process the applicable settings locally at logon and refresh. See Group Policy in Active Directory for scope and processing details, or Microsoft’s Group Policy overview documentation for the underlying mechanism.
What Does Active Directory Store and Manage?
- 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
- Service accounts
- Trust relationships between domains and forests
Core Components of Active Directory
| Component | What it does |
|---|---|
| Domain Controller | Hosts AD DS and processes authentication/directory requests |
| DNS | Helps clients locate AD services and DCs |
| Kerberos/KDC | Provides domain authentication and tickets |
| LDAP | Provides directory queries and access |
| NTDS.dit | Stores AD directory data |
| SYSVOL / Group Policy | Stores GPO files and scripts |
| Global Catalog | Enables forest-wide object lookup |
| Schema | Defines AD object types and attributes |
NTDS.dit is the database file that stores the directory data held by a domain controller. The schema defines what object types and attributes AD can store; it’s forest-wide, and extensions apply to every domain in the forest. The Global Catalog is a partial-attribute replica of objects across the forest, hosted by GC-enabled domain controllers and useful for cross-domain searches in multi-domain environments.
How Active Directory Is Organized
| Level | What it is |
|---|---|
| Forest | Outermost logical boundary; domains share schema and configuration, plus forest-wide Global Catalog search |
| Domain | Administrative and replication boundary inside a forest |
| OU | Container inside a domain used for delegation and GPO scope |
| Site | Physical topology construct for DC location and replication |
See Active Directory Structure for the full forest, domain tree, domain, and OU hierarchy, with diagrams and a worked example.
Active Directory vs Local Accounts
| Feature | Local Accounts | Active Directory |
|---|---|---|
| Centralized management | No – each machine is a separate account silo | Yes – centralized directory and management |
| Single sign-on | No centralized domain SSO | Yes – Kerberos-based SSO across resources |
| Policy enforcement | Per-device or through separate management tools | Built-in via Group Policy, applied at logon and refresh |
| Multi-site support | No centralized directory/site topology | Sites and Services replication topology control |
| Administrative delegation | Per-system administration | OU-level granular delegation |
Local accounts work fine for isolated machines with no shared resources. AD becomes useful once centralized identity, policy, resource access, delegation, or lifecycle management start to matter, regardless of exact environment size.
Active Directory vs Microsoft Entra ID
AD DS is an on-premises directory and domain service; Microsoft Entra ID (formerly Azure AD) is a cloud identity platform. They solve related problems but aren’t interchangeable. Entra ID isn’t a drop-in replacement for infrastructure that depends on LDAP, classic Kerberos or NTLM, traditional Group Policy, or AD-integrated server applications – those dependencies still need AD DS. Cloud-native environments built around Entra Join, Conditional Access, and SaaS authentication may not need traditional AD DS at all. Hybrid environments can run both: AD DS on-premises with identities synchronized to Entra ID through Microsoft Entra Cloud Sync or Entra Connect Sync.
Frequently Asked Questions
What is Active Directory in simple terms?
A Microsoft directory service that stores users, computers, and groups, and handles authentication, authorization, and policy centrally instead of managing each machine separately.
What is Active Directory used for?
Active Directory is used for centralized identity management, authentication, authorization through groups, device management, Group Policy, and access to Windows-based and AD-integrated resources.
How does Active Directory work?
DNS locates a domain controller, Kerberos authenticates the user or computer, the client gets a service ticket for the resource it needs, and the resource authorizes access based on the user’s authorization context.
What is the difference between Active Directory and a domain controller?
Active Directory Domain Services is the directory service – the database, authentication framework, and policy mechanism. A domain controller is the Windows Server that hosts and runs it.
Does Active Directory require DNS?
Yes. Normal Active Directory service discovery depends heavily on DNS, especially SRV records used to locate domain controllers and Kerberos services. DNS problems can break DC location, domain joins, new authentication, Group Policy processing, and replication.
What is the difference between Active Directory and Microsoft Entra ID?
AD DS is an on-premises directory and domain service. Entra ID is a cloud identity platform. They can run side by side in a hybrid setup, but Entra ID doesn’t replace every AD DS dependency on its own.
Is Active Directory still used?
Yes. AD DS remains a standard identity platform for on-premises Windows infrastructure. AD DS and Entra ID can also be used together in a hybrid setup.
Bottom Line
Active Directory Domain Services is the identity and policy foundation for Windows infrastructure: a directory of users, computers, and groups, tied together by DNS-based discovery, Kerberos authentication, LDAP queries, and Group Policy distribution. The core concepts – domain controllers, Kerberos authentication, LDAP directory access, DNS-based service discovery, and Group Policy – have remained recognizable across Windows Server generations, which is why understanding how these pieces fit together carries over from one version to the next.
Deployment and the full forest, domain, and OU hierarchy are covered in the guides linked above.
Active Directory Series
25 articles – Windows Server 2025 · Forest & Domain · FSMO · GPO · Replication · DNS · Security · Backup & Recovery