Authentication, authorization and compliance

Why this matters

The previous lesson covered proving who you are. This one covers what happens next: which directory or protocol carries that proof, what you are then permitted to do, and the regulatory framework that decides how much of this you are obliged to have.

The authentication protocols — RADIUS, TACACS+, LDAP, SAML — are asked about directly and are easily confused, because all four are involved in "logging in" in some sense and each does a different job.

The lesson

Single sign-on

Single sign-on (SSO) lets a user authenticate once and reach many systems without authenticating again. The user signs in to an identity provider, which issues a token that other applications accept.

The benefits are genuine on both sides. Users have one credential instead of twelve, so they stop reusing and writing down passwords. Administrators get one place to disable an account — which is the security argument: when someone leaves, one action removes their access everywhere, rather than twelve actions of which two get forgotten.

The cost is concentration. SSO makes that single credential far more valuable, which is exactly why SSO and MFA belong together: one credential protecting everything must be protected by more than a password.

RADIUS

RADIUS (Remote Authentication Dial-in User Service) is the standard AAA protocol for network access — the authentication server in the 802.1X model from the wireless lesson.

Its characteristics, and the exam tests these against TACACS+:

• Open standard, so it works across vendors.
• Runs over UDP.
• Encrypts only the password in the access request. The username, authorised services and accounting information travel in clear text.
• Combines authentication and authorization into one exchange — an access-accept carries both the fact of authentication and the attributes describing what is permitted.

Use it for network access: wireless, wired 802.1X, and VPN.

TACACS+

TACACS+ (Terminal Access Controller Access Control System Plus) is the counterpart, and the contrast is the examinable material:

• Cisco-developed (though widely implemented).
• Runs over TCP, so delivery is reliable.
• Encrypts the entire payload, not just the password.
• Separates authentication, authorization and accounting into independent functions.

That separation is what makes it the standard for device administration. It can authorise individual commands — a junior engineer may run show commands but not configure — and log every command entered. RADIUS cannot do that with anything like the same granularity.

The clean division to remember: RADIUS for network access, TACACS+ for device administration. If a question describes controlling what an administrator may type on a router, it is TACACS+.

LDAP

LDAP (Lightweight Directory Access Protocol) is not an authentication protocol in the same sense — it is a protocol for querying a directory, the organisation's structured database of users, groups, computers and their attributes. Microsoft's Active Directory is the most common implementation.

It appears in authentication because it is what the other systems look things up in: a RADIUS server typically validates credentials against LDAP, and applications query it for group membership to make authorization decisions.

It runs on TCP 389, and LDAPS on 636 wraps it in TLS. Plain LDAP carries credentials in clear text, so LDAPS is the correct choice on anything but an isolated management network.

SAML

Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between an identity provider and a service provider. It is the mechanism behind most enterprise web SSO, particularly to SaaS applications.

The flow: a user tries to reach an application (the service provider), which redirects them to the identity provider; they authenticate there; the identity provider returns a signed assertion stating who they are and what they may do; the application trusts the signature and grants access.

The property that matters: the application never sees the password. It sees a signed statement from a party it trusts. That is why a compromised SaaS vendor does not expose your directory credentials, and it is the usual exam angle.

Related and often offered alongside: OAuth, which is about authorization — granting an application limited access to a resource on your behalf — and OpenID Connect, an authentication layer built on OAuth. SAML and OIDC solve similar problems with different technology.

Authorization, least privilege and RBAC

Authorization is deciding what an authenticated identity may do. It follows authentication and is separate from it: proving who you are says nothing about what you may access.

Least privilege is the governing principle: every identity gets the minimum access required to do its job, and nothing more. It does not prevent compromise; it limits what a compromise reaches. An attacker with a compromised account inherits exactly that account's permissions, which is why over-permissioned accounts turn a small incident into a large one.

It applies to service accounts as much as to people — often more so, since service accounts are frequently given administrative rights for convenience and then never reviewed.

Role-based access control (RBAC) is how least privilege is made practical. Permissions are attached to roles rather than to individuals, and people are assigned roles. A new starter in finance gets the finance role and inherits the correct permissions; someone changing department has their role changed.

Why it beats per-user permissions: it is consistent, it is auditable — you can ask what a role permits rather than inspecting hundreds of accounts — and it handles staff changes without drift. Its failure mode is role creep, where people accumulate roles as they move around and nobody removes the old ones, which is what periodic access reviews exist to catch.

Time-based authentication restricts access to permitted periods — a contractor account that works only during business hours, or an elevated privilege granted for a two-hour maintenance window. It shrinks the window in which a stolen credential is usable, and an attempt outside the window is itself a useful alert.

Geofencing restricts access by location, using GPS, IP geolocation or network position. A common policy blocks or challenges authentication from countries where the organisation has no staff. It is a blunt control — a VPN defeats it trivially — so it is best treated as one signal among several in the policy-based authentication described in the zero-trust lesson, rather than a boundary on its own.

Common security terminology: risk

The exam uses a small, precise vocabulary, and mixing the terms up costs marks.

• A vulnerability is a weakness — an unpatched service, a default password.
• A threat is something that could exploit it — an attacker, malware, a flood.
• Risk is the combination: the likelihood that a threat exploits a vulnerability, multiplied by the impact if it does.

The practical consequence is that risk is what gets managed, because it is the only one of the three that accounts for consequence. A critical vulnerability on an isolated lab machine is low risk; a moderate one on an internet-facing payment system is not.

The four responses are named consistently across CompTIA's exams:

• Mitigate — reduce it, by patching or adding a control.
• Transfer — move it to someone else, typically insurance or a supplier contract.
• Avoid — stop doing the thing that creates it.
• Accept — decide it is tolerable and document that decision.

Accepting a risk is a legitimate answer, provided it is explicit and recorded. An undocumented acceptance is not risk management; it is an oversight waiting to be found by an auditor.

Audits and regulatory compliance

Audits and regulatory compliance is the obligation to meet external standards and to be able to prove it.

The frameworks that come up: PCI DSS for payment card data, HIPAA for health information in the US, GDPR for personal data of people in the EU, and SOX for financial reporting.

They drive concrete network requirements — segmenting cardholder systems, encrypting personal data in transit and at rest, retaining logs for a defined period, restricting and reviewing access — which is why they appear in a networking exam at all.

An audit verifies that the controls exist and work. Internal audits are preparation; external audits are the ones with consequences. Both run on evidence, which is the practical link back to domain 3: documentation, configuration records, access reviews and logs are what an audit consumes, and an organisation that keeps them well is audited easily.

Data locality — sometimes called data residency or sovereignty — is the requirement that data be stored and processed within a particular jurisdiction. GDPR constrains transfers of personal data outside the EU; various countries require citizen data to remain in-country.

For a network engineer this is a real design constraint rather than a legal abstraction: it determines which cloud regions may be used, where backups and DR sites may be located, and whether traffic may be routed or inspected abroad. A DR plan that replicates to a region in another jurisdiction can be technically excellent and legally unusable, and that is exactly how the exam frames it.