Active Directory Core Components: Users, Groups, Service Accounts

You already use most of these without naming them. You log in with a user account, you are in a few groups that decide what you can open, you sit at a domain-joined computer, and somewhere a service account you have never seen runs the application you rely on. The last sub gave you the structure; this one fills it with the objects that live inside a domain, because those objects are what the attacks in this course actually land on.

A domain is a directory full of objects, and a manageable number of object types account for almost everything you will defend. Take them in turn, and attach the security meaning to each as you go, because every one of them is both a normal part of the directory and a thing an attacker wants.

Accounts: users, computers, and services

User accounts are the obvious ones, the credentials people log in with. What makes a user account dangerous to you is not that it exists but what it carries: how much privilege it holds, whether its password is weak, whether it is a forgotten account still enabled long after its owner left. A high-privilege user with a weak password is a gift to an attacker, and most domains have more of those than anyone realizes.

It is worth separating two kinds of user account. Most users are ordinary, with access to their own work and little more.

A small number are privileged, members of administrative groups that can change the domain. The whole game of escalation is getting from the first kind to the second, so a privileged user with a weak password, an admin account used for daily web browsing, or a service-desk account with more rights than its job needs are the accounts that turn a foothold into a crisis.

Computer accounts are the ones people forget. Every machine joined to the domain has its own account, with its own password that it manages and rotates automatically, and it authenticates as itself to other systems. That matters because a computer account is a credential like any other, and several modern attacks turn on them: the right to add computer accounts, or to manipulate one, becomes an escalation path. When an alert says a computer authenticated somewhere, it is describing a real actor, not a glitch.

One default makes this sharper. Out of the box, an ordinary domain user can join a number of new computers to the domain, creating computer accounts they then control. That sounds harmless, but a controlled computer account is a credential an attacker can wield, and it is the starting ingredient for several escalation techniques that abuse delegation. So computer accounts are not background scenery; they are accounts an attacker can create, take over, and use, and they deserve the same scrutiny as the people.

Service accounts are the third kind, and often the most dangerous. These are accounts that run applications and services rather than belonging to a person. They tend to accumulate more privilege than they strictly need, their passwords are set once and rarely changed, and many carry a service principal name that makes them directly reachable for Kerberoasting. A service account is frequently the weakest strong account in the domain: powerful, stale, and unwatched.

Microsoft's answer to the unrotated-password problem is the managed service account, and its newer form, the group managed service account, where the directory itself generates and rotates a long, strong password no human ever sets. These are a real improvement and you should prefer them.

But many environments still run plenty of old-style service accounts with human-set passwords, and even the managed kinds have introduced their own concerns on the newest Windows Server, where the delegated managed service account brought the successor-link path you will study later.

Groups and the permission graph

Groups are how rights are granted at scale. Rather than assigning a permission to each account, you put accounts in a group and grant the group. That convenience is also why groups are the backbone of the permission graph you met in the attack-surface sub: membership is the edge that says this account can do what this group can do.

Two things about groups matter for defense. First, groups nest: a group can be a member of another group, so a user added to a low-level group can inherit, through a chain of nesting, the privilege of a far more powerful one. Effective membership is not what you see on the account; it is the whole chain, which is exactly why attackers and their tools compute it and casual checks miss it.

Second, a handful of built-in groups are the keys to the kingdom. Domain Admins control a domain; Enterprise Admins control the whole forest; and several others, the operators and backup and account groups, carry enough privilege to become tier zero with one more step. Knowing which groups are effectively tier zero, and watching changes to them, is some of the highest-value defensive work there is, because every attack path is ultimately trying to land in one of them.

Active Directory even has a built-in mechanism, often known by the name of the template object behind it, that periodically re-stamps the permissions on members of the most sensitive groups to keep them locked down. That mechanism is itself a known target: an attacker who can write to the wrong place can use the same machinery to plant durable access.

