"Your Identity" — Users, Groups & Authentication

Windows supports two fundamentally different kinds of user accounts, and understanding the difference is critical for any IT professional.

A local account exists only on a single machine. When you create a user on a standalone workstation, that account is stored in the SAM (Security Account Manager) database on that computer. The account can only log into that one machine. If you have 500 workstations, you'd need to create 500 separate accounts for one user — a nightmare to manage.

A domain account exists in Active Directory (AD), a centralized database stored on one or more Domain Controllers. When a user logs into any domain-joined workstation, the computer contacts the Domain Controller to verify the credentials. One account, accessible from any machine in the domain. Change the password once, and it works everywhere.

Windows doesn't actually track users by their username — it tracks them by a unique number called a Security Identifier (SID). A SID is a variable-length binary value that uniquely identifies a security principal (user, group, or computer) across the entire Windows ecosystem.

A typical SID looks like this:

The RID (Relative Identifier) at the end is what distinguishes individual accounts within the same domain. The domain portion stays the same for all accounts in that domain — only the RID changes.

Well-known SIDs are fixed across all Windows installations:

The SAM (Security Account Manager) is the database where local account information is stored on every Windows machine. It lives at C:\Windows\System32\config\SAM and is one of the most security-critical files on the system.

The SAM stores:

• Usernames and their corresponding SIDs
• Password hashes (NTLM hashes — NOT plaintext passwords)
• Local group memberships
• Account status (enabled/disabled, lockout state)

The SAM file is locked by the operating system while Windows is running. You cannot simply copy, open, or read it from a live system. This is a security measure — if the SAM were readable, any user could extract password hashes and crack them offline.

Active Directory (AD) is Microsoft's directory service for centralized identity and resource management. If the SAM is a guest list at one building's reception desk, Active Directory is the master employee database for the entire company — every office, every city, every country.

AD uses a hierarchical structure:

• Forest — The top-level security boundary. A forest can contain multiple domains that share a common schema and trust relationships. Most organizations have a single forest. Example: meridian.local.
• Domain — A logical grouping of objects (users, computers, groups) that share a common namespace and security policies. Each domain has at least one Domain Controller. Example: meridian.local.
• Organizational Unit (OU) — A container within a domain used to organize objects for administration and Group Policy application. Think of OUs like department folders. Examples: OU=Finance, OU=Engineering, OU=IT.
• Objects — The actual entries in AD: Users, Groups, Computers, Contacts, Shared Printers, etc. Each object has attributes (name, email, department, SID, etc.).

At Meridian Dynamics, the AD structure looks like this:

The Domain Controller (DC) is the server that runs AD Domain Services (AD DS). It stores the AD database (ntds.dit), handles authentication requests (Kerberos/NTLM), replicates data to other DCs, and enforces Group Policy. At Meridian Dynamics, MD-DC01 is the primary Domain Controller.

Managing permissions user-by-user is unsustainable. Groups let you assign permissions once and then add users to the group. Windows has two types of groups and three group scopes.

Group Types:

• Security Groups — Can be used to assign permissions to resources (file shares, folders, printers). They also have a SID that appears in access tokens. This is the type you'll use 99% of the time.
• Distribution Groups — Used only for email distribution lists. They have no SID and cannot be used for permissions. Think of them as mailing lists, not access lists.

Group Scopes:

AGDLP Nesting Strategy — The recommended practice for managing permissions in AD:

1. Accounts → are placed into
2. Global groups (by role) → which are nested into
3. Domain Local groups (by resource permission) → which are granted
4. Permissions on the resource

Example at Meridian Dynamics: User d.kowalski (Account) is a member of Finance-Staff (Global group), which is a member of Finance-Share-Modify (Domain Local group), which has Modify permission on the Finance$ share (Permission). If Dana transfers departments, you just remove her from the Global group — the permissions take care of themselves.

When you type your username and password at the Windows login screen, something has to verify those credentials. Windows uses two authentication protocols: NTLM (the legacy protocol) and Kerberos (the modern default in Active Directory).

When you successfully log into Windows, the system creates an access token — a data structure that represents your identity for the entire session. Think of it as a digital ID badge that every process you run carries with it.

An access token contains:

• User SID — Your unique identifier (e.g., S-1-5-21-...-1201 for intern01)
• Group SIDs — Every group you belong to (Domain Users, IT-Staff, etc.)
• Privileges — Special permissions like SeDebugPrivilege, SeBackupPrivilege, SeShutdownPrivilege
• Integrity Level — Low, Medium, High, or System (determines what objects you can access)
• Logon Session ID — Which logon session this token belongs to

Every process you launch inherits your access token. When you open Notepad, cmd.exe, or a browser — each of those processes runs with your token. When they try to access a file, the Security Reference Monitor compares the process's token against the file's DACL to decide whether to allow or deny access.

User Account Control (UAC) is Windows' mechanism for preventing administrative tasks from running automatically. Even if you're logged in as an administrator, UAC ensures that your processes run with a filtered (standard) token by default. Only when you explicitly approve an elevation prompt does the process receive the full (elevated) token.

This is called the split token model:

Integrity Levels provide an additional layer of isolation:

A process at a lower integrity level cannot write to objects at a higher integrity level, even if the DACL would otherwise allow it. This prevents a compromised browser tab (Low) from modifying your documents (Medium) or system files (High).

Account policies define the rules for passwords and account lockouts across the domain. These are configured via Group Policy and apply to all users in the domain.

Password Policy:

Account Lockout Policy: