From AME unable to create ADF Linked Service connection for CORP KUSTO using CORP SPN

Question

From AME unable to create ADF Linked Service connection for CORP KUSTO using CORP SPN

Hemant 61 Microsoft External Staff

Hello Team,

I am trying to create a Linked Service in AME ADF for CORP Kusto cluster. For that I have created SPN in AME and marked it as multi-tenant. This SPN is also created in CORP. However, AME ADF is throwing error that SPN USER does not have access to Kusto.

Please help with this issue. Since this required proper understanding of the issue, I would just the engineer working on this can ping me for a quick call.

Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-20T21:47:18.2466667+00:00
Hi @Hemant ,

The error is expected a multi-tenant SPN existing in CORP isn't enough by itself.
For a Kusto cluster to accept a principal from a different home tenant, two things must be true on the CORP Kusto side:

The AME tenant must be added to the cluster's Trusted External Tenants CORP Kusto cluster → Security → Allowed tenants → add the AME tenant ID (or leave "All tenants (*)" if the CORP policy permits it). Ref: https://learn.microsoft.com/en-us/azure/data-explorer/cross-tenant-query-and-commands

The SPN (App registered in AME) must be granted an explicit Kusto role Run this on the CORP Kusto database the ADF linked service targets, using the AME app's Client ID and the AME tenant ID (home tenant of the app, NOT CORP): .add database ['<DBName>'] viewers ('aadapp=<AME-App-ClientId>;<AME-TenantId>') 'ADF Linked Service' Use "admins" / "ingestors" instead of "viewers" if the pipeline needs write/ingest. Ref: https://learn.microsoft.com/en-us/kusto/access-control/provision-entra-id-app In the AME ADF Linked Service for Kusto, keep Authentication = Service Principal, and set: • Tenant = AME tenant ID (SPN's home tenant) • Service Principal ID = AME app Client ID • Service Principal Key = secret from the AME app registration Once (1) trust is set on the CORP cluster and (2) the .add database … command is executed successfully on the CORP DB, the "SPN user does not have access to Kusto" error will clear and Test Connection will succeed.
Hemant 61 Reputation points Microsoft External Staff

2026-07-23T01:52:29.3366667+00:00

it is still not working. Can someone please ping for a quick call?
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-23T21:44:51.0966667+00:00
Hi @Hemant ,

Thanks for the screenshot it actually points to the real blocker.

The linked service is now set to "User-assigned managed identity" (MI-ccxops-corp-kusto). That's why you're getting error 11206 / 403 Forbidden. The error shows an AME-tenant principal (…;33e01921-…) hitting the CORP cluster (ccxops), and managed identities do not support cross-tenant authentication by design a UAMI token from AME can never be authorized on a CORP Kusto cluster, regardless of any role you grant. For AME → CORP, the only supported path is a multi-tenant Service Principal.

Please switch back and set both of these on the CORP side:

Trust: CORP Kusto cluster → Security → add the AME tenant ID to Trusted External Tenants (or "*" if policy allows).

Role: on the CORP database, run: .add database ['OpsDataHub'] viewers ('aadapp=<AME-App-ClientId>;<AME-TenantId>') (use "admins"/"ingestors" instead of "viewers" if the pipeline writes/ingests) 3) ADF Linked Service: • Authentication = Service Principal • Tenant = AME tenant ID • Service Principal ID = AME app Client ID • Service Principal Key = secret from the AME app registration Once both (1) trust and (2) the role grant are in place and you're on Service Principal auth, Test Connection will pass. The UAMI option won't work here because it can't cross tenants.
Hemant 61 Reputation points Microsoft External Staff

2026-07-24T17:50:36.9966667+00:00

Hi @Ganesh Chelluri - as per discussion, point #2 did not work. Please help with this at the earlist
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-24T20:16:06.4333333+00:00
Hi @Hemant ,

Based on the error details shared (403 Forbidden / Caller is not authorized to perform this action), the issue appears to be related to authorization and access permissions on the Azure Data Explorer (Kusto) side.

To help validate the configuration, please review the following:

Verify that the principal being used for authentication has the required permissions on the target Kusto database.

Confirm that the appropriate role assignment has been granted to the Service Principal on the target database.

Ensure the AME tenant is allowed as a trusted external tenant on the CORP Kusto cluster.

Confirm the Linked Service is configured to use the intended authentication method and credentials.

The error message indicates that the principal attempting to connect does not currently have sufficient authorization to access the Kusto service or the target database.

