AD Architecture, Objects & Administration

Before you attack anything, you need a map in your head. Active Directory, called AD in short, is Microsoft's system that keeps one shared list of every user, every computer and every permission in a company. Because of this list, a laptop in Building A trusts the same login as a server in Building B.

What problem does AD actually solve?

Think of a company with 3,000 employees and 5,000 computers.

Without AD, every computer keeps its own list of who can log in there. A new employee joins, and someone has to add that person to every machine they will use. An employee leaves, and someone has to remove the account from every machine. One password change means the same work again. On 5,000 computers, this is impossible to manage.

AD solves this by keeping one list in one place.

One server, called the Domain Controller (DC), holds this master list of all identities. A DC is simply a Windows Server with the AD role installed on it. Every other computer in the company trusts what the DC says about you: who you are, and what you are allowed to open.

That trust is the whole game. Every attack in this course is some way of making the DC, or a computer that trusts it, believe something wrong about you.

The container hierarchy: Forest, Domain, OU, Object

AD keeps things in a tree, like folders inside folders. There are four levels you must know.

• Forest: the outer wall. It holds one or more domains. All domains inside one forest trust each other by default. This is why we call the forest the real security boundary.
• : a management unit inside the forest, for example . Each domain has its own password rules, its own admins and its own database of accounts.

Rendering diagram…

Permissions and GPOs flow downward in this tree, like water. Whatever you set at the top reaches everything below it.

So if you get write permission on one OU, you can often control every object inside that OU. Keep this sentence in mind. Half the privilege escalation tricks in this course come from it.

OUs and default containers are not the same thing

Every new domain comes with two built-in folders: CN=Users and CN=Computers. They look like OUs in the admin tool, but they are not OUs. They are called containers.

Why does this small difference matter?

Group Policy can only be linked to an OU. It cannot be linked to a container. So a computer or a user sitting inside CN=Computers or CN=Users never receives any GPO settings. No password rules from GPO, no security hardening, nothing. Admins can change this default with the commands redircmp and redirusr, but many companies never do.

When you enumerate a real company later, look for objects still sitting in CN=Computers. Those machines are usually forgotten machines that nobody manages. Unmanaged usually also means unpatched, and unpatched machines are easy targets.

SIDs: what they look like, and why the last part matters

A SID looks like this:

textCopy
S-1-5-21-3623811015-3361044348-30300820-1013

Read it in two parts.

The first part, S-1-5-21- followed by three long numbers, belongs to the domain. It is different for every domain in the world. This is how Windows knows that the account alice in your company is not the same person as the account alice in some other company.

The last number, here 1013, is called the RID (Relative Identifier). AD gives it to each object one by one, like a roll number in a class. Some RIDs are fixed and the same in every domain on earth:

These numbers never change, even if the admin renames the account.

This is why renaming the Administrator account to something like mgr_svc01 gives you very little protection. Windows checks the SID, not the name on screen. An attacker asks the domain for the account with RID 500 and gets the answer, whatever name it wears today.

Groups have two properties, and people mix them up

Every AD group has a type and a scope. They sound similar, so learn them separately.

Type answers: can this group be used to give permissions?

• A Security group can be given permissions on files, folders and other objects.
• A Distribution group is only an email list. It gives no permissions at all.

Both look almost the same when you list them, so always check the type before you get excited about a group.

Scope answers: how far do this group's powers reach?

• Domain Local: can be given rights inside its own domain only.
• Global: can hold members from its own domain, and can be given rights anywhere in the forest.
• Universal: can hold members from any domain in the forest, and can be given rights anywhere in the forest. The cost is that its membership is copied to the Global Catalog, explained next.

Why this matters when you attack: when a tool like BloodHound shows that your user is a member of some group, the scope tells you how far that membership can take you. A Domain Local group stops at the edge of that domain. A Universal group does not.

The Global Catalog, in short

A Global Catalog (GC) is a special job that most DCs do by default.

A normal DC knows everything about its own domain. A GC server also keeps a partial copy of every object in every domain in the forest. Partial means it stores some attributes of each object, not all of them.

