9.1 Authentication Protocols and Access Control Models

Authentication Protocols and Access Control Models

Core Security Principle: In enterprise server environments, identity and access governance represent the primary defensive perimeter. Physical security and perimeter firewalls cannot protect data if directory services broadcast cleartext credentials, authentication protocols permit credential replay, or service accounts utilize static, unrotated passwords. Robust server hardening demands an interlocking architecture: centralized directory structures, cryptographically verified ticket-granting exchanges, granular network access control (AAA), multi-factor verification, least-privilege authorization models, and automated service identity governance.

Systems administrators preparing for the CompTIA Server+ (SK0-005) certification must master the protocol mechanics, transport ports, and access control models that safeguard enterprise server fabrics across on-premises and hybrid topologies.

---

Enterprise Directory Services: Active Directory Domain Services (AD DS) and LDAP

Modern enterprise infrastructures rely on centralized directory services to store, organize, and authenticate access to network resources, including users, compute nodes, storage volumes, and security policies.

Active Directory Domain Services (AD DS)

Microsoft's Active Directory Domain Services (AD DS) organizes enterprise resources into a hierarchical logical structure:

• Forest: The top-level security and administrative boundary of an AD DS deployment. All domains within a forest share a single schema (definitions of objects and attributes) and a common Global Catalog (GC).
• Domain: A logical administrative grouping of network objects sharing common security policies, authentication databases, and trust relationships.
• Organizational Units (OUs): Subdivisions within a domain used to organize objects for administrative delegation and the targeted application of Group Policy Objects (GPOs).
• Global Catalog (GC): A distributed database contained on designated Domain Controllers (DCs) that stores a full replica of all objects in its own domain and a partial, searchable replica of every object across all other domains in the forest. Clients query the Global Catalog over TCP Port 3268 (or TCP Port 3269 for SSL/TLS) to resolve cross-domain group memberships and user principal names (UPNs) during authentication.

Lightweight Directory Access Protocol (LDAP vs. LDAPS)

The Lightweight Directory Access Protocol (LDAP) (RFC 4511) provides a standardized, vendor-neutral software protocol enabling clients and server applications to query and modify directory services over IP networks.

+-----------------------------------------------------------------------------+
|                        LDAP Namespace Hierarchy                             |
|                                                                             |
|   Root (Domain Component): dc=corp,dc=internal                              |
|        |                                                                    |
|        +---> Organizational Unit (ou): ou=Servers                           |
|        |          |                                                         |
|        |          +---> Common Name (cn): cn=sql01                          |
|        |                                                                    |
|        +---> Organizational Unit (ou): ou=Finance                           |
|                   |                                                         |
|                   +---> Common Name (cn): cn=AccountingAppService           |
+-----------------------------------------------------------------------------+

Directory objects are addressed using X.500 naming conventions:

• Distinguished Name (DN): The unique, fully qualified path to an object within the directory tree (e.g., CN=sql01,OU=Servers,DC=corp,DC=internal).
• Relative Distinguished Name (RDN): The single attribute value representing the object at its current level in the hierarchy (e.g., CN=sql01).

Protocol Security: LDAP vs. LDAPS

[!CAUTION] The Port 389 Cleartext Trap: In standard LDAP over port 389, directory authentication binds (simple binds) transmit usernames and passwords across the network wire in unencrypted plaintext. Anyone running a network packet capture tool (such as Wireshark or tcpdump) on the same broadcast domain or an intermediate switch span port can harvest administrative credentials. Server administrators must mandate LDAPS over Port 636 or enforce StartTLS (RFC 4513) on port 389 before permitting directory binds from application servers.

# Linux CLI: Testing an encrypted directory query against an LDAPS server on Port 636
ldapsearch -H ldaps://dc01.corp.internal:636 -x -D "CN=svc-app,OU=ServiceAccounts,DC=corp,DC=internal" -W -b "OU=Servers,DC=corp,DC=internal" "(objectClass=computer)" cn operatingSystem

---

Kerberos v5 Authentication Protocol Architecture

