Troubleshoot the Captive Portal Identity Source

For other related troubleshooting information, see Troubleshoot Realms and User Downloads and Troubleshoot User Control.

If you experience issues with captive portal, check the following:

  • The time on your captive portal server must be synchronized with the time on the Cisco Defense Orchestrator.

  • If you have DNS resolution configured and you create an identity rule to perform Kerberos (or HTTP Negotiate, if you want Kerberos as an option) captive portal, you must configure your DNS server to resolve the fully qualified domain name (FQDN) of the captive portal device. The FQDN must match the hostname you provided when configuring DNS.

  • If you're using Kerberos authentication, the managed device's host name must be less than 15 characters (it's a NetBIOS limitation set by Windows); otherwise, captive portal authentication fails. You set the managed device host name when you set up the device. For more information, see an article like this one on the Microsoft documentation site: Naming conventions in Active Directory for computers, domains, sites, and OUs.

  • DNS must return a response of 64KB or less to the hostname; otherwise, testing the connection the AD connection fails. This limit applies in both directions and is discussed in RFC 6891 section-6.2.5.

  • If you select Kerberos (or HTTP Negotiate, if you want Kerberos as an option) as the Authentication Type in an identity rule, the Realm you select must be configured with an AD Join Username and AD Join Password to perform Kerberos captive portal active authentication.

  • If you select HTTP Basic as the Authentication Type in an identity rule, users on your network might not notice their sessions time out. Most web browsers cache the credentials from HTTP Basic logins and use the credentials to seamlessly begin a new session after an old session times out.

  • If the connection between your Cisco Defense Orchestrator and a managed device fails, no captive portal logins reported by the device can be identified during the downtime, unless the users were previously seen and downloaded to the Cisco Defense Orchestrator. The unidentified users are logged as Unknown users on the Cisco Defense Orchestrator. After the downtime, the Unknown users are reidentified and processed according to the rules in your identity policy.

  • If the device you want to use for captive portal contains both inline and routed interfaces, you must configure a zone condition in your captive portal identity rules to target only the routed interfaces on the captive portal device.

  • The host name of the managed device must be less than 15 characters for Kerberos authentication to succeed.

  • The only way to be sure a user logs out is to close and reopen the browser. Unless that happens, in some cases, the user can log out of captive portal and be able to access the network without authenticating again using the same browser.

  • Active FTP sessions are displayed as the Unknown user in events. This is normal because, in active FTP, the server (not the client) initiates the connection and the FTP server should not have an associated user name. For more information about active FTP, see RFC 959.

  • When captive portal authenticates users that match an identity rule, any user in an Active Directory or LDAP group that has not been downloaded is identified as Unknown. To avoid users being identified as Unknown, configure the realm to download users in all groups you expect to authenticate with captive portal. Unknown users are handled according to the associated access policy; if the access policy is configured to block Unknown users, these users are blocked.

    To make sure the system downloads all users in a realm, make sure the groups are in the Available Groups list in the realm's configuration.

    For more information, see Synchronize Users and Groups.