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
Update:
“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:
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):
Correction: while this page does not show this role, the Entra PIM role management page does (Figure 4). Thank you to Steven Lim and Keith Weaver for making me aware of this view.
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 5):
The Javascript responsible for making this request resides in BwquIPUVeADz.js (Figure 6):
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 7):
Microsoft_AAD_IAM defines the allowlistedRoleTemplateIds variable (Figure 8):
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:
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.
UPDATE:
While the Entra “Roles and administrators” table hides this (and other) roles, the Entra PIM roles management table shows this role. This is the easiest way for Azure admins to audit this role.
Thank you to Steven Lim and Keith Weaver for making me aware of this view.
From the Azure portal home page, search for and click on “Microsoft Entra Privileged Identity Management” (Figure 9):
Click on “Microsoft Entra roles” (Figure 10):
Under “Manage”, click on “Roles” (Figure 11):
Find and click on the row for “Partner Tier2 Support” (Figure 12):
Here you will be able to see and audit the eligible and active assignments for that role (Figure 13):
The above is the easiest way for Azure admins to audit this role. What follows is the original text of this blog post:
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 14):
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:
The Most Dangerous Entra Role You’ve (Probably) Never Heard Of was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from Posts By SpecterOps Team Members - Medium authored by Andy Robbins. Read the original post at: https://posts.specterops.io/the-most-dangerous-entra-role-youve-probably-never-heard-of-e00ea08b8661?source=rss----f05f8696e3cc---4