Overview
The permissions required for Dremio to work with AzureAD as an identity provider have had a subtle change in 24.3 which may prevent Dremio from starting up.
Note: Entra ID is the new name for AzureAD. This article uses "AzureAD" throughout.
TL;DR;
If you want to use Dremio RBAC with AzureAD groups, make sure that the Microsoft Graph Application Permissions set up for Dremio in Azure include `User.read.All` and `GroupMember.Read.All` as Application level permissions, not Delegated.
If you only need basic Auth and don't need RBAC, then Application level Permissions are not necessary, and Dremio can be configured to use "oauth" authentication as described here
Symptoms
The server.log may contain the following as Dremio fails to start:
Dremio is exiting. Failure while starting services.
java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)
at com.dremio.extusr.azuread.AzureGraphClient.validateScopesForToken(AzureGraphClient.java:125)
at com.dremio.extusr.azuread.AzureADUserGroupService.start(AzureADUserGroupService.java:304)
at com.dremio.service.SingletonRegistry$AbstractServiceReference.start(SingletonRegistry.java:154)
at com.dremio.service.ServiceRegistry.start(ServiceRegistry.java:89)
Cause
In 24.3, a new check at bootstrap was brought in to make sure that customers who wanted to use 'full' AzureAD authentication had the correct setup. This check makes sure that Dremio can use AzureAD groups for RBAC.
If the AzureAD Application is not set up with GroupMember.Read.All and User.Read.All as Application level permissions, the new check will fail and Dremio will not start.
Reasoning
When configured to use AzureAD for authentication, Dremio requires the User.Read.All and GroupMember.Read.All application permissions in order to query for user information and group membership information for all users in order to properly synchronize AzureAD users and groups into Dremio users and roles respectively.
These must be application permissions rather than delegated permissions, because delegated permissions require all queries to Microsoft's APIs to be in the context of an active AzureAD user's session in order to delegate that AzureAD user's permissions to the application. Dremio must make offline queries to Microsoft's APIs in order to function properly where no active AzureAD user session is associated with the queries, e.g. API requests with PATs (personal access tokens), queries, checking view owners privileges in view delegation, etc.
Dremio's AzureAD integration has always used the application permissions model (versus permission delegation; see Microsoft's docs about their permission types for more details: https://learn.microsoft.com/en-us/graph/permissions-overview?tabs=http#permission-types ). Dremio needs to be able to connect to AzureAD and fetch user/group details. This is similar to Dremio's LDAP integration where BindUser credentials are used, which have privileges to search the directory.
Previous behaviour
In cases where previous versions would start successfully using the same configuration that fails on 24.3, it is very likely that only the basic SSO login worked and the backend calls (to get user's groups, etc.) to AzureAD failed. The new AzureAD application permissions check was added on application startup in 24.3.0 precisely for such use cases since some customers were running into issues with RBAC (which depends on group members) not working with AzureAD. Customers can check their server logs in earlier versions for errors like:
AzureGraphClient - Failure when getting url [https://graph.microsoft.com/v1.0/users/...] with response code 403
to verify whether queries to retrieve AzureAD users and groups was working.