Skip to main content
Last updated on

Microsoft Entra ID provisioning logs

Preview

Lakewatch is in Private Preview. To request access, reach out to your Databricks account team.

Overview​

Microsoft Entra ID provisioning logs record how the Microsoft Entra ID provisioning service creates, updates, and deletes users and groups in connected applications, including the events it skips and the errors returned by the target application. Lakewatch ingests the ProvisioningLogs diagnostic category from cloud storage using Auto Loader and schematizes it with the built-in azure_provisioning parser. This is a cloud storage source, not an API connector.

Each event lists the steps the provisioning service took in the properties.provisioningSteps array, and the attribute values it sent to the target application in properties.modifiedProperties.

Onboard Microsoft Entra ID provisioning logs​

To ingest Microsoft Entra ID provisioning logs, create a cloud-storage datasource for them and attach the built-in azure_provisioning parser so events are written to a schematized parsed table. For prerequisites, Unity Catalog access, and the full datasource setup steps, see Cloud storage.

The parser claims only events whose category is ProvisioningLogs. If one storage location mixes several Azure log categories, attach every matching Azure parser to the same datasource, with the generic azure_monitor_activity parser last. See Ingest several Azure log categories from one location.

Parsed schema and observables​

The built-in azure_provisioning parser schematizes Microsoft Entra ID provisioning logs into a parsed table. Every parsed table also carries the Lakewatch-managed columns:

  • lw_id: A non-null string Lakewatch uses as the primary key, supporting deduplication across incremental reads.
  • time: A non-null event timestamp assigned by the parser.
  • lw_meta: Standard Lakewatch processing metadata.
  • lw_observables: Values extracted from fields marked as security observables in the parser.

The full event payload is kept in the properties column as a VARIANT, so fields that the parser doesn't promote to their own columns remain queryable. For more information, see the Parser reference.

Parsed table schema

The azure_provisioning parser writes the following columns (generated from the parser definition):

Column

Data type

time

TIMESTAMP

resourceId

STRING

operationName

STRING

operationVersion

STRING

category

STRING

tenantId

STRING

resultType

STRING

resultSignature

STRING

resultDescription

STRING

durationMs

DOUBLE

correlationId

STRING

identity

STRING

level

STRING

provisioningId

STRING

jobId

STRING

cycleId

STRING

provisioningAction

STRING

provisioningStatus

STRING

errorCode

STRING

errorCategory

STRING

errorReason

STRING

initiatedById

STRING

initiatedByName

STRING

initiatedByType

STRING

servicePrincipalId

STRING

servicePrincipalName

STRING

sourceSystemName

STRING

targetSystemName

STRING

sourceIdentityId

STRING

sourceIdentityName

STRING

sourceIdentityType

STRING

sourceIdentityUserPrincipalName

STRING

targetIdentityId

STRING

targetIdentityName

STRING

targetIdentityType

STRING

properties

VARIANT

Column

Data type

time

TIMESTAMP

resourceId

STRING

operationName

STRING

operationVersion

STRING

category

STRING

tenantId

STRING

resultType

STRING

resultSignature

STRING

resultDescription

STRING

durationMs

DOUBLE

correlationId

STRING

identity

STRING

level

STRING

provisioningId

STRING

jobId

STRING

cycleId

STRING

provisioningAction

STRING

provisioningStatus

STRING

errorCode

STRING

errorCategory

STRING

errorReason

STRING

initiatedById

STRING

initiatedByName

STRING

initiatedByType

STRING

servicePrincipalId

STRING

servicePrincipalName

STRING

sourceSystemName

STRING

targetSystemName

STRING

sourceIdentityId

STRING

sourceIdentityName

STRING

sourceIdentityType

STRING

sourceIdentityUserPrincipalName

STRING

targetIdentityId

STRING

targetIdentityName

STRING

targetIdentityType

STRING

properties

VARIANT

Parser observables

The parser extracts the following fields into lw_observables (generated from the parser definition):

Field

Observable

correlationId

trace_id

cycleId

trace_id

initiatedById

actor_id

servicePrincipalId

actor_id

sourceIdentityUserPrincipalName

username

sourceIdentityUserPrincipalName

email

Field

Observable

correlationId

trace_id

cycleId

trace_id

initiatedById

actor_id

servicePrincipalId

actor_id

sourceIdentityUserPrincipalName

username

sourceIdentityUserPrincipalName

email

The following VARIANT fields are scanned for observables by matching nested key names; the observable types extracted from each:

Field

Observable types scanned

properties

username, email

Field

Observable types scanned

properties

username, email

On this page