Cipafilter Documentation - Authentication Tools
Posted by Jim Giseburt, Last modified by Jim Giseburt on 11 April 2017 03:06 PM
This page provides information and tools related to authentication.
This table lists all records currently recognized by the system's authentication engine. For each record, the IP address, host name, user name, group name, TTL (seconds left until expiry), and source of authentication are listed, where applicable. Users who are authorized but not actually authenticated are listed with their IP address as the user name. A record may be manually expired (deleted) by clicking its trash icon. The Re-authenticate All button will force the system to reload all records — note that this may place a temporary but significant load on the filter and any authentication back-ends it is configured for.
Persistent Authentication Tokens
This table lists all users who have a persistent authentication token for the captive portal. For each record, the user name, number of tokens (this usually corresponds to the total number of devices and browsers the user has used to log in to the portal), number of sessions the user currently has active as a result of persistent authentication, and date and time of the last token's creation are listed. Clicking a record's trash icon will delete all tokens for the associated user and also de-authenticate any active persistent-auth sessions, forcing the user to manually log back in. Sessions which are not the result of persistent authentication will not be de-authenticated.
This tool can be used to test the group membership that would be applied to a particular user/IP combination. Only the user name is required. When no IP address is supplied, the specified credentials will be queried against all configured authentication back-ends, and the tool will (where applicable) report the first group result which matches the group configuration on the filter. If a password is supplied, the query will test its validity; an incorrect password will result in a failed query. If an IP address is supplied, it will be matched against the filter's authorized proxy subnet rules.
This tab lists information about the filter's internal directory cache. This cache is used, where supported, to prevent unnecessary load on external authentication services like Google Directory and Active Directory. The cache is automatically updated every 30 minutes. Only user/group names, group memberships, and related metadata required for log-in and group placement are stored locally; the filter does not cache passwords or non-authentication-related data. Note that the number of records listed for each authentication method should be at least the number of users and groups in that directory, but will (for various implementation reasons) often be much higher.
During intensive troubleshooting, it may be necessary to clear the directory cache and/or reload the authentication engine and content filter. Pressing the Clear Cache button will clear and reset the membership cache, forcing the filter to rebuild it. The Clear Cache and Reload Services button will additionally trigger the authentication engine and content filter to reload, which should clear any invalid entries, update any existing ones, and inject any new ones. Please note that both of these actions may put a temporary but significant load on the filter and any authentication back-ends it is configured for.