User And Device Security practice questions

Configure the Duo Authentication Proxy for RADIUS bypass

Why it fails: RADIUS bypass is for legacy network access, not device management.

Enable 'Trusted Endpoints' in the Duo Admin panel without certificate deployment

Why it fails: Trusted endpoints require a valid certificate to verify management status.

Assign a static IP address to every endpoint

Why it fails: IP addressing does not provide reliable device management identity.

In the global organization settings

Why it fails: Global settings would apply to all applications, not just Salesforce.

In the Salesforce administrative console only

Why it fails: While Salesforce has IP restrictions, Duo policies are the standard way to enforce MFA-based access control.

In the local workstation host file

Why it fails: This is a client-side configuration that cannot be managed centrally.

Duo API Gateway

Why it fails: This is not a standard Cisco Duo component name.

Duo Universal Prompt

Why it fails: The Universal Prompt is for web-based SSO applications.

Direct integration via browser extension

Why it fails: Browser extensions are not the standard way to protect legacy applications.

To enforce hardware-based encryption on AD servers

Why it fails: This is outside the scope of the proxy.

To store user passwords locally

Why it fails: Duo does not store user passwords.

To serve as the primary identity provider for the cloud

Why it fails: The AD server remains the source of truth; the proxy just syncs it.

Duo Phone Callback

Why it fails: Callback is an alternative, not a phishing prevention feature for Push.

Duo Hardware Tokens

Why it fails: While secure, they do not have the interactive number matching flow.

Duo Passwordless

Why it fails: Passwordless prevents credential theft, but number matching is a specific Push feature.

The Duo Authentication Proxy cannot reach the AD server

Why it fails: This would usually yield a different error related to connection timeouts.

The user's password is expired in AD

Why it fails: Duo does not typically report password expiration as 'user not found'.

The Duo service is experiencing an outage

Why it fails: Outages are reported differently than specific user-level errors.

Duo Mobile TOTP

Why it fails: Requires the app to be installed on a mobile device.

Duo Push

Why it fails: Requires internet.

Phone Callback

Why it fails: Requires a live line, but not a mobile device.

The Duo Authentication Proxy must be in 'Bypass' mode

Why it fails: Bypass mode is for troubleshooting.

The device must be joined to the domain

Why it fails: Not required for self-enrollment.

Wipe the device remotely

Why it fails: Duo cannot perform MDM wipe commands directly.

Disable the user's AD account via the Duo dashboard

Why it fails: Duo cannot modify AD accounts.

Local storage of user credentials

Why it fails: Duo never stores passwords.

Provides an offline authentication database

Why it fails: It does not cache credentials.

Direct replacement of the Active Directory domain controller

Why it fails: It cannot replace the DC.

Direct SAML 2.0 Identity Provider hosting

Why it fails: Duo SSO hosts SAML, not the proxy.

SQL database direct authentication

Why it fails: Not supported natively.

The user has not enrolled a device yet

Why it fails: Result is enrollment failure.

The user forgot their password

Why it fails: Result is authentication failure.

The Duo service is temporarily down

Why it fails: Result is an error or bypass, not an access denied.

The user's email address

Why it fails: Not used to identify the client.

The Duo API key of the user

Why it fails: Users don't have API keys.

The device's MAC address

Why it fails: Not used in RADIUS matching.

Posture assessment

Why it fails: Posture assessment checks device compliance, such as antivirus status or OS patches, but it does not inherently differentiate between corporate and employee-owned devices for VLAN assignment. While posture can be part of an authorization policy, it does not provide the ownership classification needed here. The scenario requires distinguishing device ownership, which posture alone cannot do. Therefore, posture is not the primary feature to meet the requirement.

Profiling

Why it fails: Profiling identifies device types and operating systems by collecting attributes, but it does not reliably determine ownership. Employee-owned devices might be profiled similarly to corporate devices if they share hardware characteristics. Profiling can inform policy, but it is not the definitive method for separating corporate from employee-owned endpoints. The administrator needs a more explicit ownership-based control.

Change of Authorization (CoA)

Why it fails: CoA is used to dynamically change a device's authorization after the initial authentication, such as moving it to a different VLAN when posture status changes. However, CoA itself does not determine device ownership; it enforces a policy decision. Without a method to identify corporate versus employee-owned devices, CoA cannot achieve the desired segmentation. Thus, it is not the feature to configure for this scenario.

Configure an external identity source for certificate authentication

Why it fails: External identity sources are used for user authentication, not for validating device certificates. In EAP-TLS, the certificate is validated against trusted CA certificates stored in ISE. An external identity source would not help with chain validation. Thus, this option does not meet the requirement.

Enable OCSP checking

Why it fails: OCSP checking is used to query the revocation status of a certificate in real-time. Like CRL, it does not validate the certificate chain. The requirement is to ensure the certificate is issued by the corporate CA, which is chain validation. OCSP is a complementary feature but not the primary configuration for chain validation. Therefore, this option is incorrect.

Enable certificate revocation list (CRL) checking

