# Authentication, Authorization, and Encryption

> Chapter 11 of the Courseiva SERVER-PLUS curriculum — https://courseiva.com//learn/server-plus/authentication-authorization-and-encryption

**Official objective:** 2.4 — Implement cryptographic protocols (e.g., SSL/TLS, certificates) and configure authentication/authorization (e.g., MFA, permissions).

## Introduction

Authentication, authorization, and encryption are the three pillars that protect every digital interaction. Without them, any user could access any server, read any file, and pretend to be anyone else, making the entire system insecure. For the CompTIA Server+ SK0-005 exam, you must understand how these concepts work together to safeguard server resources and data.

## The Airport Security Analogy

A busy international airport terminal. Hundreds of passengers stream through, each heading to a different gate. 

First, everyone must show their passport at the check-in counter. This is authentication: proving you are who you claim to be. The passport is scanned, your face is checked, and the system confirms your identity. Without a valid passport, you cannot even enter the secure area. 

Once inside, you head to your gate. But boarding the plane requires a second check: the boarding pass. This is authorisation. Even if you have a valid passport, you cannot board any flight you like. Your boarding pass tells the gate agent which specific flight and seat you are allowed to access. Without it, you are stuck in the terminal. 

Finally, sensitive documents like your passport number and credit card details are stored in a sealed, tamper-proof envelope during travel. This is encryption. Even if someone snatches the envelope, they cannot read the contents without the key to open it. The envelope protects your data from being intercepted while in transit between check-in, security, and the aircraft. 

Together, these three layers ensure only authorised passengers board the right planes, and their private information stays secure throughout the journey.

## Core explanation

Let us break down each term from the ground up. Imagine you are a security guard at a company server room. Your job is to decide who can enter and what they can do once inside. 

**Authentication** is the process of verifying identity. It answers the question: "Who are you?"

When a user wants to log into a server, they must prove their identity. The most common method is a username and password. But passwords alone are weak — they can be stolen or guessed. That is why modern systems use multi-factor authentication (MFA), which requires at least two of the following three factors:
- Something you **know**: a password or PIN
- Something you **have**: a smartphone app, a security token, or a smart card
- Something you **are**: a fingerprint, retina scan, or facial recognition

When you type your password and then approve a push notification on your phone, you have used MFA. Servers often require MFA for remote administration to prevent unauthorised access even if a password is compromised. 

**Authorization** happens after authentication. It answers: "What are you allowed to do?"

Once the server knows who you are, it checks a set of rules — called permissions or access controls — to decide whether you can read, write, delete, or execute specific files or applications. A simple example: the server's operating system assigns each user a security identifier (SID) and compares it to the access control list (ACL) on each resource. The ACL is a list that says which users or groups have which permissions. 

There are different models for managing authorization. The most common one for servers is role-based access control (RBAC). In RBAC, administrators create roles (like "backup operator" or "database admin") and assign permissions to each role. Users are then added to roles, inheriting the permissions automatically. This makes it easy to grant the same set of permissions to many people without configuring each one individually. 

For the SK0-005 exam, you need to know the difference between authentication and authorization, and be able to identify scenarios where each applies. A common trap is that a user who has authenticated but not been authorised will be denied access to a resource — the server will return an "access denied" error, not a "login failed" error. 

**Encryption** is the process of scrambling data so that only someone with the correct key can read it. It protects data in two main states:
- **Data at rest**: stored on a hard drive, database, or backup tape.
- **Data in transit**: moving across a network, such as between a web browser and a server, or between two servers. 

Encryption uses mathematical algorithms and keys. A key is a string of bits that controls the scrambling and unscrambling. There are two types:
- **Symmetric encryption**: the same key is used to encrypt and decrypt. Fast but requires securely sharing the key.
- **Asymmetric encryption**: uses a pair of keys — a public key (shared openly) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the private key. This is the basis for SSL/TLS (Secure Sockets Layer / Transport Layer Security). 

**SSL/TLS** is the cryptographic protocol that secures web traffic (HTTPS). When you visit a secure website, the server presents a digital certificate. This certificate contains the server's public key and is signed by a trusted third party called a certificate authority (CA). Your browser uses the CA's public key to verify the certificate is genuine. Then a symmetric session key is exchanged using asymmetric encryption, and all subsequent data is encrypted with that session key. 

Certificates themselves contain identity information and are used to authenticate the server (and optionally the client) before encryption starts. Without certificates, you could be talking to an impostor. 

Why does this matter for a beginner? Because every server administrator must configure encryption for remote access (e.g., SSH for Linux, RDP with TLS for Windows), enable HTTPS for web services, and manage certificates. The SK0-005 exam tests your ability to select the correct encryption protocol for a given scenario and understand the role of certificates. 

Together, the three concepts form a security chain: authentication confirms identity, authorisation grants appropriate access, and encryption protects the data that flows between authenticated users and authorised resources. A failure in any one link breaks the entire security model.

## Real-world context

Meet Alex, a junior IT administrator at a medium-sized company. The company has just deployed a new web server that hosts an internal employee portal. Alex’s first task is to secure it. 

Here is what Alex actually does, step by step.

**Step 1: Configure authentication for server access.**
Alex sets up local user accounts on the Windows Server. Each employee who manages the server needs a unique username and a strong password. But Alex knows passwords alone are risky, so he enables multi-factor authentication (MFA) using the Microsoft Authenticator app. Now, every time an admin logs in remotely via RDP, after entering their password they must approve a notification on their phone. 

**Step 2: Request and install an SSL/TLS certificate.**
The employee portal must be accessible over HTTPS. Alex generates a certificate signing request (CSR) from the server and submits it to a public certificate authority (CA) like DigiCert. The CA verifies that the company owns the domain name (e.g., portal.company.com) and issues a certificate. Alex then installs the certificate on the web server and binds it to the HTTPS port (443). He also configures the server to enforce TLS 1.2 or higher and disables older, insecure protocols like SSLv3. 

**Step 3: Define authorization with RBAC.**
Alex creates three roles in Active Directory: 
- **Web Admins**: can stop/start the web service, update application files, and view logs.
- **Backup Operators**: can only run backup jobs and restore files.
- **Auditors**: can only read logs. 

He adds users to the appropriate groups. When a user logs in, the server checks the group membership and applies the corresponding access control entries (ACEs) to files and registry keys. A backup operator who accidentally tries to delete the web application gets an access denied error. 

**Step 4: Test the setup.**
Alex simulates attacks using a vulnerability scanner. He also tries to access the portal from a browser without a valid certificate — the browser shows a warning. He verifies that MFA is working by attempting login from an unauthorised device; the push notification fails. 

**Step 5: Monitor and maintain.**
Alex sets up certificate expiry alerts. Certificates typically last one to two years. He documents the renewal process. He also reviews authentication logs weekly to spot any brute-force attempts. If the server detects too many failed logins, an automatic script blocks the offending IP address. 

This real-world scenario shows that authentication, authorisation, and encryption are not just textbook concepts. Every day, IT professionals install certificates, configure permissions, enable MFA, and troubleshoot why a user cannot access a resource. For the SK0-005 exam, you must be able to walk through a similar process and choose the right tools and protocols.

## Exam focus

The SK0-005 exam (domain 2.0, objective 2.4) explicitly tests your ability to implement cryptographic protocols and configure authentication/authorisation. Expect roughly 8–12 questions on this topic across the exam. 

**What they love to test:**

- **SSL/TLS fundamentals**: Questions ask which protocol provides encrypted web traffic. They might give a scenario where a server needs secure remote administration — you must choose TLS (or SSH for Linux). Know that SSL is deprecated; TLS is the modern standard. 
- **Certificate lifecycle**: You may be asked where to install a certificate (on the server offering the service) or how to generate a CSR. The exam loves the concept of a certificate chain and what a root CA does. 
- **MFA methods**: Be ready to identify something-you-know, something-you-have, something-you-are from a list. For example, a smart card is "something you have"; a fingerprint is "something you are". 
- **RBAC vs DAC**: Role-Based Access Control vs Discretionary Access Control. RBAC uses centrally managed roles; DAC allows individual users to set permissions on their own files. The exam often presents a scenario where you need to choose the best model for a server environment — RBAC is almost always correct for large organisations. 
- **Authentication vs Authorization**: Classic trap. A question might say: "A user successfully logs in but cannot open a file. What is the issue?" The answer is authorisation failure, not authentication failure. 
- **Encryption algorithms**: They may ask about symmetric vs asymmetric examples. Symmetric: AES, DES, 3DES. Asymmetric: RSA, ECC. You do not need deep math, just recognise which is which. 
- **TLS handshake steps**: Not extremely detailed, but you should know the basic flow: client sends hello, server sends certificate, client verifies, key exchange happens, then encrypted communication. 

