Overview
Active Directory (AD) is Microsoft’s directory service for Windows-based network environments. It functions as a centralized, redundant database containing every object in the network: user accounts, computer accounts, file shares, printers, security groups, and any other resource that needs to be managed or secured. By centralizing all identity and resource information in one place, AD eliminates the need for separate credential stores on every individual system and makes consistent security enforcement across the organization possible.
What Active Directory Stores
The AD database is an inventory of everything on the network. Key object types include:
- User accounts — every person who needs to log in; stores their username, password hash, group memberships, and attributes
- Computer accounts — every domain-joined workstation, server, and device; allows policy to be applied at the machine level
- Security groups — collections of users or computers; permissions are assigned to groups and all members inherit them automatically
- File shares and printers — network resources published to the directory so users can discover and connect to them
- Organizational Units (OUs) — containers that organize objects for delegation and Group Policy application
Authentication Management
All domain-joined Windows systems authenticate against AD. When a user enters their username and password at a workstation, the credentials are validated against the AD database — not against a local account on that machine. This single-sign-on model means:
- One set of credentials grants access to all authorized resources on the domain
- Password changes take effect immediately across all systems
- Account lockout and expiration policies apply uniformly
- Multi-factor authentication requirements can be enforced centrally
Because AD is the single source of truth for identity, compromising an AD administrator account is one of the most serious security incidents possible in a Windows environment — it provides access to every resource protected by AD.
Centralized Access Control
AD enables administrators to define who can access what. Permissions are assigned to:
- Individual users — a specific person gets access to a specific resource
- Security groups — all members of a group share the same permissions; adding a user to a group grants them all the group’s access rights immediately
Group-based access control is the preferred model at scale. Rather than managing permissions for hundreds of individual users, administrators manage group memberships. A user’s access profile changes by adding or removing them from groups — not by editing permissions on every resource individually.
Help Desk Operations
The help desk uses AD as the primary administrative console for day-to-day identity tasks:
- Password resets — when a user forgets their password or a password expires
- Account creation — provisioning new employees with domain credentials
- Account deletion / disabling — removing access when an employee leaves; disabling is preferred over deletion to preserve audit history
- Account unlocks — restoring access after too many failed login attempts triggered a lockout
- Group membership changes — granting or revoking access to resources by modifying group memberships
Key Terms
- Active Directory (AD) — Microsoft’s centralized directory service; database of all network objects in a Windows domain
- Domain controller (DC) — the server hosting the AD database; authenticates users and enforces policies
- Security group — collection of AD objects (users/computers) that share a common permission set
- Organizational Unit (OU) — AD container for organizing objects; target for Group Policy application and delegated administration
- Single sign-on (SSO) — one set of AD credentials authenticates the user to all authorized resources
Overview
Group Policy is the Windows mechanism for deploying configuration and security settings to computers and users across an AD domain from a single central console. Administrators write policies in the Group Policy Management Editor and link them to Organizational Units, domains, or sites. Every domain-joined device and user receives the applicable policies automatically at login or startup — without any action by the end user.
What Group Policy Controls
Group Policy provides access to hundreds of configuration settings organized into two main categories:
Computer Configuration — settings that apply to the machine regardless of who logs in:
- Password complexity and minimum length requirements
- Account lockout thresholds (maximum failed attempts before lockout)
- Windows Firewall rules and exceptions
- Software installation and restriction policies
- USB and removable media controls
- Network configurations including Quality of Service (QoS)
User Configuration — settings that follow the user to any machine they log in to:
- Login scripts — run automatically when the user signs in (map network drives, run diagnostics)
- Desktop restrictions — prevent access to Control Panel, hide drives, restrict right-click menus
- Screen lock timeout — automatically lock the workstation after a period of inactivity
- Internet Explorer / Edge security zones
- Printer and drive mappings
Practical Security Examples
Common security hardening tasks accomplished through Group Policy:
- Require passwords of at least 14 characters with complexity requirements (uppercase, lowercase, number, symbol)
- Lock workstations after 5 minutes of inactivity — enforces unattended-system policy without relying on users
- Disable USB mass storage devices on all workstations — prevents data exfiltration via removable media
- Prevent users from installing software — reduces attack surface from unauthorized or malicious applications
- Deploy certificates and trusted root CAs to all machines automatically
- Enable audit logging on all systems — ensures consistent log collection for SIEM ingestion
Because policies are distributed centrally and applied automatically, organizations maintain consistent security configurations across thousands of devices without touching each one individually. A new security requirement is implemented by editing one policy — all affected machines receive it at the next policy refresh.
Group Policy and Least Privilege
Group Policy directly supports the principle of least privilege by restricting what users can do on their workstations. Without Group Policy, local administrators on each machine could change any setting. With Group Policy:
- Standard users cannot install software, change system settings, or disable security tools
- Local administrator rights can be removed from end users entirely
- Access to specific tools (Registry Editor, Command Prompt, Task Manager) can be blocked for non-administrators
Group Policy does not replace AD — it depends on AD. Policies are stored in AD and delivered to domain-joined machines through the domain controller. Without AD, Group Policy applies only locally (Local Group Policy) on a single machine with no central management.
Key Terms
- Group Policy — Windows mechanism for centrally deploying configuration and security settings to AD-joined computers and users
- Group Policy Management Editor — the central console used to create, edit, and link Group Policy Objects
- GPO (Group Policy Object) — a container holding a collection of policy settings; linked to an OU, domain, or site
- Login script — script run automatically at user sign-in; used for drive mappings, environment configuration
- QoS (Quality of Service) — network traffic prioritization policy configurable through Group Policy
Overview
Every operating system enforces some model of access control that determines who can read, write, or execute resources. The two primary models — Discretionary Access Control (DAC) and Mandatory Access Control (MAC) — represent fundamentally different philosophies about where security authority should reside. Standard Linux uses DAC. Security-Enhanced Linux (SELinux) adds MAC to the Linux kernel, providing a significantly stronger security posture for high-security environments.
Discretionary Access Control (DAC)
In a DAC system, the owner of a resource controls its permissions. On a standard Linux system, the user who creates a file decides who can read, write, or execute it. This is the chmod / chown model familiar to every Linux administrator.
Strengths: Flexible and easy to use. Users manage their own files without needing administrator involvement. Works well in low-sensitivity environments.
Security limitation: If a user account or process is compromised, the attacker inherits all the permissions that user or process had. A compromised web server running as a low-privilege user might still have DAC access to files owned by that user — including configuration files, keys, or data directories. The attacker operates within the access envelope the owner established, which may be much broader than the process actually needs.
Mandatory Access Control (MAC)
In a MAC system, a central administrator defines security policies that control access to all resources. Users and processes cannot override these policies — even a file owner cannot grant permissions that the MAC policy prohibits. The security authority belongs to the administrator, not the resource owner.
Strengths: Significantly harder to exploit after a compromise. Even if an attacker controls a process, they can only access what the MAC policy explicitly permits for that process — not everything the process’s Linux user account technically owns.
Limitation: More complex to configure and maintain. Overly restrictive MAC policies can break applications if they deny access the application legitimately needs.
Security-Enhanced Linux (SELinux)
SELinux is a set of security patches for the Linux kernel that adds Mandatory Access Control. It was originally developed by the NSA and is now open source, included by default in Red Hat Enterprise Linux (RHEL), CentOS, Fedora, and other distributions.
How SELinux works: Every process and every file/resource on the system is assigned a security label (called a security context). SELinux policy rules define which process labels can access which resource labels. The kernel enforces these rules on every access attempt. DAC file permissions are checked first; if they permit access, SELinux policy is checked second — both must allow the access for it to succeed.
Application confinement — the key benefit: A web server process (e.g., Apache) is confined to access only the files, ports, and resources its SELinux policy allows. Even if an attacker fully exploits the web application:
- The web server process cannot read
/etc/shadow(the password file) — that label is not permitted for web server processes - The process cannot write to system binaries — policy does not allow web server label to modify executables
- The process cannot open outbound connections on arbitrary ports — only the ports the policy permits
- The attacker is contained within the web server’s security context rather than having full access to everything the Linux user account owns
Least privilege in practice: SELinux enforces least privilege at the kernel level. Each process gets exactly what its job requires — nothing more. A potential breach has limited scope because the compromised process is already confined before the attacker arrives.
DAC vs. MAC Comparison
| Property | DAC (Default Linux) | MAC (SELinux) |
|---|---|---|
| Who sets permissions | Resource owner (the user) | Central administrator (policy) |
| Can user override policy | Yes — owner can change their own file permissions | No — MAC policy cannot be overridden by users |
| Post-compromise scope | Attacker gets everything the owner could access | Attacker is confined to the process’s security context |
| Complexity | Low — familiar chmod/chown model | High — requires policy authoring and maintenance |
| Least privilege | Approximate — depends on owner diligence | Enforced — kernel-level, policy-defined |
| Example | Standard Linux file permissions | SELinux, AppArmor |
Key Terms
- DAC (Discretionary Access Control) — access model where the resource owner controls permissions; default on standard Linux
- MAC (Mandatory Access Control) — access model where a central administrator defines policies that users cannot override
- SELinux — Security-Enhanced Linux; kernel patches adding MAC to Linux; developed by NSA; open source
- Security context / label — SELinux tag assigned to every process and resource; policy rules match labels to determine access
- Application confinement — SELinux restricting a process to only the resources its policy permits; limits breach impact
- Least privilege — principle that users and processes receive only the minimum permissions needed for their function