Why it fails: CRL checking validates that a certificate has not been revoked, but it does not validate the certificate chain itself. The scenario requires ensuring that the certificate is issued by the corporate CA, which is chain validation. CRL checking is an additional security measure but not the primary requirement for chain validation. Therefore, this is not the correct configuration to enable certificate chain validation.

Configure 802.1X authentication on all access ports

Why it fails: 802.1X authentication is used to authenticate users and devices and assign them to the network. While it is often part of a TrustSec deployment to assign SGTs dynamically, it is not the component that enforces SGACLs. The scenario already assumes SGTs are assigned; the missing piece is propagation and enforcement. Thus, 802.1X alone does not meet the requirement.

Configure Change of Authorization (CoA) on ISE

Why it fails: CoA is used to dynamically change a session's authorization, such as reassigning VLAN or SGT after a posture change. It is not the component that enforces SGACLs. Enforcement happens on the network device using the SGTs and SGACLs. CoA might be used to update SGTs, but it is not the primary requirement for enforcement. Hence, this option is not correct.

Enable Device Sensor on the switches

Why it fails: Device Sensor is used to collect endpoint attributes for profiling, such as CDP or LLDP information. It does not play a role in SGT propagation or SGACL enforcement. While profiling can inform policy, it is not required for TrustSec segmentation. Therefore, this option is incorrect for the given scenario.

Match on the calling station ID (MAC address) against a list of corporate devices

Why it fails: Matching on MAC address is not a reliable indicator of domain join, as MAC addresses can be spoofed and managing a list is impractical. It does not verify domain membership. The requirement is to ensure devices are domain-joined, which requires a more secure and dynamic condition. Thus, this option is not suitable.

Match on the user's group membership in Active Directory

Why it fails: Matching on user group membership verifies the user's identity and role, but it does not ensure that the device is domain-joined. A user could connect from a non-domain-joined device using their credentials. The requirement is to restrict access to domain-joined devices, which requires a device-based condition, not a user-based one. Therefore, this condition does not meet the requirement.

Match on the device's certificate issued by the domain CA

Why it fails: PEAP-MSCHAPv2 does not use client certificates for authentication; it uses username and password. While a device certificate could be used in EAP-TLS, the scenario specifies PEAP-MSCHAPv2. Therefore, matching on a certificate is not applicable here. The administrator needs a condition that works with PEAP-MSCHAPv2 to identify domain-joined devices.

In the Active Directory GPO for the user

Why it fails: Active Directory Group Policy manages Windows clients and domain objects; it cannot govern Duo's cloud SSO browser checks. It is tempting because GPO is the familiar place for browser restrictions in managed estates, but this denial originates from Duo's own policy settings, applied before the application is reached.

In the Duo Authentication Proxy configuration file

Why it fails: The Duo Authentication Proxy handles on-premises LDAP and RADIUS authentication, not browser policy for cloud SSO. It is tempting because the proxy is a genuine Duo component administrators configure, but browser support restrictions for a cloud application are set in the Duo policy settings in the Duo Admin Panel.

In the local browser settings of the client machine

Why it fails: Client browser settings control which browser the user runs, not which browsers Duo accepts for a protected application. It is tempting because the error names the browser, suggesting a local cause, but the allow-list is enforced server-side by Duo's policy configuration, not by anything on the endpoint.

By analyzing the user's browser user-agent string

Why it fails: Duo assesses device health through its Device Health application, which reports OS patch level, disk encryption and firewall status; the user-agent string only identifies browser and platform. It is tempting because user-agent parsing is used for browser-based policy, but that governs access, not out-of-date status.

By querying the Active Directory server for the last patch date

Why it fails: Duo reads patch state from its own endpoint client telemetry, not from Active Directory, which stores no reliable last-patch attribute for managed devices. Querying AD would suit identity or group-membership lookups, but it cannot supply the OS build data Duo needs to flag a device as Out-of-Date.

By checking the device's public IP address geolocation

Why it fails: Duo's Out-of-Date status derives from the device's OS patch level and Duo software version, reported by the Duo Desktop or mobile client, not from network metadata. Geolocation via public IP only informs policies such as country-based access restrictions, so it would be the right signal for blocking logins from unexpected regions.

Microsoft Conditional Access Policy

Why it fails: Microsoft Conditional Access enforces Entra ID sign-in conditions such as device compliance or location, and cannot read Cisco Duo Device Health posture signals. It is tempting because it is Microsoft's posture engine, but it would be correct only for Entra-registered devices using Intune compliance, not Duo's patch check.

Duo Authentication Proxy

Why it fails: The Authentication Proxy brokers LDAP and RADIUS authentication for on-premises applications, not cloud app posture enforcement. It is tempting because it sits in the Duo authentication path, but Duo's cloud service, not the proxy, evaluates Device Health signals and returns the allow or deny decision for browser-based cloud access.

Duo Device Health Application

Why it fails: The Device Health application only collects and reports endpoint signals such as patch status to Duo's cloud; it does not itself permit or block the authentication. It is tempting because it detects the missing patch, but enforcement happens server-side in Duo's policy engine, which returns the deny to the requesting application.