Kerberos v5 (RFC 4120) is the default network authentication protocol for Microsoft Active Directory domains and enterprise Linux identity fabrics (such as FreeIPA and MIT Kerberos). Kerberos operates on the concept of shared symmetric cryptography and trusted third-party ticket issuance, preventing passwords from ever traversing the network.

Core Kerberos Components

• Principal: Any unique entity to which Kerberos can assign tickets. This includes user accounts (username@CORP.INTERNAL) and service accounts bound to Service Principal Names (SPNs) (MSSQLSvc/sql01.corp.internal:1433).
• Key Distribution Center (KDC): The trusted authentication authority, typically co-located on Active Directory Domain Controllers. The KDC houses two essential functional components:
  • Authentication Server (AS): Verifies the initial identity of the requesting principal and issues a Ticket Granting Ticket (TGT).
  • Ticket Granting Server (TGS): Issues application-specific Service Tickets based on valid TGT presentations.
• Ticket Granting Ticket (TGT): A cryptographic token issued by the AS that proves the principal has successfully authenticated. The TGT is encrypted using the KDC's private secret key (the krbtgt account hash in Active Directory).
• Service Ticket (ST / TGS Ticket): A cryptographic token issued by the TGS that grants the principal access to a specific target server or service. The Service Ticket is encrypted using the secret key (password hash) of the target service account.

The Kerberos Authentication Handshake Flow

+-----------------------------------------------------------------------------+
|                   The Kerberos v5 Ticket Exchange Flow                      |
|                                                                             |
|   [Client / Principal]                                  [KDC (Domain Ctrl)] |
|         |                                                        |          |
|         |--- 1. AS-REQ (Encrypted Timestamp via UDP/TCP 88) ---->|          |
|         |                                                        | (AS)     |
|         |<-- 2. AS-REP (TGT [KDC Key] + Session Key [User Key]) -|          |
|         |                                                        |          |
|         |--- 3. TGS-REQ (TGT + Authenticator + Target SPN) ----->|          |
|         |                                                        | (TGS)    |
|         |<-- 4. TGS-REP (Service Ticket [Target Service Key]) ---|          |
|         |                                                        |          |
|         +--------------------------------------------------------+          |
|         |                                                                   |
|         v                                                                   |
|   [Application Server]                                                      |
|         |                                                                   |
|         |--- 5. AP-REQ (Service Ticket + Client Authenticator) ------------>|
|         |<-- 6. AP-REP (Mutual Authentication Confirmation - Optional) -----|
+-----------------------------------------------------------------------------+

1. Authentication Service Request (AS-REQ): The client requests a TGT. The client encrypts its current local timestamp using a cryptographic key derived from the user's password and transmits it to the KDC on UDP or TCP Port 88.
2. Authentication Service Response (AS-REP): The KDC's AS decrypts the timestamp using its copy of the user's password hash stored in the directory. If the timestamp is valid and within tolerance, the AS returns the TGT (encrypted with the KDC's secret key) and a temporary Logon Session Key (encrypted with the user's password key).
3. Ticket Granting Service Request (TGS-REQ): When the client needs to connect to an application server (e.g., an SMB file share or SQL database), it presents its TGT, an authenticator message encrypted with the Logon Session Key, and the target Service Principal Name (SPN) to the KDC's TGS on port 88.
4. Ticket Granting Service Response (TGS-REP): The TGS validates the TGT using the KDC's secret key, verifies the authenticator, and constructs a Service Ticket containing the client's authorization data (Group SIDs). The Service Ticket is encrypted using the target service account's secret key and returned to the client alongside a Server Session Key.
5. Application Request (AP-REQ): The client transmits the Service Ticket and an authenticator directly to the target application server. The target server decrypts the Service Ticket using its own local password hash, extracts the client's identity and group memberships, and evaluates local access permissions.

The Critical 5-Minute Maximum Clock Skew Tolerance

