Microsoft Active Directory over LDAP¶

When Microsoft Active Directory (AD) username reporting is enabled, Plixer Scrutinizer is able to retrieve domains, datasources, and first/last seen details for AD users and report the information in various web interface views and functions.

This integration relies on the Plixer AD Users utility to retrieve username data and forward it to Plixer Scrutinizer as IPFIX flows.

The Plixer AD Users utility reads a Windows event log file, continually parses authentication events, and sends event data to an IPFIX collector (Plixer Scrutinizer) for viewing in the Explore > Entities > Usernames table in the web UI. If the AD Users service is stopped, the last sent event record ID is saved to last_recordID.txt. If this file exists, only events with record IDs greater than the number in the file will be sent to Plixer Scrutinizer. This feature helps avoid duplicate events being sent to the collector or a lapse in the authentication events processed should the program restart.

Plixer AD Users 2.0.0

Plixer AD Users 2.0.0 allows integration with the Plixer ML Engine 19.4.0. When configured, both Active Directory authentication events and sign-in logs from designated Azure storage containers are processed by the ML Engine. The result is model generation used to detect anomalies, send alerts, and generate reports for usernames or email (Azure) login data.

Note

Azure login data typically categorizes users by email.

For Azure sign-in logs, there is a configuration setting to pull logs older than the specified number of minutes to account for any missed events back to a certain time. The Plixer ML Engine will remove duplicates of both AD and Azure events for model generation.

Configuring the servers¶

User permissions¶

By default, the Plixer AD Users installer configures the program to run using a local system account and this is the recommended configuration. However, the program can also be configured to run as a different user.

If not using a local system account, the user who is configured to run the Plixer AD Users service needs to:

Have administrator privileges
Have permissions to query domain controller event logs by being added to the event log readers built-in group
Have Log on as a service rights if running as a service

Domain controller audit policies¶

To allow authentication events to be collected, logon/logoff audit policies on the domain controller must be enabled.

To do this, make the following changes to the domain controller’s default policies:

Expand Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff.
Enable Success and Failure for Audit Logoff and Audit Logon.

The advanced audit policies require that another group policy override setting is enabled. To do this, follow these steps:

Expand Computer Configuration > Policies > Windows Settings > Local Policies > Security Options.
Select Audit: Force audit policy subcategory settings.
Tick Define this policy setting, and then tick Enable.

Event forwarding¶

Running Plixer AD Users directly on the Active Directory server does not require any additional configuration, other than ensuring that the config file points to Security.evtx.

To run Plixer AD Users on a separate event collection server joined to the same domain as the Active Directory server/domain controller, follow these steps:

On the Active Directory server(s), run the following command from an elevated-permissions command prompt: C:\> winrm quickconfig
On the event collection server, run the following command from an elevated-permissions command prompt: C:\> wecutil qc
Establish a subscription by performing the following on the event collection server:
- As an Administrator, launch Event Viewer, and then click Subscriptions.
- In the Actions pane, click Create Subscription.
- Enter a subscription name.
- Select Computers, and then enter your Active Directory server(s).
- Go to Destination log > Forwarded Events, and then select Keep User Account as Machine Account.
- Select Events, then select Security for Event logs, and then enter the following event IDs to include: 4624,4634,4647,6272-6274,6278,6279.

Plixer ML Engine¶

The Azure storage account name and Azure storage account key will need to be entered during the setup script. Apart from this, no further configuration is required on the Plixer ML Engine.

If the user did not configure AD Users to send Azure data during the initial setup process of their ML Engine (i.e. responded “no” to the example prompt included below), user can re-run /home/plixer/ml/setup.sh on the ML engine, which will prompt the user again if they would like to configure Azure for AD Users.

Re-running setup.sh on an ML engine that has already been configured and running does not take the user through the entire configuration process again. It only applies any changes or updates made to the ML engine configuration since the last time it was run (e.g. Azure credentials that were not previously entered).

The following is an example of a Plixer ML Engine setup script:

Successfully upgraded PXI deployment
Will you configure AD Users to send Azure data to your ML Engine? (yes/no):
yes
Configuring Azure storage account info...
Enter your Azure storage account name:
<Your Azure storage account name>
Enter your Azure storage account key:
<Your Azure storage account key>
secret/azure-backup created

Note

Plixer ML Engine 19.4.0 only supports integration with one Azure storage account. If storage account credentials were entered previously (i.e. for configuring an Azure backup or previous sign-in log storage), they should be changed accordingly to the storage account containing Azure sign-in data for AD Users.

Existing Azure storage account credentials that were submitted to the ML engine previously (either for AD Users or as an Azure backup) can be changed with the following commands:

kubectl -n pxi delete secret azure-backup --ignore-not-found
kubectl -n pxi create secret generic azure-backup --from-literal=azure.client.secondary.account=<Your storage account name> --from-literal=azure.client.secondary.key=<Your storage account key>

Microsoft Azure¶

To archive both interactive and non-interactive sign-in logs to a storage account, create a storage account, and then set up archiving for the sign-in logs to that storage account.