The GC exists so that a search across the whole company stays fast. For example, "find any user named Sharma anywhere in the company" can be answered by one GC instead of asking every domain one by one.

The GC also matters for logins. Universal group membership has to be checked across the whole forest, so a GC must be reachable when a user logs in. If you ever see strange login failures during a multi-domain job, an unreachable GC is one thing worth checking.

Authentication and authorization are two different checks

These two words look similar, and beginners mix them up constantly. Keep them apart from day one.

• Authentication answers "who are you?" You prove you are alice, using a password, a certificate, or a Kerberos ticket.
• Authorization answers "what are you allowed to do?" This is checked separately, every single time you touch something, against the Access Control List (ACL) on that object. An ACL is simply the list of permissions attached to a file, folder or AD object.

Think of an office. The security guard at the gate checks your ID card, that is authentication. The lock on the finance room door decides if your card can open it, that is authorization. Getting inside the building does not mean you can enter every room.

This matters when you attack. If you steal a Kerberos ticket, you have only stolen proof of identity. Where that ticket takes you still depends on the permissions the account behind it holds.

Tier Zero: the accounts that decide everything

Not all admin accounts are equally dangerous. Microsoft uses the name Tier Zero for anything that can control the whole domain, directly or indirectly:

• Domain Controllers
• The Domain Admins group
• The Enterprise Admins group
• Accounts that manage AD Certificate Services
• Backup systems that can restore a Domain Controller

If you control any Tier Zero asset, you control the forest. Notice that backup software is on this list. Its name says nothing about admin rights, but a system that can restore a DC can also read everything on that DC.

On almost every real job, your work reduces to one question: starting from one ordinary user account, is there a path to Tier Zero? Every lesson after this one is another way to answer yes.

Toolbox

Get-ADUser / Get-ADGroup / Get-ADComputer: PowerShell, RSAT "ActiveDirectory" module

These are Microsoft's own commands for asking AD questions. They are signed by Microsoft, they write nothing to disk, and their traffic looks like normal admin work. They are available on any domain-joined Windows machine that has RSAT installed. RSAT means Remote Server Administration Tools, a free Microsoft add-on.

powershellCopy
Get-ADUser -Filter * -Properties Description,MemberOf | Where-Object {$_.Description -ne $null}

dsquery / dsget: built into Windows

The older command-line tools from before PowerShell. They are still present on every domain-joined Windows Server. Learn them, because sometimes you land on a machine where the AD PowerShell module is not installed.

textCopy
dsquery user -name svc-* | dsget user -memberof -expand

ldapsearch: Linux, openldap-clients / ldap-utils

This is your tool when you attack from a Linux machine that is not joined to the domain. It speaks LDAP directly, so it needs no Microsoft software at all.

bashCopy
ldapsearch -x -H ldap://10.10.10.5 -D "[email protected]" -w 'Passw0rd!' -b "DC=corp,DC=local" "(objectClass=user)"

Lab exercise: build the map before you touch anything

1. Set up a small lab. A free option is GOAD (Game Of Active Directory), or a single-forest lab inside HTB CAPE.
2. Create two OUs and a few users. Then create one Domain Local group, one Global group and one Universal group. Put a user in each and see how they behave in the admin tool.
3. On the DC, run dsa.msc to open Active Directory Users and Computers. Walk through the tree. Notice how OUs sit inside each other, and how and sit outside the OU structure.

Key points to remember

• One Domain Controller holds the master list, and every other machine trusts it. That trust is the target.
• The order is Forest, then Domain, then OU, then Object. Permissions flow downward.
• CN=Users and CN=Computers are containers, not OUs, so GPO settings never reach objects inside them.
• The SID is the real name of an account. RID 500 is Administrator, 512 is Domain Admins, 519 is Enterprise Admins, in every domain.

Check yourself

• What is the practical difference between a Forest and a Domain, and why is the forest the real security boundary?
• Why is renaming the built-in Administrator account a weak defence?
• Why is a computer left in CN=Computers more interesting to an attacker than one placed in an OU?
• Why does authorization need a separate check even after authentication succeeds?
• What makes an asset Tier Zero even when its name says nothing about being an admin?