EntraID - Discovering Directory Roles

[flegare]

Hi folks,

Quick one, Saviynt uses directoryRoles in order to discover this entitlement type.  According to the documentation, this endpoint should return all activated roles.  There is no mention of the scope of the call being limited to built-in roles only.

However, when testing it, I saw that some enabled, active custom roles are not being viewed at all. 

Could it be a permission issue in that specific tenant that is hiding the object?  If not, is there a way to get Saviynt to invoke a different endpoint, possibly /roleManagement/directory/roleDefinitions without re-writing the whole inbound connector?

[rushikeshvartak]

Is it working from postman ?

[NM · Accepted solution]

Hi @flegare , yes that is right it will only pull in built in role.

You have to use rest connector and use a different endpoint.

[flegare]

That is the answer I was scared of.  The lack of documentation on both Saviynt and MS for this component is definitely puzzling.  I reaalllyyy don't want to rebuild the whole connector but I think there is no other smart way out of this.

Thanks for the help!!

[NM]

Hi @flegare , we had the same use case .. client wasn't interested to have another connector so eventually we dropped the idea of managing it..

Plus we had only 2 role

[mayankshah]

@rushikeshvartak  @NM - I am using OOB Azure AD connector for importing DirectoryRole entitlement types but when I checked the Saviynt we are getting less count of Directory Roles. Below is one of the example where both the Role are Built in and out of these the "Attack Payload Author" is not present in Saviynt and same behavior  for the API (https://graph.microsoft.com/v1.0/directoryRoles/) response as well.

Role	Assignments	Type
Attack Payload Author	0	Built-in
Attack Simulation Administrator	0	Built-in

What could be the case that I am not getting Attack Payload Author role in the API response?

[NM]

Hi @mayankshah , share postman response.. and if using rest connector you might have to do pagination.

[mayankshah]

@NM - Attached below is the response for the API and screenshot from Azure Portal. 

I completely agree that the URL (https://graph.microsoft.com/v1.0/directoryRoles) is fetching details for built-in roles but there seems to be some built-in roles (screenshot shared for Attack Payload Author) which is not getting fetched for the API response. I wanted to understand what could be the reason for that.

Right now I am just testing the behavior for the Graph API and no plan for now to use REST Connector.

[flegare]

@mayankshah ,

The graph api documentation indicates the call will only return roles that have been activated.  Is it possible this specific role has not been activated yet?

[mayankshah]

@flegare  It's quite possible, I'll check with the Directory team with regards to see if the role is activated.

Doc reference for anyone looking how to activate Entra Role: 

https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-acti...

[flegare]

Graph api also allows role activation: Activate directoryRole - Microsoft Graph v1.0 | Microsoft Learn

Privilege required: RoleManagement.ReadWrite.Directory

POST https://graph.microsoft.com/v1.0/directoryRoles

Sample body:

{

    "roleTemplateId": "810a2642-a034-447f-a5e8-41beaa378541"

}

[mayankshah]

Right, It's just that I don't want to do that directly from API before checking with the respective team. Do we have an GET method API rather to check all activated Roles?

[rushikeshvartak]

Using Graph Explorer

You can test this using the Microsoft Graph Explorer by signing in with your Azure AD account and running the GET request to /v1.0/directoryRoles.

Summary

The /v1.0/directoryRoles endpoint inherently filters out deactivated roles and returns only those that are currently active in your tenant. There’s no need for additional filtering parameters—simply make the GET request to this endpoint, and it will provide the list of active roles.

[flegare]

@mayankshah the idea here is to only expose through Saviynt roles that have to be governed/provisioned to, right?  Asset owners should confirm which roles should be scoped in and as a one-time activity activate the role either through the UI as you mentioned or through the API.

I know I'd take the api and save myself (or someone else) mindless clicking around 😉