Listen to this Post
Introduction:
Authentication is the process of proving who you are—but on a network, that’s surprisingly difficult. Anyone can eavesdrop, replay credentials, or impersonate a legitimate user. Over decades, the industry has developed a layered ecosystem of authentication protocols, each designed for specific use cases: network entry, centralized access control, internal directory services, and web-based single sign-on. Understanding how these protocols complement rather than compete with each other is essential for any cybersecurity professional, particularly for CISSP candidates who must distinguish between protocol purpose, server implementation, and proper use cases.
Learning Objectives:
- Distinguish between authentication, authorization, and accounting protocols across network, internal, and web domains
- Understand the relationship between complementary protocols (e.g., Kerberos + LDAP, EAP + RADIUS, SAML/OIDC vs. OAuth)
- Apply practical configuration commands for RADIUS, Kerberos, LDAP, and TACACS+ in Linux and network environments
- Network Entry Protocols: EAP, RADIUS, TACACS+, and DIAMETER
When you connect to a corporate Wi-Fi network, your device doesn’t authenticate directly with the access point. Instead, the Extensible Authentication Protocol (EAP) carries your credentials, while RADIUS (Remote Authentication Dial-In User Service) transports that authentication request to a central server that makes the final decision. This separation of duties is critical: EAP “presents” your identity, RADIUS “transports” it for validation.
Step‑by‑step guide: Setting up a FreeRADIUS server on Ubuntu
FreeRADIUS is the most widely used open-source RADIUS server, supporting multiple backends including flat files, SQL, and LDAP.
1. Install FreeRADIUS:
sudo apt update sudo apt install freeradius freeradius-utils
- Configure RADIUS clients (e.g., your Wi-Fi controller or switch) in
/etc/freeradius/3.0/clients.conf:client wlan_controller { ipaddr = 192.168.1.100 secret = your_shared_secret shortname = wlc }
3. Add users in `/etc/freeradius/3.0/users`:
user1 Cleartext-Password := "password123" user2 Cleartext-Password := "securepass"
4. Test authentication using the RADIUS test utility:
radtest user1 password123 localhost 0 testing123
A successful response returns `Access-Accept`.
TACACS+ (Terminal Access Controller Access-Control System Plus) serves a different purpose. While RADIUS combines authentication and authorization in a single packet, TACACS+ separates these functions and encrypts the entire payload, not just the password. It’s the protocol of choice for network device administration—configuring routers, switches, and firewalls.
Cisco TACACS+ configuration example:
configure terminal aaa new-model aaa authentication login default group tacacs+ local tacacs-server host 192.168.1.50 tacacs-server key 7 "your_secret_key"
This configures the device to attempt TACACS+ authentication first, falling back to the local database if the server is unreachable.
DIAMETER is the evolution of RADIUS, designed for 4G/5G mobile networks and IP multimedia subsystems. It adds reliability, better error handling, and support for roaming, but it’s rarely encountered outside telecom environments.
Windows equivalent: Network Policy Server (NPS) is Microsoft’s RADIUS server implementation, configurable through the Server Manager GUI or PowerShell.
2. Internal Authentication: Kerberos and LDAP
At 8:05 AM, you log into your Windows workstation. You type your password once, and Kerberos issues a ticket-granting ticket (TGT). For the rest of the day, that ticket authenticates you to every internal service without re-entering credentials.
Kerberos verifies who you are. But to know what you’re authorized to do, it consults LDAP (Lightweight Directory Access Protocol)—the directory that stores user attributes, group memberships, and permissions. Kerberos is the authentication mechanism; LDAP is the database it queries.
Step‑by‑step guide: Working with Kerberos on Linux
1. Install Kerberos client utilities:
sudo apt install krb5-user
2. Obtain a ticket-granting ticket:
kinit [email protected]
You’ll be prompted for your password. The password never traverses the network after this initial step.
3. List your active tickets:
klist
This displays the TGT and any service tickets you’ve acquired.
4. Destroy your ticket cache when done:
kdestroy
- For automated service authentication using a keytab file:
kinit -k -t /etc/krb5.keytab service/[email protected]
LDAP authentication from the command line:
The `ldapsearch` command can query and authenticate against an LDAP directory:
ldapsearch -x -H ldap://ldap.example.com -D "cn=admin,dc=example,dc=com" -W -b "dc=example,dc=com" "(objectClass=user)"
-x: Use simple authentication (non-SASL)-H: LDAP server URI-D: Bind DN (the user authenticating)-W: Prompt for password-b: Search base DN
For LDAPS (secure LDAP over TLS):
LDAPTLS_CACERT=/etc/ssl/certs/ca-certificates.crt ldapsearch -H ldaps://ldap.example.com:636 -D "cn=admin,dc=example,dc=com" -W -b "dc=example,dc=com" "(&(objectClass=person)(cn=John))"
Windows equivalent: Active Directory uses Kerberos as its primary authentication protocol and LDAP as its directory service. Commands like `klist` and `ktpass` are available in Windows through the built-in Kerberos tools.
- Single Sign-On (SSO): Kerberos for Internal, SAML/OIDC for External
Throughout the morning, you open ten internal applications—none ask for your password again. Your Kerberos ticket handles them all. This is internal SSO: prove your identity once, access everything inside the corporate perimeter.
But at 2 PM, you connect to an external tool. Kerberos stops working because that service isn’t in your domain. Now your organization certifies your identity using SAML (Security Assertion Markup Language) or OpenID Connect (OIDC) . The external tool trusts your identity provider and lets you in.
SAML vs. OIDC vs. OAuth—the critical distinction:
- SAML and OIDC prove who you are (authentication)
- OAuth grants access without proving identity (authorization)
When you authorize a third-party app to read your Google Drive files without giving it your password, that’s OAuth. It issues an access token with specific scopes—it doesn’t authenticate you; it authorizes the app.
Step‑by‑step guide: OIDC/OAuth 2.0 application registration (generic)
- Access your identity provider’s admin console (e.g., Microsoft Entra ID, Okta, or a custom OIDC provider).
2. Create a new application registration:
- Set the application type to “Web application”
- Configure redirect URIs (e.g., `https://yourapp.com/callback`)
- Note the Client ID and Client Secret generated.
- Configure allowed grant types—for OIDC, enable “Authorization Code” and “Refresh Token” flows.
- For SAML integration, upload your service provider metadata or manually configure the ACS URL and Entity ID.
4. Protocol vs. Server: Never Confuse the Two
One of the most common mistakes in security exams and real-world implementations is confusing the protocol with the server that implements it:
| Protocol | Server Implementation |
|-|-|
| RADIUS | FreeRADIUS, Microsoft NPS, Cisco ISE |
| Kerberos | Microsoft Active Directory KDC, MIT Kerberos |
| LDAP | OpenLDAP, Microsoft Active Directory, 389 Directory Server |
| TACACS+ | Cisco ACS, Tac_plus (open-source) |
RADIUS is the protocol; the RADIUS server is the machine running it. Kerberos is the protocol; the KDC (Key Distribution Center) is the server. This distinction matters for troubleshooting, architecture design, and exam preparation.
- The Authentication Workflow: A Full Day in the Life
Follow the authentication thread through a typical workday:
| Time | Action | Protocol(s) |
||–|-|
| 8:00 AM | Connect to corporate Wi-Fi | EAP (presentation) + RADIUS (transport) |
| 8:05 AM | Log into Windows workstation | Kerberos (TGT issuance) + LDAP (directory lookup) |
| 8:05 AM–12:00 PM | Open internal apps | Kerberos (service tickets) |
| 2:00 PM | Access external SaaS tool | SAML or OIDC (identity assertion) |
| 2:05 PM | Authorize app to read calendar | OAuth 2.0 (access delegation) |
| Ongoing | Network admin configures router | TACACS+ (device administration) |
PAP and CHAP are the ancestors of EAP—largely obsolete today but still tested in certification exams. PAP sends passwords in cleartext; CHAP uses a challenge-response mechanism but is vulnerable to modern attacks.
6. Hardening and Security Considerations
- RADIUS: Always use RADIUS over TLS (RadSec) to encrypt the entire authentication flow, not just the password.
- Kerberos: Set short ticket lifetimes and enforce renewable tickets. Monitor for Kerberoasting attacks—offline brute-forcing of service account passwords.
- LDAP: Use LDAPS or STARTTLS to encrypt queries. Implement access controls to prevent anonymous binds.
- OAuth: Use PKCE (Proof Key for Code Exchange) for public clients and enforce scope restrictions. Rotate refresh tokens regularly.
- SAML: Validate signatures and enforce encryption of assertions. Use short validity windows for SAML responses.
What Undercode Say:
- Key Takeaway 1: Authentication protocols are not competitors—they are complementary layers in a defense-in-depth strategy. EAP presents, RADIUS transports, Kerberos verifies, LDAP stores, and SAML/OIDC federates. Each has a specific role, and a typical enterprise uses nearly all of them in a single day.
-
Key Takeaway 2: The most common pitfall is confusing protocol purpose with protocol implementation. OAuth is authorization, not authentication. SAML and OIDC are authentication protocols. RADIUS is a protocol; FreeRADIUS is a server. Understanding these distinctions is what separates a security practitioner from a certification-only candidate.
Analysis: The original post brilliantly maps authentication protocols to real-world scenarios, making abstract concepts tangible. The key insight is that these protocols form a relay chain—each hands off to the next based on context (network vs. internal vs. web). This layered approach is why modern identity and access management (IAM) is so robust. For CISSP candidates, the post highlights a frequent exam trap: assuming protocols compete when they actually cooperate. The practical commands and configuration examples provided here extend that knowledge into actionable skills—essential for both exam success and real-world implementation. The growing adoption of zero-trust architectures will only increase the importance of understanding these protocols, as continuous authentication and fine-grained authorization become the norm.
Prediction:
- +1 The convergence of OIDC and SAML through federation gateways will simplify hybrid identity management, reducing the friction of managing multiple authentication silos.
- +1 Passwordless authentication (WebAuthn, FIDO2) will increasingly overlay these protocols, eliminating the weakest link while preserving the underlying authentication flows.
- -1 The complexity of managing 11+ authentication protocols across cloud and on-premises environments will drive demand for IAM platforms that abstract protocol details—but will also create new single points of failure and vendor lock-in risks.
- -1 As quantum computing advances, the cryptographic foundations of Kerberos and SAML will require urgent upgrades to post-quantum algorithms, potentially breaking backward compatibility.
- +1 AI-driven anomaly detection will integrate with these protocols to provide real-time risk-based authentication, making static protocol configurations obsolete in favor of adaptive, context-aware access decisions.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Biren Bastien – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
