Identity and Access Management practice questions

SAML supports only IdP-initiated SSO.

Why wrong: 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 wrong: 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 wrong: 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.

Self-service password reset

Why wrong: 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 wrong: 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.

Need-to-know

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Attribute-Based Access Control (ABAC)

Why wrong: ABAC uses attributes, not owner discretion.

Mandatory Access Control (MAC)

Why wrong: MAC is system-enforced based on labels.

Role-Based Access Control (RBAC)

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

Somewhere you are

Why wrong: "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 wrong: "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 wrong: "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.

Two-step verification

Why wrong: 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 wrong: 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 wrong: 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.

Domain Controller

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: RBAC assigns permissions based on roles, not owner discretion.

Mandatory Access Control (MAC)

Why wrong: MAC uses system-wide policies, not owner discretion.

Attribute-Based Access Control (ABAC)

Why wrong: ABAC uses policies based on attributes, not owner discretion.

Need-to-know

Why wrong: Need-to-know is an access control principle that dictates individuals should only be granted access to information or resources strictly necessary for them to perform their assigned job functions. While it restricts overall data exposure by limiting access to relevant data, it does not inherently prevent a user from being assigned two distinct operational privileges that, while individually necessary, create a conflict when held concurrently by the same person, which is the specific focus of the question.

Least privilege

Why wrong: Least privilege is a fundamental security principle that ensures users, programs, or processes are granted only the minimum necessary rights and permissions to perform their authorized tasks and nothing more. Although it limits the scope of potential damage by preventing excessive rights, it does not specifically address the scenario where two individually minimal but conflicting privileges might be assigned to the same user, which is precisely what separation of duties aims to prevent.

Job rotation

Why wrong: Job rotation is an administrative control that involves periodically moving employees among different roles or responsibilities within an organization. This practice serves as a detective control to uncover potential fraud or errors and provides cross-training benefits, but it does not directly prevent a single user from possessing two conflicting permissions or duties at any given moment, which is the immediate concern of the security policy requiring specific duty separation.

Kerberos

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

LDAP

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

OAuth 2.0

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

PIN

Why wrong: A Personal Identification Number (PIN) is classified as 'something you know' (Type 1) because it is a secret numerical code that the user must recall from memory to authenticate. Unlike physical tokens, a PIN's security is entirely dependent on its secrecy and the user's ability to keep it confidential. It offers a relatively low level of assurance when used in isolation, as it can be susceptible to guessing, brute-force attacks, or shoulder surfing.

Password

Why wrong: A password is a classic example of 'something you know' (Type 1), functioning as a secret string of characters that a user must memorize and input to prove their identity. Its effectiveness as an authentication factor is directly tied to its complexity, uniqueness, and the user's ability to keep it private. Passwords alone are vulnerable to various attacks, including dictionary attacks, brute-force attempts, and phishing, highlighting the need for stronger authentication methods.

Fingerprint

Why wrong: A fingerprint is categorized as 'something you are' (Type 3) because it leverages a unique biological characteristic inherent to an individual for authentication. This biometric factor involves scanning and matching the distinct patterns of ridges and valleys on a user's finger against a stored template. While convenient and difficult to forge perfectly, biometric systems can be susceptible to presentation attacks (spoofing) and raise privacy concerns regarding the storage and use of immutable personal data.

Biometric authentication

Why wrong: Biometric authentication refers to a specific type of authentication factor, 'something you are,' such as a fingerprint or facial scan. While it can be a component of a robust multi-factor authentication scheme, it does not describe the overarching requirement for combining multiple *different* types of factors for system access. The question implies a broader requirement for multiple factor types, not just the use of a biometric factor in isolation or as the sole additional factor.

Step-up authentication

Why wrong: Step-up authentication is a security mechanism that demands additional or stronger authentication factors only when a user attempts to access particularly sensitive resources or perform high-risk operations *after* their initial login. It is a conditional process that enhances security for specific actions, rather than defining the standard, initial login method that combines different factor types from the outset. Therefore, it does not describe the fundamental requirement for a system configured to use multiple factors for every login attempt.

Single-factor authentication

Why wrong: Single-factor authentication (SFA) relies on only one category of authentication credential, such as a password (something you know) or a smart card (something you have), to verify a user's identity. This method provides a lower level of security as it presents a single point of failure for attackers to target. The question explicitly indicates that two distinct authentication factor types are employed, directly contradicting the definition of SFA.