Entra ID has a built-in role called “Partner Tier2 Support” that enables escalation to Global Admin, but this role is hidden from view in the Azure portal GUI.

Why it matters

• An adversary may target the “Partner Tier2 Support” role to maintain stealthy, privileged persistence in an Entra ID tenant
• Since the Azure portal GUI obscures this role, it can be challenging for Azure admins and security professionals to audit assignments for this role

“Partner Tier2 Support” is a built-in Entra ID role. The Microsoft documentation says:

This is a privileged role. Do not use.

The documentation continues:

This role has been deprecated and will be removed from Microsoft Entra ID in the future. This role is intended for use by a small number of Microsoft resale partners, and is not intended for general use.

Beyond that, it’s hard to find concrete documentation anywhere about precisely who or what this role is for.

Extremely powerful. “Partner Tier2 Support” is not quite as powerful as Global Admin, but the role does allow a principal with the role to promote themselves or any other principal to Global Admin. Here are the notable privileged actions a principal with the “Partner Tier2 Support” admin role assignment can do:

• Promote itself to Global Admin
• Reset the password for any user, including Global Admins
• Grant any service principal any app role
• Grant admin consent to any app role
• Add new credentials to all existing app registrations
• Add new owners to all existing app registrations
• Add new members to non-role-assignable groups
• Add new owners to non-role-assignable groups

Admins who want to audit assignments for this role face a challenge: the Azure portal GUI hides the role from view. Entra ID roles can be seen by navigating to Entra ID > Roles and administrators. Scroll down the alphabetically-ordered list of roles, and you would expect to see “Partner Tier2 Support” here (Figure 2):

You can search for the role, but it won’t show up (Figure 3):

The Azure portal GUI constructs the list of roles based on a response it makes to the MS Graph roleManagement/directory/roleDefinitions endpoint. By using the browser developer tools, we can see that this endpoint does, in fact, return the “Partner Tier2 Support” role (Figure 4):

The Javascript responsible for making this request resides in BwquIPUVeADz.js (Figure 5):

It’s here that we can see the function filters the response from the MS Graph API based on whether the role is built in and whether the role is listed in a variable called allowlistedRoleTemplateIds (Figure 6):

Microsoft_AAD_IAM defines the allowlistedRoleTemplateIds variable (Figure 7):

The template ID of “Partner Tier2 Support” is e00e864a-17c5–4a4b-9c06-f5b95a8d5bd8 and the role is a built-in role. The role GUID does not appear in allowlistedRoleTemplateIds; ergo the role is not rendered in the GUI.

The following, powerful built-in roles are also not shown in the GUI:

• Directory Synchronization Accounts — Can add new owners and credentials to all service principals
• Partner Tier1 Support — Can add new owners/credentials to all app registrations and add owners/members to all non-role eligible security groups

It’s important to understand the logic of how these roles are hidden in the GUI because this also means that an adversary can’t create a new, hidden Entra role as custom roles are never built in and non-built in roles are always displayed in the GUI according to this logic.

Azure admins should immediately and regularly audit the active and eligible assignments for this role. To audit the current and eligible assignments for this role, Azure admins can make a GET request to the MS Graph roleAssignmentSchedules endpoint and supply an MS Graph-scoped token in the $Token variable:

$PartnerTier2SupportAssignments = $null
$URI = "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignmentSchedules?`$filter=roleDefinitionId eq 'e00e864a-17c5–4a4b-9c06-f5b95a8d5bd8'&`$expand=principal"
    do {
        $Results = Invoke-RestMethod `
            -Headers @{
                Authorization = "Bearer $($MSGraphToken)"
            } `
            -URI $URI `
            -UseBasicParsing `
            -Method "GET" `
            -ContentType "application/json"
        if ($Results.value) {
            $PartnerTier2SupportAssignments += $Results.value
        } else {
            $PartnerTier2SupportAssignments += $Results
        }
        $uri = $Results.'@odata.nextlink'
    } until (!($uri))
$PartnerTier2SupportAssignments

BloodHound CE and BloodHound Enterprise (BHE) users can easily see there are four service principals and one user with this role currently active. Just search for the role using the upper left search box, click the role, and click “Active Assignments” in the entity pane to see the current assignments for that role or any other role (Figure 8):

If you identify a principal with an active assignment for this role, you should immediately investigate whether this is a legitimate assignment and which principals were involved with the creation of the assignment, as this could be evidence of a malicious backdoor in your Entra ID tenant.

Entra ID is a complicated, opaque, and dynamic system. Azure admins must remain diligent to understand the obvious and the not-so-obvious configurations that may negatively affect the security posture of Entra ID and other Azure services.

We have an active Azure security community in the BloodHound Gang Slack full of helpful folks who will help you along your journey. You can get an invite for that Slack here.

We have free and paid tools to help:

• Use BARK to create your own application to audit Entra ID and Azure RM (free)
• Use BloodHound CE to discover and validate attack paths (free)
• Use BloodHound Enterprise to automate continuous attack path identification and risk assessment, remediation guidance, and reporting (paid)