Identity and Access Management practice questions

Two-step verification

Why it fails: Two-step verification (2SV) involves a second authentication step, but it does not inherently guarantee the use of a different authentication factor type. For instance, it could involve a password followed by security questions, both relying on "something you know." While often implemented with different factors, 2SV's definition is broader and doesn't strictly meet the security requirement of combining distinct factor types for enhanced assurance, which is the hallmark of true multi-factor authentication.

Single-factor authentication

Why it fails: Single-factor authentication (SFA) relies on only one category of authentication credential, such as solely a password ("something you know") or a smart card ("something you have"). This method is inherently less secure as compromise of that single factor grants full access. The question implies a need for a more robust authentication mechanism than just a password, making SFA an insufficient security control against modern threats like phishing or credential stuffing.

Step-up authentication

Why it fails: Step-up authentication is a dynamic security measure where additional authentication factors are requested only when a user attempts to access more sensitive resources or perform high-risk transactions *after* an initial login. The scenario describes a general organizational requirement for user authentication at the standard login stage, not a conditional enhancement for specific, elevated operations. Therefore, it doesn't address the baseline authentication need.

SAML supports only IdP-initiated SSO.

Why it fails: This statement is incorrect because SAML 2.0 is designed to support both Identity Provider (IdP)-initiated and Service Provider (SP)-initiated Single Sign-On (SSO) flows. In an IdP-initiated flow, the user starts at the IdP and clicks a link to access an SP, receiving an assertion. Conversely, in an SP-initiated flow, the user attempts to access a resource directly at the SP, which then redirects them to the IdP for authentication before receiving an assertion. The flexibility to support both initiation types makes SAML highly adaptable to various enterprise and cloud application integration scenarios.

SAML uses JSON for its assertions.

Why it fails: This statement is incorrect. SAML (Security Assertion Markup Language) fundamentally relies on XML (Extensible Markup Language) for structuring its assertions, protocols, and metadata. SAML assertions, which convey authentication and authorization information, are digitally signed XML documents. While JSON (JavaScript Object Notation) is a popular data interchange format, it is not the format specified or used by the SAML standard for its core components, which predates widespread JSON adoption.

SAML is primarily used for authorization, not authentication.

Why it fails: This statement is incorrect because SAML's primary and most widespread use case is for authentication, specifically enabling Single Sign-On (SSO) across disparate security domains. While SAML assertions can contain authorization attributes (e.g., roles or group memberships) that service providers use to make access control decisions, its fundamental purpose is to convey authentication decisions from an Identity Provider to a Service Provider. The authorization aspect is typically a secondary function, leveraging the authenticated identity rather than being the sole or primary focus.

Kerberos

Why it fails: Kerberos is a network authentication protocol, not typically used for web SSO.

LDAP

Why it fails: LDAP is a directory access protocol, not an SSO protocol.

OAuth 2.0

Why it fails: OAuth 2.0 is an authorization framework, not authentication.

Self-service password reset

Why it fails: Self-service password reset is a common feature in general Identity and Access Management (IAM) systems, designed primarily for end-users to regain access to their standard accounts without IT intervention. However, it is not a core or specific feature of Privileged Access Management (PAM). PAM focuses on strictly controlling and managing *existing* highly sensitive privileged credentials, rather than empowering users to reset their own administrative passwords, which would undermine the principle of least privilege and increase risk.

Break-glass access

Why it fails: Break-glass access refers to an emergency procedure designed to provide immediate, unfettered access to critical systems when normal authentication and authorization mechanisms fail or are unavailable. While a PAM solution might facilitate the secure storage and retrieval of break-glass credentials, the concept itself is an *emergency protocol* for exceptional circumstances, not a standard, routine operational feature of PAM. PAM's primary function is to *manage* and *control* privileged access under normal conditions, not to provide a bypass mechanism as a regular offering.

Domain Controller

Why it fails: A Domain Controller is a server role specific to Microsoft Active Directory environments, responsible for managing user accounts, authenticating users, and enforcing security policies within a Windows domain. While a Domain Controller typically hosts the Kerberos Key Distribution Center (KDC) service in a Windows network, it is an implementation detail of a directory service rather than a fundamental component of the Kerberos protocol itself. Kerberos is a protocol that can be implemented independently of Active Directory, making 'Domain Controller' a specific product term, not a universal Kerberos component.

