Active Directory Fundamentals

Active Directory Domain Services, or AD DS, is the directory service built into Windows Server. It stores information about network objects and makes that information available to authorized users, computers, and applications.

The directory is more than an address book. It supplies shared identity, authentication, authorization data, policy scope, and administrative boundaries for Windows-centered infrastructure. A user can sign in with one domain identity. A computer can prove that it belongs to the domain. A service can find accounts and groups through directory queries. Administrators can apply settings to many systems through Group Policy.

This course uses Active Directory to mean AD DS. Microsoft Entra ID is a separate cloud identity service. The two can exchange identity data in a hybrid design, but they have different protocols, structures, and operating models.

Start with objects and attributes

AD DS stores objects. Common objects represent users, computers, groups, printers, and organizational units. Each object has attributes that describe it. A user object can have a sign-in name, display name, group memberships, and other properties.

The schema defines which object classes and attributes can exist. It also defines rules for those objects and attributes. The schema applies across the forest, so a schema change has forest-wide consequences.

Every object has a distinguished name that identifies its location in the directory hierarchy. For example, a user can sit inside an organizational unit within a domain. Applications normally query directory data through the Lightweight Directory Access Protocol, or LDAP.

Do not confuse an object's location with its access rights. Moving an account to another organizational unit can change delegated administration or Group Policy scope. It does not automatically grant access to a file share. Resource permissions normally depend on security principals, security groups, and access control lists.

The logical hierarchy

Keep this structure in mind:

forest
└── domain
    └── organizational unit
        ├── user object
        ├── computer object
        └── group object

A forest is the top-level AD DS boundary. Its domains share a schema, configuration, and global catalog. Domains in one forest have automatic two-way, transitive trust relationships.

A domain is a directory partition and an administrative scope within a forest. It holds objects such as users, computers, groups, and organizational units. A domain also establishes an authentication and policy boundary for many everyday operations.

An organizational unit, or OU, is a container inside one domain. Use OUs to arrange objects for delegated administration and Group Policy. An OU is not a security boundary against a forest administrator. It is an administrative scope within the forest's trust boundary.

A forest can contain one domain or several domains. More domains add replication, administration, and recovery complexity. Create them only when their boundary solves a defined requirement. Organizational charts alone rarely justify extra domains because OUs can represent delegated administrative scopes.

Domain controllers make the directory available

A domain controller, or DC, runs AD DS and stores a writable copy of its domain's directory data. Domain controllers authenticate domain identities, answer directory queries, and replicate changes.

AD DS normally uses multimaster replication. A writable domain controller can accept many directory changes, then replicate them to its partners. This design removes one permanent write server from ordinary account management.

Some operations still need a single owner to avoid conflicts. AD DS assigns five operations master roles, often called FSMO roles. Two operate at forest scope: Schema Master and Domain Naming Master. Three operate in each domain: RID Master, PDC Emulator, and Infrastructure Master.

A global catalog stores a searchable partial representation of every object in the forest. It helps users and applications find objects beyond one domain. It also participates in forest-wide sign-in behavior.

Replication creates availability, not backup. A mistaken deletion or harmful change can replicate to every domain controller. Recovery still requires tested backups, protected recovery credentials, and a documented forest recovery plan.

DNS connects clients to domain services

AD DS depends on DNS for service discovery. Domain controllers register service records. Domain members query DNS to find suitable domain controllers and services.

The domain controller locator process uses DNS information, availability checks, and site awareness. A client should use DNS servers that can resolve the AD DS namespace and its service records. Pointing a domain member only at an unrelated public resolver breaks this discovery path.

Many apparent Active Directory failures begin as name-resolution failures. Authentication, Group Policy, replication, and directory queries can all fail when clients or domain controllers cannot locate the right services. Treat DNS health as part of directory health.

Sites describe the physical network

Forests, domains, and OUs form the logical model. Sites, subnets, and site links describe network topology.

A site usually represents well-connected IP subnets. Mapping each subnet to the correct site helps clients find nearby domain controllers. Site links guide replication traffic between sites. Their schedules and costs can represent slower or more expensive network paths.

