Identity and Access Management Implementation

The meeting after the incident

The contractor had been gone for eleven days, and on day twelve they logged in from home and downloaded the archive. Nothing exotic: no exploit, no insider tool, no leaked administrator password. They used their own username, their own password, and a VPN account that the operations team had simply forgotten to close. The post-incident meeting did not go looking for a villain. It went looking for the process that was supposed to make that login impossible, and it found three gaps stacked on top of each other. The VPN directory had never been told the contractor left. The SaaS analytics platform had never been told the VPN directory existed. And nobody had ever scheduled a moment when the two were forced to compare themselves.

That is the real subject of IAM implementation. Not the widgets, the vaults, and the token services. Those exist to answer one question, repeated for every system in the estate: who is allowed to be here right now, and how do we know that answer is true? Chapter 19 gave you the grammar of identity: the four-step process, the factors, the models, the administration shapes. This chapter is the usage. It is about the machinery that makes the grammar run day after day: the lifecycle that creates and destroys identities, the directory that stores them, the federation protocols that carry them between organizations, the provisioning channel that keeps systems in sync, and the privileged access layer that handles the accounts nobody should have.

I have operated identity infrastructure in places with three hundred users and places with a hundred thousand. The failure modes are the same at both scales. They are rarely cryptographic. They are almost always the same three things: identities that outlive their people, systems that never learned about each other, and privilege that was granted once and never revisited. Every control in this chapter is a countermeasure against one of those three. If you remember nothing else, remember that the exam’s identity implementation questions are stories about one of those three gaps wearing a different costume each time.

The lifecycle: joiner, mover, leaver

Identities are born, they change, and they die. The discipline of managing all three moments is the identity lifecycle, and in the industry shorthand it is called joiner, mover, leaver, or JML. The exam will not use the acronym, but it will hand you scenarios that are pure lifecycle stories, and the answer is always the control that belongs to the moment the scenario is about.

The joiner moment is the creation of an identity for a new person. It looks administrative, but it is a security event, because everything downstream inherits the decisions made here. The person must be proofed before they are provisioned: something must establish that the person is who they claim to be and that the role they are about to receive is actually theirs. NIST SP 800-63A-4, the identity proofing guideline, grades this with identity assurance levels, IAL1 through IAL3, and the level you choose decides how much evidence you demand. IAL2, the level most organizations aim for in practice, requires the person to provide evidence that their identity information is valid and to prove that they are the owner of that evidence, typically through a document check plus a liveness-checked photo or an equivalent remote process. Provisioning before proofing is how you get an account that belongs to a ghost. The joiner control is not “create the account quickly,” it is “create the account after proof, with the minimum rights the job actually requires,” which is least privilege applied at the moment of birth. ISO/IEC 27001:2022 Annex A control A.5.16, identity management, says it plainly: the full lifecycle of identities for personnel and third parties must be managed. “Third parties” is the phrase that matters, because contractors and consultants are where lifecycle discipline dies.

The mover moment is a change of role: a promotion, a transfer, a department change, a project ending. In role-based access control, the mover is a role-assignment change, and the danger is that nobody makes it. The employee who transferred from accounts payable to sales six months ago still carries the payment-approval role, not because anyone wanted them to, but because the transfer ticket never mentioned access. The mover control is the re-certification: when the role changes, the access changes with it, and the change itself is reviewed. NIST SP 800-53, the security and privacy control catalog, treats this under account management, AC-2, which requires the organization to manage the lifecycle of accounts, review them, and remove or disable them when they are no longer needed. The review is the load-bearing part. An access review is a periodic, documented exercise in which an owner of each system attests, account by account, that every identity on the list is still a real person who still has the right reason to be there. ISO/IEC 27001:2022 Annex A control A.5.18, access rights, requires exactly this: access rights are defined and managed, and they are reviewed at defined intervals. The exam loves the review for a reason: it is the control that converts “we intended to have least privilege” into “we know we have least privilege.”

The leaver moment is the one that gets the most exam questions, because it is the most visible failure. A leaver is an employee who resigns, is fired, retires, or is a contractor whose engagement ends. The lifecycle answer is a strict sequence: revoke access, review what was revoked, and remove the account, then verify the revocation took effect. NIST SP 800-53 control AC-2(3) says it as a requirement: disable accounts within an organization-defined time period when the accounts are no longer associated with a user, when access privileges are revoked, or when access is no longer required. Note the shape of that control. It does not say “when the person is fired.” It says when the account’s reason to exist has ended, which is a much broader trigger, and it covers the contractor whose contract lapsed, the intern whose program ended, and the vendor whose project closed. The verification step is the part that gets skipped: the directory shows the account disabled, but the application kept its own copy of the user, and the application is the one the attacker used. Termination of a third party is also its own control in the 27001 Annex A: control 6.5 covers responsibilities after termination or change of employment, which is the HR side of the same coin.

Two lifecycle pathologies deserve their own names, because the exam uses them as answer choices. An orphan account is an account whose owner no longer exists in the source of truth, the HR system or the master directory, but which still exists in some system and may still be active. A ghost account, sometimes called a shadow account, is an account that was never registered in the central identity store at all, because it was created directly in an application by an administrator who wanted to skip the process. Both are the same disease: a gap between the systems that should know about an identity and the systems that actually do. The medicine is the same: an authoritative source of truth plus a reconciliation process that compares every system’s account list against it, periodically, and flags anything that should not be there. NIST SP 800-53 AC-2(9) targets one flavor, restricting the use of shared and group accounts and terminating their credentials when members leave, because a shared account has no single owner to revoke, which is precisely why it is a lifecycle hazard.

