Access control

• 1: Access Control Overview
• 2: Microsoft Entra application registration
• 3: Role-based access control

1 - Access Control Overview

Access control is based on authentication and authorization. Each query and command on an Azure Data Explorer resource, such as a cluster or database, must pass both authentication and authorization checks.

Access control is based on authentication and authorization. Each query and command on a Fabric resource, such as a database, must pass both authentication and authorization checks.

• Authentication: Validates the identity of the security principal making a request
• Authorization: Validates the security principal making a request is permitted to make that request on the target resource

Authentication

To programmatically authenticate, a client must communicate with Microsoft Entra ID and request an access token specific to the Kusto service. Then, the client can use the acquired access token as proof of identity when issuing requests to your database.

The main authentication scenarios are as follows:

• User authentication: Used to verify the identity of human users.
• Application authentication: Used to verify the identity of an application that needs to access resources without human intervention by using configured credentials.
• On-behalf-of (OBO) authentication: Allows an application to exchange a token for said application with a token to access a Kusto service. This flow must be implemented with MSAL.
• Single page application (SPA) authentication: Allows client-side SPA web applications to sign in users and get tokens to access your database. This flow must be implemented with MSAL.

User authentication

User authentication happens when a user presents credentials to Microsoft Entra ID or an identity provider that federates with Microsoft Entra ID, such as Active Directory Federation Services. The user gets back a security token that can be presented to the Azure Data Explorer service. Azure Data Explorer determines whether the token is valid, whether the token is issued by a trusted issuer, and what security claims the token contains.

Azure Data Explorer supports the following methods of user authentication, including through the Kusto client libraries:

• Interactive user authentication with sign-in through the user interface.
• User authentication with a Microsoft Entra token issued for Azure Data Explorer.
• User authentication with a Microsoft Entra token issued for another resource that can be exchanged for an Azure Data Explorer token using On-behalf-of (OBO) authentication.

Application authentication

Application authentication is needed when requests aren’t associated with a specific user or when no user is available to provide credentials. In this case, the application authenticates to Microsoft Entra ID or the federated IdP by presenting secret information.

Azure Data Explorer supports the following methods of application authentication, including through the Kusto client libraries:

• Application authentication with an Azure managed identity.
• Application authentication with an X.509v2 certificate installed locally.
• Application authentication with an X.509v2 certificate given to the client library as a byte stream.
• Application authentication with a Microsoft Entra application ID and a Microsoft Entra application key. The application ID and application key are like a username and password.
• Application authentication with a previously obtained valid Microsoft Entra token, issued to Azure Data Explorer.
• Application authentication with a Microsoft Entra token issued for another resource that can be exchanged for an Azure Data Explorer token using On-behalf-of (OBO) authentication.

Authorization

Before carrying out an action on a resource, all authenticated users must pass an authorization check. The Kusto role-based access control model is used, where principals are ascribed to one or more security roles. Authorization is granted as long as one of the roles assigned to the user allows them to perform the specified action. For example, the Database User role grants security principals the right to read the data of a particular database, create tables in the database, and more.

The association of security principals to security roles can be defined individually or by using security groups that are defined in Microsoft Entra ID. For more information on how to assign security roles, see Security roles overview.

Group authorization

Authorization can be granted to Microsoft Entra ID groups by assigning one or more roles to the group.

When checking authorization for a user or application principal, the system first looks for an explicit role assignment that permits the specific action. If the role assignment doesn’t exists, then the system checks the principal’s membership in all groups that could authorize the action.

If the principal is a member of a group with appropriate permissions, the requested action is authorized. Otherwise, the action doesn’t pass the authorization check and is disallowed.

Force group membership refresh

Principals can force a refresh of group membership information. This capability is useful in scenarios where just-in-time (JIT) privileged access services, such as Microsoft Entra Privileged Identity Management (PIM), are used to obtain higher privileges on a resource.

Refresh for a specific group

Principals can force a refresh of group membership for a specific group. However, the following restrictions apply:

• A refresh can be requested up to 10 times per hour per principal.
• The requesting principal must be a member of the group at the time of the request.

The request results in an error if either of these conditions aren’t met.

To reevaluate the current principal’s membership of a group, run the following command:

.clear cluster cache groupmembership with (group='<GroupFQN>')

Use the group’s fully qualified name (FQN). For more information, see Referencing Microsoft Entra principals and groups.

Refresh for other principals

A privileged principal can request a refresh for other principals. The requesting principal must have AllDatabaseMonitor access for the target service. Privileged principals can also run the previous command without restrictions.

To refresh another principal’s group membership, run the following command:

.clear cluster cache groupmembership with (principal='<PrincipalFQN>', group='<GroupFQN>')

Related content

• Understand Kusto role-based access control.
• For user or application authentication, use the Kusto client libraries.
• For OBO or SPA authentication, see How to authenticate with Microsoft Authentication Library (MSAL).
• For referencing principals and groups, see Referencing Microsoft Entra principals and groups.

2 - Microsoft Entra application registration

Microsoft Entra application authentication requires creating and registering an application with Microsoft Entra ID. A service principal is automatically created when the application registration is created in a Microsoft Entra tenant.

The app registration can either be created in the Azure portal, or programatically with Azure CLI. Choose the tab that fits your scenario.

Portal

Register the app

1. Sign in to Azure portal and open the Microsoft Entra ID blade.

2. Browse to App registrations and select New registration.

   

3. Name the application, for example “example-app”.

4. Select a supported account type, which determines who can use the application.

5. Under Redirect URI, select Web for the type of application you want to create. The URI is optional and is left blank in this case.

   

6. Select Register.

Set up authentication

There are two types of authentication available for service principals: password-based authentication (application secret) and certificate-based authentication. The following section describes using a password-based authentication for the application’s credentials. You can alternatively use an X509 certificate to authenticate your application. For more information, see How to configure Microsoft Entra certificate-based authentication.

Through the course of this section, you’ll copy the following values: Application ID and key value. Paste these values somewhere, like a text editor, for use in the step configure client credentials to the database.

1. Browse to the Overview blade.

2. Copy the Application (client) ID and the Directory (tenant) ID.

   [!NOTE] You’ll need the application ID and the tenant ID to authorize the service principal to access the database.

3. In the Certificates & secrets blade, select New client secret.

   

4. Enter a description and expiration.

5. Select Add.

6. Copy the key value.

   [!NOTE] When you leave this page, the key value won’t be accessible.

You’ve created your Microsoft Entra application and service principal.

Azure CLI

1. Sign in to your Azure subscription via Azure CLI. Then authenticate in the browser.

   az login
   

2. Choose the subscription to host the principal. This step is needed when you have multiple subscriptions.

   az account set --subscription YOUR_SUBSCRIPTION_GUID
   

3. Create the service principal. In this example, the service principal is called my-service-principal.

   az ad sp create-for-rbac -n "my-service-principal" --role Contributor --scopes /subscriptions/{SubID}
   

4. From the returned JSON data, copy the appId, password, and tenant for future use.

   {
     "appId": "00001111-aaaa-2222-bbbb-3333cccc4444",
     "displayName": "my-service-principal",
     "name": "my-service-principal",
     "password": "00001111-aaaa-2222-bbbb-3333cccc4444",
     "tenant": "00001111-aaaa-2222-bbbb-3333cccc4444"
   }
   

You’ve created your Microsoft Entra application and service principal.

Configure delegated permissions for the application - optional

If your application needs to access your database using the credentials of the calling user, configure delegated permissions for your application. For example, if you’re building a web API and you want to authenticate using the credentials of the user who is calling your API.

If you only need access to an authorized data resource, you can skip this section and continue to Grant a service principal access to the database.

1. Browse to the API permissions blade of your App registration.

2. Select Add a permission.

3. Select APIs my organization uses.

4. Search for and select Azure Data Explorer.

   

5. In Delegated permissions, select the user_impersonation box.

6. Select Add permissions.

   

Grant a service principal access to the database

Once your application registration is created, you need to grant the corresponding service principal access to your database. The following example gives viewer access. For other roles, see Kusto role-based access control.