**Traps to avoid:**

- Confusing encryption with authentication. A certificate authenticates the server's identity, but it also enables encryption. The exam may ask which purpose a certificate serves — the correct answer often includes both. 
- Thinking that MFA replaces passwords. MFA adds an extra layer; passwords are still part of the process (except passwordless methods like FIDO2, but those are not covered heavily). 
- Believing that HTTPS uses encryption only. HTTPS uses TLS, which provides encryption, but also authenticates the server via its certificate. 
- Mixing up public and private keys. The private key is kept secret on the server; the public key is shared in the certificate. If a question says "which key is used to decrypt data sent to the server?", that is the private key. 
- Assuming all encryption is symmetric. TLS handshake uses asymmetric to exchange a symmetric session key, then uses symmetric for bulk data. 

**Key definitions to memorise:**

- **Authentication**: Verifying identity (username/password, MFA).
- **Authorization**: Granting access rights (permissions, groups).
- **Encryption**: Scrambling data so only authorised parties can read it.
- **SSL/TLS**: Protocols for secure network communication.
- **Certificate**: Digital document binding a public key to an entity, signed by a CA.
- **CA (Certificate Authority)**: Trusted entity that issues and signs certificates.
- **ACL (Access Control List)**: List of permissions attached to a resource.
- **RBAC**: Role-based access control using roles and group memberships.

## Step by step

1. **Authenticate to the server** — The user presents credentials (e.g., username and password). The server checks against its user database or directory service. If successful, the user is authenticated and receives a security token or session ID.
2. **The server evaluates authorisation rules** — When the user attempts to access a file or service, the server examines the resource's access control list (ACL). It compares the user's identity and group memberships against the ACEs (access control entries). If a matching rule grants access, the request proceeds; otherwise, access is denied.
3. **Establish an encrypted channel (if needed)** — For remote administration or web traffic, the server initiates a TLS handshake. The server presents its digital certificate, which the client verifies using the CA's public key. A symmetric session key is then exchanged using asymmetric encryption, and subsequent communication is encrypted with that key.
4. **Configure multi-factor authentication** — The administrator enables an MFA provider (e.g., Microsoft Entra ID with authenticator app). Users enrol their device. During login, after the password, the server sends a push notification or requires a time-based one-time password (TOTP). The user must approve or enter the code to complete authentication.
5. **Assign permissions via RBAC** — The administrator creates roles (e.g., backup operator, server admin) and assigns permissions to those roles. Users are then added to roles. The server enforces the role permissions automatically. This step ensures that only authorised users can perform specific administrative tasks.
6. **Monitor and audit access** — The server logs all authentication events and authorisation decisions. Administrators review logs for failed logins or access denied errors. They also set certificate expiry alerts. This ongoing process ensures the security configuration remains effective and compliant.

## Comparisons

### Authentication vs Authorization

**Authentication:**
- Verifies identity: 'Who are you?'
- Uses credentials like passwords, MFA, biometrics
- Occurs first in the access process

**Authorization:**
- Determines access rights: 'What can you do?'
- Uses permissions, ACLs, roles
- Occurs after authentication

### Symmetric Encryption vs Asymmetric Encryption

**Symmetric Encryption:**
- Uses one shared key for encrypt and decrypt
- Faster and suitable for bulk data
- Challenge: securely distributing the key

**Asymmetric Encryption:**
- Uses a public/private key pair
- Slower, used for key exchange and digital signatures
- Public key can be shared openly; private key is secret

### SSL (Deprecated) vs TLS (Modern)

**SSL (Deprecated):**
- Older protocol with known vulnerabilities (e.g., POODLE)
- Uses port 443 but version-dependent
- Not recommended for any new deployment

**TLS (Modern):**
- Current standard (TLS 1.2 and 1.3)
- Provides stronger encryption and perfect forward secrecy
- Required by modern security standards

### RBAC (Role-Based Access Control) vs DAC (Discretionary Access Control)

**RBAC (Role-Based Access Control):**
- Permissions assigned to roles, users added to roles
- Centrally managed by administrator
- Better for enterprise environments with many users