The service account deserves a paragraph of its own, because service accounts break the joiner-mover-leaver model. A service account is an identity used by software rather than by a person: an application that reads a database, a backup job that mounts storage, an API consumer. It has no person, so it has no firing, no resignation, and no one whose bad day triggers a revocation. Its password is a long random string that nobody types and everybody forgets to rotate. The lifecycle answer is to treat service accounts as assets with owners, expiration, and rotation: an owner named in the directory, a review on the same cadence as human accounts, and credentials rotated on a schedule or by policy rather than by memory. NIST SP 800-53 AC-6(9) contributes the audit side, requiring that use of privileged functions be audited, which is how you find out that a service account is doing more than its job description.

The directory: one tree to rule them

The directory is where identities live, and almost every organization ends up with one or two of them doing the real work. The architecture underneath is older than most of the people who administer it, and it is worth understanding from the ground up, because the exam’s directory questions are structural.

The ancestor is X.500, the ITU-T directory standard, which defined a hierarchical tree of entries: countries at the top, organizations below them, organizational units and people below that. X.500 is powerful and heavy, and LDAP, the Lightweight Directory Access Protocol, was designed in RFC 4511 as a lighter way to read and write that same tree. The tree itself is the directory information tree, the DIT. Every entry in the tree is a node: a person, a group, a printer, an organizational unit. Every entry has a name that locates it in the tree, the distinguished name, DN, which is built from the path from the root down: the entry cn=jdoe sits under ou=People, which sits under dc=example, dc=com, so the DN is cn=jdoe,ou=People,dc=example,dc=com. Read the DN and you know exactly where in the tree the entry hangs. Each entry carries attributes defined by an object class, and the object classes and attribute definitions are the schema, the rules that say which entries may exist and what they may contain. This is why a directory is not a database. A relational database has no idea what cn means. The directory’s whole job is to know, structurally, that entries are people and groups and printers, arranged in a hierarchy, addressable by name.

Two operational facts about LDAP matter for the exam and for real life. First, the protocol itself does not encrypt anything by default. Plain LDAP runs on port 389, and everything in it, including the bind, the authentication exchange, can travel in the clear. The secure variants are LDAPS on port 636, which wraps the whole conversation in TLS, and STARTTLS per RFC 4513, which upgrades a plain connection on 389 to TLS at the application’s request. An exam scenario about “the directory is sending credentials across the network unprotected” is a scenario about LDAP without TLS, and the answer is LDAPS or STARTTLS, not a new database. Second, directories are read-heavy and hierarchical, and they scale through replication, not through a single enormous server. Microsoft Active Directory, the default exam example and the most common enterprise directory, is LDAP and Kerberos bolted together: LDAP for the tree and the queries, Kerberos for authentication, with domain controllers replicating the tree among themselves. The replication is what makes the directory both powerful and fragile: a directory that cannot replicate is a directory that goes stale, and a directory whose replicas disagree is a directory that is lying to half its clients.

The directory is also the crown jewel, and the exam wants you to see it as one. Every system that authenticates against it trusts it, so the directory is the single highest-value target in the identity estate: compromise the directory and you control every account it serves. That is why directory access is locked down with its own access control, why directory changes are logged and reviewed, and why the exam treats “the administrator of the directory” as a role with more responsibility than any other system administrator. Centralization is a risk trade, as Chapter 19 noted: one store to keep consistent, one store to protect.

The directory raises the question every identity implementation has to answer: what is the source of truth? In a well-run organization, one system is authoritative for each fact about a person. HR is authoritative for who is employed, the directory is authoritative for which accounts exist, and the finance system is authoritative for who is on the payroll. The sin is letting every application be its own source of truth, which is how identity silos form: the CRM keeps its own user table, the analytics platform keeps its own, the file server keeps its own, and nobody reconciles them. The fix is an identity governance layer, sometimes a commercial IAM suite, that reads the authoritative sources, decides what each system should contain, and pushes the decisions out. The technical channel for that push, in the modern world, is SCIM, which this chapter covers later. The managerial habit that makes it work is the same reconciliation review from the lifecycle section: compare, periodically, and audit the comparison.

Trust, borrowed and earned: federation

Federation is the answer to a specific problem: an organization that must let outsiders in and its people out, without creating a separate account for every person in every system. The idea is that each organization keeps its own identity store and its own authentication, and the organizations trust each other’s assertions. You authenticate at your own company, and my application accepts your company’s word that you are you. The product of federation is not a protocol. It is a trust relationship, and everything security-relevant in federation is about the shape of that trust.

The vocabulary is fixed. The identity provider, IdP, is the party that authenticates the user and asserts who they are. The service provider, SP, is the party that consumes the assertion and decides what the user may do. One IdP can serve many SPs, which is how a single login becomes single sign-on, SSO: authenticate once at the IdP, and every SP that trusts the IdP accepts the session. The user experience is the visible benefit, but the security property is the actual product: the user’s credentials are presented to exactly one party, the IdP, so the SP never handles passwords, and an attacker who compromises an SP gets applications, not credentials.

The trust relationship has to be engineered, and the engineering is metadata plus signatures. The IdP and the SP exchange metadata, XML documents that describe each other: endpoints, certificate keys, supported profiles. The SP must know the IdP’s signing key, so that it can verify the assertion actually came from the IdP and not from someone pretending to be it. The IdP must know which SPs it serves, so that it does not hand out assertions to strangers. When the exam describes “an assertion accepted without verifying the signature” or “a new SP added to the trust relationship without exchanging keys,” it is describing a trust failure, and the correct answer is the metadata and key exchange that was skipped.

Federation concentrates risk exactly the way SSO does. The IdP becomes a single choke point: if the IdP is breached or if its sessions are stealable, every SP in the federation inherits the damage. That is why the IdP is held to the highest assurance standards, why its own authentication is multi-factor, and why the exam pairs “we federated everything” with “so we hardened the identity provider and monitor its authentication events like a critical asset.” Federation is not a way to avoid security work. It is a way to move security work to one place where it can be done well.

One more shape belongs to this section, because the exam draws a line between them. Enterprise SSO, sometimes called legacy SSO, is single sign-on inside a single organization’s boundary, typically powered by Kerberos, and it assumes the participating systems already trust the same directory. Federated SSO crosses organizational boundaries, and it is powered by SAML or OpenID Connect. The distinction matters when a question offers “the partner company’s users need access to our portal” as the scenario: that is federation, because there is no shared directory between the two companies, and no amount of enterprise SSO will create one. The protocols that carry each kind are the subject of the next three sections.

Kerberos: the protocol behind the curtain

Kerberos, RFC 4120, is the oldest of the identity protocols in this chapter and the most quietly present: it is the default authentication protocol in Active Directory, which means most enterprise readers have authenticated through it today without knowing it. Chapter 19 introduced the cast of characters, the KDC with its two services, the AS and the TGS, and the tickets. This section is about how the machinery actually runs, because the exam’s Kerberos questions are about the flow, not the characters.

The first exchange gets the user a ticket-granting ticket. The client sends an AS request containing the user’s identity and a pre-authentication value, a proof that the user knows the secret, typically a timestamp encrypted with the user’s password-derived key. The KDC checks the proof, and if it is good, it returns a TGT plus a session key, all encrypted so that only the legitimate client can read it. The user now holds a ticket that says, in effect, “this user proved their identity to the KDC, and may request service tickets for a while.” The TGT has a lifetime, usually measured in hours, and it can be renewable under policy.

The second exchange gets the user into a specific service. The client presents the TGT to the TGS and asks for a ticket to a named service, such as the file server or the mail server. The TGS issues a service ticket, encrypted with the service’s key, containing another session key for the client and service to use with each other. The client presents the service ticket to the service, and the service can decrypt it, because the service shares a key with the KDC. That is the elegant core: neither the client nor the service ever sends a password, because both possess keys or tickets issued by the KDC, and the KDC is the only party that holds everyone’s long-term keys.

The replay defense is timestamps. Tickets and requests carry time information, and the KDC and the services check it against their own clocks within a tolerance, the clock skew, typically a few minutes. A captured request that is replayed later fails the time check. This is why the exam pairs Kerberos with “the clock must be synchronized,” and why a domain with wildly skewed clocks has mysterious authentication failures: time is not incidental to Kerberos, it is part of the security mechanism.

In practice, applications do not speak Kerberos directly. The web browser and the web server negotiate through SPNEGO, the Simple and Protected GSSAPI Negotiation Mechanism, RFC 4178, which lets the client and server agree on a security mechanism, usually Kerberos, and then carry the Kerberos exchange inside an HTTP conversation. This is how a user signs into a corporate workstation and then opens internal web applications without typing credentials again: the browser has a TGT, SPNEGO negotiates Kerberos for each site, and the site’s service principal authenticates the session. The SPN, the service principal name, is the identity the service presents in the directory, which is why the exam treats “the application’s service principal name is missing or wrong” as a real Kerberos failure mode.

The attack family is the reason the exam cares. Pass-the-ticket replays a captured ticket. Pass-the-hash uses the NT hash of a password, extracted from a compromised machine, to authenticate as that user without knowing the password. The golden ticket is a forged TGT, created with the key material of the krbtgt account, the KDC’s own account, which lets the attacker mint tickets for anyone, including accounts that do not exist, until the krbtgt password is reset twice. The silver ticket is the smaller cousin, a forged service ticket minted with the key material of a specific service account, granting access to just that service. The management lesson the exam draws from the whole family: Kerberos is strong against network attackers who lack domain access, and it is only as strong as the machines that hold key material, because a foothold in the domain turns the protocol into an accomplice. This is why Kerberos deployment hygiene, clock sync, service account key rotation, and monitoring for anomalous ticket requests, is a security program, not an operations chore.

SAML: the XML assertion of trust

SAML, the Security Assertion Markup Language, version 2.0, is the OASIS standard that defined federated web single sign-on for a generation, and it is still the default for enterprise-to-enterprise federation. Its job is to carry the trust relationship this chapter described earlier in a concrete form: an XML document called an assertion, produced by the IdP and consumed by the SP.

The assertion is the product. It names the subject, the user, in a name identifier such as an email address or a persistent ID. It carries a conditions block, which contains validity, the assertion is good from this time until that time, and audience restrictions, which state which SP the assertion is for. It carries an authentication statement, a record that the subject authenticated at a particular time by a particular method, which is what lets the SP know it is a session, not just a name. It may carry an attribute statement, a set of attributes about the user, such as department, role, or membership in a group, which the SP can use for authorization without running its own directory. The whole assertion is signed by the IdP, which is the trust anchor: the SP verifies the signature against the IdP’s key from the exchanged metadata, checks the validity window, checks the audience, and only then creates a session.

The flow has two shapes, and the exam distinguishes them. SP-initiated SSO starts at the SP: the user tries to reach a resource, the SP does not know them, so it redirects the user to the IdP with an authentication request. The user authenticates at the IdP, the IdP builds the assertion and returns it, and the SP validates it and admits the user. IdP-initiated SSO starts at the IdP, which is how a portal page with a list of applications works: the user signs into the IdP, picks an application, and the IdP posts an unsolicited assertion to that application, which validates and admits. The transports are the SAML bindings: HTTP Redirect for the request, HTTP POST for the assertion, and the Artifact binding, which passes a small reference that the SP resolves back to the IdP over a back channel, for cases where the assertion is too large for a URL or the browser should not carry it. Single logout, SLO, is the protocol’s answer to “the user closed the session”: the IdP propagates the logout to every SP in the session, which is notoriously hard to get right and is a favorite exam scenario for “the user logged out of the IdP but the application session is still alive.”

The attack surface is XML, and the exam knows the classics. Signature stripping removes the signature from the assertion or removes the assertion element the signature covers, and the fix is to validate the signature over the full content, not to skip validation when a signature is absent. XML wrapping smuggles attacker content into a structure the signature does not cover, and the fix is to parse the signed content, not the unsigned envelope. Replay submits a previously captured valid assertion, and the fix is to track assertion IDs and reject repeats, plus the validity window already in the assertion. The lesson that ties the section together: SAML’s security is not in the XML, it is in the validation discipline of the SP, and the exam rewards the SP that verifies signature, validity, audience, and freshness before trusting a single attribute.

OAuth 2.0 and OpenID Connect: tokens for the API age

SAML was designed for a world where the browser is the application and XML is the format. OAuth 2.0, RFC 6749, was designed for the world where applications are software, data lives in APIs, and the token is the currency. It is an authorization framework, not an authentication protocol: its job is to let a client obtain access to resources on a user’s behalf without ever seeing the user’s credentials. The distinction is the first thing the exam tests, so hold it: OAuth grants access, it does not prove identity. Identity is layered on top by OpenID Connect, and the two together are the modern web and mobile stack.

The OAuth 2.0 cast has four roles. The resource owner is the user who owns the data. The client is the application that wants the data. The authorization server is the party that authenticates the resource owner and issues tokens. The resource server is the API that holds the data and accepts the tokens. The grant is the mechanism by which the client obtains a token, and the standard defines a small set, each built for a different client shape. The authorization code grant is for applications with their own backend: the client redirects the user to the authorization server, the user authenticates and consents, the authorization server returns a code to the client’s backend, and the backend exchanges the code for tokens, which keeps the tokens away from the browser entirely. For native and single-page applications, the public clients, the code grant is used with PKCE, the Proof Key for Code Exchange of RFC 7636, which adds a per-request verifier that protects the code exchange against interception, so a client that cannot keep a secret is not forced to pretend it has one. The client credentials grant is for machine-to-machine communication, where there is no user at all: the client presents its own credentials to the authorization server and receives a token in its own name. The resource owner password credentials grant, where the client collects the user’s password and passes it along, exists in the standard and is discouraged in current security guidance, because it puts credentials where OAuth exists to avoid them.

Two more objects complete the vocabulary. Scopes, RFC 6749 section 3.3, are the granular permissions the client requests and the user consents to: read the calendar, write the contacts, nothing else. Scopes are how OAuth implements least privilege at the API layer, and a client that asks for full account access when it only needs to read a calendar is a client to reject. The refresh token is the long-lived credential that the client keeps server-side and exchanges for new access tokens when the short-lived access token expires, which is how a mobile app stays authorized for weeks without asking the user to log in again, and why a stolen refresh token is a serious incident. The access token itself, in its most common form, is a bearer token per RFC 6750: any party that possesses it can use it, which means it must travel only over protected channels and must never be logged, embedded in a URL, or stored where an attacker can read it.

The authorization code flow has a hygiene checklist the exam loves. The state parameter, which the client generates and checks on return, binds the redirect back to the original session and defeats CSRF, so a login can be replayed into someone else’s account. The redirect URI is validated exactly, because an attacker who can make the client send the code to their own endpoint has won. PKCE binds the code exchange to the requesting client. The token is never exposed to the browser in the code flow. Read the checklist as a set, because the exam presents its failures one at a time: “the app accepted a code from a different redirect URI,” “the app did not check the state parameter,” “the app stored the bearer token in a URL.”

OpenID Connect, OIDC, defined by the OpenID Foundation, is OAuth 2.0 with an authentication layer. It adds the openid scope, which the client must request, and it adds a new token type, the ID token, which is the identity statement: a JWT that tells the client who the user is. The ID token carries registered claims: iss, the issuer; sub, the subject, the user’s unique identifier at the issuer; aud, the audience, which must include the client; exp, the expiry; iat, the issued-at time. The client validates the ID token’s signature, issuer, audience, and freshness, and it can optionally fetch more profile claims from the userinfo endpoint with the access token. Discovery, the OpenID Connect Discovery document at the provider’s well-known configuration URL, lets clients learn the provider’s endpoints and key material automatically, which is how modern sign-in buttons connect without hand-carried metadata. The architecture is now clean enough to state in one line: OAuth issues tokens that grant access to APIs, OIDC adds a signed identity token so the client knows who the user is, and the two are used together, which is why the exam treats “an OAuth token used to prove identity” as a confusion of the two layers.

