Introduction

When connecting Microsoft Sentinel to Defender XDR, there are a couple of changes happening in tables which you should be aware of. Even though they are documented in the Microsoft Learn, I it is not always clear what the exact impact is. Let’s go over it together.

IdentityInfo table

In the transition guidance from Microsoft Sentinel to the Defender Portal, there is a subtile mention that the IdentityInfo table schema changes when connecting Sentinel to Defender XDR when you have enabled UEBA in Microsoft Sentinel. It mentions that ‘Some fields that existed when used in the Azure portal are either renamed in the Defender portal, or aren’t supported at all’, and proceeds to urge you to check your queries and update them as needed. But what are the exact changes?

The two table versions

When digging deeper in the Microsoft Learn pages, more specifically in the UEBA Reference, they mention the following:

So let’s start with the terminology here. According to Microsoft there are now two tables references for IdentityInfo:

• Log Analytics IdentityInfo table, for which you find the schema reference here.
• Unified IdentityInfo table, for which you find the schema reference here.

The Log Analytics version is slightly more expanded compared to the Unified version, although the Unified version is the most recent one.

Comparing the table versions

In the UEBA documentation under the ‘Compare to unified schema’ tab we can find a reference showing us the difference between the Log Analytics versions of the table schema and the Unified version. In essence there are both column name changes and columns that are removed, in the new Unified schema:

Column name changes

Columns that are removed

• TenantID (not to confuse with AccountTenantId that has been renamed to TenantId)
• UserState
• UserStateChangedOn
• Applications
• EntityRiskScore
• ExtensionProperty
• InvestigationPriority
• InvestigationPriorityPercentile
• IsMFARegistered
• IsServiceAccount
• LastSeenDate
• OnPremisesExtensionAttributes
• RelatedAccounts
• ServicePrincipals
• Tags
• UACFlags

Impact on Custom Detections VS Analytic Rules

The complicated part about this change, is that the impact for the Custom Detection Rules and the Analytic rules are different. I setup an environment where I connected a Microsoft Sentinel workspace with the Defender XDR portal (unified experience):

In this setup I have - like most organizations have - a combination of Analytic Rules and Custom Detection Rules. But what I asked myself was do both Analytic Rules and Custom Detection rule use the new Unified Schema of IdentityInfo once you connect Microsoft Sentinel to Defender XDR?

It turns out, they do not. I tested this by running the below KQL in both Advanced Hunting of Defender XDR and Microsoft Sentinel, which essentially tells me which table schema we are querying.

1IdentityInfo
2| getschema 
3| extend UnifiedSchema = iff(ColumnName == 'CloudSid',"TRUE","FALSE")
4| extend LogAnalyticsSchema = iff(ColumnName == 'AccountCloudSID',"TRUE","FALSE")
5| where not(UnifiedSchema == "FALSE" and LogAnalyticsSchema == "FALSE")
6| distinct UnifiedSchema, LogAnalyticsSchema

When I run this query in Advanced Hunting of Defender XDR, we can see that the Unified table schema is used:

While when I run the same query in Microsoft Sentinel, we can see that the Log Analytics schema is being used:

The same results are returned when you create an analytic rule for this query in Microsoft Sentinel, and when you create a custom detection rule for it in Defender XDR. The Analytic Rule runs on the ‘old’ Log Analytics table schema, while the Custom Detection rule runs on the new Unified table schema. This means that there is no direct impact for your Analytic Rules regarding the IdentityInfo table when you connect Microsoft Sentinel to Defender XDR. For custom detections there is also no direct impact since the table schema stays the same in Defender XDR.

In which scenario is this important?

The switch of the IdentityInfo table schema when connecting Microsoft Sentinel to Defender XDR is important in two scenarios:

• When you hunt in the Defender XDR portal on IdentityInfo while you did this in Microsoft Sentinel in the past.
• When you want to migrate your Analytic Rules to Custom Detection rules

How to assess impact on your detections

The easiest way to assess impact is to perform a lookup on your Microsoft Sentinel Analytic Rules to first search for the Log Analytics table columns as mentioned before. The rules that have hits on this search are rules for which you need to change the column names to the new ones when you migrate to Custom Detections in Defender XDR. In the second phase you search for rules that use column names that are deprecated in the Unified schema as mentioned before. for those rules you will need to assess impact on the detection logic, since you will probably have to rework them

Based on the output of the AI, you now have a list of the Analytic Rules you need to review.

SecurityAlert table

Once you onboard into the Unified Experience with Microsoft Sentinel and Defender XDR, you will notice that there is no recognition for the SecurityAlert table in Advanced Hunting, while you can still query the table. This is also noted in the Microsoft Learn pages.

For me, this feels like Microsoft is gently pushing us to stop using this table. This is very strange to me, since the two Defender XDR Alert tables AlertInfo and AlertEvidence do not have feature parity with the SecurityAlert table yet. A couple of columns are still missing compared to the SecurityAlert table, and the Learn pages also mention that the Defender XDR alert tables only include information of alerts from Defender for Endpoint, Defender for Office 365, Defender for Cloud Apps, and Defender for Identity.

Although this information seems to be false when I test this in my environment:

1AlertInfo
2| distinct ServiceSource, DetectionSource

Either way, if you can I would suggest to migrate away from SecurityAlert to the Defender XDR alert tables instead, since I have a feeling Microsoft will deprecate SecurityAlert at a certain point in time. But know that you can still SecurityAlert in Advanced Hunting and Custom Detections if you want to.