After validating the above configuration, please retry the connection test and share the updated results or any new error messages.
Hemant 61 Reputation points Microsoft External Staff

2026-07-24T21:38:39.48+00:00

Hi @Ganesh Chelluri

Below points were discussed in yesterday’s call and implemented. Also, as highlighted in previous email an in below screenshot, can you provide the details about it?
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-25T00:15:59.3633333+00:00
Hi @Hemant ,

Let's do this slowly, step by step. Two things must be right:

(1) the login type in ADF, and (2) the permission on the CORP Kusto side.

Please do exactly the steps below.

PART A — Set the correct login in ADF (must be Service Principal, NOT Managed Identity)

Open Azure Data Factory Studio (AME).

Click "Manage" (left menu, the toolbox icon).

Click "Linked services".

Open your Kusto linked service.

In "Authentication method", select "Service principal".

(Do NOT use "User-assigned managed identity". It cannot work across tenants.)

Fill these 3 boxes:

Tenant = AME tenant ID (the tenant where you created the app)

Service principal ID = the app's Application (client) ID from AME

Service principal key = the client secret of that same AME app

Do NOT press Test yet. Click Save.

PART B — Get the AME app values (needed for Part C)

Open Azure Portal (AME) → Microsoft Entra ID → App registrations.

Open your app → "Overview".

Copy these two:

Application (client) ID

Directory (tenant) ID ← this is your AME tenant ID

PART C — Give the app permission on CORP Kusto

Open the CORP Kusto cluster in the Kusto Web UI (or Kusto Explorer).

Check trust: CORP cluster → Security → Trusted external tenants →

the AME tenant ID must be listed (or "*").

Open a query window on the CORP database the pipeline uses, and run

(use "viewers"; use "ingestors" or "admins" only if the pipeline writes data):

.add database ['<DBName>'] viewers ('aadapp=<AME-App-ClientId>;<AME-TenantId>') 'ADF SPN'

IMPORTANT: the tenant in this command MUST be the AME tenant ID

(the same one you put in ADF) — NOT the CORP tenant ID.

PART D — Confirm the permission really landed (this is the key check)

On the same CORP database, run:

.show database ['<DBName>'] principals

Find your app in the list. It must show as:

"Application <app id> from AAD tenant <AME-TenantId>"

If you see this line → permission is correct, go to Part E.

If you do NOT see it → the command used the wrong App ID or wrong tenant.

Redo Part C.

PART E — Test

Go back to the ADF linked service → click "Test connection".

If it passes → you are done.

If it still fails, please send me these 3 things:

a) the full error text and the number (for example 403 / 11206)

b) the exact line from ".show database ... principals" for your app

c) confirm the "Tenant" box in ADF = AME tenant ID

Most common reasons it fails after all this:

The login is still "Managed identity" (must be Service principal).

The .add command used the CORP tenant ID instead of the AME tenant ID. once Part D shows your app "from AAD tenant <AME-TenantId>", the Test connection will pass.

2 answers

Your answer

Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-20T21:47:18.2466667+00:00

Hi @Hemant ,

The error is expected a multi-tenant SPN existing in CORP isn't enough by itself.
For a Kusto cluster to accept a principal from a different home tenant, two things must be true on the CORP Kusto side:

The AME tenant must be added to the cluster's Trusted External Tenants CORP Kusto cluster → Security → Allowed tenants → add the AME tenant ID (or leave "All tenants (*)" if the CORP policy permits it). Ref: https://learn.microsoft.com/en-us/azure/data-explorer/cross-tenant-query-and-commands

The SPN (App registered in AME) must be granted an explicit Kusto role Run this on the CORP Kusto database the ADF linked service targets, using the AME app's Client ID and the AME tenant ID (home tenant of the app, NOT CORP): .add database ['<DBName>'] viewers ('aadapp=<AME-App-ClientId>;<AME-TenantId>') 'ADF Linked Service' Use "admins" / "ingestors" instead of "viewers" if the pipeline needs write/ingest. Ref: https://learn.microsoft.com/en-us/kusto/access-control/provision-entra-id-app In the AME ADF Linked Service for Kusto, keep Authentication = Service Principal, and set: • Tenant = AME tenant ID (SPN's home tenant) • Service Principal ID = AME app Client ID • Service Principal Key = secret from the AME app registration Once (1) trust is set on the CORP cluster and (2) the .add database … command is executed successfully on the CORP DB, the "SPN user does not have access to Kusto" error will clear and Test Connection will succeed.
Hemant 61 Reputation points Microsoft External Staff

