Which IIQ version are you inquiring about?
8.4p1
@suneethkodeere Based on the Entra ID Connector Guide (8.5p1), here are a few things to verify for Azure Role Assignment aggregation :
-
OAuth scope — Existing clients must be modified to support
management.azure.comas the scope. Ensure your app registration includes the Azure Service Management → user_impersonation delegated permission. -
API permissions — The service principal needs at minimum Reader role at the Management Group or Subscription scope for
Microsoft.Authorization/roleAssignments/readandMicrosoft.Authorization/roleDefinitions/read -
Group schema — Confirm the
azureRoleAssignmentgroup object attributes (listed under “Azure Role Assignment” in the schema section) are correctly added to your group schema. -
Please also share your app xml.
Does task results throws any warnings/errors?
no errors or warning
Ok. Can you check OAuth Scope as suggested my Neel
Use Azure Cli to check OAuth scope, RBAC is configured correctly on Azure side and able to retrieve needed data
i will check and let you know.i am checking with azure team.
Hello Suneeth. Since the aggregation completes without errors, I would first check whether IIQ is actually scanning azureRoleAssignment. In your Account Group Aggregation task, select only the Azure application and check Filter object types to scan. Make sure azureRoleAssignment is included, or leave the filter empty. Also try one full run with Delta Aggregation disabled.
Next, I would compare your schema with the Azure Role Assignment documentation:
- Group schema:
objectType="azureRoleAssignment",nativeObjectType="azureRoleAssignment",aggregationType="group",identityAttribute="id". - Account attribute:
name="azureRoleAssignments"(plural),schemaObjectType="azureRoleAssignment"(singular), marked as entitlement, managed and multi-valued.
The group schema is important here. A wrong account attribute mapping alone would not explain why group aggregation returns no objects. On the Azure side, Neel has already mentioned the permissions. I would verify that the service principal has Microsoft.Authorization/roleAssignments/read and Microsoft.Authorization/roleDefinitions/read (or Reader) at the relevant Subscription or Management Group scope. These are Azure IAM permissions, separate from app registration API permissions.
If those look correct, could your Azure team test the Role Assignments API using the same service principal at a scope where assignments are known to exist? If the API returns assignments but IIQ does not, I would focus next on the connector configuration and logs. Also, since you are on 8.4p1, please confirm that your installed Entra connector build supports this configuration.
Could you share your group schema, aggregation task settings and any relevant connector logs, with sensitive details removed? That should help narrow it down.
i have tried before running group aggregation task with only azureRoleAssignment object type. Nothing is coming .Nothing is getting read.
Regarding this - Also, since you are on 8.4p1, please confirm that your installed Entra connector build supports this configuration.
what is this .We have the cloud governenace licesens.That is only thing we need right?
Hello Suneeth. Yes, the Cloud Governance license is correct, and you do not need another license or connector. I would not assume 8.4p1 is the problem.
Since the task filter is already ruled out, I would focus on the Azure connection. One thing to pin down first is your OAuth grant type, since it changes whose permissions matter:
- Client Credentials: confirm the service principal has Reader, or
roleAssignments/readandroleDefinitions/read, at the relevant Subscription or Management Group scope. - Refresh Token / Auth Code (delegated): check the authenticated user’s permissions instead.
Either way, have your Azure team confirm the connector can get a token for management.azure.com, then call the Azure Role Assignments API with that same identity at a scope where assignments exist. If Azure returns them but IIQ does not, enable connector debug logging and rerun to see whether the management.azure.com call is made and what status it returns.
Could you confirm the grant type you are using? That will help narrow it down.
@suneethkodeere Did you get a chance to check these pointers with your Azure team?
here are logs
sailpoint.connector.AzureADConnector:2037 - Inside iterateObjects
sailpoint.connector.AzureADConnector:3760 - Selected Grant Type : CLIENT_CREDENTIALS
sailpoint.connector.AzureADConnector:3874 - Azure IAAS enablement status : true
sailpoint.connector.AzureADConnector:3899 - Azure IAAS enablement status for Azure ServicePrincipals : true
sailpoint.connector.AzureADConnector:3874 - Azure IAAS enablement status : true
sailpoint.connector.AzureADConnector:2045 - Initiating aggregation request for Azure Object ‘azureRoleAssignment’
sailpoint.connector.AzureADConnector:13318 - Trying to destroy connector resources on server.com
sailpoint.connector.AzureADConnector:13319 - Flags: aggregationType = group, phaseName = , isTerminate = false, deltaAggregation = false, isPartitioned = false
sailpoint.connector.AzureADConnector:13344 - Ignoring call to destroy
=============
Group schema
<Schema aggregationType=“group” displayAttribute=“displayName” " identityAttribute=“id” nativeObjectType=“azureRoleAssignment” objectType=“azureRoleAssignment” >
<AttributeDefinition name="displayName" type="string">
<Description>Display Name</Description>
</AttributeDefinition>
<AttributeDefinition name="id" type="string">
<Description>Azure Role Assignment ID</Description>
</AttributeDefinition>
<AttributeDefinition name="resource" type="string">
<Description>Display name of the resource on which role can be assigned</Description>
</AttributeDefinition>
<AttributeDefinition name="roleName" type="string">
<Description>Display name of the role which can be assigned on resource</Description>
</AttributeDefinition>
</Schema>
azure team told me that , it has all permission and but this one is not there “Ensure your app registration includes the Azure Service Management → user_impersonation delegated permission” .is this required ?
@suneethkodeere Based on references, yes it is required. The SailPoint connector calls ARM APIs (default base: https://management.azure.com) to list role assignments, subscriptions, resource groups, and management groups. Without Azure Service Management → user_impersonation those calls cannot authenticate.
Microsoft Graph Bicep Templates doc confirms: “Azure Resource Manager APIs provide one delegated permission: user_impersonation” — meaning any app calling ARM endpoints (management.azure.com) needs it.
Permissions and Privileges for Microsoft Graph Bicep Template Deployments - Microsoft Graph Bicep | Microsoft Learn.
so please give it a try and let us know the result.
sure.we will try and let you know.
i have tried with postman, i am able to fetch role Assignments and role definition using below api
is it an issue with SailPoint Azure connector.
@suneethkodeere Could you please share your app xml?
Hi Suneeth,
As per above discussion, my observation is that this does not appear to be an Azure permissions issue. You have already confirmed that the same service principal can successfully retrieve both Azure Role Assignments and Role Definitions using the Azure Management APIs outside of SailPoint.
Additionally, the logs indicate that the Azure AD connector recognises the azureRoleAssignment object type and initiates the aggregation process. Based on this, the issue is more likely related to the SailPoint Azure AD connector configuration, connector version support, or a potential product limitation/defect in IIQ 8.4p1.
I would recommend verifying the Azure AD connector bundle version and, if the issue persists, raising a SailPoint Support ticket with the relevant aggregation logs for further investigation.