Configuring UEBA in Microsoft Sentinel for Behavioural Threat Detection

User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel provides machine learning-driven anomaly detection that goes beyond signature-based alerts. In this post, I'll walk through enabling and configuring UEBA to detect insider threats, compromised accounts, and lateral movement based on behavioural baselines rather than static rules.

Prerequisites

• Microsoft Sentinel workspace deployed

• Security Admin or Sentinel Contributor permissions

• At least one of the following data sources ingesting for 7+ days:

- Azure Active Directory (SigninLogs, AuditLogs) - Office 365 (via the Office 365 connector) - Azure Activity logs - Security Events (Windows logs)

• Familiarity with KQL and the Azure Portal

Step 1 – Enable UEBA on Your Sentinel Workspace

Navigate to Microsoft Sentinel > Settings > Settings tab > UEBA.

Click Enable UEBA and select the data sources you want UEBA to analyse:

• Azure Active Directory

• Azure Activity

• Office 365

• Security Events

Click Apply.

Important: UEBA requires a minimum learning period of 7 days before anomalies will surface. Initial baselines are built during this period.

Step 2 – Configure Entity Mappings in Analytics Rules

UEBA builds profiles for entities (users, hosts, IP addresses). To maximise effectiveness, ensure your analytics rules properly map entities.

Edit an existing analytics rule or create a new one. In the Set rule logic tab, scroll to Entity mapping:

SecurityEvent
| where EventID == 4625
| project TimeGenerated, Computer, Account, IpAddress

Map the fields:

• Entity type: Account → Identifier: Account (or UserPrincipalName)

• Entity type: Host → Identifier: HostName

• Entity type: IP → Identifier: Address

This allows UEBA to correlate failed logon events with user and host entities.

Step 3 – Review Entity Behaviour Analytics Settings

Navigate to Microsoft Sentinel > Entity behaviour.

Here you'll see:

• Entity pages: Click any user or host to view their behavioural timeline, anomalies, and peer group comparisons.

• Anomaly scoring: UEBA assigns investigation priority scores (0-100) based on deviation from baseline.

Configure peer groups if you have distinct user populations (e.g., admins, developers, finance):

Go to Settings > UEBA > Peer groups and define groups based on Azure AD group membership or OU structure.

Step 4 – Enable Built-In Anomaly Detection Rules

Navigate to Analytics > Rule templates and filter by Anomaly.

Enable relevant templates:

• Anomalous login behaviour

• Anomalous Azure AD sign-in

• Anomalous Azure Activity

• Anomalous Office 365 activity

Click Create rule and adjust the threshold (default is usually high sensitivity). Start with default settings and tune based on your environment's noise level.

Step 5 – Create Custom Anomaly Queries

Beyond built-in templates, create custom queries that leverage UEBA data. Here's an example detecting users accessing resources outside their normal pattern:

BehaviorAnalytics
| where TimeGenerated > ago(24h)
| where ActivityType == "LogOn"
| where InvestigationPriority > 5
| summarize AnomalousLogons = count(), Resources = make_set(ResourceId) by UserPrincipalName
| where AnomalousLogons > 3
| project UserPrincipalName, AnomalousLogons, Resources, InvestigationPriority

Save this as a scheduled analytics rule running every 6 hours.

Step 6 – Tune Anomaly Thresholds

UEBA will generate noise initially. Monitor the BehaviorAnalytics table:

BehaviorAnalytics
| where TimeGenerated > ago(7d)
| summarize AnomalyCount = count() by UserPrincipalName, ActivityType
| sort by AnomalyCount desc
| take 20

Identify high-volume false positives and either:

• Adjust peer groups to better reflect user roles

• Exclude known-good behaviours using watchlists

• Increase the InvestigationPriority threshold in your analytics rules

Step 7 – Monitor UEBA Data Ingestion

Verify UEBA is processing entity data:

BehaviorAnalytics
| where TimeGenerated > ago(1d)
| summarize EntitiesProcessed = dcount(SourceRecordId) by bin(TimeGenerated, 1h)
| render timechart

If you see gaps, check that source connectors (Azure AD, Office 365, etc.) are healthy and ingesting data.

Step 8 – Integrate UEBA with Incident Workflows

UEBA anomalies should trigger incidents for investigation. Create an automation rule to enrich incidents with entity context:

Navigate to Automation > Create > Automation rule.

Set conditions:

• If: Analytics rule name contains "Anomaly"

• Then: Run playbook Enrich-Entity-Context

This can pull additional user context from IdentityInfo or HR systems via Logic Apps.

Troubleshooting

No anomalies appearing after 7 days: Verify you have sufficient data volume. UEBA requires a critical mass of events to establish baselines—at least 1,000+ events per day per entity type is recommended.

High false positive rate: Review peer group assignments. Users in the wrong peer group (e.g., IT admin grouped with regular users) will generate excessive anomalies.

BehaviorAnalytics table is empty: Check that UEBA is enabled and data sources are selected in Settings > UEBA. Confirm source connectors are operational.

Investigation priority scores seem random: UEBA scoring improves over time as baselines stabilise. Expect tuning to take 30-60 days in dynamic environments.

Hardening Considerations

• Entity scope: Limit UEBA to high-value accounts (admins, privileged users) initially to reduce noise and focus on critical threats.

• Baseline protection: Avoid making major organisational changes (mass onboarding, AD restructures) during the initial learning period—this poisons baselines.

• Watchlist exclusions: Maintain a watchlist of service accounts, scheduled tasks, and automation identities to exclude from anomaly detection.

• Alert fatigue: Start with InvestigationPriority > 7 thresholds and gradually lower as you tune peer groups and exclusions.

• Data retention: UEBA relies on historical data. Ensure Log Analytics retention is set to 90+ days for optimal baseline accuracy.

• Peer group granularity: Over-segmenting peer groups can reduce anomaly detection effectiveness. Aim for groups of 50+ similar users where possible.

Final Thoughts

UEBA isn't a set-it-and-forget-it feature. I've seen too many organisations enable it, get overwhelmed by false positives in the first week, and disable it entirely. The reality is that behavioural analytics takes time to mature—expect to spend the first 30 days tuning peer groups and exclusions before you start seeing real value.

That said, once it's properly configured, UEBA catches threats that traditional rules miss entirely. I've personally seen it surface compromised accounts that showed no obvious IOCs but were behaving just slightly off-pattern. Those subtle deviations are exactly what attackers rely on to stay under the radar.

Start small, focus on your highest-risk users first, and build confidence in the system before rolling it out broadly. The investment in tuning is worth it.