2026-07-23T01:52:29.3366667+00:00

it is still not working. Can someone please ping for a quick call?
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-23T21:44:51.0966667+00:00

Hi @Hemant ,

Thanks for the screenshot it actually points to the real blocker.

The linked service is now set to "User-assigned managed identity" (MI-ccxops-corp-kusto). That's why you're getting error 11206 / 403 Forbidden. The error shows an AME-tenant principal (…;33e01921-…) hitting the CORP cluster (ccxops), and managed identities do not support cross-tenant authentication by design a UAMI token from AME can never be authorized on a CORP Kusto cluster, regardless of any role you grant. For AME → CORP, the only supported path is a multi-tenant Service Principal.

Please switch back and set both of these on the CORP side:

Trust: CORP Kusto cluster → Security → add the AME tenant ID to Trusted External Tenants (or "*" if policy allows).

Role: on the CORP database, run: .add database ['OpsDataHub'] viewers ('aadapp=<AME-App-ClientId>;<AME-TenantId>') (use "admins"/"ingestors" instead of "viewers" if the pipeline writes/ingests) 3) ADF Linked Service: • Authentication = Service Principal • Tenant = AME tenant ID • Service Principal ID = AME app Client ID • Service Principal Key = secret from the AME app registration Once both (1) trust and (2) the role grant are in place and you're on Service Principal auth, Test Connection will pass. The UAMI option won't work here because it can't cross tenants.
Hemant 61 Reputation points Microsoft External Staff

2026-07-24T17:50:36.9966667+00:00

Hi @Ganesh Chelluri - as per discussion, point #2 did not work. Please help with this at the earlist
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-24T20:16:06.4333333+00:00

Hi @Hemant ,

Based on the error details shared (403 Forbidden / Caller is not authorized to perform this action), the issue appears to be related to authorization and access permissions on the Azure Data Explorer (Kusto) side.

To help validate the configuration, please review the following:

Verify that the principal being used for authentication has the required permissions on the target Kusto database.

Confirm that the appropriate role assignment has been granted to the Service Principal on the target database.

Ensure the AME tenant is allowed as a trusted external tenant on the CORP Kusto cluster.

Confirm the Linked Service is configured to use the intended authentication method and credentials.

The error message indicates that the principal attempting to connect does not currently have sufficient authorization to access the Kusto service or the target database.

After validating the above configuration, please retry the connection test and share the updated results or any new error messages.
Hemant 61 Reputation points Microsoft External Staff

2026-07-24T21:38:39.48+00:00

Hi @Ganesh Chelluri

Below points were discussed in yesterday’s call and implemented. Also, as highlighted in previous email an in below screenshot, can you provide the details about it?

Answer 1

Smaran Thoomu 170 Microsoft External Staff Moderator

Hi @Hemant
Thank you for your patience while I validated this scenario internally.

Based on the latest confirmation, Federated Identity Credentials (Workload Identity Federation) are currently not supported for Azure Data Factory Linked Services, including the Azure Data Explorer (Kusto) linked service.

Since the linked service expects Service Principal authentication, the currently supported authentication methods are:

Service Principal with Client Secret
Service Principal with Certificate

As your application is configured to use Federated Credentials only, there is currently no supported value that can be supplied for the Service Principal Key field in the linked service.

From the information you've shared, the Kusto-side configuration (trusted tenant, required permissions, and database access) appears to be configured correctly. The remaining blocker is the authentication method itself.

To proceed with the Azure Data Explorer linked service in Azure Data Factory, we recommend using one of the currently supported Service Principal authentication methods:

Service Principal with a Client Secret, or
Service Principal with a Certificate.

Please let us know if using one of these supported authentication methods is feasible in your environment. If not, we can discuss possible alternative approaches based on your security requirements.

Thank you.

Hemant 61 Reputation points Microsoft External Staff

2026-08-04T16:32:34.3466667+00:00

Hi @Smaran Thoomu

Since Service Principal with a Client Secret is blocked in both Microsoft and AME tenants, we would like to use Service Principal with a Certificate. I am not sure about how to create Certificate. Therefore, please guide on it and help with creating a connection.
Hemant 61 Reputation points Microsoft External Staff

2026-08-05T18:30:41.05+00:00

Hi @Smaran Thoomu

Since Service Principal with a Client Secret is blocked across the Microsoft and AME tenants, we would like to use Service Principal with a Certificate. Therefore, please guide us on how to create a Certificate and it will create a connection or not.
Smaran Thoomu 170 Reputation points Microsoft External Staff Moderator

