Unknown login DB000009\WF-3NA2FzD74odWt2n accessing Azure SQL — legitimate managed identity or security risk?

Question

Unknown login DB000009\WF-3NA2FzD74odWt2n accessing Azure SQL — legitimate managed identity or security risk?

Michael Clemans 140

I have noticed activity on my Azure Synapse dedicated pool from a login named DB000009\WF-3NA2FzD74odWt2n. This identity has executed queries that moved a large number of rows and consumed significant resources, but I do not recognize it as a human user, nor does it correspond to a known machine name.

Imagen del usuario

Here are my questions:

Could this be a Managed Identity / Service Principal in Azure AD used by some service (e.g. App Service, Azure Data Factory, Synapse)?

How can I reliably determine which exact Azure resource is using that identity to connect to the database?

Given this unexpected access, what measures should I implement to ensure it is not exfiltrating data (e.g. set up auditing, alerts, restrict permissions)?

I appreciate any guidance or examples for detecting, investigating, and mitigating potential misuse.

Michael Clemans 140 Puntos de reputación

2025-11-27T16:31:05.2466667+00:00

Does this mean that DB000009\WF-3NA2FzD74odWt2n is neither a real user nor a Managed Identity/Service Principal? I’m not concerned about whether the role was assigned correctly; I just want to understand what DB000009\WF-3NA2FzD74odWt2n actually is and how I can identify who is responsible for the queries, since they were quite heavy.
Anónimas

2025-11-27T19:24:09.4333333+00:00
This login does not match typical patterns for Microsoft Entra users, groups, service principals, or managed identities. In Synapse dedicated SQL pools, such names often indicate system-generated identities used internally by the platform. To confirm:

Check session type: SELECT sessionid, loginname, isuserprocess FROM sys.dmpdwnodesexecsessions WHERE login_name = 'DB000009\WF-3NA2FzD74odWt2n'; is_user_process = 1 → user session; 0 → internal/system session.

Review queries: SELECT requestid, command, totalelapsedtime FROM sys.dmpdwexecrequests r JOIN sys.dmpdwexecsessions s ON r.sessionid = s.sessionid WHERE s.loginname = 'DB000009\WF-3NA2FzD74odWt2n' ORDER BY submit_time DESC;

Identify client/app: Check app_name and client_id in sys.dm_pdw_exec_sessions and correlate with Entra sign-in logs.

Security best practices:

Enable SQL Auditing and filter by principal_name.

Turn on Microsoft Defender for SQL to detect anomalies.

Restrict access via private endpoints and least-privilege roles.

These steps help verify the identity and ensure no data exfiltration risk
Anónimas

2025-11-28T19:20:48.7066667+00:00

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

1 respuesta

Su respuesta

Michael Clemans 140 Puntos de reputación

2025-11-27T16:31:05.2466667+00:00

Does this mean that DB000009\WF-3NA2FzD74odWt2n is neither a real user nor a Managed Identity/Service Principal? I’m not concerned about whether the role was assigned correctly; I just want to understand what DB000009\WF-3NA2FzD74odWt2n actually is and how I can identify who is responsible for the queries, since they were quite heavy.
Anónimas

2025-11-27T19:24:09.4333333+00:00

This login does not match typical patterns for Microsoft Entra users, groups, service principals, or managed identities. In Synapse dedicated SQL pools, such names often indicate system-generated identities used internally by the platform. To confirm:

Check session type: SELECT sessionid, loginname, isuserprocess FROM sys.dmpdwnodesexecsessions WHERE login_name = 'DB000009\WF-3NA2FzD74odWt2n'; is_user_process = 1 → user session; 0 → internal/system session.

Review queries: SELECT requestid, command, totalelapsedtime FROM sys.dmpdwexecrequests r JOIN sys.dmpdwexecsessions s ON r.sessionid = s.sessionid WHERE s.loginname = 'DB000009\WF-3NA2FzD74odWt2n' ORDER BY submit_time DESC;

Identify client/app: Check app_name and client_id in sys.dm_pdw_exec_sessions and correlate with Entra sign-in logs.

Security best practices:

Enable SQL Auditing and filter by principal_name.

Turn on Microsoft Defender for SQL to detect anomalies.

Restrict access via private endpoints and least-privilege roles.

These steps help verify the identity and ensure no data exfiltration risk
Anónimas

2025-11-28T19:20:48.7066667+00:00

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Answer 1

Hi @Michael Clemans,
Welcome to the Microsoft Q&A and thank you for posting your questions here.
This error usually occurs when the authentication method does not match the account configuration. Common causes include:

Using local account keys when the account requires Azure AD (Entra ID) authentication.
Token issued from a different tenant than the Cosmos DB account.
Missing role assignment for the user.

fix:

Use Entra ID authentication\ Sign in via https://cosmos.azure.com using Entra ID credentials.

Assign the correct role\ Ensure the user has the Cosmos DB Built-in Data Contributor role. You can assign it using Azure CLI or PowerShell:

az cosmosdb sql role assignment create \

--account-name <CosmosAccountName> \

--resource-group <ResourceGroupName> \

--role-definition-id <RoleDefinitionId> \

--scope "/" \

Verify tenant alignment\ If the token comes from a different tenant, switch to the correct directory before logging in.

For details, see https://learn.microsoft.com/azure/cosmos-db/how-to-setup-rbac.

Compartir a través de

Unknown login DB000009\WF-3NA2FzD74odWt2n accessing Azure SQL — legitimate managed identity or security risk?

1 respuesta

Su respuesta