[!IMPORTANT] The Kerberos Clock Skew Mandate: Because Kerberos authenticators contain unencrypted timestamps to prevent replay attacks (where an eavesdropper captures an authentication packet and resends it to gain access), the KDC compares the incoming packet timestamp against its own system clock. By default, Kerberos v5 permits a maximum clock skew of 5 minutes (300 seconds). If the time difference between the client workstation/server and the KDC exceeds 5 minutes, the KDC immediately rejects the authentication request with the error code KRB_AP_ERR_SKEW. Maintaining continuous, accurate time synchronization via Network Time Protocol (NTP) across all domain controllers, member servers, and hypervisors is mandatory for Kerberos operational integrity.

# Windows Server: Display cached Kerberos tickets on the local system
klist

# Windows Server: Purge cached Kerberos tickets to force re-authentication
klist purge

# Linux: Display Kerberos ticket cache
klist -e

---

Network Access Authentication: RADIUS vs. TACACS+

Enterprise servers, out-of-band management controllers (iDRAC, iLO), and network infrastructure devices (switches, routers, VPN concentrators) utilize centralized Authentication, Authorization, and Accounting (AAA) protocols to manage administrative and client network access.

+-----------------------------------------------------------------------------+
|                        RADIUS vs. TACACS+ Topology                          |
|                                                                             |
|   RADIUS (UDP 1812/1813):                                                   |
|   [Client/Switch] ---> [Packet: Cleartext Header + Encrypted Password Only] |
|                        * Combines Authentication + Authorization.           |
|                                                                             |
|   TACACS+ (TCP 49):                                                         |
|   [Client/Switch] ---> [Packet: Cleartext Header + FULLY ENCRYPTED BODY]    |
|                        * Decouples Authentication, Authorization, & Acct.   |
|                        * Supports Granular Per-Command Authorization.       |
+-----------------------------------------------------------------------------+

RADIUS (Remote Authentication Dial-In User Service)

• Standard & Architecture: Defined in RFC 2865 (Authentication/Authorization) and RFC 2866 (Accounting). RADIUS operates under a client/server model where the network access server (NAS) acts as a RADIUS client querying a centralized RADIUS server (such as Microsoft Network Policy Server / NPS or FreeRADIUS).
• Transport Protocols & Ports: Operates over UDP Port 1812 for Authentication and Authorization, and UDP Port 1813 for Accounting. (Legacy implementations utilized UDP ports 1645 and 1646).
• AAA Coupling: RADIUS combines Authentication and Authorization. When the RADIUS server validates credentials, it bundles user authorization attributes (such as VLAN assignment or filter IDs) directly into the Access-Accept response packet.
• Cryptographic Weakness: RADIUS encrypts only the password field within the payload using a shared secret and MD5 hashing. The packet header, username, IP attributes, and accounting logs traverse the network in cleartext.

TACACS+ (Terminal Access Controller Access-Control System Plus)

• Standard & Architecture: Originally developed by Cisco (RFC 8907). TACACS+ is engineered specifically for device administration and management plane security.
• Transport Protocols & Ports: Operates over TCP Port 49, utilizing connection-oriented transport to ensure reliable session state and error recovery.
• AAA Separation: TACACS+ completely separates Authentication, Authorization, and Accounting into independent transactions. An administrator can authenticate via an external directory, authorize individual commands entered during a terminal session, and log keystrokes to a distinct accounting server.
• Cryptographic Superiority: TACACS+ encrypts the entire body of the packet, including usernames, authorization parameters, and command strings. Only a small, 12-byte fixed TACACS+ header remains in cleartext.

Architectural Comparison: RADIUS vs. TACACS+

---

Multi-Factor Authentication (MFA) Categorization

Password-only authentication is vulnerable to phishing, credential stuffing, brute-force guessing, and keylogging. Multi-Factor Authentication (MFA) requires users and administrators to present two or more independent authentication factors before being granted access to server operating systems or administrative consoles.

