Users, Groups, and Computer Objects
Active Directory models a network through three core object types: user objects representing people who log in, group objects that collect users (or other groups, or computers) for the purpose of assigning permissions in bulk, and computer objects representing each domain-joined machine, which — like users — have their own account, password, and SID used for authentication. Understanding how these three interact, particularly how group membership is evaluated during logon, is fundamental to designing a secure and manageable AD environment.
Cricket analogy: Similar to how a cricket board tracks three kinds of entities: individual players (users), squads that bundle players together for a tournament (groups), and the actual equipment/kits assigned per team (computers) — each tracked separately but working together on match day.
User Accounts: Attributes and Authentication
Every user object carries a set of core attributes: the sAMAccountName (the legacy pre-Windows-2000 logon name, limited to 20 characters), the userPrincipalName or UPN (a modern logon name in email format like [email protected]), and a unique SID that actually underlies all permission checks — the SID, not the username, is what gets embedded into access tokens and ACLs. Best practice strongly favors disabling a departed employee's account (Disable-ADAccount) rather than immediately deleting it, because deletion destroys the SID permanently; if that same person needs an account restored, or if you need to audit what that SID previously had access to, a deleted account's history is effectively unrecoverable without a system state backup.
Cricket analogy: Similar to how a player's official BCCI registration number is what actually matters for tournament eligibility, not their nickname — and a board would suspend a player's registration for a disciplinary issue rather than permanently erase their entire career record.
Group Types and Scopes
AD groups come in two types — security groups, which can be assigned permissions on resources and are also mail-enabled if needed, and distribution groups, which can only be used for email distribution lists and cannot be granted any permissions at all. Independently, groups have a scope: domain local (used to assign permissions on resources within that same domain, can contain members from any trusted domain), global (used to organize users who share job function, can only contain members from its own domain, but can be granted permissions anywhere in the forest), and universal (can contain members from anywhere in the forest and is visible forest-wide via the Global Catalog). Microsoft's classic AGDLP model (Account → Global group → Domain Local group → Permission) recommends putting user accounts into global groups, nesting those global groups inside domain local groups, and assigning the actual resource permission only to the domain local group.
Cricket analogy: Similar to how a state cricket association has both a playing squad (which can actually be selected for matches, like a security group) and a fan mailing list (which can only receive newsletters, like a distribution group) — very different purposes despite both being 'groups' of people.
# Create a new user account
New-ADUser -Name "Jane Doe" -SamAccountName "jdoe" -UserPrincipalName "[email protected]" `
-Path "OU=Sales,DC=contoso,DC=com" -AccountPassword (ConvertTo-SecureString "TempP@ss123!" -AsPlainText -Force) -Enabled $true
# Create a global security group and add a member (AGDLP pattern step 1)
New-ADGroup -Name "GG_Sales_Users" -GroupScope Global -GroupCategory Security -Path "OU=Sales,DC=contoso,DC=com"
Add-ADGroupMember -Identity "GG_Sales_Users" -Members "jdoe"
# Create a domain local group and grant it the resource permission (AGDLP step 2-3)
New-ADGroup -Name "DL_SalesShare_Modify" -GroupScope DomainLocal -GroupCategory Security -Path "OU=Sales,DC=contoso,DC=com"
Add-ADGroupMember -Identity "DL_SalesShare_Modify" -Members "GG_Sales_Users"Universal groups are cached and replicated to every Global Catalog server in the forest, so changing universal group membership frequently generates forest-wide GC replication traffic. This is why AGDLP nests global groups inside domain local groups rather than using universal groups by default — universal groups are best reserved for cross-domain scenarios where their forest-wide visibility is actually needed.
Computer Objects and the Machine Account
A computer object represents a domain-joined machine and, functionally, behaves like a user account: it has its own SID, its own password (a 120-character random value by default), and it authenticates to the domain the same way a user does when establishing the secure channel used for machine-level Group Policy and service authentication. That machine account password automatically rotates every 30 days by default (governed by the DisableMachineAccountPasswordChange and MaximumMachineAccountPasswordAge policies), and if a computer goes offline for an extended period and misses too many rotation cycles — or its local copy and AD's copy of the password fall out of sync for any reason — the machine's trust relationship with the domain breaks, requiring the classic fix of rejoining the domain or resetting the computer account.
Cricket analogy: Similar to how each stadium in the IPL circuit has its own equipment registration and security clearance that needs periodic renewal — let it lapse too long, and the venue loses its accreditation and needs to be re-certified before hosting again.
Deeply nested groups (a global group inside another global group inside a universal group, and so on) inflate the Kerberos access token generated at logon. When that token exceeds roughly 48KB, Kerberos authentication can fail with 'token too large' errors on resources requiring Kerberos — a real, documented failure mode, not a theoretical one — so keep group nesting shallow and intentional, especially for accounts in many groups.
- AD models a network through three core object types: users, groups, and computers, each with its own SID.
- The SID, not the username, is what actually underlies permission checks and ACL entries.
- Disable departed users' accounts rather than deleting them, since deletion permanently destroys the SID and its access history.
- Security groups can be assigned resource permissions; distribution groups can only be used for email.
- Group scope (domain local, global, universal) determines where members can come from and where the group can be used.
- The AGDLP model nests global groups inside domain local groups, then assigns permissions only to the domain local group.
- Computer accounts authenticate like user accounts and rotate a 120-character machine password every 30 days by default.
Practice what you learned
1. What actually underlies AD permission checks on resources — the username or something else?
2. Why is disabling a departed employee's account preferred over deleting it?
3. What is the key difference between a security group and a distribution group?
4. In the AGDLP model, where is the actual resource permission assigned?
5. What can cause a domain-joined computer to lose its trust relationship with the domain?
Was this page helpful?
You May Also Like
Organizational Units (OUs)
How OUs let administrators organize AD objects for delegated administration and targeted Group Policy application.
What Is Active Directory?
An introduction to Active Directory as Microsoft's directory service for centralizing identity, authentication, and resource management across a Windows network.
Installing AD DS and Promoting a Domain Controller
A walkthrough of installing the AD DS server role on Windows Server and promoting it into a new or existing domain controller.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics