Skip to main content
McAfee MVISION Cloud

Username to Event Logon Mapping

McAfee MVISION Cloud Discovery and Risk Assessment relies on the logs exported from the egress device on the client’s side. Some egress devices do not have the functionality to capture user name information for their traffic events, but capture the IP address instead. MVISION Cloud Connector can be used to map the IP address from the egress device logs with the user name from Active Directory before forwarding the processed events to MVISION Cloud for analysis. Having user names instead of IP addresses provides more context and relevance to the data rendered on the MVISION Cloud dashboard, more so, as IP addresses are assigned dynamically to various users.

When a user logs into their Windows PC in a domain, the event is logged in the corresponding Domain Controller. This event includes the username, the IP address from which the login was triggered, and the timestamp. Cloud Connector has the functionality to query Active Directory to fetch this information, and also fetch associated attributes corresponding to the users.

There are two methods to integrate Cloud Connector with Active Directory:

  1. The first method uses Windows Domain Controller (DCOM) for fetching the logon events from all the Domain Controllers. This method requires Administrator permissions. This is the only method that can be used when Cloud Connector is run on a Linux machine. This method can also be used with Windows Cloud Connector.
  2. The second method uses Window’s native APIs to fetch the logon events. This method can only be used if Cloud Connector is running on a Windows machine. This method is also more reliable and the most scalable of the two. Additionally, this method does not require Administrator permissions.

Configure Integration with Cloud Connector

Set the method you use to connect to Event Logon Mapping during Cloud Connector installation. 

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.

Fetching Events from Domain Controller

  1. During Installation, select the second option from the Active Directory Domain Access menu: Yes, fetch user information from domain controllers.
  2. Enter the following login information to connect to the Active Directory Domain Controller.
    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. Activate Test Connection. 

  1. Cloud Connector will attempt to connect to the Domain Controllers in the domain. If the connection is successful, a confirmation screen displays with the list of Domain Controllers in the domain.

  1. Proceed with the installation by providing your MVISION Cloud dashboard login credentials. This may be different from your Cloud Connector credentials. Credentials can be obtained from MVISION Cloud Support.
  2. Once the installation is complete, start the Cloud Connector service from services.msc.

Fetch Events from Central Event Source

  1. Select third option from the Active Directory Domain Access menu: Yes, fetch user information from central event source. 
  2. Enter the following login information to connect to the Central Event Source.
    1. Central Event Source: The IP Address of the Windows Host registered as an authentication event receiver.
    2. Name of the Forwarded Event Source: A descriptive name of your data source. Default is Application.
    3. Activate Test Configuration.

NOTE: Before proceeding, make sure to add the user running Cloud Connector to the Event Log Readers Group in the computer running the Event Collector.

  1. Cloud Connector will test the connection. If the connection is successful, a confirmation screen is displayed.

  1. Proceed with the installation by providing your MVISION Cloud login credentials. This may not be the credentials used to access Cloud Connector. Credentials can be obtained from MVISION Cloud Support.
  2. Once the installation is complete, start the Cloud Connector service from services.msc.

Configuring Integration After Installation

If Active Directory or Central Event Source integration was not established during Cloud Connector installation, it can be configured from the Cloud Connector user interface. 

  1. Open a web browser and enter the IP Address you set during installation into the address bar.
  2. Sign in using an email address and password with Cloud Connector permissions.
  3. Navigate to IP Address to User Name Mapping.
  4. Select Data Source:
    1. To fetch events from Domain Controller, select Active Directory.
    2. To fetch events from Central Event Source, select Windows Event Source.

/Users/mitch/Downloads/Screen Shot 2016-03-14 at 8.30.45 PM.png

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.

/Users/mitch/Downloads/Screen Shot 2016-03-14 at 8.36.01 PM.png

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 MVISION Cloud 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 MVISION Cloud 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 the MVISION Cloud ​​​​​​dashboard.

/Users/amit/Desktop/users overview.jpg

Using a CSV File for IP-User Mapping

You may also map user names from IP addresses using a CSV file exported from a SIEM or Identity Service.

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. 

Troubleshooting

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.

IP User Mapping from Log Files

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?

Our support team can help create parsing rules just like any other logs. We need to 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. Please refer http://fisheye.corp.sjc.shn/browse/~br=trunk/skyhighdev/LogProcessor/trunk/test-log-files/ipuserTracking/QradarAuthLogs.json?r=31770
  • 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 us 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.