+-----------------------------------------------------------------------------+
|                   Authentication Factor Categories                          |
|                                                                             |
|   1. SOMETHING YOU KNOW (Knowledge):                                        |
|      * Passwords, PINs, Passphrases, Security Challenge Answers             |
|                                                                             |
|   2. SOMETHING YOU HAVE (Possession):                                       |
|      * Hardware Smart Cards (CAC/PIV), FIDO2 WebAuthn Keys, TOTP Tokens     |
|                                                                             |
|   3. SOMETHING YOU ARE (Inherence):                                         |
|      * Fingerprint Scanners, Facial Recognition, Iris Scans, Voice Prints   |
|                                                                             |
|   4. SOMEWHERE YOU ARE (Location / Context):                                |
|      * Geolocation Fencing, Internal Corporate IP Subnet Matching           |
+-----------------------------------------------------------------------------+

[!NOTE] True MFA vs. Multi-Step Authentication: Presenting two items from the same category (e.g., a password and a PIN) is NOT Multi-Factor Authentication—it is two-step single-factor authentication. True MFA strictly requires items from at least two different factor categories (e.g., a password [Knowledge] plus a FIDO2 hardware token [Possession]).

Detailed Factor Classifications

1. Something You Know (Knowledge Factor): Information the user commits to memory, including alphanumeric passwords, complex passphrases, and personal identification numbers (PINs). Knowledge factors are susceptible to social engineering, interception, and credential replay.
2. Something You Have (Possession Factor): Physical cryptographic tokens or hardware devices under the user's physical custody:
   • Hardware Smart Cards (CAC / PIV): Microprocessor-embedded cards containing private X.509 cryptographic keys that require a PIN to unlock. Extensively deployed in defense and high-security enterprise server consoles.
   • One-Time Password (OTP) Hardware Tokens: Devices generating time-synchronized codes based on the OATH Time-Based One-Time Password (TOTP, RFC 6238) or HMAC-Based One-Time Password (HOTP, RFC 4226) standards (e.g., RSA SecurID).
   • FIDO2 / WebAuthn Hardware Security Keys: Fast Identity Online (FIDO2) USB/NFC hardware security keys (e.g., YubiKey) implementing asymmetric public-key cryptography. They provide cryptographic binding to the browser origin, completely neutralizing phishing and man-in-the-middle attacks.
3. Something You Are (Inherence Factor): Measurable biological characteristics unique to an individual, including fingerprint biometrics, facial geometry recognition, retina scans, and iris patterns. Inherence systems are measured by their False Rejection Rate (FRR / Type I error) and False Acceptance Rate (FAR / Type II error); the point where both rates intersect is the Crossover Error Rate (CER), which defines the biometric sensor's overall accuracy.
4. Somewhere You Are (Location / Attribute Factor): Physical geographic position or network context, verified using GPS coordinates, cellular tower triangulation, or authorized corporate IP subnet boundaries. Systems can deny administrative logins originating from unauthorized geographic regions or external IP spaces.

---

Authorization and Access Control Models

Once a principal's identity is authenticated, the operating system kernel evaluates authorization to determine which specific actions (read, write, execute, delete) the principal may execute on target server objects.

Principle of Least Privilege (PoLP)

The foundational rule of enterprise security architecture mandates that users, service accounts, and applications must be granted only the absolute minimum level of access and permissions necessary to perform their required operational duties, and for no longer than the duration required. Adhering to least privilege limits the "blast radius" if credentials are compromised.

Comparative Access Control Models

+-----------------------------------------------------------------------------+
|                   Enterprise Access Control Models                          |
|                                                                             |
|   DISCRETIONARY ACCESS CONTROL (DAC):                                       |
|   * Resource Owner sets permissions via Access Control Lists (ACLs).        |
|   * Examples: NTFS File Permissions, Linux POSIX chmod/chown.               |
|                                                                             |
|   MANDATORY ACCESS CONTROL (MAC):                                           |
|   * Operating System Kernel enforces strict security labels & levels.       |
|   * Users CANNOT override policy, even on files they created.               |
|   * Examples: Security-Enhanced Linux (SELinux), AppArmor.                  |
|                                                                             |
|   ROLE-BASED ACCESS CONTROL (RBAC):                                         |
|   * Permissions assigned to Roles; Users assigned to Roles based on job.    |
|   * Examples: Active Directory Security Groups, Azure/AWS IAM Roles.        |
+-----------------------------------------------------------------------------+

