End-to-End UBA Configuration Example

This example configures detection of a user login from a new IP address. You can use the values as a template by replacing index, field, and lookup names with values from your environment.

Example Scope

A working UBA scenario does not consist of a single configuration. You must consistently configure an object type, object fill, profiling policy, anomaly detection job with a risk score Active Action, and scoring calculation.

Source Data

The example uses two arbitrary sources:

Source	Fields	Requirement
directory-events-*	@timestamp, user_id, full_name, department, status	source data for building the lookup
employees-current	user_id, full_name, department, status	one current record per user
auth-events-*	@timestamp, user_id, source.ip, event.action	successful and failed login events

In this example, directory-events-* is the source index containing user data. It is used to build the current employees-current lookup, which serves as the source for filling the UBA objects list. The user_id value must have the same format in both sources.

To update the lookup regularly, create a scheduled job that runs this query:

source directory-events-*
| search user_id=="*" AND status=="active"
| dedup user_id sortby - @timestamp
| table user_id, full_name, department, status
| outputlookup employees-current

The outputlookup command saves the prepared records to employees-current. Configure the job schedule according to the required data refresh frequency.

1. Object Type and Scoring Type

Create an object type with the following settings:

Parameter	Value
type name	User
base fields	user_id
additional fields	full_name, department
scoring type	UBA risk

Create the UBA risk scoring type, enable UBA compatibility, and associate it with the User object type. The user_id field must be a unique base field, while full_name and department values can repeat.

For details, see Core Entities.

2. Object Fill Configuration

Create a configuration under Main Menu - User Behavior Analytics - Object Fill Configurations.

Section	Parameter	Value
General	Name	UBA: active users
Schedule	Type	Interval, every 24 hours
Filtering	Index	employees-current
Filtering	Time range and time field	leave empty for a current snapshot
Filtering	Filter	user_id=="*" AND status=="active"
Object settings	UBA object type	User
Object settings	Object identifier field	user_id
Object settings	Base field	user_id → user_id
Object settings	Additional fields	full_name → full_name; department → department
Advanced settings	Maximum number of objects	no less than the expected user count and within the license limit
Advanced settings	Lock duration	60 seconds
Advanced settings	Configuration run	enabled

Click Preview. The result must display one row for each user_id, without empty identifiers or base field duplicates. Then click Fill and save the configuration.

For filtering and deduplication details, see Filling the Objects List.

3. Profiling Policy

Create a policy under Main Menu - User Behavior Analytics - Profiling Policies.

Policy General Settings

Parameter	Value
Name	UBA: user login IP addresses
Object type	User
Indexes	auth-events-*
Fields for identifying an object in indexes	user_id
Case-insensitive matching	disabled if user_id is normalized in advance
Time range	now-30d to now
Field containing the timestamp	@timestamp
Schedule	Interval, every 24 hours
Lock duration	7200 seconds
Number of threads	4
Documents per write iteration	500

Dictionary Algorithm

Parameter	Value
Filter	event.action=="login" AND source.ip=="*"
Results index	uba_profile_users_login_source_ip_dictionary
Processed field name	source_ip
Index pattern	auth-events-*
Source field	source.ip
Partial update	disabled to rebuild the profile for the last 30 days every day

Save the policy, run it manually for the first time, and wait for successful completion. The profile index must contain known user_id and source_ip combinations for each user. Do not proceed to anomaly detection before a successful initial run because the job cannot compare events with an empty profile.

4. Profile Index Lookup

Create a lookup for the uba_profile_users_login_source_ip_dictionary index. Matching requires these fields:

Purpose	Profile index field
user identifier	_meta.object.identity
known IP address	_calculation.source_ip
matched profile indicator	_meta.object.id

The following example uses the uba_users_login_source_ip lookup name. Configure the lookup to perform exact matching on the user_id + source.ip pair.

5. Anomaly Detection Job

Create a job that runs every 5 minutes and analyzes the last 10 minutes. Use this base search query:

source auth-events-*
| search event.action=="login" AND user_id=="*" AND source.ip=="*"
| lookup uba_users_login_source_ip _meta.object.identity AS user_id _calculation.source_ip AS source.ip OUTPUT _meta.object.id AS profile_object_id
| where isnull(profile_object_id)

The query keeps logins whose current IP address is missing from the user's profile. If the lookup exposes fields under different names, adjust them in the command. For syntax details, see lookup.

Add a risk score Active Action:

Parameter	Value
Score	20
Index	uba_scoring_users_login_new_ip
Scoring type	UBA risk
UBA object	user_id from the search result
UBA object type	User
Lifetime	24 hours
Drilldown	Search

Run a test search before enabling the job. It must not return events with IP addresses that already exist in the profile.

6. Scoring Calculation

Create a calculation under Main Menu - User Behavior Analytics - Scoring Calculations.

Parameter	Value
Object type	User
Scoring type	UBA risk
Description	Aggregate user risk based on login anomalies
Indexes	uba_scoring_users_*
Time range	no shorter than the maximum lifetime of assigned scores
Field containing the timestamp	the assignment time field from scoring documents
Schedule	Interval, every 5 minutes
Use calculation function	disabled for a linear sum
Color ranges	0–19 — normal; 20–39 — warning; 40 and above — alert
Lock duration	60 seconds
Number of threads	1
Documents per write iteration	1000

Enable the calculation after the job creates at least one test score assignment.

7. End-to-End Verification

1. Verify that the user appears only once in the UBA objects list
2. Verify a successful policy run and the presence of source_ip in the Dictionary algorithm results
3. Run the job query against an event with a known IP address; the event must not be considered anomalous
4. Repeat the test with a new IP address; the query must return the event
5. Verify that the Active Action created an assignment in uba_scoring_users_login_new_ip
6. Run the scoring calculation and open the entity profile
7. Verify the resulting score, assignment history, and event drilldown

If no profile is found, first compare user_id values in the UBA object, events, and lookup. The most common causes are case differences, a domain prefix, and different identity fields.