Maximum SSO user logins and functionality of inactive users options
Description
This article covers the maximum SSO user logins and functionality of inactive users option under Users | Status.
Resolution
You can find the Maximum SSO User logins from the TSR / Tech Support report of the UTM appliance itself, the steps are as follows:
Step 1: Login the the UTM appliance and go to System | Diagnostics page.
Step 2: Enable the include "Debug information in report" option and click on Download Report button.
.
The following table lists the Max SSO user logins for all UTM appliances:
| Next Generation Firewall | 6.1.1/6.1.2/6.2.0 |
| SuperMassive 9600: | 100,000 |
| SuperMassive 9400: | 90,000 |
| SuperMassive 9200: | 80,000 |
| NSA 6600: | 70,000 |
| NSA 5600: | 60,000 |
| NSA 4600: | 50,000 |
| NSA 3600: | 50,000 |
| NSA 2600 | 30,000 |
| E10x00 SuperMassive: | 6.0.1 | 6.0.5 (and 6.1.2/6.2.0) |
| SuperMassive E10800: | 20,000 | 60,000 |
| SuperMassive E10400: | 15,000 | 40,000 |
| SuperMassive E10200: | 12,000 | 20,000 |
| Legacy UTM appliances | 5.8.1/5.9.0 |
| NSA E8510 thru E7500: | 7,500 |
| NSA E6500: | 4,000 |
| NSA E5500: | 2,500 |
NSA 5000: | 2,000 |
NSA 4500: | 1,000 |
| NSA 3500: | 500 |
| NSA 2400/2400 MX: | 250 |
| NSA 250 M: | 150 |
| NSA 240: | 150 |
| NSA 220: | 250 |
| All TZs: | 250 |
Please note: From 5.9.0, 6.1.2 and 6.0.5 firmware onwards a new option"Include Inactive Users" table has been added which allows twice this number of inactive users in addition to the above number of active SSO users (so the total limits effectively go up by a factor of 3). For example: SM 9600 running 6.1.2 and above will actually allow up to 60,000 SSO-identified users with up to 20,000 of them being active at any time.
Functionality of the Inactive User option (by Ian Puleston):
The main reason for adding the Inactive Users table was to be able to more efficiently handle unsolicited notifications of new user logins being sent to the appliance, where those users may or may not subsequently send traffic to the appliance, or may do so only some time later. It's general purpose is to allow the appliance to save information on users who are not actively passing traffic through it, with the minimum amount of data stored and minimal overhead running timers etc. for them, hence allowing much larger numbers of these users to be stored than if they were fully logged in and active.
For example: Customer has 2,000 employees, but no more than 1,000 of them accessing the internet at any time. It would seem that an NSA 4500 should be sufficient for their needs with its 1,000 user limit, and at one time that would have been the case. But with first DC log monitoring being added to the SSO agent, and more recently, RADIUS accounting, the appliance gets notified when users log in and so could conceivably be notified of anything up to 2,000 users including those who are not actually sending traffic through it, and that would exceed the limits of the NSA 4500. So now, those who are actively working through it will get logged in, and the others will be made inactive, with the NSA 4500 allowing up to 2,000 inactive in addition to the 1,000 limit for logged in users.
There are three new setting on the Users / Setting page governing use of the Inactive Users table:
If the first is checked, then on getting an unsolicited notification** of a new user login in any of the following cases, the user will be added to the inactive users table (with no LDAP user group lookup at this point) rather than being logged in:
- A change in user detected by an SSO during polling***,
- A user login notified to the appliance via RADIUS accounting.
If the 2nd is checked then on inactivity timeout the user will be moved to the inactive users table rather than logged out completely as they otherwise would be. In this case their user group memberships are saved too, hence avoiding the need for another LDAP lookup should the user become active again.
** Note that when the appliance sends a user request to an SSO agent after getting traffic from a user, that user is fully logged in, not made inactive on getting back a reply with a user name.
** When a change in user is detected during polling, previously we would log the old user out and ignore the new user. Now the old user is logged out and the new one made inactive.
Then on receiving traffic from a user, if the user is in the Inactive users table they are immediately made active and logged in, and if not already done the LDAP user group lookup is done. Also, since we don't poll inactive users, at this point a request is sent to the SSO agent to verify that the same user is still logged in.
Once a user has been made inactive, in most cases they will be removed from the inactive users table if they have not sent traffic and been activated after the "Age out inactive users after" time. The exceptions to this (which are also cases where the inactivity timer is not run for active users) are cases where the appliance can't proactively re-authenticate the user (currently, users identified to it via RADIUS accounting).
What is stored in the inactive user table is basically just what us sent from the SSO agent or RADIUS accounting client, i.e. the user name and domain plus information on how the user was identified, along with the time at which it happened. And when a previously active user gets moved to there on inactivity timeout their user group membership list is saved in it too.
There is one additional control for displaying inactive users on the Users / Status page, and when it is checked they are shown mixed in with the active users but greyed:
