Username to Event Logon Mapping

Fresh Installation

1. Locate the Cloud Connector binary installation file (shnlp_windows-x64_x_x_x-SNAPSHOT.exe).
2. Double-click the file to begin the installation for the Windows installer.
3. Respond to the options:
   1. Skip AD integration option and continue the installation.
   2. To use the Domain Controller (DCOM) service and fetch events directly from each Domain Controller in the domain, select Yes, fetch user information from domain controllers.
   3. To use the Windows native APIs and fetch events from a Central Event Source, select Yes, fetch user information from central event source.

Configure Events from Domain Controller

1. Set the data source to Active Directory and enter the following information:
   1. Domain Name. The network name for your Active Directory Domain.
   2. Domain Controller IP. The local address for your Active Directory Domain.
   3. Domain Username. The login name you use to connect with your Active Directory Domain.
   4. Domain Password. The password used to authenticate with your Active Directory Domain.
   5. Discover domain controllers. Activate the check box to automatically discover domain controllers. 
2. Click Test to confirm that your configuration is successful.
3. Click Save.

Configure Events from Windows Event Source

1. Set the data source to Windows Event Source and enter the following information:
   1. Windows Event Host. The IP Address of the host registered as an authentication event receiver.
   2. Windows Event Log. The file name where logging for central event source connection is captured.

Verifying Configuration

You can verify if Log Processor Cloud Connector is obtaining logon events from the AD by verifying that the files inside the directory leveldb/ip-user-time under the Cloud Connector installation directory are not empty:

1. In the Skyhigh CASB dashboard, navigate to Usage Analytics > User Overview.
2. In the User Overview page, in the Total Users section, you will be able to see user names as shown in the following screenshot. The user names are populated from AD for a particular IP Address. This information is sent to Skyhigh CASB by the Cloud Connector application over a secure connection.

NOTE: Both IP addresses and user names are tokenized based on the tokenization strategy chosen. If detokenization permissions are granted to the user, and the browser can connect with Cloud Connector via DNS, detokenization is performed on the fly, and the user will see a clear text user name or IP address in Skyhigh CASB​​​​.

Exporting a CSV File

Enter one of the following commands into the command line of your EC to retrieve the CSV file, depending on if your Active Directory deployment is configured to use native Active Directory lookups or not:

1. C:\shnlp> .\shnlpcli.exe ad --fetch xx days --usenative --export ad_export.tx.
2. C:\shnlp> .\shnlpcli.exe ad --fetch xx days --export ad_export.txt.

For Linux environments, use command 2 without the .exe extension.

The file is saved in your EC installation dir/path.

Submitting CSV File for Import

Make sure that the following information is saved in the file saved in a .CSV format:

• Timestamp. Any format is allowed; milliseconds time is preferred to avoid timezone related issues.
• User Name.
• IP Address.

How it Works

The logs build a local database with (IP-Timestamp-User). While processing logs from an egress device, if the actual log file does not contain a user name, then Cloud Connector uses the IP address reference into the database created with the IP user mapping fie.

In the database, for a given IP, there may be one or more user names associated for different time stamps. The algorithm attempts to find the nearest match according to the following rules: 

For example, if the IP user mapping contains (ip1, t1, u1) (ip1, t3, u2) (ip1, t7, u3):

• If the egress device contains a log entry (ip1, t2) without a user name, then u1 is selected as the user name. 
• If the egress device contains a log entry (ip1, t4), then u2 is selected.
• If the egress device contains a log entry (ip1, t7), then u3 is selected.

For every IP, by default, last 10 days of history is retained to limit disk usage. 

Fetching Events from Domain Controller

• If the firewall is enabled in the windows server, make sure that you have bi-directional communication between the Cloud Connector and the Domain Controller. For this, enable a specific range of ports by creating an inbound rule in the firewall to allow remote DCOM connections to the server (port numbers 1024-65535). 
• If there are multiple domains, the user account to query AD should have permission across all the domains user objects.
• If you are not able to see users under the leveldb/ip-user-time directory, make sure you have enabled a group policy for auditing login/logout events in the AD. 