The JWT itself, RFC 7519, deserves its own paragraph because it appears in so many questions. A JWT is three base64url-encoded segments separated by periods: the header, which names the algorithm; the payload, which carries the claims; and the signature, computed over the header and payload with a key the verifier trusts. Anyone can decode the header and payload, so a JWT’s confidentiality is nothing and its integrity is everything: the signature is the entire security story, and a JWT accepted without signature validation, or with an algorithm that allows the attacker to choose a weak mode, is an unsigned assertion wearing a signed costume. The registered claims, iss, sub, aud, exp, nbf, iat, jti, are the vocabulary every verifier checks.

Choosing between SAML and OIDC is a real architectural decision, and the exam presents it as one. SAML, with its XML assertions and its maturity, is the enterprise-to-enterprise choice, strongest for web SSO between organizations that want formal metadata exchanges and long-lived relationships. OIDC, with its JSON tokens and its simpler mobile and API story, is the choice for consumer-scale sign-in, native and single-page applications, and any system that needs the token to flow straight into an API authorization. The overlap is web SSO, where both work. The discriminator is the client: browser and enterprise trust, SAML; mobile, API, and consumer scale, OIDC.

Provisioning at scale: SCIM and the deprovisioning gap

Every protocol so far has been about authentication and authorization at the moment of access. None of them creates or destroys accounts. Somebody has to tell the SaaS platform that the contractor left, and the mechanism that does it is provisioning, and the standard that makes provisioning automatic is SCIM, the System for Cross-domain Identity Management, defined in RFC 7643 for the core schema and RFC 7644 for the protocol.

SCIM is a REST API over JSON for identity data. A system that supports SCIM exposes endpoints for the standard resource types: /Users for people, /Groups for membership, plus a set of discovery endpoints, /ServiceProviderConfig, /ResourceTypes, and /Schemas, that tell a caller what the system supports. The identity provider pushes or pulls user records through the API: create, update, and delete, or the deprovisioning move, disable, and the whole conversation is standard enough that one provisioning engine can talk to hundreds of applications without custom integrations. This is the plumbing under the modern joiner, mover, leaver process: the HR system fires an event, the identity platform translates it into SCIM calls, and the applications that accept SCIM fall into line.

The deprovisioning gap is the reason SCIM matters to security, and it is the exact failure this chapter opened with. Deprovisioning is only as good as the last system that did not get the message. Every application that holds its own user table is a place where a leaver can survive, and the exam’s deprovisioning scenarios are always the same shape: the central directory was updated, and one application was not, and the question asks what control prevents the pattern. The answers worth selecting: integrate the applications with the central identity platform through a standard like SCIM so the revocation propagates; reconcile each application’s account list against the authoritative source on a schedule; and verify deprovisioning, test that a disabled account cannot authenticate. The answer to avoid: “revoke the central account,” because the central account was never the problem, the application’s local copy was.

PAM: the last mile of privilege

Privileged access is the last mile of identity, and it is where the stakes are highest, because the accounts in question can do anything. A privileged account is a domain administrator, a root account, a database administrator, a service account with broad rights, an application administrator. PAM, privileged access management, is the control layer that manages those accounts the way the lifecycle manages ordinary ones, only harder.

The starting point is the vault. The privileged credential, the domain admin password, the root password, is not handed out and changed by hand. It is stored encrypted in a vault, a purpose-built store with its own access control, and people retrieve it on demand through a controlled path. The security property of vaulting is that the standing credential is no longer something that exists in a thousand places, an email, a spreadsheet, a Post-it, a Helpdesk ticket. It exists in exactly one place, behind its own authentication and audit, and its use is a recorded event. NIST SP 800-53 AC-6(9) backs the audit side: use of privileged functions is audited, which is only meaningful when the use is actually observable, which is what the vault makes true. ISO/IEC 27001:2022 Annex A control A.8.2, privileged access rights, sets the management obligation: the assignment and use of privileged access rights is restricted and managed. “Restricted and managed” is the whole discipline in four words.

The vault is one leg. The other legs are the behaviors that keep the credential from being the whole game. Just-in-time, JIT, access grants privilege for a specific task for a limited window instead of standing: the engineer who needs admin rights for a maintenance window requests them, gets them for the window, and loses them when the window closes. JIT converts a permanent exposure into a temporary one, which is why the exam pairs it with the word “standing”: the question offers “a standing admin group with ten members” against “a JIT elevation workflow,” and the correct answer is the one that removes the standing state. Rotation changes the credential on a schedule or on an event, so a credential leaked last week is useless this week; the vault enables rotation because it can change the credential without asking a human to memorize the new one. Session brokering and recording route the privileged session through the PAM system, so the admin does not get the raw password at all, they get a session the vault controls and records, which is how you get audit of what was done, not just who asked. Separation of duties closes the loop: the person who approves a privileged request is not the person who fulfills it, and nobody should both administer the vault and be a subject of it.

Break-glass is the controlled exception that makes the discipline credible. When the vault is down, or the workflow fails, or seconds count, there is a sealed emergency path: an envelope, a special account, an emergency code, that bypasses the normal process and is opened only in a declared emergency. The control is not the absence of the exception, it is the supervision of it: the break-glass use triggers alerting and review, and the account or credential is re-sealed and rotated afterward. The exam’s position is consistent: an emergency path is not a design flaw, it is a design decision, as long as the exception is rare, audited, and revocable.

The privileged service account is the quiet cousin that PAM exists to serve. Its credential is a long random secret no one knows, which sounds secure and is actually the worst case, because nobody rotates what nobody knows and the secret lives, unchanged, in whatever config file leaked it years ago. The PAM answer is the same as the human answer: vault the secret, rotate it on schedule, scope it to the minimum rights, and tie it to an owner who reviews it. ISO/IEC 27001:2022 Annex A control A.8.5, secure authentication, frames the goal for all of it: authentication technologies and procedures are implemented in line with the access control policy, which is a reminder that PAM is not a product, it is the access control policy made mechanical.

