Web Auth And Guest Services practice questions

The endpoint must be statically assigned an IP.

Why it fails: LWA works with DHCP as well.

A redirect ACL must be applied to the ISE interface.

Why it fails: Redirect ACLs are for CWA.

The ISE node must be the default gateway.

Why it fails: ISE does not need to be the gateway.

Administration > Identity Management > Identities

Why it fails: This is for general identity creation, not portal configuration.

Work Centers > Guest Access > Sponsor Groups

Why it fails: This is for grouping sponsors, not portal configuration.

Policy > Policy Elements > Results

Why it fails: This is for authorization results.

Policy > Policy Elements > Results > Authorization Profiles

Why it fails: AUP is a portal setting, not an auth profile attribute.

Work Centers > Guest Access > Settings > AUP

Why it fails: This is not a valid navigation path.

Administration > System > Settings > Guest

Why it fails: This is for global guest settings, not portal-specific AUP.

cisco-av-pair = redirect-url=http://ise.example.com

Why it fails: This is not the correct attribute name for CWA.

cisco-av-pair = redirect-to=https://ise.example.com

Why it fails: This is not a valid RADIUS attribute for CWA.

cisco-av-pair = url-redirect-acl=REDIRECT_ACL

Why it fails: This attribute defines the ACL name, not the URL itself.

Self-Registered Guest

Why it fails: Self-registration is for user-created accounts, not necessarily time-bound.

Hotspot Guest

Why it fails: Hotspot guests do not have account management associated with them.

Sponsored Guest

Why it fails: Sponsored guests still require manual management unless auto-expiration is set.

The guest user account is expired.

Why it fails: This would deny access, not cause a loop.

The switch is configured for redundant ISE nodes.

Why it fails: Redundancy does not cause redirect loops.

The CoA port is blocked by a firewall.

Why it fails: This would cause authentication to fail, not a redirect loop.

Enable MAC filtering on the ISE.

Why it fails: MAC filtering is for admission control, not peer isolation.

Configure a higher VLAN for the guests.

Why it fails: VLANs do not inherently block peer-to-peer traffic within the same VLAN.

Configure a static route on the default gateway.

Why it fails: Static routes do not control local subnet traffic.

A WLC with WPA3-Enterprise.

Why it fails: Not mandatory; CWA works with various security levels.

A local user database on the switch.

Why it fails: ISE handles the authentication.

A static IP address for all guest clients.

Why it fails: DHCP is typically used.

The user's email address.

Why it fails: Email is for identity, not device identification.

The switch's hostname.

Why it fails: This is not a device identifier.

The user's IP address.

Why it fails: IPs change and are not reliable for caching.

Default Sponsor email.

Why it fails: Optional setting.

Primary DNS server IP.

Why it fails: Not a portal config field.

The guest's device is blocked by a MAC filter.

Why it fails: This leads to an authentication failure.

The Guest user provided an invalid password.

Why it fails: This leads to an 'invalid credentials' message.

The NAD is not configured for RADIUS.

Why it fails: This prevents initial network access.

The RADIUS shared secret.

Why it fails: Shared secret is configured on the device, not in the profile.

The 'Framed-IP-Address'.

Why it fails: Managed by DHCP.

The ISE node is not reachable via the DNS server specified in the guest VLAN.

Why it fails: DNS issues would prevent the initial portal load, not cause a pending account status.

The authorization policy is missing a 'permit access' rule for the guest account.

Why it fails: A missing authorization rule would typically result in a failure to access the network after approval, not a pending account status.

The guest password policy is incorrectly configured in the Guest Portal settings.

Why it fails: If the password policy were incorrect, the user would receive an error during account creation, not stay in a pending state.

Increase the idle timeout on the WLC's WLAN configuration.

Why it fails: Idle timeout settings affect session termination, not the initial portal redirection process.

Verify the WLC's 'Web Auth Redirect' configuration and ensure the 'Virtual Gateway' address is reachable.

Why it fails: While important, the most frequent point of failure in CWA redirection is the client's inability to resolve the ISE FQDN.

Re-import the Guest Portal certificate on the WLC.

Why it fails: The WLC does not require the ISE portal certificate for the initial redirect handshake.

