Shulou(Shulou.com)06/02 Report--

Today, let's share an article about PowerShell. The script for this sharing is mainly used to obtain the situation of user rights distribution in Azure. The original demand is because the company's Azure account has caused some things that should not have happened because of the confusion of rights allocation, so it is necessary to reorganize all the user rights assignments, reorganize and reorganize them. In this case, it is very important to understand the current rights allocation. In general, Azure can assign permissions according to RBAC, which is very convenient. Let's briefly introduce the concept of RBAC.

RBAC concept

With RBAC, you can achieve separation of responsibilities within a team, granting users only the access rights they need to execute the job. Instead of granting everyone unrestricted access to Azure subscriptions or resources, you can only allow certain operations to be performed in a specific scope.

When planning access control policies, the best practice is to give users the minimum permissions they need to get the job done. The following figure shows the recommended patterns related to the use of RBAC.

The way to use RBAC to control access to resources is to create role assignments. This is an important concept to understand-it involves how to enforce permissions. Role assignment consists of three elements: security principal, role subscription and scope.

Security subject

A security principal is an object that represents a user, group, service principal, or managed identity that requests access to an Azure resource.

User-A person who has a profile in Azure Active Directory. You can also assign roles to users in other tenants. For information about users in other organizations, see Azure Active Directory B2B.

Group-A group of users created in Azure Active Directory. When you assign a role to a group, all users in that group own the role.

Service principal-the security identity that an application or service uses to access a specific Azure resource. The service principal can be thought of as the user identity (user name and password or certificate) of the application.

Managed identity-an identity that is automatically managed by Azure in Azure Active Directory. When developing cloud applications, managed identities are typically used to manage the credentials used to authenticate to Azure services.

Role

Azure contains several built-in roles available. Four basic built-in roles are listed below. The first three roles apply to all resource types.

Owner-has full access to all resources, including the right to delegate access to other users.

Participants-all types of Azure resources can be created and managed, but access cannot be granted to other users.

Readers-you can view existing Azure resources.

User access Administrator-allows you to manage user access to Azure resources.

Range

Scope is the set of resources to which access permissions apply. When assigning roles, you can further limit the operations allowed by defining the scope. The scope of use is helpful if you want to assign someone as a site participant, but perform this assignment for only one resource group.

In Azure, scope can be specified at several levels: administrative groups, subscriptions, resource groups, or resources. The scope adopts the structure of parent-child relationship.

When access is granted by the parent scope, these permissions are inherited to the child scope. For example:

If the owner role is assigned to an administrative group-wide user, that user can manage everything in all subscriptions in the administrative group.

If the reader role is assigned to a group in the subscription scope, members of that group can view each resource group and resource in the subscription.

If the participant role is assigned to an application in the resource group scope, the application can manage all types of resources in that resource group, but not other resource group resources in the subscription.

Role assignment is the process of attaching a role definition to a specific range of users, groups, service principals, or managed identities for the purpose of granting access. Access is granted by creating a role assignment and revoked by deleting a role assignment.

The following figure shows an example of a role assignment. In this example, the participant role of the Medical sales Resource group is assigned to the Marketing group. This means that users in the Marketing group can create or manage any Azure resource in the Pharmaceutical sales Resource group. Marketing users do not have access to resources outside the pharmaceutical sales resource group unless they belong to another role assignment.

Basically, the concept of RBAC has been briefly introduced, and we also assign permissions through RBAC. If you want to know about permission allocation, you can run the following script

Function Write-DateTimeMessage {param ([parameter (Mandatory = $false)] [switch] $Warning, [parameter (Mandatory = $true)] [string] $Message [parameter (Mandatory = $false)] [string] $ForegroundColor) if ($Warning) {Write-Warning ($(Get-Date-UFormat'% Y/%m/%d% HV% MV% S') + "*" + $Message)} else {if ($ForegroundColor) {Write-Host ($(Get-Date-UFormat'% Y /) % m Write-Host% d% UFormat% MRV% S') + "*" + $Message)-ForegroundColor $ForegroundColor} else {Write-Host ($(Get-Date-UFormat'% Y/%m/%d% MRV% S') + "*" + $Message)}} [pscustomobject []] $UserObjects = $null Get-AzureRmADUser |% {$User = $_ Write -DateTimeMessage-Message "Checking User $($User.UserPrincipalName)" $RoleAssignments = Get-AzureRmRoleAssignment-SignInName $User.UserPrincipalName if ($null-ne $RoleAssignments) {$RoleAssignments |% {$RoleAssignment = $_ $UserObject = New-Object-TypeName psobject $UserObject | Add-Member-MemberType NoteProperty-Name DisplayName-Value $RoleAssignment.DisplayName $UserObject | Add-Member-MemberType NoteProperty-Name SignInName-Value $RoleAssignment.SignInName $UserObject | Add-Member-MemberType NoteProperty-Name Scope-Value $RoleAssignment.Scope $UserObject | Add-Member-MemberType NoteProperty-Name RoleDefinitionName-Value $RoleAssignment.RoleDefinitionName $UserObject | Add-Member-MemberType NoteProperty-Name ObjectType-Value $RoleAssignment.ObjectType $UserObject | Add-Member-MemberType NoteProperty-Name CanDelegate-Value $RoleAssignment.CanDelegate $UserObject | Add-Member-MemberType NoteProperty-Name RoleDefinitionId-Value $RoleAssignment.RoleDefinitionId $UserObject | | Add-Member-MemberType NoteProperty-Name ObjectId-Value $RoleAssignment.ObjectId $UserObjects + = $UserObject}} else {Write-DateTimeMessage "No role assignment for user $($User.DisplayName)"-Warning}} $OutputPath = Join-Path-Path ([Environment]:: GetFolderPath ("Desktop"))-ChildPath ("AzureUserPermission-" + $(Get-Date-Format) | "yyyyMMdd-HHmmss") + ".csv") if ($null-ne $UserObjects) {$UserObjects | Export-Csv-NoTypeInformation-LiteralPath $OutputPath Write-DateTimeMessage-Message "Please check $OutputPath"-Warning} else {Write-DateTimeMessage "Maybe no user in the environment or didn't get information Please check "- warning}

The script does not have any parameters, just run it directly, and the effect is as follows

After running, a csv file will be generated on your desktop, in which the information will be recorded.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.