To set up a storage account, do the following:

Sign in to the Microsoft Azure portal.
Under All Services, select Storage Accounts, and then select Create.
If necessary, configure your storage account if needed. No AD Users-specific configuration is required here.
Take note of the storage account name, and then after configuring, select Create.
Under Storage Accounts, select Access Keys under Security + Networking to generate and save the value of the key for the storage account.

Setting up the Plixer AD Users utility¶

Once the domain controller has been correctly configured, set up Plixer AD Users on a Windows computer as follows:

Download the Plixer AD Users 2.0.0 product package: ad-users-2.0.0.zip
- This archive includes the ad-users.exe executable file, the ad-users-installer.exe installer, and the ad-users.yml config file.
- The checksum for the zip file can be found here: ad-users-2.0.0.zip.sha256
Run ad-users-installer.exe, and then go through the installation steps.

Important

Make sure that you select No to use recommended system account, and to tick Open config file to set the collector value.
Run a verification test via command prompt with command-line argument test. For example, ad-users.exe test.

Editing the config files¶

ad-users.yml

Name	Required?	Description	Example Value	Default Value
chunking	Yes	Number of authentication log events to collect, and then send at a time. Set to 0 to send each event as it is parsed.	1000	0
flush_wait_seconds	Yes	Time in seconds to periodically send any events in the buffer. Set to 0 if you want to use chunking value for sending events instead.	60	0
path	Yes	Path to the Windows event log. Use ForwardedEvents.evtx if forwarding events, or Security.evtx if running directly on AD server.	C:\Windows\System32\winevt\Logs\ForwardedEvents.evtx	C:\Windows\System32\winevt\Logs\ForwardedEvents.evtx
collector	Yes	This is the Plixer Scrutinizer collector to send the flows to. The format must be IP:port.	127.0.0.1:2055	127.0.0.1:2055
exporter	No	The IP address of the Windows server running AD Users. To specify your own value, use the format IP:port.	8.8.8.8:9996	(Local IP address with port 9996)

log section

Name	Required?	Description	Example Value	Default Value
name	no	Name of the log file if not running as a service.	C:\ad-users\Plixer\ad-users.log	(ad-users.log in executable directory)
level	no	Log level to use for file logging if not running as a service.	info	debug
max_size	no	Maximum size (in MB) of the log file before it gets rotated, if not running as a service.	100	5
max_backups	no	Maximum number of old log files to retain, if not running as a service.	10	0
max_age_days	no	Maximum number of days to retain old log files, if not running as a service.	14	0

ml section

Name	Required?	Description	Example Value	Default Value
send_ad_to_ml	No	Flag for sending AD data to the Plixer ML Engine, in addition to Plixer Scrutinizer.	True	False
scrut_auth_token	No (only required if send_ad_to_ml is set to True)	24-character authentication token generated from Plixer Scrutinizer.
ml_engine_ip	No (only required if send_ad_to_ml is set to True)	IP address of the Plixer ML Engine to send to the Active Directory and/or Azure data via Kafka.	0.0.0.0	0.0.0.0

azure section

Name	Required?	Description	Example Value	Default Value
send_azure_to_ml	No	Flag for sending Azure data to the Plixer ML Engine.	True	False
interactive_container	No (only required if send_azure_to_ml is set to True)	Name of the configured interactive sign-in log storage container in Azure.	insights-logs-signinlogs	insights-logs-signinlogs
non_interactive_container	No (only required if send_azure_to_ml is set to True)	Name of the configured non-interactive sign-in log storage container in Azure.	insights-logs-noninteractive-signinlogs	insights-logs-noninteractive-signinlogs
max_log_age_minutes	No	Logs terminated within the last [number] minutes set will be processed.	15	0
account_filter_list	No	Used to monitor sign-in events of admin Azure accounts (emails), and then send these events to the ML Engine. Separate multiple email addresses with a comma.	[user1@plixer.com,user2@plixer.com,user3@plixer.com]	[user1@plixer.com,user2@plixer.com,user3@plixer.com]
app_filter_list	No	Used to monitor sign-in events of applications, and then send these events to the ML Engine. Separate multiple applications with a comma.	[Microsoft Teams,Microsoft Office,Office 365 Exchange Online]	[Microsoft Teams,Microsoft Office,Office 365 Exchange Online]

Starting the service¶

Open Services, and then right-click on Plixer AD Users.
Select Properties, and then in the General tab, set the startup type to Automatic (Delayed Start).
Go to the Recovery tab, and then set all three failure options to Restart the Service.
Click OK to save.

Verifying the setup¶

Checking log files

If running Plixer AD Users as a service, the application log in Event Viewer will show the program’s log messages. At startup, there will be a few info messages indicating everything was configured properly and the program has started event monitoring. After that, there will only be error log messages if any errors occur or if the service is stopped. If the service restarts, the startup info messages will be logged again.

If running Plixer AD Users in command prompt, use command-line argument run. Log messages will be written to the log file as well as the console (stdout).