Sites do not replace domains. A domain can span many sites, and one site can host domain controllers from several domains. Use the logical structure for identity and administration. Use the site topology for service location and replication routing.

Authentication is not authorization

Authentication verifies an identity. Authorization decides what that identity may do.

In a domain environment, Windows supports several authentication providers. Kerberos is the preferred authentication protocol for Active Directory environments. NTLM remains available for compatibility and for cases where Kerberos cannot be used.

Successful authentication produces security information that Windows can use for authorization. The user's security identifier and group memberships contribute to an access token. A resource then compares that token with its access control list.

A trust lets domains accept authentication from another trusted authority. A trust does not grant universal access. Resource permissions still determine which authenticated principals can use a resource.

This separation explains a common incident pattern: a user signs in successfully but cannot open a share. Authentication worked. Authorization failed, or the user's current token does not contain the expected group membership.

Groups carry access intent

AD DS has security groups and distribution groups. A security group can appear in access control lists and receive rights or permissions. A distribution group supports email distribution and is not security-enabled.

Group scope controls membership and where a group can receive permissions:

• Global groups normally collect accounts from one domain and can receive permissions across trusted domains.
• Domain Local groups can contain principals from trusted domains and normally receive permissions within their own domain.
• Universal groups can contain accounts and groups from across one forest and can receive permissions across the forest or trusting forests.

Assign permissions to groups instead of individual accounts. This separates two decisions: who has a role, and what that role can access. Nested groups can make that relationship reusable, but excessive or undocumented nesting makes authorization hard to trace.

Privileged groups deserve separate treatment. Membership in groups such as Domain Admins carries broad control. Keep permanent membership small, protect privileged credentials, and delegate narrower tasks where possible.

OUs, delegation, and Group Policy solve different problems

OUs support two major designs: delegated administration and Group Policy scope.

Delegation grants a user or group specific administrative permissions over a domain or OU. A help desk group can receive permission to reset passwords in one OU without becoming Domain Admins. The delegated permissions apply to objects under the selected container.

Group Policy manages user and computer settings. A Group Policy Object, or GPO, can be linked to a site, domain, or OU. The Group Policy service determines which GPOs apply from the object's site, domain, and OU placement.

Do not use group membership and OU placement as interchangeable controls. Groups usually express authorization to resources. OUs usually express administrative delegation and policy scope. A clear design uses each structure for its intended job.

The forest is the security boundary that matters

All domains in a forest share critical directory services and trust relationships. Forest-level administrators and domain controller compromise can affect the whole forest. Separate forests, not separate OUs, are required when two parties cannot trust the same forest owners and service administrators.

Domain controllers hold the identity control plane. An attacker with privileged control of a domain controller can alter directory data and undermine systems that trust the forest. Protect domain controllers as high-value systems. Restrict interactive use, administrative access, software, network exposure, and physical access.

Availability also requires more than adding domain controllers. Monitor replication, DNS, time synchronization, backups, privileged access, and recovery readiness. A healthy-looking sign-in path does not prove that every directory partition is replicating correctly.

Where Active Directory fits

AD DS remains a strong fit for domain-joined Windows systems, Kerberos and NTLM workloads, LDAP-aware applications, centralized Group Policy, and on-premises resource authorization.

Microsoft Entra ID is built for cloud identity and access. It uses a tenant and cloud-oriented protocols rather than AD DS forests, domains, and OUs. Microsoft documents synchronization and hybrid patterns between the two services. Synchronization does not turn one directory into the other.

Microsoft Entra Domain Services is another distinct service. It provides managed domain capabilities for applications that need LDAP, Kerberos, NTLM, domain join, or Group Policy without customer-managed domain controllers. Evaluate it as a managed compatibility service, not as another name for AD DS.

The durable mental model is a distributed identity control plane. Objects and attributes hold identity data. Domains partition that data. Domain controllers serve and replicate it. DNS helps clients find it. Sites shape network-aware behavior. Groups, permissions, delegation, and Group Policy turn directory identity into controlled administration.