CCNA Identity and Access Management Questions

Proof Key for Code Exchange (PKCE) enhances the Authorization Code Grant flow, making it secure for public clients like mobile applications that cannot securely store a client secret. It mitigates the authorization code interception attack by requiring the client to generate a cryptographically random `code_verifier` and a `code_challenge` derived from it. The `code_challenge` is sent with the initial authorization request, and the `code_verifier` is later presented when exchanging the authorization code for an access token, proving the client's identity without a shared secret.

Role-Based Access Control (RBAC) assigns permissions to specific roles, and then users are assigned to one or more roles based on their job functions or responsibilities within an organization. This model simplifies administration by managing permissions at the role level rather than individually for each user, ensuring that users only have the access necessary for their duties. RBAC is widely adopted due to its balance of security, flexibility, and ease of management, directly addressing the question's premise.

Separation of duties (SoD) is a critical preventative control designed to mitigate the risk of fraud, error, or misuse by ensuring that no single individual possesses all the necessary permissions or capabilities to complete a critical or sensitive transaction end-to-end. This policy directly addresses the requirement that a user cannot have both conflicting responsibilities, thereby preventing a single point of failure or malicious action. It mandates that distinct, high-risk tasks are divided among multiple people.

Managers are uniquely positioned to confirm the ongoing business necessity of an employee's access privileges, as they possess direct insight into daily job functions and responsibilities. This crucial step ensures that access rights align with the principle of least privilege, preventing the accumulation of unnecessary permissions and reducing the overall attack surface within the organization. This verification is fundamental to maintaining a secure access posture.

A fingerprint scan is a classic example of Type 3 authentication, which relies on "something you are." This biometric factor captures unique physiological patterns from an individual's finger to verify identity, providing a high level of non-repudiation compared to knowledge or possession factors.

Two-person control, also known as the "two-man rule" or dual control, is a procedural security mechanism requiring the simultaneous involvement and agreement of two authorized individuals to perform a critical or sensitive action. This control prevents a single person from initiating or completing a high-risk transaction or operation, significantly mitigating the risk of fraud, error, or malicious intent by ensuring mutual oversight and accountability. It directly addresses the need for multiple people to complete a sensitive action.

The Identity Provider (IdP) is the authoritative entity responsible for authenticating the user's identity within a SAML 2.0 federation. It verifies user credentials against its own identity store (e.g., an LDAP directory or database) and, upon successful authentication, generates a digitally signed SAML assertion containing the user's authentication status and relevant attributes. This assertion is then securely transmitted to the Service Provider, confirming the user's identity without sharing their actual credentials.

The Client Credentials grant type is specifically designed for machine-to-machine authentication, where a confidential client (e.g., a service, daemon, or another API) needs to access protected resources on behalf of itself, rather than a specific end-user. In this flow, the client authenticates directly with the authorization server using its own client ID and client secret, receiving an access token that grants it access to resources it is authorized for. This grant is ideal for server-to-server interactions or automated processes where no user interaction is present or required.

