Active Directory — Part 4 — Users, Groups & Organisational Units

Introduction

In the previous parts, we covered what Active Directory is, how domains and forests work, and the role of Domain Controllers. Now it is time to get into the day-to-day building blocks of AD: the objects you will be creating and managing constantly.

The three most important objects to understand early are user accounts, groups, and Organisational Units. Once these make sense, the rest of Active Directory administration becomes much easier to understand.

User Accounts

A user account in Active Directory represents a person, or sometimes a service, that needs access to network resources.

Every user who logs into a domain-joined machine is authenticating against a user account stored in AD. That account is not just a username and password. It contains attributes, group memberships, status information, and policy-related settings.

What Is Inside a User Account?

When you create a user in AD, you are creating an object with multiple attributes.

The SAMAccountName is the older-style login name, such as jsmith. The User Principal Name, or UPN, usually looks like an email address, such as john.doe@company.local.

How User Accounts Are Created

User accounts can be created in several ways depending on the size and maturity of the environment.

Active Directory Users and Computers, often called ADUC, is the classic GUI tool. You can right-click an OU, choose New, then choose User. This is simple and visual, but best suited for one-off account creation.

PowerShell is the preferred method in modern environments because it is fast, scriptable, repeatable, and easier to standardize.

New-ADUser -Name "Jane Smith" `
           -GivenName "Jane" `
           -Surname "Smith" `
           -SamAccountName "jsmith" `
           -UserPrincipalName "jsmith@company.local" `
           -Path "OU=Sales,DC=company,DC=local" `
           -AccountPassword (ConvertTo-SecureString "P@ssw0rd!" -AsPlainText -Force) `
           -Enabled $true

Bulk import is common when creating many users at once. HR exports a CSV file and a PowerShell script loops through each row to create accounts automatically.

Identity management systems are common in enterprise environments. Tools such as Microsoft Identity Manager or HR-driven provisioning workflows can create, update, and disable accounts automatically based on employee lifecycle events.

Service Accounts

Not all accounts belong to humans. Service accounts are user accounts created specifically to run applications, scheduled tasks, background services, backup agents, SQL Server services, monitoring tools, and similar workloads.

A good service account should have only the permissions needed for that service. It should not be treated like a normal user account.

Organisational Units

An Organisational Unit, or OU, is a container object inside a domain. Think of it like a folder structure for Active Directory objects.

Users, computers, groups, and even other OUs can live inside an OU. This structure helps administrators organize objects, delegate management, and target Group Policy.

What OUs Are For

OUs serve two main purposes: organization and delegation, and Group Policy targeting.

company.local
├── IT
│   ├── Helpdesk
│   └── SysAdmins
├── Finance
├── HR
└── Sales
    ├── UK
    └── US

This structure makes it easier to find and manage objects. For example, you can delegate password reset rights to a junior administrator only within the HR OU without granting domain-wide administrative privileges.

OUs are also where Group Policy becomes practical. You can link GPOs to specific OUs so different departments, locations, or device types receive different settings.

OUs vs Containers

Active Directory also includes default containers such as Users and Computers. These look similar to OUs, but they behave differently.

The important difference is that you cannot link Group Policy Objects directly to default containers. GPOs can be linked to sites, domains, and OUs, but not to the built-in Users and Computers containers.

This is why best practice is to move objects out of default containers and into a properly designed OU structure.

Groups

Groups are how you manage access at scale. Instead of assigning permissions to individual users, you assign permissions to groups and then place users inside those groups.

This makes access easier to manage, easier to audit, and easier to remove when someone changes role or leaves the organization.

Security Groups vs Distribution Groups

This distinction trips up many people early on.

If someone asks for a group so the finance team can access a shared drive, that should be a security group. If someone asks for a group so managers can email the whole department, that may be a distribution group or a mail-enabled security group.

Group Scope

Beyond type, groups also have a scope. Scope determines where group members can come from and where the group can be used.

In a single-domain environment, the distinction may not feel important at first. In multi-domain forests, group scope becomes very important for managing access efficiently.

AGDLP

A common best-practice model for permissions is AGDLP.

A = Accounts
G = Global Groups
DL = Domain Local Groups
P = Permissions

Accounts go into Global Groups.
Global Groups go into Domain Local Groups.
Domain Local Groups are assigned permissions.

This keeps user membership separate from resource permissions and makes access easier to audit and manage.

Why You Never Assign Permissions to Individual Users

Assigning permissions directly to user accounts is one of the easiest ways to create long-term access problems.

Imagine a file share for the Finance department. If you add twelve individual users directly to the share permissions, every joiner, mover, and leaver becomes a manual cleanup task.

When someone leaves, you must remember every resource they were added to. If you miss one, access remains. When someone joins, you must manually hunt down every resource the team uses. When someone changes role, every old permission must be found and removed.

The Principle of Least Privilege

Group-based access supports the principle of least privilege. Every user should have only the access they need to do their job, and nothing more.

With groups, you can create clear access levels such as Finance_ReadOnly, Finance_ReadWrite, and Finance_Admin. Users are placed into the appropriate group instead of receiving one-off permissions directly on resources.

Quick Reference Summary

Final Thoughts

Users, groups, and OUs are the objects you will work with most often in Active Directory. They are simple on the surface, but the design decisions around them affect security, manageability, delegation, and auditing for years.

If you understand how identities, containers, and group-based access fit together, you are already thinking like an AD administrator.