C:\ad-users> ad-users.exe run
Detected 'run' program argument, not running as a service
Config: Trying to get Azure credentials via ML Engine API at x.x.x.x
Config: GET https://x.x.x.x:30888/azure_auth response code=200
{"level":"info","time":"2024-04-08T12:18:16-07:00","message":"Successfully set config values: chunking=10; path=C:\\Windows\\System32\\winevt\\Logs\\ForwardedEvents.evtx; exporter=; collector=x.x.x.x:2055; flush wait seconds=60; send AD to ML=true; send Azure to ML=true"}
{"level":"info","buffer_size":67108864,"time":"2024-04-08T12:18:16-07:00","message":"SetWriteBuffer"}
{"level:"info","time":"2024-04-08T12:18:16-07:00","message":"Successfully set collector: x.x.x.x:2055 and exporter: x.x.x.x:9996 endpoints"}
{"level":"info","time":"2024-04-08T12:18:16-07:00","message":"Successfully set ML Engine endpoint x.x.x.x and Kafka producer for topic x-topic"}
{"level":"info","time":"2024-04-08T12:18:16-07:00","message":"Successfully set up access to Azure containers x-interactive and y-noninteractive"}
{"level":"info","time":"2024-04-08T12:18:17-07:00","message":"Successfully opened Windows events file: C:\\Windows\\System32\\winevt\\Logs\\ForwardedEvents.evtx"}
{"level":"info","time":"2024-04-08T12:18:17-07:00","message":"Last sent record ID was saved as 12345"}
{"level":"info","time":"2024-04-08T12:18:17-07:00","message":"Starting event monitoring"}

Checking Plixer Scrutinizer for IPFIX flows

In the Plixer Scrutinizer UI Usernames table, AD Users authentication events will start populating. Plixer AD Users sends the IP address (no IPv6 support currently), logon type (logon or logoff), domain, username, and machine name of the authentication event.

If usernames aren’t showing up as expected, double-check that you have enough exporters licensed for the number of exporters enabled. You can see how many exporters you have licensed in the Plixer Scrutinizer UI under Admin > Plixer > Scrutinizer Licensing > Exporter Count and Enabled Exporters. You can also view specific exporters under Admin > Resources > Manage Exporters.

The Plixer AD Users machine will count as an exporter since it is sending flows with username data to Plixer Scrutinizer.

Checking the Plixer ML engine

To verify that Plixer Scrutinizer is receiving Plixer AD Users data for ML-related alerts and reports, do the following:

In the Plixer Scrutinizer UI, go to Reports > Run Report > Select Report Type.
In the Report Type dropdown, select UEBA Reports.
Select a UEBA report that you would like to run.
In the Available Devices list, select the AD users server, and then click the arrow button to add it to the Selected Devices list.
Click Next, and then continue to configure the report settings based on your preferences.
Click Run Report.

Note

The Plixer AD Users 2.0.0 will work the same as the version 1.0, especially for users who don’t want to send any data to the ML engine or do not want to integrate the ML engine. In this case, no new configuration is needed other than ensuring that the send_ad_to_ml and send_azure_to_ml config values are set to false.

To verify that the Plixer ML engine is receiving and creating models from Active Directory and Azure data, ssh to the ML engine server, and then run the following command to see a list of the AD-users-related pods with their full pod ID names:

kubectl get pods | grep uba

Then run the following command to view the logs:

kubectl logs uba-ingestion-* | tail

If everything is configured correctly and there are active log-in events coming from Azure or Windows AD, a message like the following should show:

2024-08-23T14:09:01+0000 INFO - total records received : 81.000000 total inserted : 81.000000

On default settings, it is expected to start seeing models created based on user login data. These models can then be used to generate alarms in Alarm Monitor for user activity that the ML engine determines to be anomalous.

If desired to change any ML settings, such as the amount of user data to be collected (and how long it will take) to build models, or when the ML engine should construct models, refer to the Machine Learning section or contact Plixer Technical Support.

To verify that training data has been created for AD User data, check the logs of the UBA training data generator pod by running the following command:

kubectl logs ubatrainingdatagenerator-*

Then, confirm that the UBA training data files are formatted as <username>.csv in any subdirectory of /SibylData/TrainingDataUBA/.

To verify that models have been created from collected user data, run the following command:

kubectl logs ubatrainingdatagenerator-*

Then, confirm that the model files are formatted as <username.zip> in any subdirectory of /SibylData/TrainedModelsUBA.

Export spreading¶

The config values for chunking and flush_wait_seconds should mitigate any issues from too many events being exported at a time: chunking allows for a given number of events to be queued in the buffer then sent all at once, and flush_wait_seconds will flush the buffer periodically to avoid events sitting in the queue for too long when fewer authentication events are logged in a minute than the set chunking value.

However, if working with a Plixer Scrutinizer setup where too many Active Directory authentication events at a time is a concern, you can prevent Netflow export storms by enabling export spreading. Follow the instructions here for your performance monitor configuration.