Active Directory Basics: A Beginner’s Guide to Windows Domains, Kerberos, Trees and Forests

Why We Need Windows Domains

Managing five or six computers by hand is easy. Managing hundreds, spread across several offices, is not. Creating users, applying settings and controlling access on each machine one by one quickly becomes impossible. Windows solves this with a Windows domain, a group of users and computers managed by a business from one central place.

That central place is Active Directory (AD), a database that stores everything on the network: computers, servers, printers, shared folders, user accounts, security groups and the policies that control them. The server that hosts and runs it is called a Domain Controller (DC).

A domain gives an organisation two main benefits:

Centralised identity management: every user can be configured from one spot.
Centralised security policies: settings can be applied to users and computers across the whole network.

What Active Directory Stores

The heart of AD is the Active Directory Domain Service (AD DS), which acts like a catalogue of every "object" on the network, such as users, groups, machines, printers and shares.

Users are the most common object. A user can represent a person, or a service such as IIS or MSSQL. Service users are limited to the privileges their service needs. Users are called security principals, meaning the domain can authenticate them and give them permissions over resources like files and printers.

Security groups make permissions easier to manage. Instead of giving access to each person, you give it to a group, and anyone added to the group inherits its privileges. Groups are also security principals, and a group can contain other groups. Some important default groups are:

Security Groups vs OUs

Both groups and Organisational Units (OUs) organise users and computers, but for different reasons.

OUs are used to apply policies. A user can belong to only one OU, since it would make no sense to apply two conflicting sets of policies to one person.
Security groups are used to grant permissions over resources. A user can belong to many groups so they can reach many different resources.

How Authentication Works

All credentials are stored on the Domain Controllers. When a user logs into a service, the service asks the DC to confirm that the credentials are valid. Two protocols handle this.

Kerberos

Kerberos is the modern default and works with tickets, which act as proof that someone has already logged in.

The user sends their username and a timestamp, encrypted with a key derived from their password, to the Key Distribution Center (KDC), which usually runs on the DC. The KDC replies with a Ticket Granting Ticket (TGT) and a session key. The TGT is encrypted with the password hash of the krbtgt account, so the user cannot read it. Its purpose is to let the user request more tickets without typing their password every time.
To reach a specific service, such as a file share, website or database, the user presents the TGT to the KDC along with the Service Principal Name (SPN) of the service. The KDC returns a Ticket Granting Service (TGS) ticket that works only for that one service, together with a service session key. The TGS is encrypted with a key derived from the service owner's hash.
The user sends the TGS to the service. The service decrypts it with its own account's password hash, validates it and allows the connection.

Steps 1 and 2 in a diagram: the client requests a TGT from the KDC and receives it with a session key.

Then the client uses the TGT to request a TGS for a specific service, identified by its SPN.

Finally, the client sends the TGS to the service to authenticate.

NetNTLM

NetNTLM is an older protocol kept for compatibility. It uses challenge and response:

The client asks the server for access.
The server sends back a random number as a challenge.
The client combines the challenge with its password hash to produce a response and sends it to the server.
The server forwards the challenge and response to the Domain Controller, which recalculates the response and compares it.
If they match, the client is authenticated, and the result is passed back through the server to the client.

The password or its hash is never sent over the network. With a local account, the server can do the check itself using the hash stored in its SAM, without involving the DC.

Trees

As a company grows, putting everything into one huge domain becomes hard to manage and invites misconfigurations and security problems. Active Directory allows several domains to be joined together so each part can be managed independently.

Domains that share the same namespace form a tree. For example, xyz.com can be the parent domain with bank.xyz.com as a child for a banking division, and further children such as us.bank.xyz.com and uk.bank.xyz.com for regional offices. Each domain has its own DC, users and computers, and its own IT team that manages only its own resources. A banking user, for instance, cannot change permissions in the parent domain.

Two admin groups matter here:

A Domain Admin has administrative power over a single domain only.
An Enterprise Admin has administrative privileges across every domain in the enterprise.

Forests

If the company grows further and needs to work with a vendor, such as tryvendorme.com, that vendor will have its own tree with a different namespace. A forest is a collection of trees with different namespaces that are joined together so they can share resources. Each company keeps its own separate domains and administration, while the forest allows access across both.

Trust Relationships

Splitting an organisation into trees and forests keeps things tidy, but sometimes a user from one domain needs to reach resources in another, for example a vendor employee supporting a bank employee. Trust relationships make this possible by letting one domain authorise users from another.

One-way trust: if Domain AAA trusts Domain BBB, a user from BBB can be authorised to use resources in AAA. The direction of the trust is the opposite of the direction of access.
Two-way trust: both domains can authorise each other's users. This is what gets created by default when domains are joined in a tree or forest.

A trust does not automatically give access to everything. It only makes cross-domain authorisation possible, and administrators still decide exactly which resources outside users may user

Wrapping Up

Here is everything in a few lines:

A Windows domain centralises the management of users, computers and policies in Active Directory, which runs on Domain Controllers.
Users and groups are security principals. OUs apply policies, while groups grant permissions.
Kerberos (tickets) and NetNTLM (challenge and response) verify who users are.
Large organisations split into domains, arranged in trees and forests, with Domain Admins and Enterprise Admins at different levels of authority.
Trust relationships allow controlled sharing between domains.

If you are starting out in IT administration or cybersecurity, these concepts are the foundation for almost everything else in Windows enterprise networks. Once they feel natural, topics like Group Policy, delegation and AD security become much easier to learn.

Coming next: this was just the foundation. In upcoming articles I will cover other Active Directory topics such as Group Policy, DNS and LDAP, sites and replication, FSMO roles, delegation and permissions, and common AD security misconfigurations. Follow along so you don't miss them.

Contents