Audit

UserLock detects and audits all connections once the agents have been deployed and configured on machines.

There is no need to create an access policy to audit a user connection. It only requires the UserLock agent to be installed to start auditing connections. All user session events from protected machines are therefore audited and saved in the UserLock database.

The UserLock console displays an instant view in real time of the sessions activity on the network monitored by UserLock.

When a domain user connects to the network, the UserLock agent transmits to the server a set of data. This set includes information on:

• The connection event type: Logon, reconnection, disconnection, logoff, lock, unlock.

• The connection type requested: Workstation, Terminal, Wi-Fi,VPN, IIS, SaaS, or UAC

• The user: Domain, username.

• The source: Machine or device name, IP address.

This information is retrieved by the agent itself when the connection event is submitted by the user, and sent encrypted to the UserLock server, which determines the time of the connection request and saves all in its database. Thus all user connection information performed on agent hosts are collected and stored centrally.

All user connection information transmitted by the agents are audited and saved centrally in a database. Information stored can be used to generate predefined reports directly from the console or can be scheduled and received via email.

Administrators can also use third-party tools to perform additional analysis directly from database records.

UserLock can audit and notify logons denied by Active Directory through its different alerts to users and UserLock operators.

This feature requires:

• The UserLock Desktop agent to be installed on network machines,

• The UserLock IIS agent installed on IIS servers to detect logons denied when the IIS authentication is based on Windows mode,

• The Microsoft Audit policy Audit logons events to be enabled on Failure on target machines where the UserLock agent is installed. This operation can be done through a Microsoft Group Policy with the following parameter: Security settings/Local policies/Audit policy/Audit Logon events.

These logons denied by Active Directory will be saved in the UserLock database and will be usable from predefined reports.

UserLock obtains connections denied by Windows only for existing user names in Active Directory. If a connection is attempted with an invalid username, UserLock will not save this attempt to its database.

Logons denied by Active Directory cannot be detected for RDP sessions using NLA authentication.

Such events will not be captured and will not be displayed in the reports nor in the notifications sent by the UserLock service. If you really need these notifications, you can configure your RDP servers to not use NLA authentication (not recommended).

For SharePoint working with ADFS authentication, logons denied by windows are not managed by IIS Agent

When ADFS authentication refuses a logon, the user's UPN is not sent to the SharePoint server. On the ADFS server's security log, the connection is allowed and automatically logged off. However, on the Sharepoint server's IIS log, the logon denied is logged without specifying the user, only the IP address.

UserLock allows you to audit actions performed by its admins such as changes to access policies, logging off users, and installing agents. In the console, you can see all administrator actions that you have performed with your own account by clicking on the iconin the upper right corner. This includes the last 50 actions and configurations performed by your own account for the past 30 days.

Admin actions include any action to a user, machine or session through the UserLock console. These are for UserLock admins to respond to help desk requests, or respond to suspicious behavior. The actions that are audited inlcude:

• On users: resolve MFA help requests, or reset and MFA key.

• On machines: Restart, shut down, Wake up

• On sessions: Logoff, Lock, Reset, Send popup

These events include all changes made to access policies and server properties, as well as notifications related to these events.

• On users: Block/unblock the user and temporarily disable the MFA

• On policies: Creating, modifying, and deleting access policies including the details of what was modifed.

• On server properties: All modifications made to server properties inlcuding the details of what was modified.

You can consult and schedule reports on admin actions and configurations in the Reporting section of the console.