What is Active Directory?
Active Directory is Microsoft's directory technology for centrally managing identities, computers, groups and selected security settings in an organization. In most infrastructure discussions, it refers to Active Directory Domain Services (AD DS), the Windows Server role behind domains, domain controllers and integrated authentication. It should not be confused with Microsoft Entra ID, a complementary cloud identity service.
Architecture: domains, forests, OUs and domain controllers
An AD domain contains directory objects such as user, computer and group accounts. A forest includes one or more domains sharing a schema, configuration and trust structure. An organizational unit (OU) organizes objects, enables delegated administration and scopes Group Policy; it is not a security boundary. Domain controllers (DCs) hold replicated copies of the NTDS.dit database. Multiple DCs improve authentication resilience when DNS and replication remain healthy.
- Windows PC Domain account
- Domain DNS Locates AD services
- Domain controller Validates the identity
- Kerberos Issues tickets
- Internal service Enforces access permissions
A domain controller hosts AD DS and Kerberos services; the target service still checks the user's access rights.
How authentication works
When a domain-joined workstation signs in, it locates a domain controller through DNS and usually uses Kerberos to obtain an initial ticket (TGT) from the KDC. It can later request service tickets for SMB, HTTP or SQL where SPNs and permissions are correctly configured. NTLM still appears in compatibility scenarios but should be reduced. LDAP provides directory queries; LDAPS or appropriately signed and protected LDAP connections protect communication. Kerberos, LDAP and DNS serve different purposes.
DNS, AD sites and replication
Active Directory depends on DNS: SRV records help clients locate domain controllers and Kerberos services. AD sites map the network topology and IP subnets, directing clients to suitable DCs and controlling intersite replication. Multimaster replication synchronizes most directory changes while FSMO roles retain particular responsibilities. Replication failures can cause divergent groups, passwords or objects even when one DC appears to respond normally.
Users, groups and permissions
User and service accounts represent identities while security groups support manageable access control. On Windows resources, grant permissions to purpose-built security groups instead of assigning every individual account directly. Global, domain-local and universal group scopes serve different purposes. Security identifiers (SIDs) drive access decisions; renaming an account does not change its SID. Managed service accounts, including gMSAs when supported, reduce manually maintained service passwords.
Group Policy (GPO)
Group Policy Objects centrally define computer and user settings such as security policy, screen locking, firewall configuration and scripts. They link to sites, domains or OUs; processing depends on inheritance, LSDOU order, security filtering and potentially WMI filtering. SYSVOL content replication is separate from directory database replication. A linked GPO is not necessarily applied: gpresult /h and GroupPolicy event logs help diagnose scope and processing.
Practical example: onboarding an employee
In a company with 80 workstations, an administrator creates a new employee account, assigns role-appropriate groups and places the workstation in the relevant OU. At sign-in, a DC authenticates the user, applicable policies are processed and permitted file shares become accessible. At offboarding, the account is disabled, access and sessions are revoked across relevant systems, and data is handled according to policy. This illustrates the difference between identity, group membership and actual resource permissions.
Troubleshooting checklist
When a user cannot sign in, check workstation time, DNS configuration, DC reachability, account state, group membership and Kerberos errors. Commands such as nslookup -type=SRV _ldap._tcp.dc._msdcs.domain, nltest /dsgetdc:domain, dcdiag and repadmin /replsummary provide complementary evidence. For GPO issues, use gpresult /r or gpresult /h. Avoid broad DNS, SPN or replication changes before identifying the failing component. Administrative permissions and actual domain names must be considered.
Security hardening
Prioritize protection of domain controllers, Domain Admins and Enterprise Admins, and administrative access paths. Use separate privileged identities, MFA on compatible entry points, dedicated admin workstations, least-privilege delegation and privileged-group monitoring. Gradually reduce NTLM and legacy protocols after compatibility testing; secure LDAP with suitable signing and protection. Monitor GPO changes, Kerberos delegation and backup access. A compromised DC can threaten the entire domain.
Backup, restore and continuity
Active Directory backups should support consistent domain-controller recovery, including supported System State backups. Multiple DCs are not a backup: deleted objects, compromise and corruption can replicate. Document object recovery, AD Recycle Bin when enabled, authoritative versus non-authoritative restore procedures and forest recovery. Rehearse recovery outside production. Do not simply roll back an old DC snapshot without checking support and safeguards for the Windows Server and hypervisor versions in use.
Active Directory, Entra ID and hybrid synchronization
AD DS traditionally manages on-premises network identities and resources, while Microsoft Entra ID supports cloud identities, SaaS applications and Conditional Access. Microsoft Entra Connect Sync or Cloud Sync can synchronize identities depending on architecture; they do not automatically turn GPOs or DCs into cloud services. Entra-joined devices managed through Intune differ from traditional AD domain-joined devices. Decisions depend on legacy applications, connectivity, security requirements and migration strategy.
Frequently asked questions and common mistakes
Is Active Directory required for Microsoft 365? No: a cloud-only organization can use Entra ID without local AD DS. Does a second DC replace backups? No, unwanted changes may replicate. Can an OU alone configure workstations? No: OUs organize scope, whereas policies, permissions and management tools apply changes. Finally, switching domain-joined clients from internal AD DNS to a public resolver often breaks domain-controller discovery: clients need DNS that resolves the AD zone correctly.