Cannot onboard Okta Single Sign on logs to Sentinel UEBA

Hi @Michael Ross

The key detail here is the connector type.

The current UEBA reference lists Okta UEBA support for Okta Single Sign-On (using Azure Functions) and the Okta_CL / OktaV2_CL tables. It does not explicitly list the Codeless Connector Framework (CCF) connector as the supported Okta UEBA source.

This can explain why the Defender portal reports “Data source is not ingested to Sentinel” even though OktaV2_CL contains data. The UEBA configuration appears to validate the supported connector/data-source registration, not only whether a table with that name exists.

Also verify that the records contain a valid:

actor_id_s

because Microsoft specifically requires this field for Okta UEBA processing.

You can quickly validate it with:

OktaV2_CL

| where TimeGenerated > ago(24h)

| summarize Total=count(), WithActorId=countif(isnotempty(actor_id_s))

So I would first verify the connector implementation. If you are definitely using the CCF connector and Microsoft intends that connector to support UEBA, then there appears to be a discrepancy between the current connector implementation and the UEBA documentation, and I would recommend raising a Microsoft support case.

If this helps resolve your issue, please don’t forget to mark the answer as Accepted / Resolved, as it may help others experiencing the same behavior.

Hi,

Thank you for the feedback. This does not resolve the issue.

A few things I've come across while investigating this.

• I have both connectors (legacy & CCF) installed in my Sentinel workspace. The CCF connector is connected and ingesting data. The legacy connector is present and listed as disconnected.
• OktaV2_CL table does not have field actor_id_s. My understanding is column actor_id_s does not appear in table OktaV2_CL. Based on a review of the parser the column name in OktaV2_CL is OriginalUserId. The parser normalizes this to actor_id_s
• I have the current version of the OktaSSO parser deployed via Sentinel Repositories.
• I cutover to using the Okta CCP parser not long after it became available. The Okta_CL table is still present in the workspace and has data in it. Data is over 18 months old.

My assumption is UEBA onboarding is checking for the presence of something. I am unclear what it is looking for.

regards,

Michael

Hi @Michael Ross ,

Thank you for the additional detail, and you are correct regarding actor_id_s. My previous suggestion to check that column directly in OktaV2_CL was not accurate. The OktaSSO parser normalizes the CCF schema, including the user identifier from OriginalUserId.

You can confirm the parser output with:

OktaSSO

| where TimeGenerated > ago(24h)

| where isnotempty(actor_id_s)

| summarize Events=count()

There is also an interesting inconsistency in the current Microsoft implementation/documentation. The UEBA reference lists Okta_CL and OktaV2_CL as supported tables, but still identifies the data source as Okta Single Sign-On (using Azure Functions).

At the same time, Microsoft's Sentinel solution release notes show that:

the Azure Functions connector was deprecated in v3.1.6

the OktaSSO parser was explicitly updated in v3.1.7 to include OktaV2_CL.

Given that your CCF connector is actively ingesting into OktaV2_CL, while the legacy connector remains installed but disconnected, I suspect the UEBA onboarding eligibility check may still be relying on connector/data-source registration or health metadata, rather than simply evaluating the parser output or checking whether OktaV2_CL contains current data.

That would explain the “Data source is not ingested to Sentinel” message even though the required data is clearly present.

I cannot find public documentation describing exactly what the UEBA eligibility check evaluates internally, so at this point I would consider this a likely product integration gap/bug between the new Okta CCF connector and UEBA onboarding and raise it with Microsoft Support.

I would include the fact that the legacy connector is disconnected, CCF is connected, OktaV2_CL has current data, and OktaSSO returns valid actor_id_s values. That should give engineering a very clear reproduction path.

If this helps identify the issue, please don't forget to mark the answer as Accepted / Resolved.