Reading the scenario: four gaps, four answers

Pull the whole chapter into a diagnostic, because that is how the exam will use it. Every implementation question is one of four gaps.

The lifecycle gap: an identity that exists when it should not, or lacks what it should have. A leaver who can still log in, a joiner without proofing, a mover with stale rights, an orphan account. The answers are AC-2 and its enhancements, the access review of A.5.18, and the revoke-review-remove-verify sequence.

The directory gap: systems that never learned about each other. An application with its own user table, a shadow account, an LDAP bind in the clear, a reconciliation that never runs. The answers are the authoritative source, LDAPS or STARTTLS, and SCIM-driven provisioning with periodic comparison.

The trust gap: an assertion that was not worth trusting. An unsigned or badly validated SAML assertion, a missing metadata exchange, a token accepted without checking audience or signature, an OAuth flow without state or PKCE, a bearer token in a URL. The answers are signature and validity validation, exact redirect URI matching, state, PKCE, and the discipline of checking every claim before believing the token.

The privilege gap: access that is standing when it should be temporary. A standing admin group, a shared root password, a service account nobody rotates. The answers are the vault, JIT elevation, rotation, session recording, and the restricted-and-managed rule of A.8.2.

The pattern is worth stating plainly. The exam does not ask you to build a directory or configure a token service. It hands you a moment where one of these four gaps is about to bite, and it asks you to recognize the gap and pick the control that closes it. If you can name which of the four the scenario is about, you have already found the answer, because each gap has one family of controls and one family of vocabulary. That is the entire skill this chapter teaches: not the products, the gaps.

Practice questions

1. A company’s onboarding process creates accounts in the first application a new hire needs on day one, before the hire’s identity documents have been verified. Which control is missing?

   A. Deprovisioning B. Identity proofing before provisioning C. Credential rotation D. Session recording

2. An employee is terminated on a Friday. The directory account is disabled the same day, but three weeks later the employee’s credentials still work in a SaaS platform that maintains its own user list. What is the primary missing control?

   A. Multi-factor authentication on the SaaS platform B. A federation trust with the SaaS platform C. Provisioning or reconciliation between the SaaS platform and the central identity store D. A longer password policy for the SaaS platform

3. An auditor finds an account named “temp_support” in a production system that no one can connect to any current employee or contractor. What is this account called, and what is the root problem?

   A. A shared account, solved by renaming it B. An orphan account, solved by removing it and by lifecycle controls that prevent accounts from outliving their owners C. A service account, solved by giving it an owner D. A break-glass account, solved by sealing it

4. Which control requires an organization to manage the full lifecycle of accounts, including review and removal, per NIST SP 800-53?

   A. AC-2, account management B. AC-6(9), audit of privileged functions C. IA-5, authenticator management D. PL-4, rules of behavior

5. In the LDAP entry cn=jdoe,ou=People,dc=example,dc=com, what does ou=People represent?

   A. The relative name of the person entry B. The organizational unit that is the parent of the entry in the directory tree C. The person’s email domain D. The password policy applied to the entry

6. An application authenticates users against an LDAP directory, but a network capture shows the bind requests, including credential material, in plaintext. Which change directly fixes the exposure?

   A. Moving the directory to port 389 B. Using LDAPS on port 636 or STARTTLS on port 389 C. Adding a second LDAP server for failover D. Changing the directory schema

7. In Kerberos, what does a client send to the Authentication Service to prove it knows the user’s secret?

   A. The user’s password in plaintext B. A pre-authentication value, typically a timestamp encrypted with the user’s key C. A certificate signed by a public CA D. The ticket-granting ticket

8. Why do Kerberos requests carry timestamps, and what does the clock skew enable?

   A. To charge usage, and the skew determines the billing rate B. To prevent replay of captured requests, and the skew defines the tolerance within which a request is accepted C. To encrypt the session, and the skew sets the key length D. To authorize access, and the skew sets the permission level

9. A web application in an Active Directory domain lets users authenticate through their existing domain login without typing credentials. Which standard makes this work by negotiating the security mechanism?

   A. SCIM, RFC 7644 B. SPNEGO, RFC 4178 C. SAML 2.0 D. PKCE, RFC 7636

10. An attacker who has compromised a domain controller forges ticket-granting tickets for any account. What is the forged artifact called?

A. A golden ticket B. A silver ticket C. A pass-the-hash replay D. A refresh token

11. In a SAML 2.0 federation, which party authenticates the user and produces the assertion?

A. The service provider B. The identity provider C. The resource server D. The authorization server

12. A user clicks a link in an application that trusts a SAML identity provider. The application does not recognize the user, so it redirects the browser to the identity provider with an authentication request. After the user authenticates at the identity provider, what happens next?

A. The identity provider grants the user direct access to the application’s database. B. The identity provider returns an assertion to the application, which validates it and creates a session. C. The application sends the user’s password to the identity provider for storage. D. The identity provider issues a refresh token to the browser.

13. A service provider accepts a SAML assertion because it arrived from the correct IP address, without checking the signature or the audience. Which statement is correct?

A. This is acceptable, because network provenance is stronger than a signature. B. The assertion should also be rejected unless the validity window and audience are checked, and the signature verified against the identity provider’s key. C. The assertion is secure because SAML assertions are encrypted by default. D. The service provider should instead rely on the user’s stated identity.