2026-08-07T17:54:47.0333333+00:00
Hi Hemant
Thank you for your patience.

Based on the latest confirmation from our Product Group, Federated Identity Credentials (Workload Identity Federation) are currently not supported for Azure Data Factory Azure Data Explorer (Kusto) Linked Services. The supported authentication methods are:

Service Principal with Client Secret

Service Principal with Certificate (X.509 Certificate)

Since Client Secret authentication is restricted in your Microsoft and AME tenants, the recommended and supported approach is to use Service Principal with an X.509 Certificate.

Regarding your question on certificate creation, yes, I can help guide you through the process. The high-level steps are:

Generate an X.509 certificate (self-signed or CA-issued).

Upload the public certificate to your Microsoft Entra ID App Registration under Certificates & secrets.

Configure the Azure Data Factory Linked Service to use the Service Principal with certificate-based authentication.

Test the connection after completing the configuration.

As this is the supported authentication method for Azure Data Factory Linked Services, it is the recommended approach when Client Secret authentication cannot be used. Once the certificate has been configured correctly along with the existing Kusto permissions, we can validate the connection together.
Hemant 61 Reputation points Microsoft External Staff

2026-08-08T19:26:57.07+00:00

Hi @Smaran Thoomu

Can you please provide the step for Generate an X.509 certificate (self-signed or CA-issued) ?

Answer 2

Ravi Kiran Pagidi 170

Hi Hemant,

This looks like a cross-tenant service principal authorization issue between AME ADF and the CORP Kusto cluster.

Creating the SPN and making it multi-tenant is only the identity/authentication part. The same application/service principal must also be granted the required role inside the target Kusto cluster/database.

Please check these items:

Confirm which tenant is used in the ADF linked service. If the Kusto cluster is in CORP, the linked service usually needs to use the CORP tenant where the enterprise application/service principal exists.
Ask the Kusto database admin to verify whether the SPN is added as a database principal.

Example for read/query access:

.add database <DatabaseName> viewers ('aadapp=<Application_Client_ID>;<Tenant_ID>') 'ADF SPN access'

For ingestion/write scenarios:

.add database <DatabaseName> ingestors ('aadapp=<Application_Client_ID>;<Tenant_ID>') 'ADF SPN ingest access'

Use the correct tenant ID in the Kusto principal assignment. If the enterprise app is created in CORP, use the CORP tenant ID. If you are intentionally authenticating from the AME tenant, then cross-tenant access must be allowed and the principal must be granted using the AME tenant ID.
Verify the principal assignment:

.show database <DatabaseName> principals

In the ADF linked service, confirm the client ID, tenant ID, secret/certificate, cluster URI, and database name are all for the same intended identity path.

If the error says the SPN user does not have access to Kusto, then the linked service is most likely reaching Kusto, but Kusto authorization is failing. I would first validate the database role assignment for the exact Application_Client_ID + Tenant_ID pair being used by ADF.

Hemant 61 Reputation points Microsoft External Staff

2026-07-25T05:18:19.0933333+00:00

Hi Ravi,

Cross tenant SPN was created on Juny-02. SPN permission is also grant. Still not able to create a Linked Service in AME.
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-27T19:49:16.1733333+00:00
Hi @Hemant ,

The screenshots point to an identity mismatch rather than a missing permission.

The AskIAM request provisioned a service principal with AppId starting 9d3a909e...

The app holding Database Admin on ccxops/DataHub is corp-ccxops-kusto (75b38d05...).

Those are two different applications. Provisioning an SP in CORP creates the

identity only it does not grant it any Kusto role.

Before we go further, please confirm two things:

In the AME ADF linked service, what is the Authentication method?

Earlier this was set to User-assigned managed identity (MI-ccxops-corp-kusto).

Managed identities cannot authenticate cross-tenant, so this must be

Service Principal for the connection to work.

What exact Application (client) ID and Tenant ID are configured there?

Then run this on the ccxops cluster (AllDatabasesAdmin) the Permissions blade

is filtered to 3 roles, so it may not show every grant:

.show database ['DataHub'] principals

.show cluster principals

Look for the client ID your linked service uses. If it isn't listed, grant it:

.add database ['DataHub'] viewers ('aadapp=<AppClientId>;<TenantId>')

Use 'admins' or 'ingestors' if the pipeline writes or ingests. The <TenantId>

must match the Tenant value in the linked service, and if that is the AME tenant,

