get azure ad role assignment

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Get-Azure ADMSRole Assignment

Gets information about role assignments in Azure AD.

Description

The Get-AzureADMSRoleAssignment cmdlet gets information about role assignments in Azure Active Directory (Azure AD). To get a role assignment, specify the Id parameter. Specify the SearchString or Filter parameter to find a particular role assignment.

If true, return all role assignments. If false, return the number of objects specified by the Top parameter.

Specifies an oData v3.0 filter string to match a set of role assignments.

Specifies the ID of the role assignment.

-SearchString

Specifies a search string.

Specifies the maximum number of records that this cmldet gets. The default value is 100.

Microsoft.Open.MSGraph.Model.DirectoryRoleAssignment

See the migration guide for Get-AzureADMSRoleAssignment to the Microsoft Graph PowerShell.

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

All about Microsoft 365

Generate a report of Azure AD role assignments via the Graph API or PowerShell

A while back, I published a short article and script to illustrate the process of obtaining a list of all Azure AD role assignments. The examples therein use the old MSOnline and Azure AD PowerShell modules, which are now on a deprecation path. Thus, it’s time to update the code to leverage the “latest and greatest”. Quotes are there for a reason…

The updated script comes in two flavors. The first one is based on direct web requests against the Graph API endpoints and uses application permissions, thus is suitable for automation scenarios. Do make sure to replace the authentication variables, which you can find on lines 11-13. Better yet, replace the whole authentication block (lines 7-36) with your preferred “connect to Graph” function. Also make sure that sufficient permissions are granted to the service principal under which you will be running the script. Those include the Directory.Read.All scope for fetching regular role assignments and performing directory-wide queries, and the RoleManagement.Read.Directory for PIM roles.

The second flavor is based on the cmdlets included as part of the Microsoft Graph SDK for PowerShell. As authentication is handled via the Connect-MGGraph cmdlet, the script is half the size of the first one. And it would’ve been even smaller were it not for few annoying bugs Microsoft is yet to address.

In all fairness, switching to the Graph does offer some improvements, such as being able to use a single call to list all role assignments. This is made possible thanks to the  /roleManagement/directory/roleAssignments endpoint (or calling the Get-MgRoleManagementDirectoryRoleAssignment cmdlet). Previously, we had to iterate over each admin role and list its members, which is not exactly optimal, and given the fact that the list of built-in roles has now grown to over 90, it does add up. On the negative side, we have a bunch of GUIDs in the output, most of which we will want to translate to human-readable values, as they designate the user, group or service principal to which a given role has been assigned, as well as the actual role. One way to go about this is to use the $expand operator (or the – ExpandProperty parameter if using the SDK) to request the full object.