Ticket Granting Server (TGS)

Why it fails: The Ticket Granting Server (TGS) is a component of the Kerberos Key Distribution Center (KDC) that is responsible for issuing service tickets, not Ticket Granting Tickets (TGTs). After a client obtains a TGT from the Authentication Server (AS), it presents this TGT to the TGS when requesting access to a specific network service. The TGS then validates the TGT and issues a service ticket, encrypted with the target service's secret key, enabling the client to authenticate directly to that service.

Key Distribution Center (KDC)

Why it fails: The Key Distribution Center (KDC) is the overarching logical entity in a Kerberos realm that acts as a trusted third party, providing both authentication and ticket-granting services. It comprises two distinct functional components: the Authentication Server (AS) and the Ticket Granting Server (TGS). While the KDC as a whole facilitates the entire Kerberos authentication process, it is specifically the Authentication Server (AS) component within the KDC that issues the initial Ticket Granting Tickets (TGTs).

Replay attack

Why it fails: A replay attack involves capturing a legitimate authentication message or data stream and retransmitting it later to impersonate a user or gain unauthorized access. While Kerberos does use tickets, its protocol incorporates timestamps and nonces to prevent simple retransmission of old messages from succeeding. This attack differs from pass-the-ticket because it focuses on re-sending an *existing* communication rather than leveraging a *stolen credential* to generate *new* valid requests.

Golden ticket attack

Why it fails: A Golden Ticket attack involves forging a Ticket Granting Ticket (TGT) rather than stealing an existing one. This sophisticated attack requires an attacker to compromise the Kerberos Key Distribution Center (KDC) by obtaining the NTLM hash of the KRBTGT account. With this hash, the attacker can craft a TGT for any user, with arbitrary privileges and an extended lifetime, granting persistent, full administrative control over the entire domain without ever interacting with the legitimate KDC.

Kerberos cracking

Why it fails: Kerberos cracking, while not a standard attack name, typically refers to offline brute-forcing or dictionary attacks against password hashes derived from Kerberos authentication requests. For instance, an attacker might capture an AS-REQ message containing a hash of the user's password (pre-authentication data) and attempt to crack it offline to recover the plaintext password. This process aims to discover the user's password, which is distinct from using an already obtained TGT to authenticate.

Need-to-know

Why it fails: The "need-to-know" principle dictates that individuals should only have access to the information absolutely necessary to perform their job functions, regardless of their security clearance or overall authorization. This control primarily restricts access to sensitive data and resources, focusing on who can view or retrieve information. It does not mandate how many individuals must collaborate to complete an operational task or transaction, making it irrelevant to the described policy.

Least privilege

Why it fails: The principle of least privilege ensures that users, programs, or processes are granted only the minimum necessary permissions or access rights required to perform their specific job functions or tasks. Its primary focus is on restricting the scope of actions an entity can take within a system, preventing excessive authorization that could lead to misuse or compromise. This security control limits what an individual can do, rather than mandating the involvement of multiple individuals to perform a single operation or task.

Two-person control

Why it fails: Two-person control is a specific implementation of separation of duties that mandates the involvement of two distinct individuals to complete a critical task or transaction. This policy ensures that no single person can unilaterally perform a sensitive operation, thereby significantly reducing the risk of error, fraud, or malicious activity. By requiring two different employees, the company establishes a built-in check-and-balance mechanism for the task described, directly aligning with the policy.

Configure password settings in the user's individual properties

Why it fails: Active Directory does not allow direct configuration of password policy settings, such as complexity, length, or lockout thresholds, within an individual user's properties. Password policies are security configurations applied at a broader scope, typically through Group Policy Objects (GPOs) linked to domains or Organizational Units (OUs). Attempting to enforce policy per user this way is not a native Active Directory function for standard password policies.

Apply a Group Policy Object (GPO) to the OU containing the department's users

Why it fails: Applying a Group Policy Object (GPO) directly to the Organizational Unit (OU) that contains the department's user accounts is the most effective, scalable, and granular method for enforcing specific password policies. This approach ensures that the policy applies only to the intended users within that department, leveraging Active Directory's hierarchical structure for targeted and centralized management without affecting other parts of the domain.