the AME tenant ID must also be in the cluster's Trusted External Tenants list.

Also please confirm whether DataHub is a follower database grants on a follower

are ignored when the leader sets AuthorizedPrincipalsModificationKind, in which

case the role has to be added on the leader cluster.
Hemant 61 Reputation points Microsoft External Staff

2026-07-27T20:00:45.5466667+00:00

Hi @Ganesh Chelluri

please see the below screenshots. AME tenant is marked as trusted but cannot grant the permission.
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-27T21:11:00.86+00:00
Hi @Hemant ,

That error pinpoints the blocker.

Your config is actually fine now - AME tenant is trusted, and the AppId + tenant string in the command is correct. The failure is neither of those: FollowerDatabaseWriteProtectionException "Failed to write to read-only follower database 'DataHub'" DataHub on ccxops is a FOLLOWER database (read-only). ".add database ... viewers" will always fail there - it's permanent, retrying won't help. Principals CAN be set on a follower, but only via follower commands.

On ccxops, as Database Admin: .show follower database DataHub Check AuthorizedPrincipalsModificationKind: - union or replace -> run on ccxops: .add follower database DataHub viewers ('aadapp=9d3a909e-260d-430c-848a-cba0af0d520d;33e01921-4d64-4f8c-a055-5bdaffd5e33d') - none -> principals come only from the leader.

Run the normal .add database command on the LEADER cluster (leader path is in the .show follower database output). These apply on the next schema refresh, so allow a short delay before retesting.

Two things to confirm on your side:

Does the pipeline read or write/ingest? A follower is read-only for data too - if it writes, no permission change on ccxops will help and the Linked Service must point to the LEADER cluster URI.

Is the Linked Service still on the user-assigned managed identity? Switch it to Service Principal - managed identities can't authenticate cross-tenant.

Refs: https://learn.microsoft.com/en-us/azure/data-explorer/follower https://learn.microsoft.com/en-us/kusto/management/cluster-follower
Hemant 61 Reputation points Microsoft External Staff

2026-07-30T01:45:02.5766667+00:00

Hi @Ganesh Chelluri ,

That was an error from my side as I was trying to create a Linked Server for Follower cluster which is incorrect. The correct DB is OpsDataHub. Cluster remains same. I am using the correct DB and try to create a Licked Service on OpsDataHub db which is not Follower DB. Granted the required permission, but the issue is still not solved. Can you please help?
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-30T17:44:01.81+00:00

Hi @Hemant ,

The permission is fine - OpsDataHub is Read-Write (Relationship "None", not a follower), and .show database principals confirms corp-ccxops-kusto (9d3a909e-...) has Database Admin.

The issue is ADF isn't using that principal. Authentication method is still "User-assigned managed identity" (MI-ccxops-corp-kusto), and the 403 rejects: aadapp=46ab2f95-253d-4e1f-b8f3-1625b7bc8f5d;33e01921-... That's the managed identity, not the SPN you granted. So the grant is never checked. Managed identities also can't authenticate cross-tenant, so this path can't work from AME either way.

Update the Linked Service:

Authentication method = Service Principal Endpoint = https://ccxops.eastus.kusto.windows.net
Database = OpsDataHub
Tenant = 33e01921-4d64-4f8c-a055-5bdaffd5e33d
Service Principal ID = 9d3a909e-260d-430c-848a-cba0af0d520d
Service Principal Key= client secret from the AME app registration

Then Test Connection. Also confirm the AME app secret hasn't expired.
Hemant 61 Reputation points Microsoft External Staff

2026-07-30T17:57:31.4833333+00:00

Hi @Ganesh Chelluri

As discussed, the Service Principal Key= client secret from the AME app registration is a Federated. So, please provide details what needs to be enter.
Hemant 61 Reputation points Microsoft External Staff

2026-07-30T22:48:34.0533333+00:00

Hi @Ganesh Chelluri

Can you please update?
Smaran Thoomu 170 Reputation points Microsoft External Staff Moderator

2026-07-31T07:31:00.96+00:00

Hi Hemant

Thank you for the update.

Based on the latest information, it appears the required permissions on the Kusto database have already been configured successfully. The remaining question is around the supported authentication mechanism for the Azure Data Explorer linked service when using an application configured with Federated Credentials.

I am currently validating this behavior with our Product Group to confirm whether Federated Credentials are supported for this linked service and, if so, the recommended configuration. I'll share an update as soon as I receive confirmation.

Thank you for your patience.