f

src/pentesting-cloud/azure-security/az-basic-information/README.md

@@ -212,32 +212,26 @@ Example:
       - Grant the "User Administrator" role to regional IT staff, scoped to their region's AU.
 - Outcome: Regional IT admins can manage user accounts within their region without affecting other regions.
 
-### Entra ID Roles
+### Entra ID Roles & Permissions
 
 - In order to manage Entra ID there are some **built-in roles** that can be assigned to Entra ID principals to manage Entra ID
   - Check the roles in [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
+  - Roles marked as **`PRIVILEGED`** by EntraID should be assigned with caution because as Microsoft explains [in the docs](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference): Privileged role assignments can lead to elevation of privilege if not used in a secure and intended manner.
 - The most privileged role is **Global Administrator**
-- In the Description of the role it’s possible to see its **granular permissions**
+- Roles group **granular permissions** and they ca be found in their descriptions.
+- It's possible to **create custom roles** with the desired permissions. Although for some reason not all the granular permissions are available for admins to create custom roles.
+- Roles in Entra ID are completely **independent** from roles in Azure. The only relation is that principals with the role **Global Administrator** in Entra ID can elevate to the **User Access Administrator** role in Azure.
+- It's **not possible to use wildcards** in Entra ID roles.
 
-## Roles & Permissions
+## Azure Roles & Permissions
 
-**Roles** are **assigned** to **principals** on a **scope**: `principal -[HAS ROLE]->(scope)`
-
-**Roles** assigned to **groups** are **inherited** by all the **members** of the group.
-
-Depending on the scope the role was assigned to, the **role** cold be **inherited** to **other resources** inside the scope container. For example, if a user A has a **role on the subscription**, he will have that **role on all the resource groups** inside the subscription and on **all the resources** inside the resource group.
-
-### Classic Roles
-
-| **Owner**                     | <ul><li>Full access to all resources</li><li>Can manage access for other users</li></ul> | All resource types |
-| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
-| **Contributor**               | <ul><li>Full access to all resources</li><li>Cannot manage access</li></ul>              | All resource types |
-| **Reader**                    | • View all resources                                                                     | All resource types |
-| **User Access Administrator** | <ul><li>View all resources</li><li>Can manage access for other users</li></ul>           | All resource types |
+- **Roles** are **assigned** to **principals** on a **scope**: `principal -[HAS ROLE]->(scope)`
+- **Roles** assigned to **groups** are **inherited** by all the **members** of the group.
+- Depending on the scope the role was assigned to, the **role** cold be **inherited** to **other resources** inside the scope container. For example, if a user A has a **role on the subscription**, he will have that **role on all the resource groups** inside the subscription and on **all the resources** inside the resource group.
 
 ### Built-In roles
 
-[From the docs: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure role-based access control (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) has several Azure **built-in roles** that you can **assign** to **users, groups, service principals, and managed identities**. Role assignments are the way you control **access to Azure resources**. If the built-in roles don't meet the specific needs of your organization, you can create your own [**Azure custom roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
+[From the docs: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure role-based access control (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) has several Azure **built-in roles** that you can **assign** to **users, groups, service principals, and managed identities**. Role assignments are the way you control **access to Azure resources**. If the built-in roles don't meet the specific needs of your organization, you can create your own [**Azure custom roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles).
 
 **Built-In** roles apply only to the **resources** they are **meant** to, for example check this 2 examples of **Built-In roles over Compute** resources:
 

src/pentesting-cloud/azure-security/az-services/az-azuread.md

@@ -782,6 +782,13 @@ az ad app owner list --id <id> --query "[].[displayName]" -o table
 az ad app list --show-mine
 # Get apps with generated secret or certificate
 az ad app list --query '[?length(keyCredentials) > `0` || length(passwordCredentials) > `0`].[displayName, appId, keyCredentials, passwordCredentials]' -o json
+# Get Global Administrators (full access over apps)
+az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1b2256f9-46c1-4fc2-a125-5b2f51bb43b7/members"
+# Get Application Administrators (full access over apps)
+az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1e92c3b7-2363-4826-93a6-7f7a5b53e7f9/members"
+# Get Cloud Applications Administrators (full access over apps)
+az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d601d27-7b9c-476f-8134-8e7cd6744f02/members"
+
 ```
 
 {{#endtab }}