Attribute-Based Access Control (ABAC) makes access decisions by evaluating a comprehensive set of attributes associated with the subject (e.g., user's department, clearance level), the object (e.g., resource sensitivity, file type), the action being requested (e.g., read, write), and the environmental context (e.g., time of day, network location). This highly dynamic and granular model uses policies that define rules based on these combined attributes, enabling context-aware authorization beyond static roles or identities.

SAML 2.0 (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between an identity provider and a service provider. It is specifically designed to facilitate browser-based single sign-on (SSO) for web applications across different security domains, allowing users to authenticate once and gain access to multiple services without re-entering credentials. Its robust support for federated identity management makes it a cornerstone for enterprise SSO solutions.

A smart card is a quintessential example of a "something you have" authentication factor because it is a tangible, physical item that the user must possess and present for authentication. This factor relies on the physical control of an object, such as a cryptographic token, USB key, or in this case, a smart card. The card securely stores cryptographic keys or digital certificates, which are accessed only when the card is physically inserted into a compatible reader, thereby proving possession.

OpenID Connect (OIDC) primarily extends OAuth 2.0 by adding a standardized layer for user authentication. While OAuth 2.0 focuses solely on authorization, allowing a client to obtain delegated access to protected resources, OIDC introduces the concept of an ID Token. This ID Token, a JSON Web Token (JWT), provides verifiable claims about the authenticated user, enabling the client application to confirm the user's identity and retrieve basic profile information.

Bottom-up role mining analyzes actual entitlement assignments to identify common access patterns and proposes candidate roles, which are then refined and approved by business owners. This reduces role sprawl, aligns roles with real job functions, and creates a governed, reviewable role catalog, directly addressing the drift and manual review problems.

This statement accurately describes the core purpose of PKCE. By requiring the client to generate a `code_verifier` and send a transformed `code_challenge` at the beginning of the flow, then present the original `code_verifier` when redeeming the authorization code, PKCE ensures that only the client that initiated the request can successfully exchange the code for tokens. This mechanism effectively prevents authorization code interception attacks, where a malicious application might steal the code and impersonate the legitimate client.

Multi-factor authentication (MFA) is the correct choice because it precisely describes an authentication system that requires a user to present two or more independent authentication factors from different categories to verify their identity. By combining distinct types, such as 'something you know' (e.g., a password) and 'something you have' (e.g., a token or smart card), MFA significantly enhances security. This approach ensures that even if one factor is compromised, unauthorized access is prevented due to the requirement for a second, different factor.

The Ticket Granting Ticket (TGT) is a crucial component that facilitates single sign-on within a Kerberos realm. Once a client successfully authenticates to the Authentication Service (AS) and receives a TGT, this ticket serves as proof of their identity to the Ticket Granting Service (TGS). This allows the client to subsequently request service tickets for various network services without needing to re-enter their password or re-authenticate to the KDC for each new service.

An orphaned account is an active user account that no longer has an associated legitimate user, typically because the employee has left the organization but their account was not properly deprovisioned or disabled. This oversight creates a significant security vulnerability, as the account could be exploited by an attacker or the former employee themselves to gain unauthorized access to systems and data. The discovery of a former employee's active account directly indicates a failure in the organization's identity and access management offboarding process.

Attackers actively seek out orphaned accounts because they often represent overlooked security gaps. These accounts may retain elevated privileges, possess weak or default passwords that were never updated, or simply go unnoticed in routine security audits, making them prime targets for credential stuffing, brute-force attacks, or lateral movement once initial network access is achieved. Exploiting such accounts provides a persistent backdoor for unauthorized access and privilege escalation.

Holder-of-Key subject confirmation binds the assertion to a key the requester must prove possession of, so a stolen session cookie alone cannot satisfy the SP. This directly addresses replay of a captured assertion or cookie, which is exactly the risk the security team wants to reduce for clinician access to the EHR.

A password serves as a classic example of a Type 1 authentication factor, representing "something you know." This form of authentication relies on a secret piece of information, such as a string of characters, that only the legitimate user is supposed to possess and recall. Users must cognitively remember and accurately input this credential to prove their identity, making it a foundational element in most access control systems. Its security is directly dependent on its complexity and the user's ability to keep it confidential.

A golden ticket attack leverages a compromised Kerberos Key Distribution Center (KDC) account's NTLM hash (specifically, the krbtgt account) to forge a valid Ticket Granting Ticket (TGT). This forged TGT grants the attacker unlimited, domain-wide administrative access to all resources within the Active Directory environment. The attacker can impersonate any user, including non-existent ones, and request service tickets for any service without further authentication from the legitimate KDC.

The Authorization Code grant with Proof Key for Code Exchange (PKCE) is the recommended and most secure flow for public clients like native mobile applications. PKCE mitigates the authorization code interception attack by requiring the client to generate a cryptographically random `code_verifier` and send its hash (`code_challenge`) during the initial authorization request. The same `code_verifier` must then be presented when exchanging the authorization code for an access token, ensuring only the legitimate client that initiated the request can complete the exchange, even if the code is intercepted.

Just-in-time (JIT) access is a critical security feature within a PAM solution that grants elevated privileges only when needed and for a strictly limited duration. This approach minimizes the attack surface by eliminating standing privileges, ensuring that users possess administrative rights solely for the specific task and time required. Once the task is completed or the predefined time expires, the privileges are automatically revoked, significantly reducing the window of opportunity for credential misuse or compromise.

Session recording is a critical characteristic of Privileged Access Management (PAM) systems, capturing video-like records of all activities performed by privileged users during their elevated sessions. This capability provides an immutable audit trail, enabling forensic analysis, compliance reporting, and real-time monitoring of sensitive operations. By documenting every command and action, organizations can ensure accountability and detect unauthorized or suspicious behavior associated with high-risk accounts.

Password vaulting is a fundamental PAM capability that centralizes the secure storage of privileged account credentials, such as administrator passwords and SSH keys, in an encrypted and isolated repository. It enforces strong password policies, automates credential rotation at defined intervals, and manages the secure retrieval and injection of these credentials into target systems, eliminating direct user knowledge of the actual passwords. This significantly reduces the risk of credential theft and misuse.

Session recording is a critical component of Privileged Access Management (PAM) that captures and archives all activities performed during a privileged session. This includes keystrokes, mouse movements, and screen content, providing an immutable audit trail. Such recordings are invaluable for forensic analysis, compliance auditing, and identifying unauthorized or suspicious actions by privileged users, enhancing accountability and security posture.

A smart card represents 'something you have' (Type 2) because it is a physical token that must be possessed by the user to grant access. These cards typically contain an embedded microchip capable of performing cryptographic operations, such as storing digital certificates or generating one-time passwords. Its security relies on the physical control of the device, making it a robust authentication factor, often combined with a PIN for multi-factor authentication.

This option is correct because the authentication system leverages two distinct types of factors to verify a user's identity. The password serves as the 'something you know' factor, requiring the user to recall a secret piece of information. The SMS One-Time Password (OTP), delivered to a registered mobile device, functions as the 'something you have' factor, relying on the user's possession of that specific device. This combination of two different factor categories precisely defines two-factor authentication (2FA).

DAC binds permissions to resource owners, who grant or revoke access at their discretion. This directly satisfies the stem's requirement that the owner determines both who may access the resource and which permissions they hold, unlike mandatory or role-based models where policy is centrally imposed.

The Ticket Granting Ticket (TGT) serves as a crucial credential, issued by the Authentication Server (AS), that the client presents to the Ticket Granting Service (TGS). It contains the user's identity and a session key, encrypted with the TGS's secret key, proving the user has been successfully authenticated by the AS. This allows the TGS to trust the client's request for service tickets without requiring re-authentication to the AS for each new service.

'CN' stands for Common Name, which is a fundamental attribute type used in LDAP Distinguished Names (DNs) to identify the most specific or common name of an entry within its immediate parent container. This attribute is widely employed for various object classes, such as users (e.g., "cn=John Doe"), groups, servers, or other resources, providing a human-readable identifier for the directory object. It forms a crucial part of the Relative Distinguished Name (RDN) for many entries.

This statement is correct and highlights a fundamental distinction. OAuth 2.0 is an authorization framework, primarily concerned with granting delegated access to protected resources without sharing user credentials. Conversely, OpenID Connect (OIDC) is an authentication protocol built on OAuth 2.0, specifically designed to verify the identity of an end-user and obtain basic profile information, issuing an ID Token for this purpose.

SP-initiated SSO occurs when a user attempts to access a protected resource directly from a Service Provider (SP). The SP detects the unauthenticated request, generates a SAML authentication request, and redirects the user's browser to the Identity Provider (IdP) along with this request. After the IdP authenticates the user, it creates a SAML assertion and redirects the user's browser back to the SP, allowing the user to access the requested resource without re-authenticating directly to the SP.

SAML 2.0 (Security Assertion Markup Language) is an XML-based standard specifically designed for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). It is widely adopted for enterprise single sign-on (SSO) scenarios, enabling users to authenticate once with an IdP and gain seamless access to multiple SPs without re-entering credentials. Its robust support for both IdP-initiated and SP-initiated flows makes it a strong choice for cross-domain SSO implementations.

OAuth 2.0 is an authorization framework specifically designed to enable a third-party application to obtain limited access to an HTTP service on behalf of a resource owner. It orchestrates an approval interaction where the user grants specific permissions to the application without ever sharing their credentials with it. This protocol's core purpose is the secure delegation of authority for accessing protected resources, making it an authorization framework rather than an authentication protocol for the end-user.

The Authentication Server (AS) is the precise Kerberos component responsible for the initial authentication of a user or service principal. Upon successful authentication, typically involving a shared secret (like a password hash), the AS issues a Ticket Granting Ticket (TGT) to the client. This TGT is then used by the client to request service tickets from the Ticket Granting Server (TGS) without needing to re-authenticate with the AS, streamlining subsequent access.

The Distinguished Name (DN) serves as the unique identifier for every individual entry within an LDAP directory. It specifies the exact, unambiguous path from the root of the Directory Information Tree (DIT) down to that specific entry, composed of a sequence of Relative Distinguished Names (RDNs). This hierarchical naming ensures that no two entries can share the same DN, guaranteeing absolute uniqueness across the entire directory and enabling precise referencing for all operations.

The principle of least privilege mandates that users, programs, or processes are granted only the absolute minimum set of permissions or access rights required to perform their legitimate tasks and nothing more. This fundamental security practice minimizes the attack surface by reducing the potential damage from accidental errors, insider threats, or successful external attacks, as compromised accounts have severely limited capabilities. It directly ensures a user is granted only the necessary permissions.

Forging a TGT with the KRBTGT account hash lets an attacker mint arbitrary Kerberos tickets, including domain admin privileges, without authenticating. This is the defining mechanism of a golden ticket, which grants persistent, forged access to the entire domain.

Just-in-time (JIT) access is a core principle of modern Privileged Access Management that grants elevated privileges to users only when they are needed, for the specific task at hand, and for a strictly limited duration. This approach significantly reduces the attack surface by minimizing the time privileged accounts exist with standing access. Once the task is completed or the time limit expires, the elevated privileges are automatically revoked, aligning perfectly with the goal of managing privilege duration.

LDAP (Lightweight Directory Access Protocol) is an open, vendor-neutral, industry-standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. It provides a standardized method for clients to query and update information in a directory, such as user accounts, groups, and network resources. Its "lightweight" designation refers to its streamlined design compared to its predecessor, X.500 DAP, making it efficient for common directory operations.

Separation of duties (SoD) is an administrative control designed to prevent fraud, error, and abuse by distributing critical functions and responsibilities among multiple individuals. This ensures that no single person has complete control over an entire sensitive process, requiring collusion to compromise it. The scenario, demanding two employees to authorize a financial transaction, is a direct and classic implementation of SoD, as it mandates shared responsibility for a high-risk action.

The Authorization Code flow is the most secure and widely recommended OAuth 2.0 flow for confidential clients, such as web applications, within OpenID Connect. It involves the client redirecting the user's browser to the authorization server, receiving a temporary authorization code, and then exchanging this code directly with the authorization server's token endpoint for ID and access tokens. This method prevents sensitive tokens from being exposed in the user's browser or URL, enhancing security significantly.

When an employee departs an organization and their associated user account remains active in the identity provider or directory services without an assigned owner, it is classified as an orphaned account. These accounts pose significant security risks as they lack accountability and are prime targets for unauthorized access or exploitation.

The Authorization Code Grant with Proof Key for Code Exchange (PKCE) is the recommended flow for public clients, such as mobile and single-page applications. PKCE mitigates the authorization code interception attack by requiring the client to generate a cryptographically random `code_verifier` and a `code_challenge` derived from it. This ensures that only the legitimate client that initiated the authorization request can exchange the authorization code for an access token, even if the code is intercepted.

Deprovisioning is the critical phase within the identity and access management (IAM) lifecycle that systematically revokes all access rights and disables or deletes user accounts when an individual's relationship with the organization ends or their role changes significantly. This process ensures that former employees or contractors can no longer access corporate resources, mitigating the risk of unauthorized access and data breaches. Effective deprovisioning involves removing access across all connected systems, applications, and physical access controls in a timely and comprehensive manner.

Regulatory frameworks such as HIPAA, PCI-DSS, and SOX mandate strict access control policies, including the prompt deprovisioning of inactive or terminated user accounts. Failing to identify and disable these orphaned accounts directly violates compliance requirements, potentially resulting in severe financial penalties, failed audits, and legal liabilities for the organization.

Privileged Access Management (PAM) solutions are specifically engineered to secure, manage, and monitor highly sensitive administrative accounts and access to critical systems. They enforce just-in-time (JIT) access, granting elevated permissions only when an administrator needs them for a specific task and for a limited duration, thereby significantly minimizing the attack surface. PAM also typically includes essential features like session recording, password vaulting, and comprehensive audit trails, which are crucial for compliance and incident response related to high-risk administrative operations.

Recertification is the essential periodic process of formally reviewing and validating that users' current access rights and privileges remain appropriate and necessary for their assigned job functions. This proactive measure ensures adherence to the principle of least privilege over time, identifying and remediating instances of 'privilege creep' where users accumulate excessive permissions. It significantly reduces the organization's attack surface by eliminating unnecessary access.

The Distinguished Name (DN) serves as the absolute and unambiguous identifier for every entry within an LDAP directory. It is a sequence of Relative Distinguished Names (RDNs) that traces a unique path from the root of the directory information tree (DIT) down to the specific entry. This hierarchical structure ensures that no two entries can possess the exact same DN, guaranteeing global uniqueness across the entire LDAP directory service.

The authorization code grant with PKCE lets the budgeting app obtain a limited access token after the customer authenticates directly with the bank, so credentials are never shared. PKCE protects the code exchange from interception on public clients such as mobile apps, matching the delegation and security requirements of this scenario.

Separation of duties is a control designed to prevent fraud, error, and abuse by ensuring that no single individual has complete control over a critical process from start to finish. It mandates that different individuals perform distinct parts of a sensitive task, such as authorizing, recording, and reconciling transactions. This structure prevents a single employee from both initiating and approving a financial transaction, thereby mitigating the risk of unauthorized actions.

An orphaned account is a user or service account that no longer has an active, accountable owner or associated employee, often due to an employee's departure without proper deprovisioning. When a security analyst discovers such an account during an access rights review, it represents a significant security vulnerability as it could be exploited without detection or used to maintain unauthorized access. These accounts pose a risk because they lack oversight and may retain elevated privileges, making them prime targets for malicious actors. Identifying them is a critical part of regular access reviews and identity lifecycle management.