Agents
UserLock uses agents deployed on machines to collect logon information and protect sessions using access policies. Three different types of agents can be deployed to protect Windows sessions.
Note
For more information on deploying each agent, see the Deploying an agent section of our Getting Started Guide.
The UserLock Desktop agent is designed to audit, control and protect workstations, servers and terminal servers. This agent audits all interactive sessions activity on these machines and protects them by applying restrictions defined through access policies.
This Desktop agent has to be installed on the machines you want to monitor and protect. It communicates with the UserLock servers to control all open requests for interactive sessions.
)
)
)
)
)
From version 12.2, UserLock has integrated a credential provider that allows the service to interact with the Windows login before the session is open.
The credential provider is a DLL that deactivates other credential providers so that they are not displayed to the user.
If you use other credential providers, the UserLock credential provider may not be used, in which case UserLock protection will be provided by the older UserLock agent technology.
When the user logs in with their Windows credentials, the UserLock credential provider checks Active Directory to verify if the user is authorized to log in.
If user is refused by Active Directory, the event is logged in UserLock.
If the connection is allowed, the credential provider contacts the UserLock server to verify if UserLock policies allow the user to log in.
If the user is refused by UserLock, the event is logged in UserLock, and the connection is refused.
If the user needs to be enrolled in MFA, the enrollment dialogs are not displayed by the credential provider (this technology allows very few GUI possibilities) but by the login process part of the agent that takes over to manage the enrollment.
If the UserLock server is not reachable, the credential provider manages the offline MFA according to the settings in Logons without network connection.
When a user's password expires, the following process is required if MFA is configured:
Password Expiry Detection: Upon login, the system detects an expired password and prompts for a change.
MFA Validation: If MFA is enabled, the user must successfully validate their MFA (e.g. OTP, authenticator app) before they can change their password.
Failure to Validate: If MFA validation fails, the user cannot proceed with the password change.
Password Change: After successful MFA, the user can change their password following defined complexity rules.
This ensures secure password updates when MFA is in place.
The Desktop agent is a Windows service defined to run as Local system.
When a session is authorized by Windows authentication, the system usually starts the UserInit process in order to initialize the session. UserLock configures the system to start the ULAgentExe process instead. The ULAgentExe process asks the UserLock server if the session is allowed, and then only if the session is allowed with regards to the defined access policies, the UserInit process is started to initialize the session. Otherwise the session is closed.
Note
This page is about the Desktop Agent for Windows starting with Windows Vista / Server 2008. For Windows XP / Server 2003 R2 and older, another technology was used, contact us if needed.
The UserLock Primary server always deploys its own network address and the network address of the Backup server to all agents. The agent will normally be able to contact a UserLock server without any problem.
The agent tries various ways to contact the UserLock servers in the following order:
The UserLock Primary server (deployed address).
The latest successfully contacted server (if different from the Primary server).
The UserLock Backup server (deployed address) if different from the latest successfully contacted server.
If no primary UserLock server name is deployed (in Winlogon or GPO), the agent attempts to contact a server named UserLock. In order to use this feature, you just need to add an entry in your DNS to link the UserLock name to your UserLock server.
If no primary UserLock server name is deployed (in Winlogon or GPO), the agent attempts to contact a server named UserLockBackup (see previous line).
Note
If you used Group Policy deployment to deploy the primary server and / or backup server name: a setting configured through Group Policy deployment will override the value of the same setting deployed by the service or configured manually.
The agent tries to first ping the server before initiating the communication so the ICMP protocol should be allowed between clients and UserLock servers.
The agent communicates with the UserLock server via the Microsoft Print and File Sharing protocol (SMB TCP 445). Typically client workstations need to be able to access shares on UserLock servers.
In the event of failure to connect using the procedure listed above, it is possible to an alternative method where the agent contacts the service via the Internet. This feature is called UserLock Anywhere.
You can implement this option by following this guide.
)
)
)
On a Windows server the Network Policy Service (NPS) allows you to authenticate users with the RADIUS protocol. This protocol is used by hardware routers to authenticate VPN users and, through Wi-Fi access points, to authenticate Wi-Fi client users.
UserLock can audit, control and restrict Wi-Fi and VPN sessions authenticated through NPS architecture thanks to the UserLock NPS agent specifically designed to be loaded in the Network Policy Server service.
UserLock doesn't deploy this specific agent automatically. It needs to be deployed manually through the console or by file copy.
)
)
)
)
)
The NPS agent is an extension DLL registered in the Network Policy Server service.
This DLL is called every time a user needs to be authenticated by NPS (RADIUS authentication) and when a session is opened and closed (RADIUS accounting technology). You will find more information on this technology in the following page of the MSDN:
http://msdn.microsoft.com/en-us/library/bb891989(VS.85).aspx
Note
NPS supports multiple administration DLLs. You shouldn't encounter any conflict if NPS administration DLLs are already installed.
The registry supports multiple DLL locations (REG_MULTI_SZ value type).
NPS calls the functions in the DLLs in the order in which the DLLs are listed in the registry.
Since all Wi-Fi Access Points do not fully comply with the RADIUS standard and do not always notify Wi-Fi disconnections, it is possible that the same session (the same user account, the same device, possibly the same Wi-Fi Access Point) appears multiple times in the UserLock data.
We have created 2 options in the NPS UserLock agent to avoid this:
In your NPS server (s), launch RegEdit, browse the following registry key :
HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\IASThen create the DWORD (32-bit) value AutoResetPreviousSessionSameData, set its contents to 0 or 1.
Optional, set the value AutoResetPreviousSessionSameDataAndWap and set its contents to 0 or 1 (see behaviors below):
Auto Reset Previous Session Same Data | Auto Reset Previous Session Same Data And Wap | Session with same user account, client device and WAP | Session with same user account and client device but different WAP |
|---|---|---|---|
ON | ON | Auto reset | No auto reset |
ON | OFF | Auto reset | Auto reset |
OFF | OFF | No auto reset | No auto reset |
UserLock can monitor, control and apply a user access control policy on Internet Information Services (IIS) sessions. To supervise IIS sessions, you need to deploy and set the UserLock IIS agent. The Agent distribution engine automatically detects servers where Internet Information Services is installed and running.
)
)
)
)
)
The UserLock IIS agent is specifically designed to be loaded in the Microsoft IIS service. It is compatible with all IIS applications configured with the following authentication modes: Windows Authentication, Forms Authentication or Basic Authentication.
UserLock can monitor the Internet Information Services (IIS) sessions. This feature allows you to restrict and monitor IIS sessions as defined by UserLock access policies on a specific IIS application like Outlook Web Access or an Intranet site. You can also use the generated logs recorded in the UserLock database to produce reports. To supervise IIS sessions, you need to deploy the UserLock IIS agent and then configure it on the IIS server.
The Agent distribution engine automatically detects servers where Internet Information Services is installed and running. To deploy the IIS agent, read this guide.
The IIS agent is an HTTP module. HTTP modules are designed to work only on IIS 7 and higher and can be used to protect a single Web application instead of the whole website.
In many ways, native-code HTTP modules resemble an amalgamation of the technologies that software developers used to create managed ASP.NET HTTP modules and extensions with earlier versions of IIS.' (source MSDN).
IIS 6 | IIS 7 and higher | Protect a whole web site | Protect a single web application |
|---|---|---|---|
For all authenticated requests, the agent asks the UserLock server whether the connection should be allowed or denied. In the case of a negative answer, an explicit HTML error page is displayed to the end user.
Note
You can find further documentation about HttpModules on the Microsoft website.
Several HttpModules are allowed for the same website/ Web application. You shouldn't encounter any conflict if others are already installed.
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 Access policy 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 Access policy 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 Activity views.
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.
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.
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.
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
*Adminpattern, 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.
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).
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.