General server properties
The 'General' server section allows you to define the main options for the UserLock server behavior.
The head items display some information about the current UserLock implementation ('Role', version, 'Protected zone').
UserLock server type
Displays the type of server. It can be 'Primary server', 'Backup server' or 'Standalone terminal server'.
The network zone defined during the 'Configuration wizard'. This is the network perimeter that the UserLock Primary server will be in charge of.
All the machines in this zone will be listed in the agent deployment engine view ('Agent distribution') in the UserLock console.
The version of UserLock Windows service. The information displayed here will allow our team to know exactly which version has been implemented.
Multiple 'Group protected accounts' can result in conflicts when authorizing a user to logon. For example, a user may belong to group A and group B and try to connect to a computer where group A is allowed to logon and group B is not allowed to. This situation results in a conflict where a policy has to be selected: to be either the most restrictive or the least restrictive as possible. The policy will therefore define whether the user from group A and group B will be allowed to logon or not.
Please note: A user can be a member of several permanent and/or temporary protected accounts (user, group or organizational unit). UserLock determines which rules to apply based on certain priorities. These priorities are described in the section named 'Priority management'.
- Wake up computers when needed: If enabled, UserLock will try to wake up computers on which there are sessions that currently block new sessions from logging in, or on which there are disallowed sessions.
- Consider screen saver time as locked time: Disabled by default
When this option is selected and the screen saver is password protected, UserLock will consider the session as locked at screen saver start-up.
This option allows you to get a more efficient result when generating reports using the 'Sub session' option and when setting actions to perform on idle sessions.
After that, restart the "UserLock Agent Service" ("ULAgentService") service on target computers (restart it if the OS is Windows XP or Windows Server 2003).
If you do not make that, the change is not effective. So, at screen saver startup, a Lock event will be registered in UserLock although the session may be not locked yet (the user can prevent from locking during the 5 seconds grace period).
- Logoff disallowed sessions: If this box is checked, a security process is enabled to enforce the UserLock rules - in real time - after a period during which the protection is down- such as during a network issue or a server failure. During this time, UserLock restrictions will not be enforced, but all session events are logged locally. Once the connection has been restored, these event logs are sent to the server, and all UserLock restrictions will be applied to any sessions opened during the incident.
In the same way, when changes are made to the protected account rules – such as a reduction in the number of authorized sessions - the change will take effect immediately. UserLock will force a logoff for any existing sessions that exceeds this new limit.
- Only interactive sessions (workstation and terminal) will be forced logoff. Wi-Fi/VPN and IIS sessions won't be impacted by this option.
- Implementing a UserLock 'Backup server' allows to UserLock policies to be maintained.
- Session logoff order: Define which session(s) will be closed first
if the 'Logoff disallowed sessions' option is enabled. You can choose
to close the oldest session(s) first or the newest.
Please note: The logoff notification will be displayed to users for one minute before their session(s) is (are) closed.
- Carry over unused time count: If this option is enabled, the time not consumed when the quota period has ended is automatically added to the authorized time for the next period.
- Logoff notification timeout: The number of minutes during which the notification will be displayed to users when a quota has been reached. The logoff will be initiated after the number of minutes set except if users choose to launch it. This number of minutes is not deducted from the 'Time quota' limit - if you have set a 'Time quota' of 8 hours a day and a notification timeout of 10 minutes, then the logoff will be initiated after 8 hours and 10 minutes.
Checking 'Use the agent local time to apply Time restrictions' will take into consideration the time of the user machine instead of the time of the server to verify the time restrictions.
This is useful when the UserLock server is in another time zone to the machine on which the user connects.
Please note: If you enable this option, we suggest you to implement a security policy to deny users the permission to modify the local clock settings and thus prevent them bypassing the time restrictions.
Logons without network connection
This feature requires the UserLock desktop agent 10.2 or higher to be installed on the machine. When the machine is offline, or the desktop agent cannot contact the service, the option you choose here will apply. This setting is global, so it will be applied to all users regardless if they have a protected account or MFA enabled. See below for further details on how this setting works:
- Always allow connections: By default this option is selected. Users will be able to login despite their machine being offline.
- Ask for MFA: MFA can be asked for offline connections by selecting the option 'Ask for MFA'. This will apply to users who are already enrolled in MFA. The connection will be allowed if the user already connected to the machine while on the network and with the agent (10.2 or higher) installed. MFA will be requested if configured. See the table below for all possible scenarios.
If... ...then User logged on once within network User authenticated w/MFA within network MFA required Logon Accepted Logon Denied Yes Yes check_circle <![CDATA[ ]]> <![CDATA[ ]]> Yes No <![CDATA[ ]]> check_circle <![CDATA[ ]]> No No <![CDATA[ ]]> <![CDATA[ ]]> check_circle
- Force MFA: MFA required for users already connected to that machine with MFA and agent 10.2 or higher. For users who have never authenticated with MFA on that machine, deny connections.
If... ...then User logged on once within network User authenticated w/MFA within network MFA required Logon Accepted Logon Denied Yes Yes check_circle <![CDATA[ ]]> <![CDATA[ ]]> Yes or No No <![CDATA[ ]]> <![CDATA[ ]]> check_circle
- Always deny connections: This option will deny offline connections.
Recommended for "Ask for MFA" and "Force MFA": once activated, you can test the expected behavior by disconnecting the machine from the network, and Wi-Fi, and then logging in. Make sure that the Desktop agent (10.2 or higher) is installed before testing.
For more details, see this use case.
Implementing UserLock Anywhere allows the agent to contact the service through the Internet when network connection is not established. For more information, Read the documentation.