While this is the quickest method, the lack of support for the $select operator inside an $expand query means we will be fetching a lot more data than what we need for the report. In addition, there seems to be an issue with the definition of the expandable properties for this specific endpoint, as trying to use the handy $expand=* value will result in an error ( “Could not find a property named ‘appScope’ on type ‘Microsoft.DirectoryServices.RoleAssignment'” ). In effect, to fetch both the expanded principal object and the expanded roleDefinition object, we need to run two separate queries and merge the results. Hopefully Microsoft will address this issue in the future (the /roleManagement/directory/roleEligibilitySchedules we will use to fetch PIM eligible role assignments does support $expand=* query).

Another option is to collect all the principalIDs and issue a POST request against the /directoryObjects/getByIds endpoint (or the corresponding Get-MgDirectoryObjectById cmdlet), which does have a proper support for $select . A single query can be used to “translate” up to 1000 principal values, which should be sufficient for most scenarios. With the information gathered from the query, we can construct a hash-table and use it to lookup the property values we want to expose in our report. Lastly, you can also query each principalID individually, but that’s the messiest option available.

Apart from role assignments obtained via the /roleManagement/directory/roleAssignments call, the script can also include any PIM eligible role assignments. To fetch those, invoke the script with the – IncludePIMEligibleAssignments switch. It will then call the /v1.0/roleManagement/directory/roleEligibilitySchedules endpoint, or similarly, use the Get-MgRoleManagementDirectoryRoleEligibilitySchedule cmdlet. Some minor adjustments are needed to ensure the output between the two is uniform, which includes the aforementioned issue with expanding the navigation properties. But hey, it wouldn’t be a Microsoft product if everything worked out of the box 🙂

Here are some examples on how to run the scripts. The first example uses the Graph API version and no parameters. For the second one, we invoke the – IncludePIMEligibleAssignments parameter in order to include PIM eligible role assignments as well. The last example does the same thing, but for the Graph SDK version of the script.

And with that, we’re ready to build the output. Thanks to the $expand operator and the workarounds used above, we should be able to present sufficient information about each role assignment, while minimizing the number of calls made. The output is automatically exported to a CSV in the script folder, and includes the following fields:

• Principal – an identifier for the user, group or service principal to which the role has been assigned. Depending on the object type, an UPN, appID or GUID value will be presented.
• PrincipalDisplayName – the display name for the principal.
• PrincipalType – the object type of the principal.
• AssignedRole – the display name of the role assigned.
• AssignedRoleScope – the assignment scope, either the whole directory (“/”) or a specific administrative unit.
• AssignmentType – the type of assignment (“Permanent” or “Eligible”).
• IsBuiltIn – indicates whether the role is a default one, or custom-created one.
• RoleTemplate – the GUID for the role template.

Now, it’s very important to understand that this script only covers Azure AD admin roles, either default or custom ones, and optionally eligible PIM-assignable roles (do note that the PIM cmdlets/endpoints do not cover all custom role scenarios). Apart from these, there are numerous workload-specific roles that can be granted across Office 365, such as the Exchange Online Roles and assignments, Roles in the Security and Compliance Center, site collection permissions in SharePoint Online, and so on. Just because a given user doesn’t appear in the admin role report, it doesn’t mean that he cannot have other permissions granted!

In addition, one should make sure to cover any applications (service principals) that have been granted permissions to execute operations against your tenant. Such permissions can range from being able to read directory data to full access to user’s messages and files, so it’s very important to keep track on them. We published an article  that can get you started with a sample script a while back.

9 thoughts on “ Generate a report of Azure AD role assignments via the Graph API or PowerShell ”

• Pingback: Reporting on Entra ID directory role assignments (including PIM) - Blog

This script is very nicely written, however the output of the Powershell Graph SDK version is incorrect (I didn’t check the other).

If I am eligible to activate a role I’ll be in the eligible list. However once I activate the role, my activated role assignment will show up in the list of role assignments from “Get-MgRoleManagementDirectoryRoleAssignment”. The output of that command doesn’t include a ‘status’ property. Your script assumes that if there’s no ‘status’ then the assignment is permanent, however that’s not accurate. So every eligible user who has activated a role shows up twice in the output of your script – once as as eligible for the role and once as a permanent assignment.

I came across your script because I’m trying to accomplish a similar task. My goal is to enumerate all the users who have eligible or permanent role assignments. I think the answer may be that if a user is in the eligible list, and also in the role assignment list, for the same role, then you can assume that the role assignment came from activation, but that doesn’t really seem very satisfactory.

Thanks Matt. The script is a bit outdated by now, I don’t even know if it runs with the “V2” Graph SDK. I’ll update it at some point 🙂

To further address your comment – neither the Get-MgRoleManagementDirectoryRoleAssignment nor the Get-MgRoleManagementDirectoryRoleEligibilitySchedule cmdlet returns sufficient information in order to determine whether a given (eligible) role assignment is currently activated. You can get this information via Get-MgRoleManagementDirectoryRoleAssignmentScheduleInstance, should be easy enough to add to the next iteration of the script.

Hi, thks for your great work. do you know why i dont see the eligible assignements ?

Seems they made some changes and you can no longer use $expand=* on the /v1.0 endpoint. Try using /beta, should work there. I’ll update the script when I get some time.

I’ve updated the script, let me know if you are still having issues.

Awesome, thank you very much.

Merci merci merci !!! Thanks thanks thanks !!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

• Active Directory Reporting
• Office 365 Reporting
• Azure AD Monitoring
• Managing Azure AD Roles and Permissions with PowerShell

• August 24, 2023

Managing Azure AD Roles and Permissions with PowerShell. Do you need help managing and automating Azure AD Roles and Permissions with Windows PowerShell? This article explains the typical scenarios for automating Azure Role Based Access Control (RBAC) using PowerShell.

To lay the foundation and prepare to manage Azure roles and permissions, we start with an overview of Azure role-based access control (RBAC). Following that, we explain the three elements of role assignment.

There is also a section that explains the prerequisites for managing Azure AD roles and permissions with Windows PowerShell.

The next sections are dedicated to explaining the steps for assigning Azure AD roles using PowerShell. 

Finally, we explain how to list roles assigned to users and groups using PowerShell .

Also Read  Azure AD Privileged Roles: Manage & Monitor Privileged Access

What is Azure Role-Based Access Control (RBAC)

Azure role based access control (RBAC) allows administrators to do fine grained access control to resources . In other words, Azure RBAC allows admins to control who has access to resources.

Additionally, RBAC controls the level of access to resources in Azure.  

At the core of RBAC is role assignments. Azure has hundreds of built-in roles with pre-defined permissions that are assigned to users, groups, or service principals . 

The existence of built-in roles with pre-defined permissions makes role assignments easy, as admins do not have to grant permissions to objects directly. 

However, there are instances where the built-in roles may not be suitable for an organization’s needs. In this situation, custom roles are created. 

This article covers the steps to assign existing roles and also create and assign custom Azure AD roles. 

Azure Role Assignment Elements

Assigning role assignments involves 3 elements – security principal, role definition, and scope. The security principal is the Azure Active Directory object to be assigned the role.

On the other hand, the role definition is the built-in or custom Azure AD role that is being assigned while the scope is level the role is assigned. There are 4 scopes of that roles are assigned in Azure.

Specifically, Azure roles are assigned to a resource, a resource group, a subscription, and a management group. To assign a role to a resource, you require the resource ID.

However, assigning a role to a resource group scope requires the name of the resource group. Running the Get-AzResourceGroup command returns all resource groups, including their names in the current subscription.

If assigning a role at the subscription scope, you need the subscription ID. To list all subscriptions in the tenant, run the Get-AzSubscription command.

Finally, roles are assigned a management group scope which requires the name of the management group. To get the name of a management group, run the Get-AzManagementGroup command.

Understanding these elements is important to managing Azure AD roles and permissions  with PowerShell. In the remaining part of the article, we explore how the security principal, role definition, and scope are used to assign and manage roles in Azure AD using PowerShell.

Also Read  Deploy InfraSOS Office 365 Reporting & Auditing SaaS Tool

Try our Active Directory & Office 365 Reporting & Auditing Tools

Try us out for Free .  100’s of report templates available. Easily customise your own reports on AD, Azure AD & Office 355.

Prerequisites for Managing Azure AD Roles and Permissions with PowerShell

Before an admin assigns roles, they must meet the following requirements:

• The user must be assigned the roles with Microsoft.Authorization/roleAssignments/write permissions. Sole roles with this permission are User Access Administrator , Owner, or Global Administrator. 
• Secondly, you require access to Azure Cloud Shell or Azure PowerShell . 
• The user account running the PowerShell commands must have the the Microsoft Graph Directory.Read.All permission. 
• Finally, to perform some of the tasks in this article, your account requires a minimum Azure AD Premium P1 license .

As we progress in this article, we explain the steps to assign these permissions as required. 

Also Read  Azure AD Roles & Privileges: Azure AD RBAC Model

Steps to Assign Built-in Azure AD Roles Using PowerShell

I’ll be running the PowerShell commands in this and subsequent sections from Azure Cloud Shell , a browser-based shell that allows running Azure CLI or PowerShell commands . However, I’ll be running the commands from my computer. 

If you click the cloud shell link above and sign in with your Azure account, it displays a screen like the one in the screenshot below. The benefit of Azure Cloud Shell is that it does not require installing any PowerShell modules on your PC. 

Step 1: Determine the Object ID

You need to get the object ID before assigning a role to an Azure resource. Follow these steps to determine the object ID for a user, group, or subscription. 

1. Open the Azure Cloud Shell – shell.azure.com and sign in with your Azure account.

If you’re opening Azure Cloud Shell for the first time, it requires you to create a storage account.

2. Run the commands below to get the ID of the user or group you need to assign a role. In the first command, I an returning the ID of a user that begins with 

The first command saves the ID of the user in the userid variable, while the second one saves the group ID of the group to the grouped variable. Before running the commands remember to change the UserPrincipalName and the DisplayName. 

Also Read  Try InfraSOS Office 365 Reporting & Auditing Solution

Step 2: Get the Role to Assign

The next step for managing Azure AD roles and permissions with PowerShell is determining the role to assign. Start by listing all the available roles in your Azure AD tenant using the following command.

The command displays the Name , and Id of all roles in the tenant. Additionally, it returns True or False in the IsCustom column. 

To demonstrate, I want to assign the Security Admin role to the user and group I determined in Step 1. To display the name of the role, I pipe the output of the Get-AzRoleDefinition command to Where-Object as shown in this command. 

Step 3: Identify the Role to Assignment Scope

The command below returns the ResourceID of a storage account (resource scope) and saves it in the ResourceID variable. 

Later, I assign the user in step 1 the “Security Admin” role in this storage account resource. 

Also Read  Azure AD Role-Based Access Control Best Practices: How to Use Azure AD Roles and Privileges Effectively

Step 4: Assign the Azure Role

Using the information in steps 1 to 3, run the command below to assign the role to the user . Before running the command, the role is not assigned to this storage account, as shown in the screenshot below. 

The first command assigns the “Security Admin” role to a user saved in the $userid variable. Similarly, the second command assigns the same role to a group saved in the $groupid variable. 

After running the above commands, refreshing the storage accounts displays the Security Admin role, and the user and group assigned the role. 

Also Read  Implement Azure AD Role Based Access Control Policies

Display Azure AD Role Assignment Using PowerShell

Earlier, I assigned the “Security admin” role to a user with UPN, [email protected]. If you recall,  the userId for the user was saved in the $userid variable. 

Similarly, the scope ID of the storage account was saved in the $scoperesourceID variable. To display the role assignment for the user, I run the command below. 

The command displays the role assignment details, including the RoleAssignmentName, and scope. 

You display the same information for the group by running this command. 

Also Read  Try InfraSOS Azure AD Reporting & Auditing Tool

Managing Azure AD Roles and Permissions with PowerShell Conclusion

Administering Azure roles requires knowledge of the role based access control model . Additionally, understanding Azure role assignment elements – security principal, role definition, and scope – is essential to manage role assignments with PowerShell effectively. 

Not only that, but an account assigning roles has to meet some prerequisites such as such as configuring PowerShell with the required modules and ensuring appropriate administrative privileges.

The step-by-step guide provided in this article offers a clear roadmap to follow when assigning built-in Azure AD roles using PowerShell. From determining the Object ID to identifying the scope for role assignment, each stage is meticulously outlined, facilitating a seamless and controlled role allocation process.

Try InfraSOS for FREE

Try InfraSOS Active Directory, Azure AD & Office 365 Reporting & Auditing Tool

• Free 15-Days Trial
• SaaS AD Reporting & Auditing Solution

Related posts:

• Azure AD Roles and Permissions: Assign & Manage Roles for Users & Groups
• Office 365 Identity & Access: Manage Users & Permissions
• Azure AD Custom Roles: Create & Manage Custom Roles for Azure AD
• Azure AD Privileged Roles: Manage & Monitor Privileged Access
• Azure Storage Security: Secure Accounts with Encryption & Access Policies

• Victor Ashiedu
• No Comments

Leave a comment Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Building a comprehensive report on Azure AD admin role assignments in Powershell

Keeping an eye on azure ad administrative role assignments is crucial for tenant security and compliance. forget about the built-in pim report in the azure ad portal - take reporting to the next level and build your own report with graph, kql and powershell..

Unassigning inactive roles, verifying that all role holders have registered MFA and are active users, auditing service principals, role-assignable groups and guests with roles, move users from active to eligible roles in PIM ( Privileged Identity Management ), and making sure that no synchronized users have privileged roles are just a few ideas for why you should be reporting on this topic.

In this blogpost I will showcase how to gather data from various sources and compile it all into an actionable status report. Since different tenants have different needs and ways of working, I’m providing examples so that you can write your own custom-tailored script.

The report will list the following records:

• Users with eligible or active Azure AD admin roles - including details on last role activation date, role assignment and expiration dates, MFA status and last sign-in date, admin owner account status etc.
• Service Principals / Applications and Managed Identities with active Azure AD admin roles - including details on last authentication date, tenant ownership, etc.
• Role-assignable groups with eligible or active Azure AD admin roles

Note : Role-assignable groups granted one or more Azure AD admin roles will be listed in the report but users with active or eligible membership to such groups will currently not be listed.

See the Report examples chapter for details.

Prerequisites

Connecting to graph and log analytics, mfa registration details, role assignments, principal last sign-in date, eligible role last activation date, default mfa method and capability, admin account owner, service principal owner organization, report examples, example script.

These Powershell modules are required:

• Graph Powershell SDK
• Azure Powershell

Other prerequisites:

• Global Reader role (or other AAD roles granting enough read-access)
• Admin consent to any required non-consented Graph scopes (read-only) in Graph Powershell SDK.
• Reader-role on the Log Analytics workspace where the Azure AD Sign-in and Audit logs are exported.

Connect to Graph with the Graph Powershell SDK using the required read-only scopes, and select the beta endpoint as required by some of the cmdlets:

Then connect to Azure with the Azure Powershell module, for running KQL queries on the Log Analytics workspace data. Read my Query Azure AD logs with KQL from Powershell blogpost for more information on running KQL queries in Powershell. Update the various parameters according to your environment.

Extracting data

We need to extract data from various sources using Microsoft Graph and KQL queries in Log Analytics.

To report on MFA registration details for Azure AD admin role holders it is likely most efficient to extract all registration details and create a hashtable for quick lookup, depending on the number of users in the tenant.

Assigned roles are active role assignments. This query will also return eligible role assignments which are currently activated through PIM, so we’ll filter those out as they will just be duplicates in the report as they are also listed as eligible roles.

Eligible roles are role assignments requiring activation in PIM.

Then we combine the two assignment types into one array. Use the Select-Object cmdlet to pick out a few records while developing and testing the script.

Now we have all the assignment objects we need in the $allRoleAssignments array, and will process each of those objects in a foreach loop to fetch other necessary data. In the following examples I’ve populated the $roleObject variable with one object from the $allRoleAssignments array.

Since the $allRoleAssignments array may contain both users and Service Principals with active or eligible role assignments, the $roleObject.Principal.AdditionalProperties.'@odata.type property will tell which principal type the current object is - either '#microsoft.graph.user or #microsoft.graph.servicePrincipal . And for Service Principals we can differentiate on types in the $roleObject.Principal.AdditionalProperties.servicePrincipalType property - which is either Application or ManagedIdentity .

The quickest way to get an Azure AD user’s last sign-in date is to query Graph for the user and selecting signInActivity .

For Service Principals we need to query the Azure AD logs in Log Analytics with KQL to fetch the date when the Service Principal last signed in.

KQL query for Service Principal of type Application :

KQL query for Service Principals of type ManagedIdentity :

We also need to fetch the latest date of eligible role activations for users. If $roleObject.AssignmentType equals null and the principal is a user, the following KQL query can help out:

Users with administrative roles and no registered MFA method can be a security risk, depending on tenant configuration and conditional access policies. It’s best to avoid it - while also report on the default type of MFA methods active role assignees have. We already have the $mfaRegistrationDetailsHashmap hashtable and can query it for each processed role where the principal is a user.

If you’re following Microsoft best-practises and separating normal user accounts from administrative roles, you should be having a separate admin account for each user who requires privileged roles and access.

When having separate admin accounts it’s also important to check account status of the admin account owners if possible - to make sure that all admin accounts of terminated employees have been disabled and/or deleted. This query will depend on how you identify admin account owners in your tenant, the following example extracts the owner’s accountName from the UPN and queries Graph for any user with that onPremisesSamAccountName + employeeId .

Service Principals of multi-tenant app registrations can be owned by other Azure AD tenants and consented to in your tenant. It’s important to know about these and understand why they have privileged roles.

If $roleObject.Principal.AdditionalProperties.appOwnerOrganizationId is not null , query Graph for the tenant properties of the owner organization.

$spOwnerOrg.displayName will contain the tenant organization name, and $spOwnerOrg.defaultDomainName the tenant’s default domain’, which can provide a better clue of what the Service Principal is used for and by whom.

Note : Know 100% what you’re doing before removing any privileged roles from Service Principals, especially from Microsoft-owned apps which likely have the roles for a very good reason.

That’s about it, we now have the data necessary to compile an actionable status report on all active and eligible Azure AD role assignments.

Compiling the report

We can now construct a PSCustomObject per role assignment with the collected data.

User with eligible role assignment:

User with active role assignment and owner account details:

Service Principal with role assignment:

Managed Identity with role assignment:

Role-assignable group with role assignment:

In case you need more tips on creating a reporting powershell script for this report, take a look at the example script I’ve published on GitHub .

Thanks for reading!

Be sure to provide any feedback on Twitter or LinkedIn .

• ← Previous Post
• Next Post →

Get-AzRoleAssignment

In this Azure PowerShell article, we will discuss the syntax and usage of the Get-AzRoleAssignment PowerShell cmdlet with a few examples.

Table of Contents

Syntax of Get-AzRoleAssignment

Wrapping up.

Get-AzRoleAssignment is an excellent Azure PowerShell cmdlet that can get you the lists of all the role assignments under your subscription or a specific scope.

Below is the syntax of the Get-AzRoleAssignment Azure PowerShell cmdlet.

Let’s discuss some examples of implementation of the Get-AzRoleAssignment PowerShell command.

You can execute the Azure PowerShell cmdlet below to help you get the list of all the role assignments under my current subscription.

After executing the above PowerShell command, I got the below output.

You can see the output below

You can also use the below Azure PowerShell command to get the list of role assignments under the specified service principal “http://tsinfotechnologies.com”.

Execute the below PowerShell command that can help you to get the list of role assignments under a specified tsinfo website scope.

You may also like following the articles below

• New-AzRoleAssignment
• Get-AzRoleDefinition
• Get-AzResource

In this Azure article, we have discussed the syntax and usage of the Get-AzRoleAssignment Azure PowerShell cmdlet. Thanks for reading this article !!!

I am Rajkishore, and I have over 14 years of experience in Microsoft Azure and AWS, with good experience in Azure Functions, Storage, Virtual Machine, Logic Apps, PowerShell Commands, CLI Commands, Machine Learning, AI, Azure Cognitive Services, DevOps, etc. Not only that, I do have good real-time experience in designing and developing cloud-native data integrations on Azure or AWS, etc. I hope you will learn from these practical Azure tutorials. Read more .

Get PIM Role Assignment Status For Azure AD Using Powershell

If you’re like me and you love to run reports to get valuable information for your tenant and settings, the get PIM role assignment status is the script for you. Recently I was running a report to audit user permissions in Azure AD and realized that my data was off by a bit. I knew some users were added to Privilege Identity Management (PIM) roles but they weren’t showing up in my report.  

The reason they weren’t showing up is because I was using the Get-AzureADDirectoryRoleMember cmdlet and that only shows users with current or activated access. If a user was not elevated in PIM, they basically didn’t have access so it skewing my results.

To give you a better idea of what I’m talking about, the above is a sample of the Helpdesk Administrators role. In the Azure AD GUI, the user is added as an eligible role, meaning he can elevate his just in time access. However in Powershell, since the role is not activated, it is not going to display.

Therefore we are going to use the Get-AzureADMSPrivilegedRoleDefinition Azure AD cmdlet to display the list of roles available and the Get-AzureADMSPrivilegedRoleAssignment to filter for the user we’re specifying.

Requirements for this script to work

In order to make this work you’ll need the following:

• AzureADPreview Powershell module .

I want to emphasize the “preview” in the name of the module. Using just the regular AzureAD module is not not going to work so that’s something to keep in mind.

Script Parameters

Userprincipalname.

Specify the UserPrincipalName for the user you want to check roles for.

Specify the RoleName you want to filter for. This will display all PIM roles that are granted directly or through a group.

By default it will use the TenantId from your current session. If you’re connected to a multi-tenant, you can specify the tenant here.

By using this script you’ll be able to see all the people who have standing access as well as PIM eligible roles.

We can now see that the Helpdesk Administrator is now showing up in our output and in the Assignment column it is labeled as Eligible. We’ll also take note that we can see if the member type is added through a group or if it was added directly. This script will support that option.

Get PIM role assignment status for Azure AD using Powershell will now be in your arsenal of cool tips and tricks for your Syadmin role. If you’re interested in more scripts like this, be sure to check out our Powershell Gallery or Azure Content . Finally, be sure to check out our Youtube Channel for any video content.

Paul Contreras

Hi, my name is Paul and I am a Sysadmin who enjoys working on various technologies from Microsoft, VMWare, Cisco and many others. Join me as I document my trials and tribulations of the daily grind of System Administration.

Is there a possibility we could get an updated version of this using Microsoft Graph or Graph API? I cannot find any suitable alternatives now that the azure cmdlets are depreciated.

Yes. I have the script already created, just need to create an article

Could you upload this script, please? This is wonderfull.

See my updated post for the Graph API version. https://thesysadminchannel.com/get-entra-id-pim-role-assignment-using-graph-api/

See my updated post for the Graph API script. https://thesysadminchannel.com/get-entra-id-pim-role-assignment-using-graph-api/

it was a great job but riles are changed and groups extract cannot work

What about a similar Script for Azure resource roles?

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Azure AD - List Role Assignments

Retrieving a list of all Azure AD role assignments sounds easy enough, right? Well, there are some things to consider, here is waht.

Table of Contents

Introduction.

Unfortunately, its not straight forward, to get list of all Azure AD role assignments, unless you are not using Privileged Identity Management (PIM). First, we need the Microsoft Graph PowerShell SDK. Follow these steps . Currently, to retrieve eligible, its required to set the Microsoft Graph profile to beta . Also, those information can only be queried using the Windpws PowerShell.

The gist can either be found here or explained in detail below.

I hope this makes your life a little simpler 😉

• Share on Facebook
• Share on Twitter
• global.share_on_linkedin
• global.share_on_xing

IT Insights Blog

Knowledge Delivered

We are passionate about IT and we are passionate about sharing. The only possible way for us to express our needs is to collect, enrich and share our knowledge and our everyday experiences. This blog contains knowledge from the field and our goal is to provide helpful articles for everyone that comes across a similar problem or just wants to gain some practical knowledge about cloud technologies.

Automatically generate PowerShell Markdown documentation - Part 1

This blog series introduces a PowerShell module that automatically generated MarkDown documentation of your PowerShell Scripts and modules. It also gives an introduction into Abstract Syntax Trees (ASTs) in PowerShell.

Get Server Manager Features from configuration file

Enable wake-on-lan (wol) with powershell.

With every recent Windows 10 update, and they happen a lot, Windows unfortunately also resets the power settings of the network adapters. Since I like to start both my PC and notebook from a remote location or from within the same network, I wrote a little PowerShell function to enable Wake-on-LAN (WoL) again.

Azure Active Directory License Assignment for Groups

The Azure Active Directory has for some time been offering the ability to assign licenses to users such as EMS, Office 365 (Exchange, SharePoint, etc.), but can also provide groups with licenses. As soon as a user is added to a group, if there are still enough licenses available, the user will receive the corresponding license assigned to the group. This works with synchronized groups from the local Active Directory as well as with Azure AD Security and dynamic groups.

Azure DevOps PowerShell Module - Part 1

If you are like me - at least in terms of lazyness - you automate the stuff that you face more than once. Recently, I came accross the reoccuring task of creating Azure DevOps projects with several teams over and over again.

Static Websites with Azure - Static site generators

This blog series explains what static site generators are, why we have chosen a static site generator for our blog, how static sites can be implemented using only Microsoft Azure technologies and when you should consider using them vs. a CMS like WordPress.

Process low level NtSecurityDescriptor

The SECURITY_DESCRIPTOR structure stores security related attributes of an object. It determines, who can access the object and which additional permissions are assigned. Because sometimes you are confronted with the “raw” NtSecurityDescriptor e.g. in Active Directory related scenarios, I tried give an overview about all parts of it.

Exchange hybrid user migration

During an Exchange online migration, some preparations must take plce in advance so users can be migrated easily to the cloud. A typical error in the mailbox migration process occurs because of the mail domain (property: smtp/proxyaddresses) with the message “Target mailbox doesn’t have an smtp proxy”.

Global Azure Bootcamp 2019

Once every year, all the worldwide Azure communities come together to the Global Azure Bootcamp. This year on April 27th it’s the sixth time and we are proud to be part of it the fourth time in a row!

75 posts found

List Azure AD Roles and Role Assignments using Powershell

In my previous posts I discussed about listing Azure AD users and groups and provided Powershell scripts to generate those quickly :

• List all Azure AD Users
• List all Azure AD Groups

In this post I will discuss about Azure AD Roles and Administrators assigned to those roles.

As per Microsoft document – Using Azure Active Directory (Azure AD), you can designate limited administrators to manage identity tasks in less-privileged roles. Administrators can be assigned for such purposes as adding or changing users, assigning administrative roles, resetting user passwords, managing user licenses, and managing domain names. The default user permissions can be changed only in user settings in Azure AD.

Microsoft provides a list of predefined roles to correctly assign users, groups and service principals with only required access to do their job. You can also create Custom roles for administrators (currently a preview feature) if builtin roles do not meet your requirements. With custom roles you can define your own role based access control and scope to apply this role. Refer following document to learn more about it :

Custom administrator roles in Azure Active Directory

I am sharing a script today to generate list of all administrator roles in Azure AD along with members assigned to those roles. I run this script as part of my standard Azure AD reporting and auditing permissions.

Before we start, make sure, you have Powershell Az module installed and imported. Follow this document if you have any issue. We will also need Powershell AzureAD module. Use following command to install AzureAD module :

Next, we will need to login to Azure AD with Connect-AzureAD Command.

Following script block will get all available Azure AD Roles and then loop through each role. Next, it will get members of each role and collect additional information about the user/service principal, including, Display Name, Email, Department, Account Status, Create date etc.

Finally, I export those details to a csv file as output. Here is my complete script for your reference :

You will get a csv file output once it runs successfully as shown below :

Share this:

Wim Matthyssen

Azure infra, security & governance, azure development and ai/ml, azure identity and security, stéphane eyskens, cloud-native azure architecture, geert baeke, azure kubernetes service & containerization, maik van der gaag, azure infrastructure as code & devops, bart verboven, sammy deprez, azure ai, ml & cognitive services, sander van de velde.

A powershell script for activating an eligible role assignment in Azure AD

By Anatoly Mironov

Recently my role assignments in Azure AD were switched from permanent to eligible ones. This is part of PIM - Privileged Identity Management, you can read more about it on MS Docs:

• Start using Privileged Identity Management

To activate your eligible assignment you can use Azure Portal, Graph API, and PowerShell. The activation in the portal and Graph API is described on MS Docs:

• Activate my Azure AD roles in PIM

My roles within Privileged Identity Management in Azure Portal

I created a simple powershell script for activating my eligible roles quickier when I need it. There are two variants of this script:

• a generic one, that can be run by anyone
• a “shortcut” version that can be created for a specific account, a specific role, to make it even quicker.

A generic version

This version fetches the assignments you have, tenant id (resourcid), your account id (objectid, subjectid), and then it activates your desired role. Some parts can be made even more generic, but the key thing here is that you can adjust it and run for any account.

Shortcut version

This version assumes that you already know all the ids, by running the generic version or by looking it up in Azure. When you know those ids, you can skip many calls to Azure AD, which makes activation quicker and you can start working on your task rather than surfing around to activate your role in Azure.

Save it as a script and run it when you need it. Much quicker. One important note, though: Please be aware that it still can take time to fully activate (propagate) your role, especially SharePoint Administrator, often a couple of minutes. But instead of clicking around, run the script and go grab a cup of coffee, when you’re back, you are good to go.

Security Note. Automating role activations is not less secure. You still have to log in to Azure AD using MFA (I hope you have it) even when you run the script.

• administrator