Learn Active Directory - Active Directory Users and Computers
Episode 7 of 31

Learn Active Directory - Active Directory Users and Computers

Managing directory objects through the Active Directory Users and Computers console: creating users, understanding account properties, logon hours, and user account control flags, distinguishing security and distribution groups, and designing a clean Organizational Unit structure.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Introduction

After episode 6 ensured your domain has more than one DC, it's time to populate the directory with real objects: users, groups, and Organizational Units (OUs). This is the episode where AD starts to feel real — because an admin's entire daily work revolves around these objects.

Episode 7 focuses on the Active Directory Users and Computers (ADUC) console: how to open and navigate it, create users and their properties, understand User Account Control flags and logon hours, distinguish security groups from distribution groups, and design an OU structure. We'll also start getting acquainted with its PowerShell counterparts — New-ADUser, New-ADGroup, and Add-ADGroupMember — as a bridge to episode 8.

Getting to Know the ADUC Console

Active Directory Users and Computers is an MMC snap-in that represents AD administration's most classic face. After RSAT is installed, you can find it by typing:

Open ADUC
dsa.msc

In the left pane you'll see the ad.example.com domain with built-in folders like Users, Computers, Domain Controllers, and Builtin. Don't stuff these built-in folders arbitrarily — best practice is to place your own objects inside OUs you design. The reason: built-in folders can't be delegated and aren't as flexible as OUs when it comes to Group Policy targeting.

The Anatomy of a User Account

A user account has several "names" that often confuse beginners:

IdentityExampleUsage
Display nameBudi SantosoDisplay name in the directory
User Principal Name (UPN)budi.santoso@ad.example.comModern login, primary identity
sAMAccountNamebudi.santosoLegacy login, Pre-Windows 2000

UPN and sAMAccountName can differ. Rule of thumb: use a consistent format, e.g. firstname.lastname, and apply it across the organization. Name consistency makes searching, scripting, and auditing easier later.

Creating a User in ADUC

Via GUI: right-click the target OU > New > User, fill in the name and login, set the password, and click Finish. But since you're a future efficient admin, let's go straight to the PowerShell version:

Create a user via PowerShell
New-ADUser `
    -Name "Budi Santoso" `
    -GivenName "Budi" `
    -Surname "Santoso" `
    -SamAccountName "budi.santoso" `
    -UserPrincipalName "budi.santoso@ad.example.com" `
    -Path "OU=Karyawan,DC=ad,DC=example,DC=com" `
    -AccountPassword (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force) `
    -Enabled $true

Note the -Enabled $true — if omitted, the account is created disabled. This isn't a bug but a security feature: accounts created by scripts don't become active until an admin deliberately sets a password.

User Account Properties

The Account tab in the user properties dialog contains the settings most frequently tweaked:

  • Logon hours — the hours an account may log in, set per day and per hour. Useful for shift-based work patterns.
  • Logon to computers — restricts which machines can be used to log in.
  • Account expires — the account's expiration date, ideal for contractors.

The Profile tab lets you configure a profile path (for roaming profiles), a home folder, and a logon script run every time the user logs in. The Member Of tab shows group membership — and this is where the real access keys live, because almost all permissions in Windows are granted via groups, not via users.

User Account Control Flags

Every user account has a set of internal flags controlling its behavior. A few you must memorize:

FlagEffect
Must change password at next logonForces the user to change their password on first login
User cannot change passwordPrevents the user from changing their own password
Password never expiresExempts the account from the expiration policy
Account is disabledThe account can't be used to log in
Account expiresThe account's active period is limited

Two flags cause the most problems: password never expires is often slapped carelessly onto service accounts, making password policy meaningless; while account disabled is the correct way to "freeze" the account of a departing employee rather than deleting it outright. In PowerShell, an account's active status is managed with Enable-ADAccount and Disable-ADAccount.

Groups: Security vs Distribution

Groups are the correct mechanism for granting permissions in Windows. There are two types:

TypeFunctionExample
SecurityGrants access permissions (and can be used for email)Domain Admins, IT-Pengguna
DistributionJust an address list, can't be granted permissionsHR mailing list

Most groups you create are security groups. Creating one via PowerShell:

Create a group and populate its members
New-ADGroup -Name "IT-Pengguna" -GroupScope Global -GroupCategory Security -Path "OU=Group,DC=ad,DC=example,DC=com"
Add-ADGroupMember -Identity "IT-Pengguna" -Members "budi.santoso", "siti.rahayu"

Besides type, groups have a scope determining their reach:

ScopeReachContents
Domain LocalResources in the same domainCan be from any domain
GlobalGroups in the same domainMembers from the same domain
UniversalThe entire forestMembers from any domain, stored in the GC

The naming pattern Microsoft recommends is AGDLP: accounts (users) are placed in Global groups, Global groups are placed in Domain Local groups, and Domain Local groups are granted permission over resources. This keeps the structure tidy as the company grows. Built-in groups like Domain Admins and Enterprise Admins must be kept as lean as possible — a topic deepened in episode 12.

Organizational Units

An OU is a container that can hold users, groups, computers, even other OUs. An OU's strength lies in two things: as a Group Policy target and as a delegation boundary. A simple creation example:

Create an OU with protection
New-ADOrganizationalUnit -Name "Karyawan" -Path "DC=ad,DC=example,DC=com" -ProtectedFromAccidentalDeletion $true
  • Meaningful hierarchy — design OUs based on working structure (e.g. by department), not by person names.
  • Delegation — helpdesk admins can be given password-reset rights on just one OU via the Delegation of Control Wizard.
  • Deletion protection — enable Protect object from accidental deletion on important OUs; without it, one wrong click can destroy dozens of objects.

Move objects between OUs with drag-and-drop or the Move-ADObject cmdlet. Remember: moving an object changes the Group Policy applied to it — always check the effect before moving objects in active use.

Conclusion

Episode 7 gives you the main foothold for object administration: opening ADUC via dsa.msc, understanding a user's dual identity (UPN and sAMAccountName), managing account properties including logon hours and User Account Control flags, distinguishing security and distribution groups along with their scopes, and designing secure, delegatable OUs.

Key takeaways:

  • Create objects inside well-designed OUs, not in built-in folders.
  • Permissions are granted via groups, not users — master the AGDLP pattern.
  • A disabled account is safer than a deleted account.
  • -Enabled $true is a must-watch with New-ADUser.

Everything you did manually in this episode can actually be automated. In episode 8 we'll cover it thoroughly: PowerShell for Active Directory — the ActiveDirectory module, Get-ADUser, Set-ADUser, through creating hundreds of users from a single CSV file. See you in episode 8!