Protected session types

An interactive session is a session with a desktop. You can open an interactive session on a computer either directly at the computer console or remotely via a remote desktop.

UserLock will only protect interactive sessions on computers on which the Desktop agent has been installed. Interactive sessions on computers without this agent will not be monitored by UserLock.

If you want to protect terminal sessions you just need to install the Desktop agent on terminal servers. There is nothing to install on thin clients (terminals).

Please note that, by default, only remote sessions targeting server operating systems will be considered terminal sessions (a remote session targeting a workstation operating system will be considered a workstation session). This behavior can be changed by modifying the value of the advanced setting VDI mode:

UserLock can audit, control and apply a user access policy to the following type of VPN sessions when authenticated with the RADIUS protocol on a Microsoft Network Policy Server (included in Windows Server).

• The NPS agent must be installed on this server.

• RADIUS clients (Microsoft RRAS, VPN hardware routers) should be configured to contact the NPS server for RADIUS authentication and RADIUS accounting.

• Generally, the RADIUS protocol does not allow to recover the name of the client. As a result, you will not be able to apply Machine restrictions with the client name. The only known case where this name is available is if your RRAS server is configured with RADIUS Authentication and RADIUS Accounting.

• The VPN client address is not provided by all RADIUS clients (hardware routers) so you may also not be able to apply Machine restrictions with the IP address.

• Multiple RADIUS servers for a single RADIUS client (hardware router) is not supported because session opening and closing may be handled by different NPS agents.

• When a VPN session is denied, the user is prompted to enter new credentials. There is currently no way to display a more intelligible message to the user.

• VPN sessions are not compatible with administrative logoffs.

Currently, there is no hardware compatibility list showing all hardware routers that are compatible with UserLock. We therefore suggest you test your hardware device with UserLock.

UserLock can monitor, control and apply a user access control policy on Internet Information Services (IIS) sessions. By activing access policies, you can enable MFA and contextual access restrictions on a specific IIS application such as Outlook Web Access (see this advanced use case for details), RDWeb, SharePoint, CRM etc., or an Intranet website. As UserLock audits and stores in its database all IIS session access events, you can benefit from the database logs' reporting features.

• To monitor IIS sessions, you need to deploy the UserLock IIS agent on the server hosting the Web application you want to protect, and then configure the options of the relevant website folder to load the UserLock IIS agent.

• The IIS Agent is compatible with all IIS applications configured with the following authentication modes: Windows Authentication or Basic Authentication.

Known limitations and additional settings: see here.

UserLock can audit, control and apply a user access policy to Wi-Fi sessions when authenticated with the RADIUS protocol on a Microsoft Network Policy Server (included in Windows Server).

• The NPS agent must be installed on this server.

• RADIUS clients (Wi-Fi access points) must be configured to contact the NPS server for RADIUS authentication and RADIUS accounting.

• Generally, the RADIUS protocol does not allow to recover the name of the client. As a result, you will not be able to apply Machine restrictions with the client name.

• Controlling Wi-Fi sessions may be unreliable if the Wi-Fi access point doesn't correctly notify the end of a session to the RADIUS server when a Wi-Fi client is powered off without closing the Wi-Fi session properly.

• If the Wi-Fi client is a member of the Active Directory domain, the Wi-Fi session may be authenticated with the computer account instead of the user account. In this case, UserLock will not manage the session. UserLock only manages sessions with user accounts, and not sessions with computer accounts.

• Multiple RADIUS servers for a single RADIUS client (hardware router) is not supported as the logon may be managed by a different agent to the logoff.

• When a Wi-Fi session is denied, the user is prompted to enter new credentials. There is currently no way to display a more intelligible message to the user.

The hardware routers and Wi-Fi Access points that are compatible with UserLock are listed below:

• Wi-Fi Access Points:

  • Cisco Aironet 1700 (AIR-CAP1702I-E-K9).

This list is not exhaustive as we will add to it as we are able to confirm compatibility with specific devices. We therefore suggest you test your device with UserLock.

SaaS sessions are those from applications that are configured with UserLock SSO.

Click here for guide on implementing SSO.

SaaS sessions cannot be protected by all UserLock restrictions. Since UserLock is not able to capture when a SaaS session is disconnected unless the user manually signs out of the application before closing the browser. Since this is not common user behavior, in most cases we cannot see the sign out.

Because of this, SaaS sessions have the following limitations:

• SaaS sessions are not included in the Activity views.

• Time connected to SaaS sessions are not included in the following reports:

  • Working hours reports

  • Simultaneous sessions history

• The following access policies cannot be applied to SaaS sessions:

  • Session limits: The administrator can only allow or deny all SaaS session for a protected account.

  • Hour restrictions: If you select SaaS sessions in your hour restrictions, users will be refused a login outside of authorized hours, however, you cannot force the logoff of a SaaS session that exceeds the authorized time.

  • Machine restrictions: For SaaS connections we are able to recover the IP address, but not the client name. For this reason, you can only apply workstation restrictions for SaaS applications by IP range.

  • Time quotas: Does not include time connected to SaaS applications.

UserLock can audit and protect UAC events though the MFA access policy. To protect these events, you need to install the desktop agent on the machines where the elevation of privilege request is made. You can then create an access policy for MFA for your privileged accounts to be prompted with MFA for these events.

UAC events will also be audited as soon as the agent is deployed. You can see these events in the UAC report and you can also configure notifications in the access policy alerts and notifications.

• The desktop agent must be installed on the machine.

• UAC must be configured to prompt for credentials

Local sessions are audited and displayed in the UserLock console. However, access policies rules cannot be applied to local accounts.

The exception is for servers installed in Standalone mode. In this case, local accounts can be protected.

All session events occurring with local accounts are saved in the UserLock database, and you can benefit from this data when investigating and reporting. You can also interact with these sessions from the Activity views, as with all interactive sessions.

Sessions owned by local accounts are audited automatically when the Desktop agent is installed on machines.

For these reasons, the User Status of a local account will always be Unprotected.

Local users are not considered for license consumption.