UserLock Documentation
UserLock Documentation
You are here: Use cases > Advanced use cases > How to deny all interactive sessions when UserLock service is inaccessible

How to deny all interactive sessions when UserLock service is inaccessible

As explained in the FAQ article What happens if the UserLock Primary server and Backup server are not available?, if both the Primary and Backup servers are not available, UserLock will not enforce any restrictions. All session events will be logged locally on machines, and communicated back to the server once communication is restored. For further information please refer to What happens if the UserLock Primary server is down?

The ”DenyInteractiveConnectionsIfUserLockInaccessible” setting allows this default behavior to be changed: Once enabled:

  • If an interactive logon event occurs on a computer where the Desktop UserLock Agent is installed, then the connection will be denied.
  • If an interactive unlock or reconnect event occurs on a computer where the Desktop UserLock Agent is installed, then the connection will be denied (whether the "ApplyRestrictionsOnUnlock" advanced setting is enabled or disabled).

Error displayed in both cases:

Error displayed in both cases

This setting applies uniquely to interactive sessions. As these sessions are controlled by the Desktop agent installed locally on the machine, a network failure could prevent the agent from communicating with the UserLock server and therefore allow a logon to take place. Other types of sessions such Wi-Fi, VPN and IIS sessions that are managed through NPS, IIS and RRAS UserLock agents, are installed on Windows servers;. Since these session types operate differently they are not subject to the same type of behavior.

At present, it is only possible to deny the connection through the Desktop Agent. Additional restriction checks, such as MFA, are not possible as these also require network connectivity.

Once UserLock is reachable, the corresponding session events are sent to the UserLock service, which writes them to the database with EventType 4 and LogonInfo 2048 (new reason for logons denied by UserLock).

Warning: For machines where the network connection is activated once the logon screen has appeared, the connection will be refused.

If the welcome message is enabled, end users will be notified of such events upon the next successful login. The text included avoids any mention of the solution "UserLock":

the next successful login

UserLock administrators will visualize such events in reports as follows:

  • “Session history” report: logons denied by UserLock for reason "UserLock inaccessible":

    Session history

  • "All denied logon" report: "UserLock inaccessible" is available in the "UserLock deny reason filter" field:

    All denied logon

  • Result:

    Result

  • "Logon denied by UserLock" report: "UserLock inaccessible" is available in the "UserLock deny reason filter" field:

    Logon denied by UserLock

  • Result:

    Result

How to change this setting

This setting is configurable at the UserLock service level (advanced setting dialog box, UserLockPowerShell or UserLockAPI) or through Agent configuration Group Policies. As explained here: "a setting configured through Group Policy deployment will override the value of the same setting deployed by the service or configured manually".

At the UserLock service level (advanced setting dialog box, UserLockPowerShell or UserLockAPI)

The name of the advanced setting is “DenyInteractiveConnectionsIfUserLockInaccessible”:

The name of the advanced setting

Learn how to view and modify Advanced UserLock Settings here.

Through Agent configuration Group Policies

Agent configuration group policies are documented here

The related setting in these policies is "When UserLock service is inaccessible, all interactive sessions will be denied (logons, unlocks, reconnects)":

The related setting in these policies

This option can be useful if for example you wish to activate the setting uniquely for a subset Organizational Unit (OU of certain workstations, for example). The setting can be applied as FALSE at the UserLock server level and then activated at GPO level (which will take precedence and then the setting will be applied only for that particular OU). As an alternative, the same procedure can function in reverse, the UserLock server setting can be set to TRUE (activated for all machines) but a GPO setting could override to deactivate the option for a subset of machines within an OU).

Limitations

There are two limitations of this functionality:

  • End users do not receive same credential notifications related to such events.
  • UserLock administrators do not receive notifications (e-mail and/or popup) related to such events.

Reminder about Windows cache and interactive logons

As explained on this page, in the case where the domain controller is not available, Windows allows interactive logons if the credentials used are part of the previous logons cached on that computer. The default value for this setting is 10 logons; possible values range from 0 to 50.