14. In OAuth 2.0 per RFC 6749, which party issues access tokens?

A. The resource owner B. The client C. The authorization server D. The resource server

15. A batch job on a server needs to call a payment API with no user involved. Which OAuth 2.0 grant is designed for this situation?

A. The authorization code grant B. The client credentials grant C. The implicit grant D. The resource owner password credentials grant

16. A native mobile app uses the authorization code grant with PKCE to obtain an access token. When the access token expires, what does a refresh token allow?

A. The client to obtain a new access token without re-prompting the user for their credentials B. The client to convert the token into a password C. The user to bypass the authorization server entirely D. The client to mint tokens for other users

17. Per RFC 6750, which statement about a bearer token is correct?

A. It can only be used by the person who originally received it. B. Any party in possession of the token can use it, so it must be protected in transit and at rest. C. It is encrypted so possession alone grants nothing. D. It expires only when the user changes their password.

18. A native application exchanges an authorization code for tokens, and an attacker intercepts the code and swaps their own code into the request. Which mechanism, added to the code exchange, is designed to defeat this code interception attack?

A. PKCE per RFC 7636 B. A longer access token lifetime C. Refreshing the token before use D. Logging every token request

19. In OpenID Connect, which statement correctly distinguishes the ID token from the access token?

A. The ID token grants API access; the access token identifies the user. B. The ID token is a signed statement about the user’s identity; the access token grants access to protected resources. C. Both tokens are signed statements about the user, but only the access token carries the subject claim. D. The access token is issued by the resource server; the ID token is issued by the client.

20. A JWT per RFC 7519 consists of three segments. What is the signature computed over?

A. The payload only B. The header and payload C. The expiry claim only D. A separate key exchange handshake

21. An organization must integrate its web portal with a partner company’s identity system, and it also needs a native mobile app to access its own APIs with scoped permissions. Which pair of standards best fits?

A. SAML 2.0 for the partner federation, OIDC for the mobile app and API access B. LDAP for the partner federation, SCIM for the mobile app C. Kerberos for the partner federation, SAML for the mobile app D. SCIM for both, since provisioning covers authentication

22. A SaaS application wants to receive user and group records from the organization’s identity platform automatically, including deprovisioning events, over a standard REST and JSON interface. Which standard provides this?

A. SCIM, per RFC 7643 and RFC 7644 B. SAML 2.0 C. Kerberos D. X.500

23. Which risk does SCIM-driven provisioning most directly reduce?

A. The risk that a deprovisioning event fails to reach every system holding a local user record B. The risk of weak passwords C. The risk of token replay in federation D. The risk of LDAP traffic interception

24. An administrator needs domain admin rights for a two-hour maintenance window, after which the rights should be gone. Which PAM practice matches this requirement?

A. Standing membership in the domain admins group B. Just-in-time access with a limited, expiring elevation C. Break-glass access used by default D. A shared administrator password changed monthly

25. Per ISO/IEC 27001:2022 Annex A control A.8.2, how should privileged access rights be handled?

A. Assigned freely so outages can be handled quickly B. Restricted and managed, with the assignment and use of privileged access rights controlled C. Granted permanently to a small team that is never audited D. Documented only after a security incident

Answers and rationales

1. B. Provisioning before proofing creates accounts that belong to people who have not been verified to be who they claim to be, which is how ghosts get into the directory. NIST SP 800-63A-4 frames proofing as the step that establishes identity before enrollment; the missing control is that sequence. Deprovisioning, rotation, and session recording address later stages, not the birth of the identity.

2. C. The central directory was updated, but the SaaS platform keeps its own user list, so the revocation never reached it. The missing control is the channel that propagates identity changes to applications, SCIM-driven provisioning or scheduled reconciliation against the authoritative source. MFA, federation, and password length all sit at the authentication layer, and none of them removes an account that should not exist.

3. B. An account with no owner in the source of truth is an orphan account, and the fix has two parts: remove it now, and run the lifecycle controls, review, reconciliation, and verification, that prevent accounts from outliving their owners. Renaming preserves the hazard, and labeling it a service or break-glass account does not make it legitimate.

4. A. AC-2, account management, is the NIST SP 800-53 control that requires managing the lifecycle of accounts, including review, disablement, and removal. AC-6(9) audits privileged functions, IA-5 governs authenticators, and PL-4 covers rules of behavior, none of which is the lifecycle requirement.

5. B. A distinguished name is read from the entry up toward the root, so ou=People is the organizational unit entry directly above the person entry in the directory tree. The RDN, the entry’s own name, is the cn=jdoe part, and the other options confuse the name with unrelated properties.

6. B. LDAP does not encrypt by default on port 389; LDAPS on 636 wraps the session in TLS, and STARTTLS per RFC 4513 upgrades a plain connection on 389. Moving ports, adding servers, and changing the schema do not protect the bind exchange.

7. B. In the AS exchange, the client proves knowledge of the user’s secret with a pre-authentication value, typically a timestamp encrypted with the user’s key, which is why the password itself never crosses the network. The TGT is what the client receives from this exchange, not what it sends to start it.

8. B. Timestamps in Kerberos requests and tickets are the replay defense, and the clock skew is the configurable tolerance that decides whether a presented time is current. Kerberos assumes loosely synchronized clocks, which is why clock sync is part of Kerberos hygiene.

9. B. SPNEGO, RFC 4178, lets the browser and the server negotiate a security mechanism, Kerberos in this case, and carry the exchange over HTTP, which is how domain single sign-on reaches web applications. SCIM provisions identities, SAML is a separate federation protocol, and PKCE protects OAuth code exchanges.