The point is not the detail yet but the principle, that the privileged groups are special enough that the directory ships dedicated protection for them, and worth watching.

Group Policy and organizational units

Organizational units are containers. You sort objects into OUs to organize the directory, to link Group Policy to a set of objects, and to delegate administration of part of the directory to a particular team. They are mostly an administrative convenience, but the delegation part is security-relevant: rights handed out at an OU can be broader than anyone intends.

Group Policy is the mechanism that pushes configuration and settings to users and computers across the domain. A Group Policy object holds settings, and it is linked to OUs, domains, or sites so it applies to everything underneath.

This is enormously powerful, which is precisely the problem: whoever can edit a Group Policy object that is linked to many machines can effectively run code on all of them. GPO abuse is a well-worn escalation and lateral-movement path, and the policy files themselves live in a shared location on the controllers that is worth watching closely.

It is worth picturing the scale of that. A single Group Policy object can be linked to an OU holding thousands of machines, so an attacker who edits it does not compromise one host, they queue an action on every host the policy reaches, the next time those machines refresh policy.

That is execution at the scale of the domain, achieved by changing one object rather than touching any target. The files behind those objects sit in a shared folder on every controller, replicated automatically, which is why both the objects and that folder belong on a defender's watch list.

How the directory is queried and how it authenticates

Two kinds of protocol tie all of this together, and you need both names. The first is LDAP, the protocol for reading and writing the directory. When an application looks up a user, or an attacker enumerates every account with a service principal name, that is LDAP. It is the query language of the directory, and because the directory answers most queries for any authenticated user, LDAP is also the channel reconnaissance flows through.

Because the directory is so willing to answer, LDAP is rarely the place you block reconnaissance; it is the place you reduce what can be learned and, where you can, raise the cost of querying at scale. LDAP also has its own hardening, around signing and channel binding, that closes relay paths into the directory itself. For now, hold that the same protocol that runs the business also serves the attacker's first move.

The second is authentication, and there are two protocols here that you will meet constantly. Kerberos is the modern default: the domain controller issues signed tickets that prove who you are, and almost every Kerberos-related attack in this course, Kerberoasting, AS-REP roasting, forged golden and silver tickets, is an abuse of how those tickets are requested, encrypted, or signed.

NTLM is the older protocol, a challenge-and-response scheme that predates Kerberos and is kept alive for compatibility. It is weaker, and it is the basis of relay and pass-the-hash attacks. A defender who knows which protocol an authentication used, and what each one should and should not be doing, is already reading the telemetry with the right questions.

Two facts anchor the authentication picture. Kerberos depends on the controller acting as a trusted ticket-issuing authority, and on one account, krbtgt, whose key signs every ticket, which is why stealing that key is the master key to the domain.

NTLM survives not because anyone likes it but because, as the challenges sub described, turning it off reliably breaks something, so it lingers and its relay and replay attacks linger with it. You will meet both again in depth; the aim here is only that Kerberos, NTLM, ticket, and hash now name specific things you can picture.

Holding the components in mind

You now have the inventory. Users, computers, and service accounts are all accounts that authenticate and carry privilege. Groups grant rights and nest into the privilege graph, topped by the built-in groups that are tier zero. Group Policy pushes configuration and is a mass-execution lever if its objects are not protected. OUs organize and delegate. LDAP queries the directory and carries reconnaissance, while Kerberos and NTLM do the authenticating and anchor two whole families of attack.

That is enough structure to make the rest of the course legible. When a later module says an attacker wrote a service principal name onto an account, or abused a Group Policy object, or forced an NTLM authentication, you will know what kind of object that is and why the action matters. The components are the nouns of every detection you are about to learn.

There is one more piece of the picture, and it is the one that has changed most in the last decade. The directory no longer ends at the on-prem domain. The next sub covers the modern context: hybrid identity with Entra ID, the certificate services that have become a major attack surface, and the federation services that bridge to the cloud. That is where the boundary you have been studying now reaches.