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.

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 jane.doe@contoso.com), 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.

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.

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.