Create a password policy in the Default Domain Policy

Why it fails: Creating a password policy within the Default Domain Policy would apply that policy to *all* users and computers throughout the entire Active Directory domain. This approach lacks the necessary granularity to enforce a policy specifically for only one department, as it would override any less stringent policies for other users, potentially causing unintended operational impacts or security posture changes domain-wide without specific departmental targeting.

Security question

Why it fails: A security question is something you know (Type 1).

Password

Why it fails: A password is something you know (Type 1).

Fingerprint

Why it fails: A fingerprint is something you are (Type 3).

Attribute-Based Access Control (ABAC)

Why it fails: ABAC uses attributes, not owner discretion.

Mandatory Access Control (MAC)

Why it fails: MAC is system-enforced based on labels.

Role-Based Access Control (RBAC)

Why it fails: RBAC assigns permissions based on roles, not owner discretion.

Somewhere you are

Why it fails: "Somewhere you are" refers to authentication based on a user's physical or logical location, often verified through GPS coordinates, IP address geolocation, or network segment identification. A smart card is a portable physical device, not a location, and its presence alone does not inherently verify the user's geographical or network position. Therefore, a smart card does not fall under this location-based authentication factor.

Type 3 (something you are)

Why it fails: "Something you are" factors, also known as biometric factors, rely on unique, inherent biological or behavioral characteristics of an individual for authentication. Examples include physiological traits like fingerprints, iris scans, or facial recognition, and behavioral traits such as gait analysis or voice recognition. A smart card is an external, manufactured device and does not represent any intrinsic biological attribute or behavior of the user, making this option incorrect.

Type 1 (something you know)

Why it fails: "Something you know" factors are knowledge-based authentication methods that rely on secret information known only to the legitimate user. This category includes common credentials like passwords, Personal Identification Numbers (PINs), or answers to security questions. While a smart card often requires a PIN (a "something you know" factor) to activate its functionality, the smart card itself is a physical object, not the memorized knowledge, thus it is not a "something you know" factor.

Domain Controller

Why it fails: A Domain Controller, particularly in a Windows Active Directory environment, is a server that can host the Kerberos Key Distribution Center (KDC). While it provides the physical or logical infrastructure for Kerberos services, the Domain Controller itself is not the specific Kerberos component responsible for issuing tickets. The KDC's Authentication Server (AS) sub-component performs this cryptographic function, making 'Domain Controller' too broad a term.

Ticket Granting Server (TGS)

Why it fails: The Ticket Granting Server (TGS) is a crucial logical component within the Kerberos Key Distribution Center, but its specific role is to issue *service tickets* to clients. These service tickets grant access to specific application services after the client has already obtained a Ticket Granting Ticket (TGT) from the Authentication Server (AS). Therefore, the TGS is not the component that issues the initial TGT.

Key Distribution Center (KDC)

Why it fails: The Key Distribution Center (KDC) is the central authority in a Kerberos realm, comprising two logical components: the Authentication Server (AS) and the Ticket Granting Server (TGS). While the KDC *as a whole* facilitates ticket distribution, it is the AS component *within* the KDC that specifically authenticates the user and issues the initial Ticket Granting Ticket (TGT). Thus, KDC is too general a term for the specific issuer of the TGT.

Silver ticket attack

Why it fails: A silver ticket attack involves forging a Kerberos service ticket (TGS) for a specific service on a particular server, rather than a TGT. This attack requires compromising the NTLM hash of the service account or machine account associated with the target service. The forged service ticket grants access only to that specific service, such as CIFS for file shares or HTTP for web services, without requiring interaction with the KDC for a TGT.

Pass-the-ticket attack

Why it fails: Pass-the-ticket (PtT) is a post-exploitation technique where an attacker reuses a legitimate Kerberos TGT or service ticket that has been stolen from a compromised host's memory or file system. Unlike forging, PtT does not create new tickets but rather authenticates to services using an existing, valid ticket. This attack bypasses the need for the user's password hash, relying solely on the presence of a valid, unexpired ticket.

Kerberos poisoning attack

