Active Directory Architecture: Forests, Trusts and Delegation

Welcome to the last course of the Cybersecurity track. You can already run a full penetration test in a lab; now you will go deeper into the environment that most companies still use to manage their users and computers: Active Directory. Before we talk about attacks, we need a solid map of how it is built, because every weakness in this chapter is a weakness of design, not a magic trick.

Where this course fits

In the previous course you learned the full life cycle of a test: authorization, reconnaissance, exploitation, post-exploitation and reporting. Here you move from "I can follow a method" to "I can think like a junior professional". Over seven chapters you will study enterprise identity, scripting, red and blue teams, detection, cloud, bug bounty and careers. And you will build something along the way: a portfolio and a 90-day plan. Each lesson ends with a small portfolio step.

Active Directory in plain words

Think of a large office building. At the entrance, a reception desk keeps the list of everyone who works there, which floors they may enter, and which rooms they may book. Active Directory (AD) is that reception desk for a company network. It stores identities and decides, centrally, who can sign in to what.

The main building blocks are these:

• Domain: a boundary of administration that holds users, groups and computers. In our lab we will imagine a domain called lab.local.
• Domain controller (DC): a server that holds a copy of the directory and answers authentication requests. Compromising one is usually the worst case for a company.
• Organizational unit (OU): a folder used to organize objects and to apply policies to them.
• Group Policy Object (GPO): a set of settings applied to computers or users, such as password rules or software restrictions.
• Users, groups, computers: the objects people interact with. Even computers and service programs have accounts.

Domains, trees and forests

Large organizations rarely have a single domain. Several domains can be linked in a tree that shares a naming space, and several trees form a forest. The key security idea is this: the forest, not the domain, is the real security boundary. A strong administrator in one domain can, in some circumstances, influence others in the same forest. That is why an attacker, or an auditor, who obtains very high rights in a child domain always asks whether they can reach the whole forest.

Inside a forest, special groups such as the forest-wide administrators exist for a reason, and the number of people in them should be tiny. Counting how many accounts are in the most powerful groups is one of the first things a defender checks.

Trusts: borrowing someone else's reception desk

A trust is a relationship that lets users of one domain be recognized by another. An analogy: two companies share a building, and each guard agrees to accept the other company's badges at the door. Trusts can be:

• One-way or two-way: does only company A accept B's badges, or both?
• Transitive or not: if A trusts B and B trusts C, does A trust C automatically?
• Within a forest or between forests: external trusts are common after company mergers and are often forgotten.

Trusts are convenient and sometimes unavoidable, but every trust is a path. A weakly protected partner domain can become a way into a well protected one. When you audit, you list the trusts and ask whether each one is still needed and how much it is filtered.

Authentication in two sentences

Modern AD networks mainly use Kerberos, a ticket-based protocol, and keep NTLM, an older challenge-response protocol, for compatibility. You will meet Kerberos in lesson 1.3. For now, remember that both protocols prove identity without sending the password in clear, but both have design limits that attackers study closely.

Delegation: letting a service act on your behalf

Imagine you hire an assistant to book trains for you. To do that, the assistant must present your identity to the ticket office. Delegation is the same idea in Active Directory: a service, such as a web application, is allowed to act as a user when it talks to another service, such as a database or file server.

There are three flavors you should know by name:

• Unrestricted delegation: the service receives enough material from the user to impersonate them almost anywhere. Convenient for developers, dangerous for security, because compromising that server lets someone reuse the identities of everyone who connects to it.
• Constrained delegation: the service may impersonate users only toward a short, named list of other services.
• Resource-based constrained delegation: the target resource decides which services may act on behalf of users toward it. It is more flexible, but the permission to configure it is itself sensitive.

The lesson for an apprentice is not how to abuse these settings. It is how to read them: "Which accounts and computers are trusted for delegation, and does that make sense for what they do?" A file server with unrestricted delegation and no clear reason is a finding to report.

Why old designs create new risks

Most real AD environments have years of history. Accounts created for a project and never removed, service accounts with administrator rights "just in case", forgotten trusts after an acquisition, old protocols left on for a single old application. No single item looks catastrophic, but the combination creates chains of small weaknesses. Remember this, because the next lesson is about finding such chains, and the one after is about fixing them.

Your lab for this chapter

Build the lab in an isolated network only. You need a Windows Server evaluation edition configured as a domain controller, one or two Windows client machines joined to the domain, and your Kali Linux machine on the same host-only network. Use snapshots before every change. Never connect this lab to your home or work network, and never reuse real passwords in it.

Your turn: draw the map

Without touching any tool, draw the architecture of this fictional company on paper:

• A forest named corp.local with two domains: corp.local and eu.corp.local.
• A partner domain partner.local in a separate forest with a one-way trust: corp.local trusts partner.local.
• A web application server that uses unrestricted delegation.

For each element, write one sentence explaining what risk it introduces.

See a solution

• The forest: it is the security boundary, so very high rights in eu.corp.local may be a route to corp.local. Risk: privilege spreading across domains of one forest.
• The one-way trust: users of partner.local can be given access in corp.local. If the partner is compromised, the attacker may use that trust as a bridge. Risk: a weaker organization becomes part of your attack surface. Check the trust is still needed and filtered.
• The unrestricted delegation server: anyone who controls it can reuse the identities of users that connect to it. Risk: a single server compromise can become a domain compromise. Replace it with constrained delegation or remove delegation.

Portfolio step

Create a folder named 01-active-directory in your portfolio and save your diagram (a photo of your drawing is fine) with a short README that explains the three risks in your own words. This is your first portfolio artifact, and it shows that you understand architecture and not only tools.

Next, in lesson 1.2, you will see how professionals collect and visualize this information to find real attack paths.