Active Directory Guide: Architecture, DNS, Security

Active Directory is the identity backbone of a Windows network. It’s the directory service that holds user accounts, computers, groups, password policies, and permissions in one place. Done well, it means an employee signs in once and reaches everything they’re allowed to, an administrator shapes hundreds of machines from one console, and a security team watches one layer instead of a hundred. Done badly, it produces a new fire every week and is the first thing an attacker goes for.

Think of a holding company with several businesses, hundreds of staff, and sites in different cities. Two departments keep it running. HR knows who works where, in which role, with which authority. Security and access control decides whose badge opens which door: the finance manager reaches their floor, IT reaches the server room, an intern never gets onto the production floor. On top of both sits a third layer, the internal rulebook: which software people may use, what goes where, when the building opens. Active Directory is the digital version of all three. Accounts are HR records, security groups are badge levels, and Group Policy objects are the rulebook.

This guide is the map. Each section says what a part of Active Directory does, where it usually goes wrong in the field, and where to go deeper. Five topics already have their own articles, and the map points you there instead of repeating them: DNS for Active Directory, joining computers to the domain, Kerberos, LDAP, the protocol applications use to query the directory, and installing an internal certificate authority. The rest is covered here until its own article exists.

What Is Active Directory?

Active Directory Domain Services (AD DS) is the directory that answers three questions for every sign-in: who is this, what may they reach, and which rules apply to the machine they’re using. When someone signs in, their record is looked up, the password is verified, their group memberships are collected, and the machine’s restrictions are applied. It takes seconds, and it’s all done by the domain controllers.

Active Directory vs. Workgroup: Where Central Management Pays Off

In a small office where every computer keeps its own users, its own password policy, and its own share permissions, the model is a workgroup. For three people it really is enough, and Active Directory would be overhead. So why does every growing organization abandon it?

The answer is multiplication. In a workgroup, the number of accounts isn’t users; it’s users × machines, because every machine keeps its own:

The table doesn’t say “central management is nicer.” It says past a certain size, a workgroup becomes unmanageable in practice.

The break shows most clearly on the day someone leaves. In a workgroup you delete their account on 20 machines, and the real problem is this: miss one and that machine stays an open door, and there’s no way to find out which one you missed. In Active Directory the same job is one disabled account, done in seconds and verifiable.

The third break is auditing. “Who opened this file, and when?” and “who changed this password?” have no central answer in a workgroup; the records are scattered across machines. Those are exactly the questions asked in security audits, customer security questionnaires, and, in Europe, when you have to demonstrate accountability for personal data under the GDPR.

Active Directory Architecture

The quickest way to picture AD is as nested boundaries. Outermost is the forest, the technical and security boundary of the whole structure. Inside it are one or more trees, inside those the domains, inside a domain the organizational unit (OU) hierarchy, and inside the OUs the users, groups, and computers.

Domain, Tree, Forest

A domain is AD’s basic security boundary; in the holding analogy, one company. ad.sercebilisim.com, the lab domain behind this guide’s articles, is one domain: its users, groups, and computers live inside that boundary and share one password policy and one security model.

A tree is a set of domains sharing one DNS namespace, for example ad.sercebilisim.com, eu.ad.sercebilisim.com, and us.ad.sercebilisim.com. Parent and child domains trust each other automatically (transitive trust).

A forest is the outermost boundary and contains one or more trees. It shares one schema (the template that defines what objects can exist) and one global catalog. In the analogy: the forest is the holding, a tree is a group of companies, a domain is a company, an OU is a department.

For most small and mid-sized organizations, one forest with one domain is the right choice. Extra domains usually add complexity without adding anything; OUs and Group Policy provide all the separation one domain needs.

Global Catalog: The Forest’s Shared Index

The global catalog (GC) is a special directory that holds a partial copy of every object in every domain of the forest. The key word is partial: it carries only the attributes used for searching (name, email, group membership), while the full object stays on its own domain’s controllers. Each company keeps full personnel files in its own building; head office keeps a summary register of everyone across the group. You check the register first and go to the company’s archive for detail.

Why it matters:

• Searching across domains. A normal directory query sees only its own domain; finding a user in another domain means asking the GC.
• Universal group membership. At sign-in, a user’s universal group memberships are checked, and that information lives only in the GC. If no GC is reachable, sign-in can slow down or permissions can be applied incompletely.
• Applications that read the directory, such as mail servers resolving address lists, go through the GC, which makes GC placement a performance decision.

In a single-domain forest you won’t feel the difference day to day, but leave the GC box checked on the first DC: sign-in depends on it. With several sites, put at least one GC in each so identity lookups don’t cross the WAN.

Organizational Units: The Departments

OUs group objects inside a domain like folders, but they’re more powerful than folders, because you can apply both Group Policy and delegated administration to them.

A good OU design answers two questions: how do I want to manage these objects together, and which policies will I apply to them? Every level needs a management reason. A level without one only deepens the tree, makes policy inheritance hard to follow, and turns into maintenance debt.

A pattern that works in the field: gather the location tree under one Locations OU, split each location by object type into Computers, Groups, and Users, and add department OUs under Users only where they’re needed.

ad.sercebilisim.com/
  OU=Locations/
    OU=Head_Office/
      OU=Computers/
      OU=Groups/
      OU=Users/
        OU=IT/
        OU=Finance/
    OU=Branch_North/
      OU=Computers/
      OU=Groups/
      OU=Users/
  OU=Servers/
  OU=Universal_Groups/
  OU=Service_Accounts/

The tree is a design example with English names. The lab behind this guide uses the same structure with Turkish names, which is why the screenshots in the join article show Sunucular and Lokasyonlar instead of Servers and Locations.

Notice the three top-level OUs outside the location tree. Servers keeps servers apart from clients, because the policies applied to servers (hardening, auditing, service settings) differ fundamentally from client policies. Service_Accounts separates non-human accounts: you know at a glance whether an account is a person or a service, and targeting a service-account password policy becomes easy. Universal_Groups holds groups that belong to no single site. Where new computers land by default, and why the built-in Computers container can’t receive Group Policy, is covered in the join article.

Sites and Subnets: Physical Topology

An OU is a logical management boundary; a site is a physical one. If you have domain controllers in several locations connected by WAN links, you tell AD “this subnet is the head office, that subnet is the branch, and the link between them is this fast.” Then a user signing in at the branch goes to the branch DC, not one across the WAN, and replication between sites is compressed and scheduled.

Careless site and subnet definitions are a quiet source of trouble: clients authenticate against far-away DCs, and policy that should arrive in seconds sometimes takes minutes. If gpresult /r shows policy coming from a DC you didn’t expect, look at sites and subnets before anything else.

FSMO Roles: Five Special Duties

FSMO (Flexible Single Master Operations) roles are among AD’s most misunderstood concepts. Most AD work is multi-master: a change on any DC replicates to the others. Five operations, though, must happen on exactly one DC at a time. In the holding, most daily decisions are made locally and synchronized later, but a few things, like registering a new company or issuing staff numbers, are done only at designated offices.

Forest-wide roles (one per forest, normally on the first DC in the forest root domain):

• Schema master: the only DC where the schema can be changed. Some product installs and Windows Server upgrades extend the schema.
• Domain naming master: coordinates adding and removing domains in the forest.

Domain-wide roles (one per domain):

• RID master: hands out pools of relative IDs, used to build the unique security identifier (SID) of every new user, group, and computer.
• PDC emulator: the most critical role. It’s the domain’s time reference, receives password changes first, and processes account lockouts. When it’s unavailable, sign-ins and lockouts misbehave. Its clock matters more than any other machine’s: every member follows it, and it should follow an outside time source. In the lab behind the Kerberos article, it didn’t, and nothing warned anyone.
• Infrastructure master: updates references to objects in other domains; of little consequence in a single-domain forest.

A healthy DC can transfer a role to another. If the holder dies and won’t return, the role is seized on another DC, and the original must never be reconnected, or replication breaks. See who holds what with one command, and keep the output in your documentation:

netdom query fsmo

Moving a role is one PowerShell line per role, for example:

Move-ADDirectoryServerOperationMasterRole -Identity "DC02" -OperationMasterRole PDCEmulator

DNS and Active Directory