Why it fails: Kerberos poisoning is a broader term encompassing various attacks that manipulate or exploit Kerberos protocol messages or configurations, often targeting the initial authentication request (AS-REQ/AS-REP). Examples include AS-REP Roasting, where an attacker requests TGTs for users configured with "Do not require Kerberos preauthentication" and then cracks the encrypted AS-REP offline. Another form involves manipulating Service Principal Names (SPNs) to trick clients into requesting tickets for malicious services or to facilitate other attacks.

Resource owner password credentials grant

Why it fails: This grant type directly exposes the user's credentials (username and password) to the client application, which then passes them to the authorization server. For public clients, which cannot guarantee the confidentiality of client secrets or securely store user passwords, this presents a significant security risk. It bypasses the authorization server's user interface, making it vulnerable to phishing and credential compromise, and is therefore strongly discouraged.

Implicit grant

Why it fails: The Implicit Grant is deprecated due to its inherent security weaknesses, primarily the direct exposure of access tokens in the URL fragment. This makes tokens susceptible to leakage via browser history, referrer headers, and various injection attacks. Furthermore, it does not support refresh tokens, requiring users to re-authenticate frequently, and lacks client authentication, making it less secure than the Authorization Code flow.

Client credentials grant

Why it fails: The Client Credentials Grant is designed exclusively for confidential clients to obtain an access token on their own behalf, without any user involvement. It is used for machine-to-machine communication where the client itself is the resource owner, or acts on its own behalf. Public clients, by definition, cannot securely store a client secret, which is a fundamental requirement for this grant type, rendering it unsuitable for user-facing applications.

Client credential management

Why it fails: OIDC does not primarily extend OAuth 2.0 by adding client credential management. OAuth 2.0 already defines robust mechanisms for clients to authenticate themselves to the authorization server, typically using a `client_id` and `client_secret`, or more advanced methods like mTLS. OIDC builds upon this existing client authentication framework provided by OAuth 2.0, focusing instead on standardizing the end-user's identity verification.

Authorization delegation

Why it fails: Authorization delegation is the fundamental purpose of OAuth 2.0, enabling a client application to access a user's protected resources on a resource server with the user's explicit consent, without ever sharing the user's credentials with the client. OIDC does not introduce this capability; rather, it relies on OAuth 2.0's established framework for securely delegating authorization from the resource owner to a client application.

Token introspection

Why it fails: Token introspection is an OAuth 2.0 extension (RFC 7662) that allows a resource server to query an authorization server about the active state and metadata of an access token. While OIDC relies on access tokens for authorization, the introspection mechanism itself is a separate, general OAuth 2.0 capability for token validation, not a primary feature OIDC adds to enable user authentication. OIDC's core contribution is the ID Token for identity verification.

Privileged access management

Why it fails: Privileged Access Management (PAM) is a security discipline and set of technologies designed to secure, manage, and monitor access to critical assets and information. It specifically focuses on controlling elevated permissions for administrative accounts, service accounts, and other highly sensitive credentials, often involving session monitoring and just-in-time access. While PAM is crucial for securing a subset of identities, it does not encompass the broader identity lifecycle management process, such as the systematic removal of access for all departing employees. Therefore, it's not the primary mechanism for general user deprovisioning.

Access recertification

Why it fails: Access recertification, also known as access review or attestation, is a periodic process where data owners or managers review and validate that existing user access rights remain appropriate and necessary for their roles. This process aims to identify and revoke stale or excessive permissions, ensuring the principle of least privilege is maintained over time. However, recertification is a scheduled audit and does not provide the immediate, event-driven mechanism required to revoke all access for an employee who has just departed the organization.

Separation of duties

Why it fails: Separation of duties (SoD) is an internal control principle designed to prevent fraud, error, and abuse by ensuring that no single individual has complete control over a critical process or transaction. It mandates that different individuals perform distinct steps in a process, such as initiating, approving, and recording a financial transaction. While SoD is fundamental to designing secure processes, it is a control principle for assigning responsibilities, not an operational process for the immediate revocation of access rights when an employee leaves the organization.

Separation of duties violation

Why it fails: A separation of duties (SoD) violation occurs when a single individual possesses the authority to perform two or more critical, conflicting tasks that, if combined, could lead to fraud, error, or system compromise. While an orphaned account might indirectly contribute to an SoD issue if it's later exploited, the initial discovery of an account during an access rights review, by itself, does not directly indicate that an individual is performing conflicting duties. The scenario describes an account's status, not a conflict in assigned responsibilities.

