CompTIA SY0-701: Identity & Access Management — Study Guide

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Part of the CompTIA Security+ SY0-701 — Complete Study Guide. Practice with verified answers in the CompTIA exam hub, or take timed practice tests on ExamRoll.io.

Identity and Access Management (IAM) is the discipline of ensuring that the right subjects — users, services, and devices — obtain the right access to the right resources at the right time, and only for as long as needed. It rests on two conceptually distinct pillars that are frequently, and dangerously, conflated: authentication, which proves who a subject is, and authorization, which determines what that authenticated subject may do. A user logging into a workstation with a fingerprint has authenticated; whether that user can open the payroll database is a matter of authorization. Any control design that blurs the two invites compromise.

Authentication Factors and Multi-Factor Authentication

Authentication factors are traditionally grouped into five categories: something you know (passwords, PINs), something you have (smart cards, hardware tokens, phones running TOTP apps), something you are (fingerprint, retina, facial geometry), somewhere you are (geolocation or network-based context), and something you do (behavioral biometrics such as typing cadence). Multi-factor authentication (MFA) requires evidence from at least two different categories. A password combined with a security question is not MFA — both are “something you know.” A password combined with a TOTP code from Google Authenticator is MFA.

Hardware tokens come in several forms. FIDO2/WebAuthn security keys such as YubiKeys use asymmetric cryptography: the private key never leaves the device, and the server holds only a public key, which defeats phishing and replay. HOTP tokens generate one-time passwords from a counter; TOTP tokens generate them from the current time using an HMAC-SHA1 construction:

TOTP = HMAC-SHA1(shared_secret, floor(current_unix_time / 30))

Smart cards, commonly PIV or CAC cards in government environments, store an X.509 certificate and private key on a tamper-resistant chip. Presentation of the card, combined with a PIN, satisfies two factors and enables certificate-based authentication to systems like Active Directory via Kerberos PKINIT.

MFA is the single most effective control against credential theft. When users report logins from IP addresses they did not originate, resetting passwords addresses the symptom; enforcing MFA addresses the root cause because a stolen password alone becomes insufficient.

Single Sign-On and Federation

Single sign-on (SSO) allows a user to authenticate once and access multiple applications without re-entering credentials. Federation extends this across organizational or trust boundaries — a user’s identity provider (IdP) in one domain vouches for the user to a service provider (SP) in another. The most common misconception here is treating SAML and OAuth as interchangeable; they solve different problems.

SAML 2.0 is an XML-based protocol designed for enterprise SSO and authentication assertions. When a user requests a SaaS application, the SP redirects the browser to the IdP, which authenticates the user and returns a signed SAML assertion containing identity attributes. This is the standard mechanism for allowing employees to access cloud applications like Salesforce or Workday using corporate Active Directory credentials.

OAuth 2.0 is an authorization framework, not an authentication protocol. It grants a third-party application delegated access to a resource on the user’s behalf via access tokens. Allowing an application to post to your Twitter feed is an OAuth flow. OpenID Connect (OIDC) is an identity layer built atop OAuth 2.0 that adds an id_token (a JWT) providing authentication assertions — this is what makes “Sign in with Google” possible.

A critical trap: SSO and federation reduce credential sprawl but do not remove the need for MFA. If anything, they concentrate risk — one compromised SSO credential now unlocks every federated application. MFA must be enforced at the IdP, and privileged accounts should require step-up authentication even after SSO.

Access Control Models

Once identity is established, an access control model governs authorization decisions. Discretionary Access Control (DAC) lets resource owners set permissions, typically via access control lists (ACLs). Mandatory Access Control (MAC) enforces policy centrally based on labels and clearances, common in military systems and enforced by frameworks like SELinux. Role-Based Access Control (RBAC) assigns permissions to roles and users to roles — a “Billing Analyst” role carries a defined permission set, and users inherit permissions by role membership. Attribute-Based Access Control (ABAC) evaluates policies against attributes of the subject, resource, action, and environment, enabling rules like “allow read access to HR files only during business hours from corporate-managed devices.”

Overlaying every model is the principle of least privilege: subjects receive only the minimum access necessary to perform their function, and no more. Complementary is separation of duties, which prevents any single individual from controlling an entire sensitive process — the person who requests a payment should not also approve it.

Practical access controls include file system ACLs, network ACLs on routers and firewalls, and time-of-day restrictions that permit login only during authorized hours. A Windows ACL entry granting read-only access to a finance share might read:

icacls C:\Finance /grant "Domain\Finance-RO:(OI)(CI)R"

Privileged Access Management

Privileged accounts — domain admins, root, database sysadmins, cloud root accounts, service accounts — are the crown jewels of any environment. Privileged Access Management (PAM) systems such as CyberArk, BeyondTrust, or HashiCorp Vault enforce controls around these accounts: credentials are vaulted and rotated automatically, sessions are recorded, checkout requires justification and often approval, and passwords are frequently one-time or ephemeral.

Just-in-time (JIT) access elevates privileges only for the duration of a specific task, eliminating standing admin rights. A developer who needs to run a database migration receives a time-limited credential that expires automatically after 30 minutes — there is no persistent privileged account to steal. Privileged Identity Management (PIM) in Azure AD implements this pattern natively, requiring approval workflows and MFA re-authentication before elevation.

Service accounts present a distinct challenge. They are often over-privileged, their passwords rarely rotated, and their usage rarely audited. Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs) in Active Directory automate password rotation and eliminate the need for humans to know service account credentials at all.

Directory Services and Provisioning

Active Directory (AD) remains the dominant on-premises identity store. Users, computers, and groups are organized into Organizational Units (OUs), and Group Policy Objects (GPOs) apply configuration and security settings hierarchically. AD trusts extend authentication across domains and forests. Azure Active Directory (Entra ID) extends these concepts to the cloud, adding conditional access policies, identity protection risk scoring, and seamless integration with thousands of SaaS applications.

LDAP (Lightweight Directory Access Protocol) is the underlying protocol for querying directory services. RADIUS centralizes authentication for network access — VPN, Wi-Fi, and 802.1X wired authentication all commonly authenticate against a RADIUS server backed by AD. TACACS+ serves a similar role for network device administration, with the added benefit of separating authentication, authorization, and accounting into distinct phases.

User provisioning and deprovisioning must be tightly coupled to HR processes. The most persistent IAM failure is the orphaned account — a former employee whose Active Directory account remains active weeks or months after departure. Automated provisioning via SCIM (System for Cross-domain Identity Management) or HR-to-AD connectors, combined with mandatory deprovisioning checklists, closes this gap.

Practical Scenario: Credential Compromise via Orphaned Account

A manufacturing company’s IT team discovered unusual after-hours access to its ERP system from a service account that had been created for a now-discontinued integration project. The account had domain user rights and had never been reviewed during quarterly access reviews because it was not associated with a named employee. An attacker who had purchased credentials from a dark-web dump used the account to enumerate file shares, exfiltrate pricing data, and establish a persistent foothold via a scheduled task. The breach was discovered only when the ERP vendor flagged anomalous API call patterns. The root cause was a failed deprovisioning process — the integration was decommissioned but the account was never disabled. Implementing a PAM system with automated discovery of orphaned accounts and mandatory review cycles would have surfaced the account long before it was exploited.

← Governance · All domains · Threats →

Practice these questions → · Timed practice on ExamRoll.io →