When you select the Include inactive users option, the inactive users are listed in grey in the Active User Sessions panel of the Users > Status page.

On the Dashboard > User Monitor page, when you click the Tools icon, you can select the user types that you want to display, including Inactive Users.

When you select Inactive Users, the inactive users are shown in grey on the User Monitor. This graphic shows a test repeatedly logging 50,000 users in and then letting them go inactive.

On the Users > Status page, each panel has a Filter button and an associated input box to enter the filter string. Help information is displayed when you pause your mouse over the Filter button.

When you pause your mouse over the Stats button, the user counts are displayed.

Don't block user traffic while waiting for SSO

When traffic is received from an unidentified user the UTM appliance normally queues the packets until the user has been identified so that the correct access rights and policies can be applied for these initial connections from the user. That, however, can lead to delays being seen by the users if the SSO agents are slow to identify the users, and such slowness can happen particularly if the agents are overloaded with large numbers of requests to process, as can happen especially in large environments.

When this new setting is enabled the appliance will let the user’s traffic through instead of queuing it while waiting for the user to be identified, applying default policies at this time. Note that this will avoid delays being seen by the users, but could result in some users initially getting blocked from access to something to which they would normally be allowed, or in some cases possibly getting access to something that they would normally be blocked from (the latter would be unusual).

By default this setting will apply when SSO is required for App Rules, CFS policies¹ or manually-set SSO enforcement, but not when it is required for access rules. However there will be settings to override that and have it applied for access rules too, either for all access rules or for selected ones. When the latter is selected a checkbox will appear in the access rules to select those to which is applies.

Try next agent on getting no name from NetAPI/WMI

When using NetAPI/WMI the UTM appliance normally assumes that any SSO agent can identify any user, and so it picks an agent to use based on current loadings, and if that agent returns no user name and no error then the appliance assumes that other agents will give the same result and does not retry. But operation of the underlying NetAPI/WMI protocols is performed by Windows and is out of the SSO agent’s control, and it has been found, particularly in large complex environments, that there have been cases where one agent would get back no name for a user while another agent could identify that same user.

So this new setting is added for that situation. If it is enabled then on getting back no user name and no error from an agent that used NetAPI or WMI the appliance will handle that as it handles errors, re-trying the request to another agent and trying each-agent in turn until it gets back a user name or until the configured retry count is exhausted.

And mouse-over on the new “stats” icon to the left of the filter button brings up the user counts display dialog as shown here.

1.: Note that the packets are not queued while waiting for SSO – this does not mean that they won’t be blocked by App rules or CFS and they are still subject to those, as applied for an unknown user.