1. Discretionary Access Control (DAC)

In Discretionary Access Control (DAC), the creator or owner of a data resource possesses the discretion to assign access rights to other users. DAC is governed by Access Control Lists (ACLs) containing Access Control Entries (ACEs):

• Windows NTFS Permissions: The file owner can grant or deny specific permissions (Full Control, Modify, Read & Execute, List Folder Contents, Read, Write) to individual users or groups.
• Linux Standard POSIX Permissions: File permissions are divided into User (Owner), Group, and Other (World) permissions using read (r=4), write (w=2), and execute (x=1) bits managed via chmod and chown.
• Weakness: DAC scales poorly in large enterprises and suffers from permission drift, privilege creep, and accidental over-permissive sharing by users.

2. Mandatory Access Control (MAC)

In Mandatory Access Control (MAC), the operating system kernel centrally enforces access rules based on formal security labels, data classifications (e.g., Unclassified, Confidential, Secret, Top Secret), and user clearances. Data owners have zero discretion to modify access permissions on objects they create; the kernel mediates all access requests:

• SELinux (Security-Enhanced Linux): Enforces MAC in Linux kernels using Type Enforcement. Every process (subject) and file/socket (object) is assigned an SELinux security context consisting of user:role:type:level (e.g., system_u:system_r:httpd_t:s0). Even if the Apache web daemon (httpd_t) is compromised and running with root privileges, the SELinux kernel blocks it from reading files labeled with the database context (mysqld_db_t) or shadow password hashes (shadow_t).

# Linux CLI: Inspecting SELinux security context labels on critical files
ls -Z /etc/shadow
# Output: system_u:object_r:shadow_t:s0 /etc/shadow

# Checking active SELinux enforcement status
getenforce

3. Role-Based Access Control (RBAC)

In Role-Based Access Control (RBAC), access permissions are bound directly to functional job roles rather than individual user identities. Administrators create roles (e.g., "Database Administrator", "Backup Operator", "Helpdesk Tier 1") and assign explicit permissions to those roles. Users are then made members of the appropriate roles:

• Operational Advantage: When an employee changes departments, administrators simply remove them from their previous role group and add them to their new role group. This completely eliminates orphaned privileges, accelerates provisioning, and simplifies compliance auditing.

---

Privileged Access Management (PAM) and Dual Control

Enterprise servers host the organization's most sensitive operational data, making administrative accounts (root, Domain Admins, Enterprise Admins) the primary target for malicious actors. Privileged Access Management (PAM) establishes a secure operational framework to govern elevated identities.

+-----------------------------------------------------------------------------+
|                        PAM Operational Workflow                             |
|                                                                             |
|   [Admin User] ---> 1. Requests Elevated Access ---> [PAM Vault / Engine]   |
|                                                             |               |
|   [Dual Approver] <- 2. Second-Person Approval -------------+               |
|                                                             |               |
|   [Admin User] <--- 3. JIT Ephemeral Credentials Issued <---+               |
|         |           (Session Recorded & Keystroke Audited)                  |
|         v                                                                   |
|   [Target Production Server]                                                |
+-----------------------------------------------------------------------------+

Core PAM Capabilities

• Just-in-Time (JIT) Privileged Access: Eliminates permanent, 24/7 "standing privileges." Administrators operate as standard unprivileged users for daily tasks. When administrative intervention is required, the PAM system temporarily elevates the user's account or provisions an ephemeral, time-bounded token that expires automatically after a set duration (e.g., 2 hours).
• Credential Vaulting: High-privilege passwords (such as local root or Windows local Administrator passwords) are locked inside an encrypted, centralized vault. Administrators never see or know the actual password; the PAM vault initiates an automated, proxied RDP or SSH connection, injecting the credentials automatically.
• Session Recording and Keystroke Logging: The PAM proxy records full-motion video and keystroke telemetry for all administrative sessions, creating an indisputable audit trail for forensic investigation and regulatory compliance.
• Two-Person Integrity (Dual Control / Four-Eyes Principle): Mandates that high-impact administrative actions—such as rotating root encryption keys, deleting production database clusters, or promoting domain controllers—cannot be executed by a single individual. The action requires cryptographic or programmatic authorization from two independent administrators before the PAM vault releases privileges.