Active Directory doesn’t start without DNS. A client finds its domain controller, its Kerberos KDC, and its LDAP server by asking DNS for SRV records, which AD writes automatically when a DC is promoted. That’s why the rule that matters most is also the one broken most often: domain members must use internal domain controllers as their DNS servers, never a public resolver. Internet names are resolved through forwarders on the DC.

With AD-integrated zones, DNS data is stored in the directory itself, replicated to every DC without zone transfers, writable on any DNS server, and protected by secure dynamic updates so only authenticated machines update their own records.

Most field problems that look like Active Directory problems are really DNS: failed joins, replication that stops, Group Policy that doesn’t arrive. The configuration steps (forwarders, reverse lookup zones, conditional forwarders, and split-brain DNS) are in Active Directory DNS, together with the lab case where an internal zone for the public domain quietly broke access to the organization’s own website for three months.

Joining Computers to the Domain

The join itself is three clicks or one Add-Computer line. Where it fails is in the prerequisites: DNS must point to a domain controller, clocks must be within five minutes, and the hostname should be set before the join, not after. Where it succeeds and still does nothing useful is placement: a computer that lands in the default Computers container gets no OU-linked policy at all, which is the most common cause of “the join worked but no GPO applies.”

Two lab findings belong on every checklist. A domain’s NetBIOS name doesn’t have to match the first label of its DNS name, so ad\user can fail where SERCEBILISIM\user works. And a switched-off domain controller stays in DNS, so clients keep trying it. Prerequisites, redircmp, pre-created objects and the 2022 join hardening, the common errors, and offline domain join at scale are all in How to Join a Computer to an Active Directory Domain.

Users, Groups, and Permissions

Once AD is running, the real work begins: bringing in real users, groups, and computers, placing them in the right OUs, and giving them the right memberships.

Three OU principles. Delegation is per OU: to let a junior admin reset passwords only for sales staff, sales users need their own OU. Group Policy is linked per OU: “block USB storage for finance” needs a finance OU. And the default Users and Computers containers are not used as permanent homes: they can’t receive Group Policy, so redirusr and redircmp point new objects elsewhere.

Two names per user. The UPN (User Principal Name), such as jane.doe@example.com, is the modern sign-in name. The sAMAccountName is the older NetBIOS-era name, limited to 20 characters (jdoe). Modern applications use the UPN; legacy services may still rely on the short name.

Creating users in bulk is far faster in PowerShell than in the GUI:

$SecurePass = Read-Host -AsSecureString -Prompt "Initial password"
New-ADUser -Name "Jane Doe" `
  -SamAccountName "jdoe" `
  -UserPrincipalName "jane.doe@example.com" `
  -Path "OU=Finance,OU=Users,OU=Head_Office,OU=Locations,DC=ad,DC=sercebilisim,DC=com" `
  -AccountPassword $SecurePass `
  -ChangePasswordAtLogon $true `
  -Enabled $true

Groups come in two types and three scopes. Security groups carry permissions; distribution groups are for email only. Security groups are domain local (grant access to resources in this domain), global (collect accounts by role), or universal (forest-wide).

AGDLP is the permission model that keeps this maintainable: Account → Global group → Domain Local group → Permission. Users go into a global group by role (“Finance Staff”); a domain local group represents one level of access to one resource (“Finance Share Read”); the global group joins the domain local group; the permission on the resource is granted only to the domain local group. When someone new arrives, you add them to one global group instead of touching folder permissions, and maintenance cost drops sharply.

Group Policy Basics

Group Policy is the primary way to enforce user and computer settings centrally. Password length, screen lock, drive mappings, printers, application restrictions, firewall rules: hundreds of settings are managed through Group Policy objects (GPOs).

A GPO is created in the Group Policy Management Console (GPMC) and linked to a site, the domain, or an OU. Policies apply in LSDOU order: Local, Site, Domain, then OUs from parent to child. When the same setting is defined at several levels, the last one in the chain wins, so a child OU’s GPO overrides a domain GPO. Enforced and Block Inheritance change that order and should be rare, because every exception makes the chain harder to reason about.

Common uses: the domain password and lockout policy (in the Default Domain Policy), mapped drives, printer deployment, AppLocker or software restriction policies, screen lock after inactivity, and Windows Defender Firewall rules.

When a policy doesn’t apply, ask the client before guessing:

gpresult /r
gpresult /h C:\Temp\GPResult.html
gpupdate /force

gpresult /h produces a readable report of which GPOs applied and which were filtered out, and why. If only the Default Domain Policy appears, the computer object is probably still in the Computers container. If the right GPOs appear but arrive late, look at which DC they came from and at site topology. Group Policy will get its own article in this guide; until then, this section is the map.

Replication, Sites, and Services

With one domain controller there’s nothing to replicate. From the second DC on, keeping them in step is critical. In the holding, every branch keeps its own copy of the personnel register, and all of them must reflect head office: someone who leaves at one branch must be removed from every register, or the other branches still see them as active.

Intra-site replication, between DCs in the same site, is fast (changes usually flow within seconds) and uncompressed. Inter-site replication is compressed and runs on a schedule so WAN links aren’t flooded. The topology is calculated automatically by the Knowledge Consistency Checker (KCC), and in each site the Inter-Site Topology Generator (ISTG) handles links to other sites.

The fastest diagnosis:

repadmin /replsummary
repadmin /showrepl
dcdiag /test:replications

In repadmin /replsummary, a large “largest delta” (days rather than minutes) means replication with that partner has stalled. The usual causes are DNS, firewalls blocking RPC, or a DC that was offline longer than the tombstone lifetime trying to come back. A “target principal name is incorrect” error usually means a machine account password is out of sync; Reset-ComputerMachinePassword fixes it. If replication is completely stuck and the tombstone lifetime is near, demote the problem DC and clean up its metadata rather than forcing it back.

Active Directory Security

Active Directory is an attacker’s first target, because whoever becomes Domain Admin runs the whole organization. Most large ransomware incidents move through AD. Four controls do most of the work.

The tier model. Privileges are split into three layers. Tier 0 is the identity backbone: domain controllers, federation servers, certificate authorities (the one you build with AD CS belongs here). Tier 1 is servers and applications. Tier 2 is end-user devices and the help desk. The rule: an account from a higher tier never signs in to a machine in a lower tier. When a Domain Admin signs in to an ordinary workstation and that workstation is compromised, the credentials and tickets cached there can be used against the whole domain. Daily work happens on a standard account; administration on a separate admin account, ideally from a dedicated privileged access workstation.

LAPS. Every Windows machine has a local Administrator account, and the classic mistake is giving it the same password everywhere, so one compromised machine opens all the others. Windows LAPS, built into current Windows and Windows Server, gives each machine its own random password, rotates it, and stores it protected in the directory.

Lockout diagnosis and auditing. “My account keeps locking” is one of the most common complaints, usually caused by an old password saved somewhere: a phone, a forgotten remote session, a scheduled task, a mapped drive. Enable auditing for logon and account lockout events, search for Event ID 4740 on the PDC emulator, and read its Caller Computer Name field: it names the device causing the lockouts.

Fine-grained password policies. The Default Domain Policy sets one password policy for everyone, but service accounts and administrators usually need different rules. Fine-grained password policies apply a Password Settings Object to specific security groups.

Two more habits cost nothing. Run administrative consoles with an admin account instead of elevating a daily one; the “you need to elevate” error is a reminder that the account model is being bypassed. And remember krbtgt: after any suspected domain compromise it has to be reset twice, with replication in between, as explained in What Is Kerberos?

Kerberos and Time

Every sign-in above rests on Kerberos: the user proves their identity once, receives a time-limited ticket, and shows tickets instead of a password for the rest of the day. Two things make it the source of so many confusing faults. It depends on time (a default tolerance of five minutes), and when it fails, Windows often falls back to NTLM silently instead of showing an error, so a misconfigured service name can go unnoticed for months.

Both are measured at packet level in What Is Kerberos?: the six messages of a real sign-in, a clock set 400 seconds wrong that still authenticated, why w32tm /resync can report success and change nothing, and a diagnosis order from symptom to error code. The short version for the architecture: your PDC emulator’s time source is part of your identity infrastructure. Check it with w32tm /query /source; if it says Local CMOS Clock, the whole domain is following a guess.

Backup and Disaster Recovery

Active Directory is the single most critical component of the operation: lose it and nobody reaches anything. Three layers protect it.

System State backups include the directory database, SYSVOL, and the registry. Take them daily, keep at least one copy off the server and, weekly, one off-site. How many copies to keep, whether one should be immutable against ransomware, and how to prove a restore works are covered in the backup and recovery guide, starting with the 3-2-1 rule and restore testing.

Two kinds of restore. A non-authoritative restore brings a DC back from backup and then lets replication overwrite it with the other DCs’ current data, so a deleted object doesn’t come back. An authoritative restore marks the restored objects as newer (with ntdsutil), so replication pushes them to the other DCs; that’s the one for undoing an accidental deletion.

The AD Recycle Bin makes most of that unnecessary. It restores deleted objects with all their attributes during the deleted-object lifetime, without a restore from backup. Enabling it is a one-way, forest-wide change, and it should be the first thing done in any new forest:

Enable-ADOptionalFeature -Identity "Recycle Bin Feature" `
  -Scope ForestOrConfigurationSet `
  -Target "ad.sercebilisim.com"

Before risky changes (schema extensions, role moves, bulk deletions), take a manual backup regardless of the schedule.

Hybrid Identity: Entra ID

Microsoft 365, Teams, and SharePoint Online authenticate against Entra ID (formerly Azure AD), Microsoft’s cloud identity service. It isn’t the same as Active Directory, and most organizations connect the two so that people use one identity for internal resources and the cloud.

Decide the UPN suffix first. If the AD domain is ad.example.com, users’ default UPN is jane.doe@ad.example.com, which doesn’t match their email address. Add the public domain as an alternative UPN suffix in Active Directory Domains and Trusts, set users’ UPNs to jane.doe@example.com, and they sign in with the same address everywhere. Skip this, and synchronization falls back to an onmicrosoft.com address: licenses land on the wrong identity, mailboxes don’t appear, and sign-in experiences split in two. Make the decision before building the domain if you can.

Choose the sync tool and sign-in method. Entra ID Connect is the established synchronization tool; Cloud Sync is a lighter, cloud-managed alternative. For authentication, password hash synchronization is the simplest and most common; pass-through authentication keeps verification on your own DCs; federation (AD FS) is rarely chosen for new deployments.

Migrating Active Directory

Every AD eventually needs moving: to a newer Windows Server version, into another forest after a merger, or apart after a split. Like moving a company into a new building, it goes best in stages: prepare the new building, move things gradually, and empty the old one last.

Version upgrades are done side by side, not in place:

1. Install new servers and add them to the existing domain as additional DCs (current versions prepare the schema automatically during promotion; older ones need adprep).
2. Transfer the FSMO roles to the new DCs.
3. Demote and remove the old DCs.
4. Raise the domain and forest functional levels.

That keeps downtime at zero and leaves a way back at every step. Cross-forest migrations, after a merger for example, move users, groups, computers, and SID history from one forest to another with migration tooling, and usually run as a project of their own.

Conclusion: More Than a Directory

Active Directory is less a technology choice than an organization’s discipline for identity, permissions, and policy. A well-designed AD runs quietly for years, the invisible first step of every working day. A badly designed one produces a fire every week, keeps the security team awake, and takes the whole organization down in the first serious attack.

Nobody gets every section of this map to full maturity at once. What matters is knowing which one you’re weak in. A short checklist to start from:

• DNS: every domain member uses internal DCs for DNS; forwarders are set; no internal zone exists for a public name you don’t host.
• Time: the PDC emulator follows an outside source, and w32tm /query /source says so.
• Placement: new computers land in an OU with a baseline policy, not the Computers container.
• Roles: you know which DC holds each FSMO role, and it’s written down.
• Replication: repadmin /replsummary shows no stalled partners.
• Privilege: nobody signs in to workstations with a Domain Admin account, and LAPS is on.
• Recovery: daily System State backups exist, one copy is off-site, the Recycle Bin is enabled, and a restore has actually been tested.

The articles in this guide go deeper where the field fails most: Active Directory DNS for the foundation, How to Join a Computer to an Active Directory Domain for getting machines in correctly, What Is Kerberos? for what happens at every sign-in, What Is LDAP? for how applications read the directory and why port 389 can carry a password in plain text, and Install Active Directory Certificate Services for the internal CA that signs your servers’ certificates.