Account lockout

Why it fails: Account lockout is a security mechanism designed to prevent brute-force attacks by temporarily disabling a user account after a predefined number of consecutive failed login attempts. While an analyst might observe an account in a locked-out state, the question describes the discovery of an underlying issue during a review of access rights, not the activation of a protective measure. The scenario implies a persistent problem with account management or ownership, not a temporary state triggered by login failures.

Privilege escalation

Why it fails: Privilege escalation refers to the unauthorized act of gaining elevated access rights or permissions within a system or network beyond what was initially granted. This typically involves exploiting vulnerabilities or misconfigurations to move from a lower-privileged user to a higher-privileged user, such as an administrator. The scenario describes a security analyst discovering an issue with an account's status during a review, not an active attempt or successful exploit to gain higher permissions.

Password vaulting

Why it fails: Password vaulting is a foundational component of a Privileged Access Management (PAM) solution, designed to securely store, manage, and rotate credentials for privileged accounts. While it centralizes secret management and enhances credential hygiene by eliminating hardcoded passwords, it primarily addresses the secure storage and retrieval of secrets. It does not inherently eliminate standing privileges, as users might still be granted continuous access to the vault or the accounts managed by it, even if the credentials themselves are regularly rotated.

Break-glass account

Why it fails: A break-glass account is a highly privileged emergency account designed for use during critical system failures or when standard access mechanisms are unavailable. While it provides elevated access, its purpose is for exceptional, unforeseen circumstances, not for routine administrative tasks or as a mechanism to implement regular time-limited access. Its existence is a contingency, and its use is typically heavily audited and restricted, distinct from the proactive privilege reduction offered by JIT.

Session recording

Why it fails: Session recording in a PAM solution captures and logs all activities performed during a privileged session, providing an immutable audit trail for accountability, compliance, and forensic analysis. While it is an essential detective control for monitoring, compliance, and incident response, session recording does not prevent or reduce the existence of standing privileges. It merely records what happens *after* privileges have been granted, thus not addressing the core problem of excessive or continuous access rights.

The root of the directory

Why it fails: While the root of the directory, often referred to as the Root DSE (Directory Service Agent Specific Entry), is indeed an entry, the Distinguished Name (DN) is not exclusively for it. The Root DSE itself has a DN (often a null string or a specific base DN), but the fundamental purpose of a DN is to uniquely identify *any* entry, regardless of its position or special status within the Directory Information Tree (DIT). Therefore, identifying only the root is too narrow a scope for the DN's universal identification function.

The schema of the directory

Why it fails: The schema defines the structural rules and constraints for an LDAP directory, specifying what types of entries can exist, what attributes they can possess, and the syntax for those attributes. It dictates the permissible object classes and attribute types, essentially providing the blueprint for the directory's content and ensuring data consistency. However, the schema does not identify specific data instances or entries; rather, it governs their creation and validity, making it distinct from the unique identification function of a DN.

A group within the directory

Why it fails: A group is merely one specific type of entry within an LDAP directory, typically defined by an objectClass like 'groupOfNames' or 'groupOfUniqueNames'. While every group, as an entry, possesses a unique Distinguished Name (DN) to identify it, the DN's function is not limited to groups. It universally identifies any entry, whether it's a user, a computer, an organizational unit, or any other object stored in the directory, making this option too restrictive and not representative of the DN's broader purpose.

Role-Based Access Control (RBAC)

Why it fails: RBAC assigns permissions to roles rather than letting the resource owner decide, so authority rests with role administrators, not owners. RBAC is correct where job functions map cleanly to fixed permission sets, such as large enterprises with stable, well-defined organisational roles.

Mandatory Access Control (MAC)

Why it fails: MAC enforces access through system-assigned labels and clearances, removing owner discretion entirely, so it cannot satisfy owner-determined permissions. MAC is the right model for high-assurance environments, such as military or government systems, where central policy must override individual owners.

Attribute-Based Access Control (ABAC)

Why it fails: ABAC grants access from policies evaluating attributes of subject, resource and environment, not from the resource owner's discretion, so ownership does not drive permissions. ABAC is correct for fine-grained, context-aware policy at scale, such as dynamic least-privilege across many resources.