1. Use the values of Application ID and Tenant ID as copied in a previous step.

2. Execute the following command in your query editor, replacing the placeholder values ApplicationID and TenantID with your actual values:

   .add database <DatabaseName> viewers ('aadapp=<ApplicationID>;<TenantID>') '<Notes>'
   

   For example:

   .add database Logs viewers ('aadapp=00001111-aaaa-2222-bbbb-3333cccc4444;9876abcd-e5f6-g7h8-i9j0-1234kl5678mn') 'App Registration'
   

   The last parameter is a string that shows up as notes when you query the roles associated with a database.

   [!NOTE] After creating the application registration, there might be a several minute delay until it can be referenced. If you receive an error that the application is not found, wait and try again.

For more information on roles, see Role-based access control.

Use application credentials to access a database

Use the application credentials to programmatically access your database by using the client library.

. . .
string applicationClientId = "<myClientID>";
string applicationKey = "<myApplicationKey>";
string authority = "<myApplicationTenantID>";
. . .
var kcsb = new KustoConnectionStringBuilder($"https://{clusterName}.kusto.windows.net/{databaseName}")
    .WithAadApplicationKeyAuthentication(
        applicationClientId,
        applicationKey,
        authority);
var client = KustoClientFactory.CreateCslQueryProvider(kcsb);
var queryResult = client.ExecuteQuery($"{query}");

[!NOTE] Specify the application id and key of the application registration (service principal) created earlier.

For more information, see How to authenticate with Microsoft Authentication Library (MSAL) in apps and use Azure Key Vault with .NET Core web app.

Troubleshooting

Invalid resource error

If your application is used to authenticate users, or applications for access, you must set up delegated permissions for the service application. Declare your application can authenticate users or applications for access. Not doing so will result in an error similar to the following, when an authentication attempt is made:

AADSTS650057: Invalid resource. The client has requested access to a resource which is not listed in the requested permissions in the client's application registration...

Enable user consent error

Your Microsoft Entra tenant administrator might enact a policy that prevents tenant users from giving consent to applications. This situation will result in an error similar to the following, when a user tries to sign in to your application:

AADSTS65001: The user or administrator has not consented to use the application with ID '<App ID>' named 'App Name'

You’ll need to contact your Microsoft Entra administrator to grant consent for all users in the tenant, or enable user consent for your specific application.

Related content

• Kusto connection strings
• Create a Microsoft Entra application and service principal that can access resources

3 - Role-based access control

Azure Data Explorer uses a role-based access control (RBAC) model in which principals get access to resources based on their assigned roles. Roles are defined for a specific cluster, database, table, external table, materialized view, or function. When defined for a cluster, the role applies to all databases in the cluster. When defined for a database, the role applies to all entities in the database.

Azure Resource Manager (ARM) roles, such as subscription owner or cluster owner, grant access permissions for resource administration. For data administration, you need the roles described in this document.

Real-Time Intelligence in Fabric uses a hybrid role-based access control (RBAC) model in which principals get access to resources based on their assigned roles granted from one or both of two sources: Fabric, and Kusto management commands. The user will have the union of the roles granted from both sources.

Within Fabric, roles can be assigned or inherited by assigning a role in a workspace, or by sharing a specific item based on the item permission model.

Fabric roles

Roles can further be defined on the data plane for a specific database, table, external table, materialized view, or function, by using management commands. In both cases, roles applied at a higher level (Workspace, Eventhouse) are inherited by lower levels (Database, Table).

Roles and permissions

The following table outlines the roles and permissions available at each scope.

The Permissions column displays the access granted to each role.

The Dependencies column lists the minimum roles required to obtain the role in that row. For example, to become a Table Admin, you must first have a role like Database User or a role that includes the permissions of Database User, such as Database Admin or AllDatabasesAdmin. When multiple roles are listed in the Dependencies column, only one of them is needed to obtain the role.

The How the role is obtained column offers ways that the role can be granted or inherited.

The Manage column offers ways to add or remove role principals.

Related content

• Manage view access to tables within the same database
• Manage function roles
• Manage cluster permissions
• Allow cross-tenant queries and commands