Fetching Events from Central Event Source

• Make sure that the user running Cloud Connector is in the Event Log Readers group.
• Also, make sure there is connectivity between Cloud Connector and the Event Collector machine.

Use case

You may have an existing infrastructure to collect authentication logs which gives IP to user mapping. Instead of integrating with AD, we can use this information to derive the IP-User mapping based on the timestamp of the event.

Prerequisite

You need to collect authentication logs from the SIEM system or Identity Service in any format like CSV, TSV, or key-value pairs. This log file must contain the following fields:

• Timestamp ( Any format is allowed, milliseconds time is preferred to avoid timezone related issues)
• User Name
• IP Address

Typically, from AD, eventID 4624 ("An account was successfully logged on") is good enough to capture data.

You need to send a sample log to our support team so the support team can create parsing rules.

How to configure?

Skyhigh Security Support can help create parsing rules just like any other logs. You must add some additional configuration to identify the source of IP user mapping.

1. Logs with authentication information that contains IP user mapping:
   1. We need to create parsing rules for extracting "timestamp", "Source IP address", "username" from this log file
   2. The CSV files can be placed in any directory, and the path needs to be configured via admin console >> log settings for producer files
   3. Add the additional configuration property ip_user_map.producer=true
2. Logs from egress devices without a username 
   1. Treat like any other logs for configuration. If the user name already exists in this log file, it will take precedence otherwise we will explicitly use the IP user mapping.
   2. Add the additional configuration property ip_user_map.consumer=true

3. IP-user mapping can be configured on EC WebUI for central event source and direct AD integration/communication. For CSV file based IP-user mapping, refer the above topic Using a CSV File for IP-User Mapping.

4. To make sure the IP user mappings file is processed before regular egress device logs, we will compare the last known timestamp from the IP user mapping file with egress device timestamp. If the egress device log timestamp is later than the IP user mapping timestamp, we defer the log processing until new IP user mapping logs processed. We allow 12 hours of lag between these logs. We can increase or decrease using ip_user.maxlagAllowed. We can add this property to logprocessor.local.properties file as ip_user.maxlagAllowed=43200000 

Implementation Details

• We use a level DB to store this information in a compact fashion. If we index a large volume of backlog data (several months data), we may use more disk space. For ten thousand users, one-month login/logout data may take up to 600MB on disk.
• EC parses the new set of producer (IP-user mapping CSV files) logs 'almost immediately' and caches the data in level DB store. It is possible that the DB size increases significantly, and to purge old records, one needs to use the command "./shnlpcli purgeipuser" to clean older data.

• purgeipuser(pipu)      Command to purge old entries from the iptime_user DB

       Usage: purgeipuser(pipu) [options]

         Options:

               --numdays

              Remove records older than specified number of days

              Default: -1

               --timelimit

              Stop running after specified number of seconds

              Default: -1

• If the logs configured with authentication data are not processed, we will defer the processing of the logs configured as consumers.
• As part of the parsing rules configuration, we need to filter out the events not related to login type. 
• To view the existing mappings information from log file use the following command: ./shnlpcli x --script "ctx.getBean(\"ipUserTracker\").dump();  \"\".toString();"

How does it work?

We process the IP user logs just similar to any other logs but we don't export any data from these logs. Instead, we will build a local database with (IP-Timestamp-User). While processing logs from egress devices, if the actual log file does not contain any user name then we will use the IP address to look-up into the database created with the IP user mapping file.

In our database for a given IP, there may be one or more user names associated with different time stamps. We will find the nearest match as explained here:

Let's say if the IP user mapping contains (ip1, t1, u1) (ip1, t3, u2) (ip1, t7, u3)

If egress device contains a log entry (ip1, t2) without user name then we will pick u1 as user name. 

If egress device contains a log entry (ip1, t4) then we will pick u2

If egress device contains a log entry (ip1, t7) then we will pick u3

For every IP we keep the last 10 days of history to limit the disk usage.