---

Service Account Management: Standard vs. Group Managed Service Accounts (gMSA)

Enterprise services (SQL Server instances, IIS application pools, backup agents, monitoring daemons) require service accounts to interact with the operating system and network resources.

The Failure of Standard Service Accounts

Historically, administrators created standard Active Directory user accounts to run background services. This model created severe vulnerabilities:

• Static, Unrotated Passwords: To prevent services from breaking due to expired credentials, administrators frequently checked the "Password Never Expires" flag.
• Shared Passwords: The same service account password was often configured across dozens of servers.
• Kerberoasting Attacks: Because standard service accounts require Service Principal Names (SPNs) registered in Active Directory, any authenticated domain user can request a Kerberos Service Ticket for that SPN and attempt offline brute-force attacks against the service account password hash.

Group Managed Service Accounts (gMSA)

Introduced in Windows Server, Group Managed Service Accounts (gMSAs) completely solve the risks associated with static service accounts:

+-----------------------------------------------------------------------------+
|                  Group Managed Service Account (gMSA) Flow                  |
|                                                                             |
|   Active Directory Domain Controllers:                                      |
|   * Generates complex 128-character cryptographic password.                 |
|   * AUTOMATICALLY ROTATES PASSWORD EVERY 30 DAYS.                           |
|                                                                             |
|   Target Host Server (Clustered Application Servers):                       |
|   * Server queries DC via Netlogon secure channel.                          |
|   * Retrieves rotated password directly in-memory.                          |
|   * ZERO manual password changes; ZERO service interruptions.               |
+-----------------------------------------------------------------------------+

• Automated Password Rotation: Active Directory domain controllers automatically generate a cryptographically strong, 128-character random password for the gMSA and rotate it automatically (by default every 30 days).
• Zero Administrative Knowledge: No human administrator knows or can view the gMSA password. The password is never stored on disk in cleartext.
• Host-Bound Delegation: The host server operating system queries the domain controller via its secure Netlogon machine channel to retrieve the password directly into memory. The service launches seamlessly without manual password entry or configuration updates.
• Cluster Support: Unlike standalone Managed Service Accounts (sMSAs), gMSAs can be shared across multiple servers in a farm or load-balanced cluster, enabling resilient multi-server application scaling.

Rule-Based, Scope-Based Access, and Segregation of Duties

Beyond role-based access control, SK0-005 names three further authorization concepts that determine when and how far a granted permission actually reaches.

Rule-based control is the one most often confused with role-based on the exam, and the discriminator is simple: a rule applies to everyone who meets a condition and ignores who you are, while a role applies to you because of who you are. "Deny all administrative logons between 22:00 and 05:00" is rule-based even when the account is a domain administrator.

Scope-based control is what converts a dangerously broad role into a safe one. Two administrators can hold the identical "reset password" role while one is scoped to a single site OU and the other to the entire forest; the permission verb is the same and the blast radius differs by orders of magnitude. Cloud RBAC makes this explicit through an assignment scope, and Active Directory implements it through delegation on an OU.

Segregation (separation) of duties splits any single high-risk workflow so that no one person can both initiate and approve it. In server operations that means the administrator who writes a change cannot be the one who approves it, the person who runs backups is not the person who authorizes restores to alternate locations, and the administrator who manages an audit-log platform cannot delete its records. Where headcount makes true separation impossible, the compensating controls are dual control / two-person integrity for the specific dangerous action, delegation of narrowly scoped rights instead of blanket administrator membership, and independent auditing of user activity, logins, group memberships, and deletions to detect an unsplit action after the fact.