**DAC (Discretionary Access Control):**
- Resource owners set permissions individually
- Decentralised and flexible
- Used in personal systems or small workgroups

### Password Only vs Multi-Factor Authentication

**Password Only:**
- Single factor – something you know
- Vulnerable to theft, phishing, brute force
- Often insufficient for server access

**Multi-Factor Authentication:**
- Two or more factors: know, have, or are
- Significantly reduces risk of credential compromise
- Required for many compliance regulations (e.g., PCI DSS)

### Public Key vs Private Key

**Public Key:**
- Shared openly in a certificate
- Used to encrypt data or verify signatures
- Anyone can obtain it without compromising security

**Private Key:**
- Kept secret on the server or user device
- Used to decrypt data or create digital signatures
- If leaked, all encrypted data can be read

## Common misconceptions

- **Misconception:** Authentication and authorization are the same thing — once you log in, you can do anything. **Reality:** Authentication only confirms who you are. Authorization then determines what you are allowed to do. They are two separate steps. (The words sound similar and often appear together, so beginners merge them into one concept.)
- **Misconception:** Encryption alone guarantees that the person you are communicating with is who they claim to be. **Reality:** Encryption only protects the data from being read by eavesdroppers. It does not authenticate the other party — that requires a certificate or some other identity proof. (Movies often show 'encrypted messages' as secure, leading people to think encryption covers identity verification.)
- **Misconception:** A digital certificate is the same as an encryption key. **Reality:** A certificate is a container that holds a public key and identity information. It is signed by a CA. The actual encryption is performed using the keys, not the certificate itself. (The words 'certificate' and 'key' are used interchangeably in casual conversation, but they are different concepts.)
- **Misconception:** Multi-factor authentication (MFA) is optional and not necessary for server security. **Reality:** MFA is a critical defence against credential theft. For servers, especially those exposed to the internet, MFA is strongly recommended and often required by compliance standards. (Many beginners think a strong password is enough, ignoring that passwords can be phished or guessed.)
- **Misconception:** SSL and TLS are the same thing and can be used interchangeably. **Reality:** SSL is the older, deprecated protocol. TLS is the modern secure version. Modern systems should use TLS 1.2 or higher; SSL is considered insecure. (The terms are historically linked, and many people still say 'SSL' when they mean 'TLS'. The exam tests the distinction.)

## Key takeaways

- Authentication verifies identity; authorisation determines access rights; encryption protects data in transit and at rest.
- Multi-factor authentication combines two or more factors from something you know, have, or are to improve security.
- SSL/TLS certificates bind a public key to an identity and are signed by a trusted certificate authority.
- Role-based access control (RBAC) simplifies permission management by assigning permissions to roles and adding users to those roles.
- Access control lists (ACLs) define which users or groups can perform specific actions on a resource.
- The exam often tests the difference between authentication (login success) and authorisation (permission to access a resource).
- TLS is the modern replacement for SSL; always choose TLS for secure server communications.
- Public keys encrypt data that only the corresponding private key can decrypt; private keys must be kept secret on the server.

## FAQ

**What is the difference between authentication and authorization?**

Authentication confirms who you are (e.g., username and password). Authorization determines what you are allowed to do after you are authenticated (e.g., read or write a file).

**How does SSL/TLS work in simple terms?**

A client connects to a server. The server sends a digital certificate that proves its identity. The client and server then exchange keys using asymmetric encryption to create a shared session key, which is used to encrypt all subsequent data.

**What is a certificate authority (CA)?**

A CA is a trusted third party that issues digital certificates. It verifies the identity of the certificate requester and signs the certificate so clients can trust it.

**Do I need to encrypt data at rest on a server?**

Yes, to protect data if the physical drive is stolen or if an attacker gains low-level access. Technologies like BitLocker or LUKS encrypt entire volumes.

**What is Multi-Factor Authentication (MFA) and why is it important?**

MFA requires two or more verification factors (password + phone app, for example). It prevents attackers from logging in with a stolen password alone.

**What is an Access Control List (ACL)?**

An ACL is a list of permissions attached to a resource (file, folder, printer). It specifies which users or groups can perform actions like read, write, or execute.

**Is SSL still secure?**

No. SSL (all versions) is deprecated and has known vulnerabilities. Modern systems should use TLS 1.2 or higher.

---

Interactive version with quiz and diagrams: https://courseiva.com//learn/server-plus/authentication-authorization-and-encryption