The Access Point (AP) in FlexConnect mode.

Why it fails: While APs can perform local switching, they do not handle the RADIUS authentication logic in LWA.

The Cisco ISE node directly.

Why it fails: ISE does not interact directly with the client browser for credential submission in LWA; it interacts with the WLC.

The client browser via HTTPS POST.

Why it fails: The browser sends credentials to the WLC, not directly to ISE.

Device Sensor Service.

Why it fails: This is used for profiling, not specifically for the guest access workflow.

Active Directory Join.

Why it fails: While AD can be used as an identity store, it is not a mandatory component for guest access workflows.

MAC Authentication Bypass (MAB) enabled on the switch port

Why it fails: MAB is not required for CWA redirection. CWA can be triggered by 802.1X authentication attempts as well. In fact, MAB is often used for devices that do not support 802.1X, but it is not a mandatory component for the redirection mechanism. The redirect relies on the attributes returned in the authorization policy, regardless of the authentication method.

A certificate installed on the guest endpoint for HTTPS redirection

Why it fails: The guest endpoint does not need a certificate for the initial redirect. The redirection is performed at the network layer by the switch using HTTP redirects. The client simply receives an HTTP 302 redirect to the portal. While the portal itself may use HTTPS, the endpoint does not require a client certificate for the redirection to succeed.

A downloadable ACL (dACL) pushed from ISE to the switch

Why it fails: A downloadable ACL is not required for the initial redirection. The redirection is controlled by the url-redirect-acl, which references a preconfigured ACL on the switch. A dACL is an optional method for enforcing full access policies after authentication, but it is not needed to perform the redirect itself.

Trusted Certificates store

Why it fails: The Trusted Certificates store holds CA certificates that ISE trusts for validating other certificates, such as those from external servers. It is not used to store the server certificate that ISE presents to clients. The guest portal certificate must be a local certificate, not a trusted CA certificate, so this store is incorrect.

System Certificates store

Why it fails: The System Certificates store is used for certificates that secure communication between ISE nodes and for administrative services. It is not the correct store for portal certificates. Portal certificates should be placed in the Portal Certificates store to be used by the guest and sponsor portals. Placing the certificate here would not make it available for portal use.

Local Certificates store

Why it fails: While the Local Certificates store contains certificates used for various ISE services, it is not the dedicated store for portal certificates. The Portal Certificates store is the correct location for guest portal certificates. Using the Local Certificates store would not properly bind the certificate to the portal, and the portal might still present a default self-signed certificate.

The Cisco ISE Policy Service Node (PSN)

Why it fails: The PSN hosts the portal and evaluates policy, but the redirect itself is generated by the network access device that intercepts the initial HTTP request. It is tempting because ISE is central to CWA, and it would be correct if the question asked which node serves the guest portal or authorises the session.

The endpoint's default browser

Why it fails: The browser renders the redirect but does not issue it; the network device returns the HTTP 302 that sends the client to the portal. It is tempting because the user visibly lands in the browser, and it would be the correct component if the question asked where the guest enters credentials rather than what performs the redirection.

The Guest Portal application

Why it fails: The Guest Portal application presents the login page after redirection; it does not generate the HTTP redirect that sends the browser there. It is tempting because the portal is the visible destination of the redirect, and it would be correct if the question asked which component authenticates guest credentials or sponsors accounts.

The ISE portal is configured for HTTP instead of HTTPS.

Why it fails: HTTP portals redirect to HTTPS automatically, and the warning arises from the certificate presented on that HTTPS connection, not the initial scheme. Configuring HTTP is correct when a captive portal must accept plain-text redirects before authentication, but it does not explain the certificate warning.

The DNS server is not resolving the ISE FQDN.

Why it fails: Name resolution failure produces a browser error page, not a certificate warning; the redirect still reaches ISE by IP or the client cannot connect at all. DNS records are the correct fix when clients cannot reach the portal FQDN, but here the browser connects and rejects the presented certificate.

The switch is not configured for SSL interception.

Why it fails: Switches do not perform SSL interception; that is a proxy or firewall function, and interception would itself cause warnings rather than prevent them. Configuring SSL inspection is the right action when a proxy must decrypt and re-sign traffic, not for a guest portal redirect.