Known limitations and additional settings
IIS session logoffs
The UserLock 'IIS agent' is able to detect a logoff from Web applications that allow a user to disconnect before closing the web browser (e.g. 'Outlook Web Access'). However, this is only true when the 'Disconnect' or 'Logoff' button is clicked. If the user simply closes the web browser, the logoff will not be detected as no logoff request is sent to the server. As a consequence, both UserLock and the IIS server will still consider the session as open.
The session will be seen as closed by UserLock’s 'IIS agent' after a specific time of inactivity. By default, this timeout value is 5 minutes (see the specific section below for more details).
If a user who has been limited to 1 simultaneous IIS session through the protected account rules tries to access a Web application from another location before this timeout has been reached, UserLock will reject their logon attempt, as he is still seen as connected on the first application.
If no limit for the concurrent number of IIS sessions has been set in the protected account rules the user will be allowed a new IIS session.
We advise to properly set rules for the number of allowed concurrent sessions and to adjust the timeout value if needed.
It is also possible to close IIS sessions directly from the UserLock console. If an IIS session looks suspicious, an administrator can decide to close it immediately from the User sessions view.
IIS session timeout
As mentioned above, UserLock uses a timeout to automatically consider an IIS session as closed. By default this timeout is set to 5 minutes.
UserLock allows you to personalize this limit. To change it, first create a specific registry value on the protected IIS server:
HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\IIS\SessionTimeout
(REG_DWORD)
And then enter the desired value in minutes, for example 10.
This would mean that an IIS session without any activity for 10 minutes would be considered as closed in UserLock.
You will need to restart/recycle the application pool to apply the change.
Important note! If you reduce the timeout value too much you will get a lot of IIS logon/logoffs in the session history in UserLock.
Specify IIS Application Pools to monitor.
By default, when you configure the UserLock IIS agent on an IIS website, all applications from this site are monitored independently of the application pool they run on.
If needed, you can choose to monitor only Web applications running on specific application pools by creating the following registry value (REG_MULTI_SZ type) on the IIS server:
HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\IIS\ProtectedApplicationPools
Then enter the list of all application pools you want to supervise (one per line).
On an Exchange server for example, many Web applications are created on the 'IIS Default' website. If you configure the UserLock 'IIS agent' for this site, UserLock will display a lot of IIS sessions.
In most cases, you only want to control sessions from 'Outlook Web Access' and ignore the other Web applications. You can do this by specifying only MSExchangeOWAAppPool as application pool to monitor.
If you are interested in Active Sync, add “MSExchangeSyncAppPool”.
Please note: Using the HttpModule version of UserLock 'IIS agent' may avoid using this advanced configuration. HttpModules allow a more fine-grained protection i.e. at Web application level rather than the web site level, making the use of this advanced configuration unnecessary.
Ignore specific users
By default, when you configure the UserLock 'IIS agent' on an IIS Web application, all users from this application are monitored. Unfortunately, some Web applications have built-in accounts, used for health diagnostics or other purposes, which can create a lot of entries in the UserLock database history, degrading performance and making reports less readable. 'Health Mailbox' accounts of 'Outlook Web Access 2013' are such an example.
If needed, you can choose to ignore some of these users by creating the following registry values in the "HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\IIS" registry key on the IIS server:
- "IgnoredUsers" (REG_MULTI_SZ): The list of accounts you want to ignore using the syntax 'Domain\user_account' (one per line).
- "IgnoredLocalUsers" (REG_MULTI_SZ): The list of accounts you want to ignore only local requests i.e. requests sent from the IIS server itself.
- "IgnoredUsersPattern" (REG_MULTI_SZ): The list of accounts with a name pattern you want to ignore.
You can define patterns with the '*' character as a wildcard. This character can be the first, the last or both. Patterns are not case sensitive.Examples:
- With the "DOMAIN\J*" pattern, all DOMAIN users whose name begins with a "J" will be ignored.
- With the "*HealthMailbox*" template, all Exchange HealthMailboxes will be ignored (this template is active by default, no need to add it specifically).
- With the "*Admin" pattern, all accounts whose name ends with "Admin" will be ignored.
- "ProtectHealthmailboxSessions" (REG_DWORD): Set this value to 1 to enable auditing of HealthMailbox sessions.
You will need to restart the Application Pools protected by the IIS Agent to make the changes effective.
Application pools, IIS websites, cookies and web browsers
UserLock will differentiate an IIS session from an existing one on the same IIS server if it relates to a:
- Different website.
- Different user account.
- Different client IP address.
- Different application pool.
The above statements are independent of using different web browsers.
The UserLock 'IIS agent' tracks authenticated sessions on IIS sending a cookie. Therefore it's necessary to allow cookies in all web browser clients and enable the option to delete them on exit.
In the UserLock console the IIS session name is composed of:
- The name of the IIS server.
- The name of the Web application (if it's different from the site root application).
- The client IP address.
The name of the Web application taken into consideration is the first accessed. If other Web applications are then accessed, then the session name won't be modified (except if it's considered as a new session as mentioned before).
Forms and Windows Authentication using HTTP module
The HttpModule can now be used for both Windows and Forms Authentication with IIS applications using both authentication types. By default, the Windows authentication is activated.
Activating the new mode is possible by creating a specific registry value of type DWORD “EnableFormsAuthentication” and setting the registry value to 1 on the protected IIS server in the following path:
HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\IIS\
You will need to restart/recycle the application pool to apply the change.