Note: This topic applies to the Leeds Release.
Global authentication settings determine the common behavior, irrespective of the authentication method used, such as, login time out and debug level.
- Go to Services > Authentication > Settings.
Determines the inactivity period after which the user is logged out. The default time out is
Setting a short login time out increases the load on the machine, particularly when using transparent NTLM (see Creating Authentication Policies) or SSL (see Using SSL Authentication) login methods. It also increases the rate of re-authentication requests.
Setting a long login time out may enable unauthorized users to access the network if users leave computers without actively logging out.
The behavior of some authentication mechanisms is automatically adjusted by the time out period. For example, the SSL Login refresh rate updates to ensure that authenticated users do not time-out — see Managing Authentication Policies.
Tip: You should encourage users to proactively log out of the system to ensure that other users of their workstation cannot assume their privileges if Login timeout (minutes) is yet to occur.
Determines the number of log in attempts allowed per user.
You can either choose to have No limit on the number of attempts, or enter the number of attempts allowed.
Determines whether all variations of username and domain are normalized into the same format. For example, Active Directory prefers DOMAIN
\user, but can accept
DOMAIN\user, and so on.
The Smoothwall stores the user-supplied username in the configured directory server’s preferred format. This reduces the number of possible forms of a username to one, preventing users circumventing temporary bans by using a different format of username for example. For a detailed description of each preferred format, see About Directory Services.
If you are migrating configuration from another Smoothwall installation, this setting is disabled by default to prevent log-searches and username-based reports from not working, and ensuring any temporary bans before the migration still apply. If required, this feature can then be enabled at a convenient time.
Unless BYOD clients require access to other parts of your internal network through the Smoothwall, it is recommended you turn this option off.
This section relates to the ID Indexing System, which provides a way of reliably identifying already authenticated users in a wide variety of wide-area, Active Directory domain networks, where link and speed cannot be guaranteed. The settings here relate to how user identity is handled by the Smoothwall.
The IDex Cluster shares the information received from the IDex Client and the IDex Agent between all nodes in a Central Management cluster (see Setting up a Centrally Managed System), so that web filtering requests can be load-balanced between them.
If your Smoothwall makes use of the ID Indexing System and Central Management features , you must enter the IP addresses of all nodes here, including this node's IP address. You must repeat this task on each node in the cluster.
Each IP address must be on a separate new line. If required, you can copy and paste a list of IP addresses from another source to this field. For example,
When IDex configuration is changed, such that new directories are added with different database keys, or the database keys for an existing directory are changed, it may be necessary to clear the IDex Directories to remove obsolete information.
The Clear IDex database operation will clear user and group authentication information from the IDex Directory. All information will be removed up to the point in time the clear request was made. The Clear operation will log off any users currently logged into the system, therefore it is recommended that this operation be performed when there is minimal user activity.
The clear process will be performed across the entire IDex Cluster, there is no need to perform the Clear directory operation on all cluster nodes.
Note: Defined mapping will be preserved when performing the IDex directory clear.
The process of clearing the IDex directory may take some time to complete and result in higher system load for all nodes in the IDex Cluster. The amount of time required to perform the operation will depend on the amount of information stored in the IDex Database, and in turn this depends on the number of users in your system, the number of groups, how many users are logged on, and how many IDex Cluster nodes there are.
Determines whether you can create Firewall rules for groups that contain IDex-identified users requiring access to other segments of your internal network. Our knowledge base article, How do I create a Group Bridging Rule in the New Firewall?, provides more information about using groups in Firewall rules.
Unless IDex-identified users do require access to other segments of your internal network specifically through the Smoothwall, it is recommended you leave this option off.
- Click Save changes.