10. A. A forged ticket-granting ticket minted with the krbtgt account’s key material is the golden ticket, and it lets an attacker create tickets for any account. The silver ticket is a forged service ticket for a specific service; pass-the-hash replays a captured hash; a refresh token is an OAuth object.

11. B. The identity provider authenticates the user and produces the signed assertion; the service provider consumes it. The resource server and authorization server are OAuth 2.0 roles, not SAML parties.

12. B. In SP-initiated SAML SSO, the flow ends with the identity provider returning an assertion to the application, which validates the signature, the validity window, and the audience, then creates a session. The identity provider does not touch the application’s data, and the application never sees the user’s password.

13. B. An assertion’s trust anchors on the identity provider’s signature, verified with the key exchanged through metadata, plus the validity window and the audience check. IP provenance is spoofable and not a substitute, SAML assertions are not encrypted by default, and the user’s self-stated identity is exactly what the assertion is meant to replace.

14. C. The authorization server authenticates the resource owner, issues the access token, and issues refresh tokens when the grant supports them. The resource owner owns the data, the client is the application, and the resource server validates the token against the protected resources.

15. B. The client credentials grant is for machine-to-machine access, where the client is also the resource owner and no user is involved. The authorization code grant requires a user, the implicit grant is a deprecated browser flow, and the password credentials grant collects a user’s password, which is inappropriate and discouraged.

16. A. The refresh token is a long-lived credential kept by the client and exchanged for new access tokens when the short-lived access token expires, preserving the user’s authorization without re-prompting. It does not convert to a password, bypass the authorization server, or authorize other users, and its theft is exactly why refresh tokens are protected and revocable.

17. B. A bearer token per RFC 6750 grants access to whoever holds it, so the token must be protected in transit and at rest, never embedded in URLs or logs. The other options describe properties bearer tokens do not have.

18. A. PKCE, RFC 7636, binds the code exchange to the original client with a verifier and challenge, so an attacker who intercepts the code cannot redeem it with their own client. Token lifetime, refresh, and logging do not protect the code exchange itself.

19. B. The ID token is the signed JWT that tells the client who the user is, validated for signature, issuer, audience, and freshness; the access token is the opaque or JWT credential that grants access to APIs. The subject claim lives in the ID token, and the resource server, not the client, issues neither token.

20. B. A JWT’s signature is computed over the encoded header and payload with the signing key, which is why a verifier must check it over the full content. Signing only the payload, or the expiry alone, would let an attacker alter the parts that were not signed.

21. A. SAML 2.0 is the mature standard for cross-organization web federation with formal metadata exchanges, and OIDC, built on OAuth 2.0, is the fit for native mobile clients and scoped API access. LDAP, Kerberos, and SCIM do not provide the assertion and token flows the scenario requires.

22. A. SCIM, the System for Cross-domain Identity Management, standardizes identity provisioning over REST and JSON, with /Users and /Groups resource types per RFC 7643 and RFC 7644. SAML authenticates, Kerberos authenticates within a trusted domain, and X.500 is the directory architecture, none of which is a provisioning channel.

23. A. Provisioning is the channel that propagates joiner, mover, and leaver events to every system, so SCIM directly reduces the deprovisioning gap, the risk that a revocation fails to reach an application holding its own user records. The other risks belong to authentication strength, token handling, and transport security, not provisioning.

24. B. Just-in-time access grants privilege for a defined task and window and removes the standing state, which matches a two-hour maintenance elevation exactly. Standing membership, break-glass used by default, and a shared password all preserve permanent or unsupervised exposure.

25. B. A.8.2 requires privileged access rights to be restricted and managed: assignment and use are controlled, which is the management obligation underneath vaulting, JIT, rotation, and review. Free assignment, permanent grants, and post-incident documentation are the failures the control exists to prevent.

Identity implementation on one page

The machinery of identity runs on four channels, and the exam scenarios are failures of one of them. The lifecycle channel, joiner, mover, leaver, creates and destroys identities under proofing, review, and revocation, with AC-2, AC-2(3), and A.5.18 as the load-bearing controls, and the deprovisioning gap as the classic failure. The directory channel stores identities in the X.500-shaped tree that LDAP, RFC 4511, reads and writes, protected by LDAPS or STARTTLS per RFC 4513, with Active Directory as the common implementation and the directory as the crown jewel.

The trust channel carries identities between parties. Kerberos, RFC 4120, is the in-domain workhorse, with the KDC’s AS and TGS, the TGT and service tickets, timestamps and clock skew against replay, SPNEGO, RFC 4178, carrying it into web applications, and the golden and silver ticket forgeries as its signature attack family. SAML 2.0 is the cross-organization web standard, built on the IdP’s signed assertion and the SP’s validation discipline, signature, validity, audience, freshness. OAuth 2.0, RFC 6749, is the API authorization layer, with its four roles, the authorization code grant with PKCE per RFC 7636, the client credentials grant for machines, refresh tokens, bearer tokens per RFC 6750, scopes, and the state parameter; OIDC adds the signed JWT ID token so clients know who the user is, and the JWT of RFC 7519 is trusted only through its signature.

The provisioning channel keeps the others honest: SCIM, RFC 7643 and RFC 7644, pushes user and group records to applications so a leaver cannot survive in a system that never got the message. PAM, vaulting, JIT, rotation, session recording, and break-glass under the restricted-and-managed rule of A.8.2, closes the last mile of privilege, including the service account nobody rotates. Four channels, four gap families, one habit: name the gap, and the control names itself.