create role assignment policy

Using Azure policies to audit and automate RBAC role assignments

Usually different RBAC role assignments in Azure might be inherited from subscription / management group level but there may come a time when that's just way too broad spectrum to give permissions to an AD user group.

While it’s tempting to assign permissions on a larger scope, sometimes you might rather prefer to have only some of the subscription’s resource groups granted with a RBAC role with minimal permissions to accomplish the task at hand. In those scenarios you’ll usually end up with one of the following options to handle the role assignments:

Include the role assignments in your ARM templates / Terraform codes / Bicep templates
Manually add the role to proper resource groups

If neither these appeal to you, there’s a third option: define an Azure policy which identifies correct resource groups and then deploys RBAC role assignments automatically if conditions are met. This blog will go over with step-by-step instructions how to:

Create a custom Azure policy definition for assigning Contributor RBAC role for an Azure AD group
Create a custom RBAC role for policy deployments and add it to your policy definition
Create an assignment for the custom policy

The example scenario is very specific and the policy definition is created to match this particular scenario. You can use the solution provided in this post as a basis to create something that fits exactly to your needs.

Azure policies in brief

Azure policies are a handy way to add automation and audit functionality to your cloud subscriptions. The policies can be applied to make sure resources are created following the company’s cloud governance guidelines for resource tagging or picking the right SKUs for VMs as an example. Microsoft provides a lot of different type built-in policies that are pretty much ready for assignment. However, for specific needs you’ll usually end up creating a custom policy that better suits your needs.

Using Azure policies is divided into two main steps:

You need to define a policy which means creating a ruleset (policy rule) and actions (effect) to apply if a resource matches the defined rules.
Then you must assign the policy to desired scope (management group / subscription / resource group / resource level). Assignment scope defines the maximum level of scanning if resources match the policy criteria. Usually the preferable levels are management group / subscription.

Depending on how you prefer governing your environment, you can resolve to use individual policies or group multiple policies into initiatives . Initiatives help you simplify assignments by working with groups instead of individual assignments. It also helps with handling service principal permissions. If you create a policy for enforcing 5 different tags, you’ll end up with having five service principals with the same permissions if you don’t use an initiative that groups the policies into one.

Creating the policy definition for assignment of Contributor RBAC role

The RBAC role assignment can be done with policy that targets the wanted scope of resources through policy rules. So first we’ll start with defining some basic properties for our policy which tells the other users what this policy is meant for. Few mentions:

Policy type = custom . Everything that’s not built-in is custom.
Mode = all since we won’t be creating a policy that enforces tags or locations
Category can be anything you like. We’ll use “Role assignment” as an example

Now we have our policy’s base information set. It’s time to form a policy rule. The policy rule consists of two blocks: policyRule and then . First one is the actual rule definition and the latter is the definition of what should be done when conditions are met. We’ll want to target only a few specific resource groups so the scope can be narrowed down with tag evaluations and resource group name conventions. To do this let’s slap an allOf operator (which is kind of like the logical operator ‘and’) to the policy rule and set up the rules

As can be seen from the JSON, the policy is applied to a resource (or actually a resource group) if

It’s type of Microsoft.Resources/subscriptions/resourceGroups = the target resource is a resource group
It has a tag named RbacAssignment set to true
The resource group name starts with my-rg-prefix

In order for the policy to actually do something, an effect must be defined. Because we want the role assignment to be automated, the deployIfNotExists effect is perfect. Few mentions of how to set up an effect:

The most important stuff is in the details block
The type of the deployment and the scope of an existence check is Microsoft.Authorization/roleAssignments for RBAC role assignments
An existence condition is kind of an another if block: the policy rule checks if a resource matches the conditions which makes it applicable for the policy. Existence check then confirms if the requirements of the details are met. If not, an ARM template will be deployed to the scoped resource

The existence condition of then block in the code example below checks the role assignment for a principal id through combination of Microsoft.Authorization/roleAssignments/roleDefinitionId and Microsoft.Authorization/roleAssignments/principalId . Since we want to assign the policy to a subscription, roleDefinitionId path must include the /subscriptions/<your_subscription_id>/.. in order for the policy to work properly.

The last thing to add is the actual ARM template that will be deployed if existence conditions are not met. The template itself is fairly simple since it’s only containing the definitions for a RBAC role assignment.

And that’s it! Now we have the policy definition set up for checking and remediating default RBAC role assignment for our subscription. If the automated deployment feels too daunting, the effect can be swapped to auditIfNotExist version. That way you won’t be deploying anything automatically but you can simply audit all the resource groups in the scope for default RBAC role assignments.

That should be enough, right? Well it isn’t. Since we’re using ARM template deployment with our policy, we must add a role with privileges to create remediation tasks which essentially means we must add a role that has privileges to create and validate resource deployments. Azure doesn’t provide such policy with minimal privileges out-of-the-box since the scope that has all the permissions we need is Owner. We naturally don’t want to give Owner permissions to anything if we reeeeeally don’t have to. The solution: create a custom RBAC role for Azure Policy remediation tasks.

Create custom RBAC role for policy remediation

Luckily creating a new RBAC role for our needs is a fairly straightforward task. You can create new roles in Azure portal or with Powershell or Azure CLI. Depending on your desire and permissions to go around in Azure, you’ll want to create the new role into a management group or a subscription to contain it to a level where it is needed. Of course there’s no harm done to spread that role to wider area of your Azure environment, but for the sake of keeping everything tidy, we’ll create the new role to one subscription since it’s not needed elsewhere for the moment.

Note that the custom role only allows anyone to validate and create deployments. That’s not enough to actually do anything. You’ll need to combine the deployment role with a role that has permissions to do the stuff set in deployment. For RBAC role assignments you’d need to add “User Access Administrator” role to the deployer as well.

Here’s how to do it in Azure portal:

Go to your subscription listing in Azure, pick the subscription you want to add the role to and head on to Access control (IAM) tab.
From the top toolbar, click on the “Add” menu and select “Add custom role”.
Give your role a clear, descriptive name such as Least privilege deployer or something else that you think is more descriptive.
Add a description.
Add permissions Microsoft.Resources/deployments/validate/action and Microsoft.Resources/deployments/write to the role.
Set the assignable scope to your subscription.
Review everything and save.

After the role is created, check it’s properties and take note of the role id. Next we’ll need to update the policy definition made earlier in order to get the new RBAC role assigned to the service principal during policy initiative assignment.

So from the template, change this in effect block:

Assigning the created policy

Creating the policy definition is not enough for the policy to take effect. As mentioned before, the definition is merely a ruleset created for assigning the policy and does nothing without the policy assignment. Like definitions, assignments can be set to desired scope. Depending on your policy, you can set the policy for management group level or individual assignments to subscription level with property values that fit each individual subscription as needed.

Open Azure Policy and select “Assignment” from the left side menu. You can find “Assign policy” from the top toolbar. There’s a few considerations that you should go over when you’re assigning a policy:

The scope: always think about your assignment scope before blindly assigning policies that modify your environment.
Exclusion is a possibility, not a necessity. Should you re-evaluate the policy definition if you find yourself adding a lot of exclusions?
You can fix all the non-compliant resources with a remediation task after initial compliance scan

Remediation

If you have a policy that changes something either with modify of deployIfNotExists effect, you’ll be creating a service principal for implementing the changes when you assign the policy. Be sure to check the location (region) of the service principal that it matches your desired location.
If you select to create a remediation tasks upon assignment, it will implement the changes in policy to existing resources . So if you have doubts if the policy works as you desire, do not create a remediation task during assignment. Review the compliance results first, then create the remediation task if everything’s ok.

Non-compliance message

It’s usually a good idea to create a custom non-compliance message for your own custom definitions.

After you’ve set up all relevant stuff for the assignment and created it, it’s time to wait for the compliance checks to go through. When you’ve created an assignment, the first compliance check cycle is done usually within 30 minutes of the assignment creation. After the first cycle, compliance is evaluated once every 24 hours or whenever the assigned policy definitions are changed. If that’s not fast enough for you, you can always trigger an on-demand evaluation scan .

Stefanos Cloud

How to manage Microsoft 365 user role assignments and administrative units

Role assignments
Administrative Units

This article provides guidance on how to manage Microsoft 365 user role assignments and administrative units. The article is also available on my podcast and Youtube channel .

View this article as a how-to video on Youtube.

You need to manage existing user roles, create new custom user roles and assign users and groups to existing roles in Microsoft 365 . You need to also manage Microsoft 365 administrative units.

In this how-to article, we will show you how to manage Microsoft 365 user role assignments and administrative units.

Role assignments #

From within the Microsoft 365 Admin Center portal, you can assign ‎ Azure AD‎ built-in roles to users who need access to other admin centers and resources in ‎ Azure Active Directory‎, such as users, groups, and apps which use ‎Microsoft Graph‎ API. The following groups of user role assignments can be made from the Admin Center portal.

Azure AD role assignments
Exchange Online role assignments
Intune role assignments

In the next steps, we will show you how to assign the Global Administrator Azure AD role to a user and group. Follow the steps below to assign the Global Administrator role to a user or group.

Navigate to https://admin.microsoft.com and authenticate as a global admin user.
On the left pane, expand the "Roles" section and click on "Role assignments". On the main section click on the "Global Administrator" role. On the popup form on the right, you should be able to review the general properties of the role in question. On the permissions tab, the system lists details of the permissions which are assigned with the role in question.
On the "Assigned" tab, you can assign users or groups to the role in question. Click on "Add Users" and then "Add Groups" to add a user and group respectively to the specific role.
To run the Azure portal as a specific Azure AD user role, tick on the checkbox next to the role and click "Run As". This will show you the view of the Azure portal as if you had logged in via a user with the role in question.
To compare permissions of user roles, tick on two or more roles and then click on "Compare Roles". In the next screen, you should see a tabular comparison of the permissions assigned to each of the compared roles. You can also click on "Export comparison" to export the comparison matrix of the selected roles.

In the next steps, we will show you how to assign the Organization Management Exchange Online role to a user and group, as well as how to create a new custom Exchange Online role. Follow the steps below.

Navigate to the "Exchange" tab under the "Role Assignments" section.
Click on the "Organization Management" role. On the popup form on the right, you can review the general settings of the role under the "general" tab. Under the "Permissions" tab, you can review in detail the available permissions of the role in question.
Under the "Assigned" tab, you can assign a user or group to the role in question. Click "Add" and choose the user or group to assign to the role.
You can also create a custom Exchange Online role by ticking the checkbox next to the role which will be used as the template for the new role. Then click on "Copy role group". This will take you to a wizard to create your new custom role. On the "Set up the basics" page, fill-in the name, description and write scope of the new role and click Next.
Select the roles to add to the ‎new custom role group. Roles define the scope of the tasks that the members assigned to this role group have permission to manage.
Select the users to assign to this role group. They'll have permissions to manage the roles that you assigned in the previous step.
Review your selections and click Finish.

In the next steps, we will show you how to assign Intune roles. Assign ‎Intune‎ roles to specialists who need to view or manage ‎Intune‎ data, devices, or services. These roles can only be assigned to users who have a license that includes ‎Intune‎. Follow the steps below.

Under the "Role assignments" section, navigate to the "Intune" tab. If you need to export existing assignments, click on the "Export assignments" button.
Click on the Intune role you wish to edit assignments of. On the "General tab" you can review the general settings of the role in question. On the "Permissions" tab you can see in detail all permissions of the role in question.
To assign users to the Intune role, under the "Assigned" tab click on "Add". This will take you to the "Set up the basics" wizard. Fill-in a name and description and click Next.
Select the security groups that contain the users you want to become admins for the role. Click Next.
Select a built-in security group like 'All users', or search for and select security groups which contain the users and devices that the ‎Intune role can manage.
You can optionally add tabs which limit the specific Intune policies, apps and devices that the admins can see. Click "Next".
Review all your assignment settings and click "Finish".

Administrative Units #

Now we will move on to show you how to create and manage Microsoft 365 Administrative Units. Units let you sub-divide your organization into any unit that you want, and then assign specific administrators that can only manage that unit. For example, you can assign the Helpdesk Administrator role to a regional support specialist, so they can manage users only in that region.

Carry out the following steps:

Under the "Roles" section, click on "Administrative Units". Click on "Add Unit" to add a new administrative unit.
Provide a name and Description of the new administrative unit and click "Next". Administrative units let you limit admins to manage users for a specific department, region, or any segment that your organization defines. Start by giving the administrative unit a name and description that will let other admins know its purpose.
Choose "Add up to 20 users and groups" or "Upload users" if you need to bulk upload a large number of users to be linked to the new administrative unit. If you choose "Add up to 20 users and groups", then click on "Add Users" or "Add Groups" to add the desired users to the administrative unit and click Next. The administrators assigned to this unit will manage the settings for these users and groups. Adding groups doesn't add users to the unit, it lets the assigned admins manage group settings. You can only add up to ‎20‎ members individually or you can bulk upload up to ‎200‎ users. If you need to add more, you can edit this unit to add them.
Assign admins to scoped roles. The following roles are the only roles that support administrative units. Authentication Administrator Cloud Device Administrator Groups Administrator Helpdesk Administrator License Administrator Password Administrator SharePoint Administrator Teams Administrator Teams Device Administrator User Administrator.

Select a role and then assign admins to it. The admins that you assign to roles in this step will manage the members of this administrative unit.

Review your selections and click "Finish". The new administrative unit has been created. You can always edit its properties by clicking on the Administrative Unit name. From that page you can edit the administrative unit's members and role assignments.
You can also edit the name and description of an administrative unit by ticking the checkbox next to the administrative unit name and clicking on "Edit name and description".

What are your Feelings

Share this article :, how can we help.

Subscribe for Practical 365 updates

Please turn off your ad blocker and refresh the page to subscribe.

You may withdraw your consent at any time. Please visit our Privacy Statement for additional information

Exchange Server

Exchange server role based access control in action: using management roles.

Exchange Server uses a permissions model called Role Based Access Control (RBAC) to manage the delegation of permissions for Exchange administrative tasks. RBAC was first introduced in Exchange 2010 and continues to be used in Exchange Server and Exchange Online today. It’s important to understand how RBAC works because it is the mechanism that you use to apply a least-privilege approach to Exchange administrative permissions. RBAC is also how end users are granted permissions to perform tasks such as managing their own distribution groups.

In this tutorial we’ll look at:

How RBAC works by examining the pre-defined RBAC management roles
How to configure custom management roles

The Basics of Role Based Access Control

Whether you understand the inner workings of RBAC or not, you’re still making use of it every day when you perform Exchange administrative tasks. That’s because RBAC has a series of pre-defined management role groups, management roles, and management role assignments for a variety of common administrative scenarios.

Management role groups are the security groups in Active Directory. You can see the management role groups that Exchange creates during setup in the Microsoft Exchange Security Groups OU in Active Directory.

Some of those groups should already look familiar to you, such as Organization Management and Recipient Management. Some of the groups in that OU are for other purposes, such as the Exchange Trusted Subsystem group which contains computer accounts for Exchange servers. So if you want to see just the role groups, you can switch to the Exchange Management Shell instead and run the Get-RoleGroup cmdlet.

Notice how each role group has one or more assigned roles, which refer to management roles. An example of a management role is Mail Recipients.

Management roles are collections of management role entries. Management role entries are specific tasks that can be performed by users who are assigned with that particular role. Continuing with the example of the Mail Recipients role, the management role entries can be summarized by looking at the description of the management role.

So the Mail Recipients role contains a whole bunch of role entries to make that possible. Role entries have a naming convention of “RoleEntry”, so all of the role entries for the Mail Recipients role will be named “Mail RecipientsEntry”. This means that you can see the list of role entries for the Mail Recipients role by running the following command:

On my system there’s 125 role entries for the Mail Recipients role, so I won’t list them all here. But they basically include all the cmdlets you’d need for that purpose, such as Get-Mailbox, Set-Mailbox, and Enable-Mailbox (for mail-enabling an existing user). However, it is a separate management role called “Mail Recipient Creation” that has the role entries that permit creating entirely new recipients, such as New-Mailbox, New-MailUser, and New-MailContact.

Both the Mail Recipients and Mail Recipient Creation roles, along with others, are assigned to the role group named Recipient Management. You can see the role assignments for the Recipient Management role group by running the Get-RoleGroup cmdlet.

The Recipient Management role group is one of the Active Directory security groups that exists in the Microsoft Exchange Security Groups OU. Therefore, if you add a user account to the Recipient Management group, they are granted the ability to perform those administration tasks such as managing mail recipients, distribution groups, and performing message tracking. When that user opens the Exchange Management Shell, only the cmdlets that are included in the role entries for the management roles assigned to the role groups they are a member of will be available. For example, a Recipient Management role group member won’t have access to the New-AcceptedDomain or Set-AcceptedDomain cmdlets, but they do have access to the Get-AcceptedDomain cmdlet.

When the user logs into the Exchange Admin Center, they will also see only the sections that they have access to through their role group membership. For example in the screenshot below, the web browser on the left shows the sections visible to a Recipient Management role group member, and the browser on the right shows the sections visible to an Organization Management role group member.

Some of the differences are obvious, for example the Recipient Management role group member can’t see the compliance management section of the Exchange Admin Center. Others are not so obvious at first. Both users can see the mail flow section where things like Accepted Domains are managed. The Recipient Management role group holder can still see that section, because they need to be able to “see” the list of accepted domains in the organization when assigning SMTP addresses to recipients. But they can’t edit any of the accepted domains, nor can they add new ones.

As the final piece of the RBAC picture, there’s also the concept of management role scope. The management roles (such as Mail Recipients) assigned to the pre-canned role groups (such as Recipient Management) have a scope of “Organization”, which effectively means they apply to the entire organization. Management roles can be scoped to more specific area, such as to a single organizational unit in Active Directory.

So to summarize what’s been covered so far, RBAC is made up of:

Management role entries, which are specific tasks that a user can perform, such as running the Set-Mailbox cmdlet.
Management roles, which are collections of role entries, such as the Mail Recipients role.
Management role scope, which defines where in the organization a management role is applicable to, such as the entire organization, a specific server, or a specific organizational unit.
Management role assignments, which link management roles to role groups.
Management role groups, which are security groups that users can be added to as members to grant them the permissions to perform administrative tasks.

Once you are comfortable with those basics, you can start looking at creating custom roles.

Creating a Custom RBAC Role

Let’s say that you have a user in the organization who is responsible for managing mail contacts. To provide them with the permissions to perform that task, without any additional effort on your part, you would need to add them to the Recipient Management role group. However, that role group permits them to do much more than just manage the mail contacts they are responsible for, so it doesn’t align with the least privilege approach to security.

The more sensible approach is to create a custom RBAC role and assign it to that user, or to a role group that the user can be made a member of.

The easiest way to create a custom role is by using the Exchange Admin Center. In the permissions section under admin roles , click the icon to create a new role group.

Give the role group a meaningful name, and set the organizational unit that you want to limit the role group to.

Next, click the icon to add a role. In scanning through the list of existing roles (remember, these are collections of role entries), there doesn’t appear to be one already created for managing mail contacts. So a custom role (or two) with the role entries for managing contacts needs to be created. Creating custom roles is easiest when you create the custom role based on an existing role, and then customize it for your needs. In this case, Mail Recipients and Mail Recipient Creation are the two roles to base the new custom roles on.

The next step is to remove the unwanted role entries from each of the custom roles, so that they’re only left with the capability to manage mail contacts.

So now we’re left with two custom roles called “Custom Role – Mail Contacts” and “Custom Role – Mail Contacts Creation”, each containing only the role entries required for managing contacts.

Back to the Exchange Admin Center, the two custom roles are now visible in the picker to add to the new role group we’re creating. Add the two custom roles, and also add the View-Only Recipients role.

Finally, add the users who will be performing the administrative tasks to the role group as members, and save the new role group.

When the members of the new “Mail Contact Managers” role group log in to the Exchange Admin Center, they’ll be able to see the recipients in the organization (just as they can see them in the global address list via Outlook), and in the Contacts area will be able to create new Mail Contacts. If the role group member shown above tries to create a contact in an OU other than the one their role has been scoped to, they’ll receive an error.

But if they choose the correct OU when creating the contact, they’ll be successful. The same OU restrictions also apply to modifying or deleting contacts.

In this tutorial I’ve demonstrated how to use pre-defined management roles in Exchange Server to assign RBAC permissions for administrative tasks. I’ve also demonstrated how to create custom roles and role groups to assign limited permissions to users for specific tasks.

About the Author

Paul Cunningham

Is an Exchange mailbox required on a domain account to add it to the Organization Management Role ? We are using Exchange 2016

It seems I can add domain user accounts and universal security groups to a role. But I’m wondering if there are any limitations in any of the permissions when there is no mailbox assigned to the account?

Thank, Bill

Yor admin account will need a mailbox to sign in to the ECP console on Exchange 2016.

You do not need to use the mailbox for mail . You can set the mailbox to reject all mail under: Mailbox features – Message Delivery Restrictions.

I am trying to create exactly this same thing in Office 365 Exchange and run into an issue with running the second removal command. One user posted the same issue but never got a response.

When running

Get-ManagementRoleEntry “Custom Role – Mail Contacts Creation\*” | Where {$_.Name -notlike “*MailContact”} | Remove-ManagementRoleEntry

Cannot process argument transformation on parameter ‘Identity’. Cannot convert value “Custom Role – Mail Contacts Creation” to type “Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter”. Error: “The format of the value you specified in the Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter parameter isn’t valid. Check the value, and then try again. Parameter name: identity” + CategoryInfo : InvalidData: (Custom Role – Mail Contacts Creation:PSObject) [Remove-ManagementRoleEntry ], ParameterBindin…mationException + FullyQualifiedErrorId : ParameterArgumentTransformationError,Remove-ManagementRoleEntry + PSComputerName : outlook.office365.com

For some reason when running

Get-ManagementRoleEntry “Custom Role – Mail Contacts\*” | Where {$_.Name -notlike “*MailContact”} | Remove-ManagementRoleEntry

It works fine but only leaves 2 cmdlets in there instead of the 4 you are showing. I basically need working script that enables a user to add and remove mail contacts in the ECP, that’s it.

Excellent article and thank you for posting this. I’m having trouble with the following: Get-ManagementRoleEntry “CustomBNSKMailContacts\*” | Where {$_.Name -notlike “MailContact”} | Remove-ManagementRoleEntry

The error I get multiple times is: Cannot process argument transformation on parameter ‘Identity’. Cannot convert value “CustomBNSKMailContacts” to type “Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter”. Error: “The format of the value you specified in the Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter parameter isn’t valid. Check the value, and then try again. Parameter name: identity” + CategoryInfo : InvalidData: (CustomBNSKMailContacts:PSObject) [Remove-ManagementRoleEntry], ParameterBi ndin…mationException + FullyQualifiedErrorId : ParameterArgumentTransformationError,Remove-ManagementRoleEntry + PSComputerName : outlook.office365.com

Any ideas? Thanks in advance – John

I know I’m a year late, but just in case anyone else comes across this same problem.

The syntax for that command needs to look like the below (using your example):

Get-ManagementRoleEntry “CustomBNSKMailContacts\*” | Where {$_.Name -notlike “MailContact”} | %{Remove-ManagementRoleEntry -Identity “$($_.id)\$($_.name)”}

Not sure if this was an error in the article or an Exchange vs EOL thing, or just something Microsoft have changed since, but hey.

Slight error in your script. Missing an *.

Get-ManagementRoleEntry “CustomBNSKMailContacts\*” | Where {$_.Name -notlike “*MailContact”} | %{Remove-ManagementRoleEntry -Identity “$($_.id)\$($_.name)”}

thx for your post !

Hi Paul, I am a great fan of your articles – you save my a.. many times :). I try to find something, hope can help me with this. I need to understand what rights or group in RBAC – Exchange 2010 – give rights to user to change user account photo. Thumbnail photo I think is name of attribute.

Is I can see it, it’s possible to possible to limit 2: nd level support to only create/change users is specific OU, is it also possible to limit them to a specified DB? – we have all our users in site-specific databases.

Did this, and works great for write scopes, but why on god’s green earth can’t I seem to find a way to limit read scopes?

Does view only permission group members actually need a account with license on office 365 ?

Thanks Paul,

Very helpful article.

One question – is it possible to create a custom group from blank and only add the permissions you require, or is modification by removal from an existing group the only way?

Is there any role only can change user mailbox quota?

You can create a custom role for that.

Great writeup,

I’m looking to delegate ONLY certain functions to a specific group at my organization; We want them to be able to modify quotas, mailbox delegates, and e-mail addresses, but you don’t appear to be able to do that without a high level of control (or at least it doesn’t appear in the limited ECP).

Is there a way to give the same “view” as full admins for mailbox objects only?

I don’t understand your question. RBAC lets you control granular admin access all the way down to specific cmdlets and parameters of cmdlets. You can create custom roles to allow as much or as little admin access as necessary.

Dear Paul Cunningham, There are three OU into exchange 2016. When I user of any OU login in CEP, he can see all recipients of all OU but I want that “A user will only see his own OU recipients login exchange 2016 ecp” is it possible ?

i want to remove “wipe mobile device” permission from role My test role doesn’t contains clear-mobiledevice command but i can choose this option. Which role entry related with wipe mobile device?

My test role entries:

Set-CASMailbox Get-MobileDevice New-PartnerApplication Test-ClientAccessRule Set-ClientAccessRule New-ClientAccessRule Get-CASMailboxPlan Set-PartnerApplication Export-AutoDiscoverConfig Get-ActiveSyncDeviceAccessRule Get-ActiveSyncDeviceClass Get-ActiveSyncOrganizationSettings Get-ClientAccessArray Get-DomainController Get-OutlookProvider Get-RpcClientAccess New-ActiveSyncDeviceAccessRule New-OutlookProvider New-RpcClientAccess Remove-ClientAccessArray Remove-OutlookProvider Remove-RpcClientAccess Set-ActiveSyncDeviceAccessRule Set-RpcClientAccess Write-AdminAuditLog New-AuthRedirect Set-AuthRedirect Remove-AuthRedirect Get-AuthRedirect New-ClientAccessArray New-AuthServer Remove-AuthServer Set-AuthServer Get-PartnerApplication Set-AuthConfig Set-ClientAccessArray Get-ClientAccessRule Get-CASMailbox Get-AuthServer Get-AuthConfig Set-OutlookProvider Remove-ClientAccessRule Get-ActiveSyncDevice Remove-PartnerApplication Start-AuditAssistant Set-UnifiedAuditSetting Set-SweepRule Set-MailboxLocation Remove-SweepRule Remove-MailboxUserConfiguration Remove-MailboxLocation New-SweepRule Import-RecipientDataProperty Get-UnifiedAuditSetting Get-SweepRule Get-RbacDiagnosticInfo Get-OnlineMeetingConfiguration Get-MobileDeviceStatistics Get-MailboxUserConfiguration Get-MailboxPreferredLocation Get-MailboxLocation Enable-SweepRule Disable-SweepRule Add-MailboxLocation SetUserPhoto

i have a little bit extra for you excellent blog post. Thank you so much. Why this? When you use the role View-Only Recipients, you see to much of ecp functions from exchange. We reduce the view to the most necessary.

New-ManagementRole -Parent “View-Only Recipients” -Name “Custom Role – View-Only Recipients”

Get-ManagementRoleEntry “Custom Role – View-Only Recipients\*” | Where {$_.Name -notlike “*MailContact”} | Remove-ManagementRoleEntry

I have not found a option to add more than one role to the custom view

Add-ManagementRoleEntry “Custom Role – View-Only Recipients\Get-OrganizationalUnit” Add-ManagementRoleEntry “Custom Role – View-Only Recipients\Get-Recipient” Add-ManagementRoleEntry “Custom Role – View-Only Recipients\Get-Contact”

Now you have only 4 roles

Get-Contact Get-OrganizationalUnit Get-Recipient Get-MailContact

that is all!

Can you help with my above problem running Exchange 2016? I am unable to set the Write Scope to a specific OU. Please see above comments from me.

Problem was sorted out by upgrading from CU7 to CU8

Not working in Exchange 2016. Getting error when applying the role group to the Contacts OU as write scrope:

“Object class organizationalUnit is not recognized as a valid object class for E-mail recipient objects.”

Can you help?

What command are you running?

I am doing from the ECP. According to your guide, I set the Write Scope to a specific OU where we have got the contacts, and then the ECP throws above error.

The corresponding command would be something like:

New-RoleGroup -Name “Mail Contacts Manager” -RecipientOrganizationalUnitScope Contacts -Roles “Custom – Mail Contacts”, “Custom – Mail Contacts Creation” -Members contactadmin

Are you using the full path to the OU?

Yes. Using the Full path in ECP, it sees the OU, otherwise it would say it does not exist.

Ok. I haven’t seen the issue. Maybe there’s an ambiguous OU name causing problems or something like that. Perhaps running the command in the shell will work better.

I know it has been a while, but I just came across this same error:

“Object class organizationalUnit is not recognized as a valid object class for E-mail recipient objects.”

What I had to do was create it with the Write Scope set to Default, save it, then I could come back and change the write scope to an Organizational Unit.

Hope this helps someone in the future.

Thank you. This worked for me.

Perfect! Worked for me too

Awesome! Worked for me.

From ECP Create the Role with Default Scope. After it is created in 2nd Step Add the required OU. Worked for me .

Hey Poul, wonderfull article and really nicely written.

I have tried deploying this setup in our test/QA enviroments but i run into a error when the user needs to select the ou upon contact creation. I looks to me like there is some role/permission needed, if a user should be granted access to navigate the AD (so they can select the right ou which they are allowed to write to)

When the user tries to browse the AD, they are informed that they do not have permission to browse the ad, and the progress circle just keeps spinning.

Have you seen this problem before?

Exchange Online

Using Entra ID Support for Passkey Authentication with Microsoft 365

Entra ID supports passkeys as an authentication method. In fact, support is a variation of the existing FIDO2 authentication method using device-bound passkeys managed by the Microsoft Authenticator app. Passkeys are a strong phishing-proof authentication method. The question is whether the current implementation will be considered too complicated by regular users.

Practical Protection: Breaches, Exposure, and You

In this edition of Practical Protection, Paul Robichaux dives into 5 steps you can take to protect yourself, and potentially your organization, from future breaches.

MSExchangeGuru.com

Learn Exchange the Guru way !!!

Contact us -MS Exchange Guru
MSExchangeGuru on YouTube

Role Based Permissions in Exchange Server 2016

Microsoft Exchange Server 2016 includes a huge bundle of predefined permissions, based on the Role Based Access Control (RBAC) permission model, which can be used straightaway to grant permissions to administrators and users based on the requirements

A Role defines a set of tasks that an Administrator or a user can perform, the Role based permissions in Exchange 2016 includes Admin Roles and End-User Roles:

Admin Roles:

Admin roles include set of pre-defined permissions that can be assigned to an Administrator or specialist user using Role group which manage recipients, servers, or databases.

To see Admin Roles, Open EAC and Navigate to Permissions à Admin Roles:

Built-in Role Groups in Exchange server 2016 (TechNet):

User Roles in Exchange 2016:

User role permissions allow users to manage the features of their own mailbox and distribution groups, they cannot manage any other mailboxes, these roles will be assigned using role assignment policies with the prefix My .

To see User roles, Open EAC and Navigate to Permissions à User Roles:

As we know, Admin roles are assigned using Role groups and User roles will be assigned using Role Assignment policies . Let us see how Role Groups and Role Assignment policies work:

Role Groups:

Role Groups are special universal security groups (USGs) used by Exchange 2016 to grant permissions to administrators and specialist users. The Role Groups can contain Active Directory users, USGs, and other role groups. When a role is assigned to a role group, the permissions decided by the roles are assigned to all members of the role group. This enables to assign multiple roles to various role group members at once. Role groups naturally incorporate a wide management area, such as recipient management and these are used only with administrative roles, and not end-user roles.

NOTE : It is possible to assign a role directly to a user or USG without using a role group. However, Microsoft recommends using role groups to manage permissions.

Create new Role Group:

In the New Role Group window provide the name, description of the new role group, Select the Roles you want to add to the roll group, add the members to the group and save as below:

Roles available:

Once the new Role has been created, the new role group can be used as other role groups.

Add the Members to the existing Role Group/Assign the permissions to the administrator:

Role Assignment Policies:

Exchange Server 2016 provides a role assignment policy which allows granting permissions to end users to change the settings of their own mailboxes and on distribution groups that they own. These settings include their display name, contact information, voice mail settings, and distribution group membership.

An Exchange 2016 organization can have multiple role assignment policies that provide different levels of permissions for the different types of users in the organization depending on the requirement. The Role assignment policies can assign directly to the mailboxes, and each mailbox can only be associated with one role assignment policy at a time. One of the role assignment policies in the organization is marked as default and this default role assignment policy is associated with new mailboxes that are not explicitly assigned a specific role assignment policy when they are created.

End-user roles are assigned to role assignment policies. Role assignment policies can share the same end-user roles.
Role assignment policies are associated with mailboxes. Each mailbox can only be associated with one role assignment policy at a time.
After a mailbox is associated with a role assignment policy, the end-user roles are applied to that mailbox. The permissions granted by the roles are granted to the user of the mailbox.

NOTE: Only end-user roles can be assigned to role assignment policies.

In the New Role Group window provide the name, description for the Role Assignment policy and select the Roles needs to be provided and click on Save:

PowerShell command for Role Assignment policies:

Create new Role Assignment policy:

New-RoleAssignmentPolicy <assignment policy name> -Roles <roles to assign>

Assign/change a Role Assignment policy to the user:

Set-Mailbox <mailbox alias or name> -RoleAssignmentPolicy <assignment policy>

Remove Role Assignment Policy:

Remove-RoleAssignmentPolicy <role assignment policy>

NOTE: Before removing a role assignment policy need to follow the below steps:

All users assigned to the assignment policy must be changed to another assignment policy.
All the management role assignments between the assignment policy and the assigned management roles must be removed
If default assignment policy needs to be removed, it must be the last assignment policy in the Exchange 2016 organization.

Ratish Nair

Microsoft MVP | Exchange Server

Posted December 18th, 2015 under Exchange 2016 , RBAC . RSS 2.0 feed. Leave a response , or trackback .

Name (required)

Mail (will not be published) (required)

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Active Directory
Autodiscover
Best Practices
Certificate Authority
Co-existence
Cumulative Update
Database Management
Disaster Recovery
Edge Transport
Exchange 2003
Exchange 2007
Exchange 2010
Exchange 2013
Exchange 2016
Exchange 2019
Exchange ActiveSync
Exchange Online Protection
Exchange Tools
Export Mailbox using Shell
Installation
LegacyExchangeDN
Miscellaneous blabberings
msExch Attributes
Online and Offline Defrag
Public Folders
Recovery Storage Group
Site Updates
Skype for Business
Uncategorized
Windows 2012 R2
January 2021
December 2019
November 2019
September 2019
January 2019
December 2018
October 2018
September 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
February 2010
January 2010
November 2009
October 2009
September 2009

Microsoft MVP award

Subcribe to MSExchangeGuru

Other cool places

Flipping Bits
Lets Exchange
MSExchangeTeam
PowerWindows

Theme by BytesForAll

Manage Azure Role Assignments Like a Pro with PowerShell

Azure Governance Future Trends and Predictions - AzureIs.Fun

Today’s blog post is a little bit different. I have a couple of examples of how you can use PowerShell snippets and simple commandlets to get or set role assignmnets in your Azure Subscriptions.

PowerShell examples for managing Azure Role assignments

List all role assignments in a subscription, get all role assignments for a specific resource group, get all role assignments for a specific user, add a role assignment to a user, remove a role assignment for a user, remove all role assignments for a specific user, list all built-in roles, list all custom roles, create a custom role, update a custom role, delete a custom role, list all users or groups assigned to a specific role, list all permissions granted by a specific role, list all resource groups that a user has access to, create a role assignment for a service principal, powershell script to manage azure role assignments.

And now there is a script that combines some of these examples into one usable function:

I hope this was useful. Let me know if you liked the format of this blog and if you want me to include more of these examples.

Vukasin Terzic

Recent Update

Writing your first Azure Terraform Configuration
Transition from ARM Templates to Terraform with AI
Getting started with Terraform for Azure
Terraform Configuration Essentials: File Types, State Management, and Provider Selection
Dynamically Managing Azure NSG Rules with PowerShell

Trending Tags

Retrieve azure resource group cost with powershell api.

The Future Of Azure Governance: Trends and Predictions

Azure Cost Optimization: 30 Ways to Save Money and Increase Efficiency

As organizations continue to migrate their applications and workloads to the cloud, managing and controlling cloud costs has become an increasingly critical issue. While Azure provides a robust s...

Custom PowerShell API for Azure Naming Policy

To continue our PowerShell API series, we have another example of a highly useful API that you can integrate into your environment. Choosing names for Azure resources can be a challenging task. ...

Allow Users To Manage Distribution Groups Without Creating New Ones

In a previous post we discussed a scenario where users were delegated the capability to create Mail Enabled Contacts in Active Directory using a custom RBAC role. As part of the solution, we enabled the MyDistributionGroups Role. While this may meet the needs of most organisations it does introduce one issue where users who are assigned such a Role Assignment Policy can edit Distribution Groups they own but also create new ones.

This post is based on Exchange 2010. If you would prefer an Exchange 2013 specific post, please view this entry .

Update 20-1-2014 : Corrected PowerShell code to add a missing bracket in $Roles = (Get-RoleAssignmentPolicy -Identity "Default Role Assignment Policy").AssignedRoles

Update 1-6-2015: Link to an Exchange 2013 specific version of this post was added.

How can we solve the challenge of allowing users to managed Distribution Groups that they own, but also prevent them from removing or adding new ones? Well, it’s a similar story to the previous blog – we will create a custom RBAC Role!

One thing that is a little different is that the RBAC configuration for the items related to configuring your own mailbox is stored within a Role Assignment Policy . The same terminology applies but we need to be clear that end-user RBAC is contained within a Role Assignment Policy and administrator RBAC lives in Management Roles.

This scenario calls for having multiple Role Assignment Polices as each will have a different configuration. For example you may envision the following:

Default Role Assignment Policy – can edit zero Distribution Groups
DG-Management Role Assignment Policy – can edit Distribution Groups owned by user, cannot create new ones.
DG-Full-Management Role Assignment Policy – can edit Distribution groups owned by user, and can create new ones.

We will create option #2 in this blog. Option1 is the initial setup with the Default Role Assignment Policy, and Option3 can be done by following the steps in the previous blog to simply enable the MyDistributionGroups Role in the relevant Role Assignment Policy.

Let’s get jiggy with it , and create a new Role Assignment Policy! **

Create New Role Assignment Policy

Let’s create a new Role Assignment Policy called DG-Management . We want to mirror the existing Default Role Assignment Policy, as a mailbox can only be assigned a single Role Assignment policy and we need to ensure that the user can perform all required activities on their mailbox. This can be customised to suit your requirements, in this example we will copy from the Default Role Assignment Policy, but this is not required.

We can write down the roles assigned to the Default Role Assignment Policy and manually add them, or alternatively we can save the Default Role Assignment Policy roles to a variable. We can then provide this variable as the list of roles when the new Role Assignment Policy is created. let’s save the Roles assigned to the variable $Roles.

$Roles = (Get-RoleAssignmentPolicy -Identity "Default Role Assignment Policy").AssignedRoles

$Roles will then contain the following Roles:

MyBaseOptions MyContactInformation MyVoiceMail MyTextMessaging MyDistributionGroupMembership

When creating the new Role Assignment Policy called DG-Management , we provide the $Roles variable which contains the saved roles.

New-RoleAssignmentPolicy –Name DG-Management –Roles $Roles

Create Custom Management Role

All the Management Roles that can be assigned to a Role Assignment Policy are prefixed with “ My ” to indicate that they are for user RBAC. This is a list of the Exchange 2010 roles starting with the prefix “ My ”:

The Management Role Entries for MyDistributionGroups is shown below along with showing that this is a built-in role and is intended for end user purposes.

In order to stop users with this Management Role creating and deleting Distribution Groups, we need to remove the “New-DistributionGroup” and “Remove-DistributionGroup” cmdlets. As before, the built-in RBAC roles are read only so we need to make a writable copy.

New-ManagementRole -Name "Edit-Existing-DG-Only" -Parent MyDistributionGroups

Then removing the new and remove distribution group cmdlets:

Remove-ManagementRoleEntry Edit-Existing-DG-OnlyNew-Distributiongroup

Remove-ManagementRoleEntry Edit-Existing-DG-OnlyRemove-Distributiongroup

Checking to see the current Management Role Entries, note the New and Remove cmdlets are gone:

Once happy, will assign this custom Role to our new Role Assignment Policy.

New-ManagementRoleAssignment -Policy "DG-Management" -Role Edit-Existing-DG-Only

Note that we can do most RBAC work in ECP after Exchange 2010 SP1, though I still prefer PowerShell as that was what I had to learn initially. Old dog, new tricks etc…..

Testing & Validation

In order to test the work we have done, the Role Assignment Policy must be assigned to a mailbox. As mentioned above a mailbox can only have a singe Role Assignment Policy at any given time. You can have multiple Role Assignment Policies, and assign one to a given mailbox. You do not have to explicitly assign a Role Assignment Policy, and this is the default behaviour for a mailbox. If you do not explicitly state which one should be used when creating or moving a mailbox to Exchange 2010, Exchange will use the one marked as default. Note it is not necessarily the one called “Default Role Assignment Policy”; that one is created by default, is the only one by default and is initially marked as default. This can be changed to suit your needs. Let’s say you create a Role Assignment Policy that you want 95% of the users to have as it’s your base standard then you can mark it as the default.

Set-RoleAssignmentPolicy -Identity "Contoso Standard" -IsDefault:$true

Viewing all of the Role Assignment Policies shows Contoso Standard is the default. Mailboxes created will now leverage the Contoso Standard Role Assignment Policy unless explicitly stated otherwise. Mailboxes created prior to this point will continue to use their existing Role Assignment Policy and will not automagically change to this new default policy.

Let’s set our test mailbox (user-20) to explicitly use the DG-Management Role Assignment Policy

Set-Mailbox -Identity user-20 -RoleAssignmentPolicy DG-Management

When user-20 then opens up ECP, they have the following capabilities, note that there is no New or Delete button under “Public Groups That I Own”.

For a Distribution Group to show up, it must have the ManagedBy attribute set. In this test org there are several DGs, but only the ones that user-20 has ManagedBy appear.

We can see that the basic steps to tune and customise RBAC are very similar to the previous blog on delegating Mail Enabled Contact creation . There are some differences as we are creating a custom Management Role to be used as part of a Role Assignment Policy though all the concepts still apply.

** – Forget the music and stuff Will Smith, where is Independence Day 2 anyway ?!?!?

Rhoderick Milne [MSFT]

One comment.

I had to update the syntax for Remove-ManagementRoleEntry to "Remove-ManagementRoleEntry Edit-Existing-DG-Only\New-Distributiongroup"

Azure RBAC: role assignments and ARM templates

This post is about Azure's role assignments and ARM templates. Role assignments can be thought of as "permissions for Azure".

If you're deploying to Azure, there's a good chance you're using ARM templates to do so. Once you've got past "Hello World", you'll probably find yourself in a situation when you're deploying multiple types of resource to make your solution. For instance, you may be deploying an App Service alongside Key Vault and Storage .

One of the hardest things when it comes to deploying software and having it work, is permissions. Without adequate permissions configured, the most beautiful code can do nothing . Incidentally, this is a good thing. We're deploying to the web; many people are there, not all good. As a different kind of web-head once said:

Spider-man saying with great power, comes great responsibility

Azure has great power and suggests you use it wisely .

Access management for cloud resources is critical for any organization that uses the cloud. Azure role-based access control (Azure RBAC) helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to. Designating groups or individual roles responsible for specific functions in Azure helps avoid confusion that can lead to human and automation errors that create security risks. Restricting access based on the need to know and least privilege security principles is imperative for organizations that want to enforce security policies for data access.

This is good advice. With that in mind, how can we ensure that the different resources we're deploying to Azure can talk to one another?

Role (up for your) assignments

The answer is roles. There's a number of roles that exist in Azure that can be assigned to users, groups, service principals and managed identities. In our own case we're using managed identity for our resources. What we can do is use "role assignments" to give our managed identity access to given resources. Arturo Lucatero gives a great short explanation of this:

Whilst this explanation is delightfully simple, the actual implementation when it comes to ARM templates is a little more involved. Because now it's time to talk "magic" GUIDs. Consider the following truncated ARM template, which gives our managed identity (and hence our App Service which uses this identity) access to Key Vault and Storage:

Let's take a look at these three variables:

The three variables above contain the subscription resource ids for the roles Storage Blob Data Contributor , Key Vault Secrets Officer and Key Vault Crypto Officer . The first question on your mind is likely: "what is ba92f5b4-2d11-453d-a403-e96b0029c9fe and where does it come from?" Great question! Well, each of these GUIDs represents a built-in role in Azure RBAC. The ba92f5b4-2d11-453d-a403-e96b0029c9fe represents the Storage Blob Data Contributor role.

How can I look these up? Well, there's two ways; there's an article which documents them here or you could crack open the Cloud Shell and look up a role by GUID like so:

Or by name like so:

As you can see, the Actions section of the output above (and in even more detail on the linked article ) provides information about what the different roles can do. So if you're looking to enable one Azure resource to talk to another, you should be able to refer to these to identify a role that you might want to use.

Creating a role assignment

So now we understand how you identify the roles in question, let's take the final leap and look at assigning those roles to our managed identity. For each role assignment, you'll need a roleAssignments resource defined that looks like this:

Let's go through the above, significant property by significant property (it's also worth checking the official reference here ):

type - the type of role assignment we want to create, for a key vault it's "Microsoft.KeyVault/vaults/providers/roleAssignments" , for storage it's "Microsoft.Storage/storageAccounts/providers/roleAssignments" . The pattern is that it's the resource type, followed by "/providers/roleAssignments" .
dependsOn - before we can create a role assignment, we need the service principal we desire to permission (in our case a managed identity) to exist
properties.roleDefinitionId - the role that we're assigning, provided as an id. So for this example it's the keyVaultCryptoOfficer variable, which was earlier defined as [subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'ba92f5b4-2d11-453d-a403-e96b0029c9fe')] . (Note the use of the GUID)
properties.principalId - the id of the principal we're adding permissions for. In our case this is a managed identity (a type of service principal).
properties.scope - we're modifying another resource; our key vault isn't defined in this ARM template and we want to specify the resource we're granting permissions to.
properties.principalType - the type of principal that we're creating an assignment for; in our this is "ServicePrincipal" - our managed identity.

There is an alternate approach that you can use where the type is "Microsoft.Authorization/roleAssignments" . Whilst this also works, it displayed errors in the Azure tooling for VS Code . As such, we've opted not to use that approach in our ARM templates.

Many thanks to the awesome John McCormick who wrangled permissions with me until we bent Azure RBAC to our will.

Role (up for your) assignments
Creating a role assignment

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

Notifications

[Examples] Create Custom Policies Policy Sets and Assignments

This page describes how to deploy your Azure landing zone with custom policy definitions and policy set (Initiative) definitions.

In this example you will use three custom policies and a custom policy set definition. The custom policies will be named Enforce-RG-Tags , Enforce-Resource-Tags and Deny-NIC-NSG . You will then create a custom policy set definition (Initiative) named Enforce-Mandatory-Tags that will include the Enforce-RG-Tags and Enforce-Resource-Tags custom policies.

You will update the built-in configuration by following these steps:

Create the custom policy definition file for Enforce-RG-Tags
Create the custom policy definition file for Enforce-Resource-Tags
Create the custom policy definition file for Deny-NIC-NSG
Create the custom policy set definition file for Enforce-Mandatory-Tags
Make the custom policy definitions available for use in Azure by extending the built-in archetype for es_root
Create the policy assignment files for Enforce-RG-Tags , Enforce-Resource-Tags , Deny-NIC-NSG and Enforce-Mandatory-Tags
Assign the custom policy set definition for Enforce-Mandatory-Tags at the es_root Management Group by extending the built-in archetype for es_root
Assign the custom policy definition for Deny-NIC-NSG at the Landing Zones Management Group by extending the built-in archetype for es_landing_zones

IMPORTANT: To allow the declaration of custom or expanded templates, you must create a custom library folder within the root module and include the path to this folder using the library_path variable within the module configuration. In our example, the directory is /lib .

In order to create and assign custom policies, we need to create both a definition file and an assignment file for each custom policy or custom policy set definition. In this example we will do this by using the below files:

lib/policy_definitions/policy_definition_es_enforce_rg_tags.json

Lib/policy_definitions/policy_definition_es_enforce_resource_tags.json, lib/policy_definitions/policy_definition_es_deny_nic_nsg.json, lib/policy_set_definitions/policy_set_definition_enforce_mandatory_tagging.json, lib/policy_assignments/policy_assignment_es_enforce_rg_tags.json, lib/policy_assignments/policy_assignment_es_enforce_resource_tags.json, lib/policy_assignments/policy_assignment_es_deny_nic_nsg.json, lib/policy_assignments/policy_assignment_es_enforce_mandatory_tagging.json.

NOTE: This module provides the ability to define custom template variables used when reading in template files from the built-in and custom library_path. For more info click here .

Create Custom Policy Definition

In your /lib directory create a policy_definitions subdirectory if you don't already have one. You can learn more about archetypes and custom libraries in this article .

NOTE: Creating a policy_definitions subdirectory is a recommendation only. If you prefer not to create one or to call it something else, the custom policies will still work.

In the policy_definitions subdirectory, create a policy_definition_es_policy_enforce_rg_tags.json file. This file will contain the policy definition for Enforce-RG-Tags . Copy the below code in to the file and save it.

Now create a policy_definition_es_policy_enforce_resource_tags.json file. This file will contain the policy definition for Enforce-Resource-Tags . Copy the below code in to the file and save it.

Next create a policy_definition_es_policy_deny_nsg_nic.json file. This file will contain the policy definition for our last custom policy - Deny-NSG-NIC . Copy the below code in to the file and save it.

Create Custom Policy Set Definition

In your /lib directory create a policy_set_definitions subdirectory.

NOTE: Creating a policy_set_definitions subdirectory is a recommendation only. If you prefer not to create one or to call it something else, the custom policies will still work.

In the policy_set_definitions subdirectory, create a policy_set_definition_enforce_mandatory_tags.json file. This file will contain the Policy Set Definition for Enforce-Mandatory-Tags . The policy set will contain the Enforce-RG-Tags and Enforce-Resource-Tags custom policies that you previously created. Copy the below code in to the file and save it.

Create Custom Policy Assignment Files

In order to assign your custom policies or policy sets, you need to create policy assignment files. The first step is to create a policy_assignments subdirectory within /lib .

NOTE: Creating a policy_assignments subdirectory within \lib is a recommendation only. If you prefer not to create one or to call it something else, the custom policies will still work.

You will then need to create a file named policy_assignment_es_enforce_rg_tags.json within the policy_assignments directory. Copy the below code in to the file and save it.

Now create a file named policy_assignment_es_enforce_resource_tags.json within the policy_assignments directory. Copy the below code in to the file and save it.

Next create a file named policy_assignment_es_deny_nic_nsg.json within the policy_assignments directory. Copy the below code in to the file and save it.

Finally, create a file named policy_assignment_es_enforce_mandatory_tagging.json . Copy the below code in to the file and save it.

Make the Custom Policy Definitions and Policy Set Definition available for use

You now need to save your custom policy and policy set definitions at the es_root Management Group to ensure they can be used at that scope or any scope beneath. To do that, we need to extend the built-in archetype for es_root .

NOTE: Extending built-in archetypes is explained further in this article .

If you don't already have an archetype_extension_es_root.tmpl.json file within your custom /lib directory, create one and copy the below code in to the file. This code saves the custom policy definition and policy set definitions but we still haven't assigned them anywhere yet.

Assign the Enforce-Mandatory-Tags Custom Policy Set at the es_root Management Group

You now need to assign the Enforce-Mandatory-Tags policy set and in this example, we will assign it at es_root . To do this, update your existing archetype_extension_es_root.tmpl.json file with the below code and save it.

You should now kick-off your Terraform workflow (init, plan, apply) to apply the new configuration. This can be done either locally or through a pipeline. When your workflow has finished, the Enforce-Mandatory-Tags policy set will be assigned at es_root .

Assign the Deny-NIC-NSG Custom Policy Definition at the Landing Zones Management Group

As you have already saved the Deny-NIC-NSG Custom Policy Set at es_root , this gives us the ability to assign it at the es_root scope or at any scope beneath it. In this example, we will assign it at the Landing Zones Management Group. To do this, either update your existing archetype_extension_es_landing_zones.tmpl.json file or create one and copy the below code in to it and save.

You should now kick-off your Terraform workflow (init, plan, apply) again to apply the updated configuration. This can be done either locally or through a pipeline. When your workflow has finished, the Deny-NIC-NSG Policy Definition will be assigned at the Landing Zones Management Group.

You have now successfully created and assigned both a Custom Policy Definition and a Custom Policy Set Definition within your Azure environment. You can re-use the steps in this article for any Custom Policies of your own that you may wish to use.

This wiki is being actively developed

If you discover any documentation bugs or would like to request new content, please raise them as an issue or feel free to contribute to the wiki via a pull request . The wiki docs are located in the repository in the docs/wiki/ folder.

Azure landing zones Terraform module

Getting started
Module outputs
Module permissions
Module variables
Module releases
Module upgrade guidance
Provider configuration
Archetype definitions
Core resources
Management resources
Connectivity resources
Identity resources
Video guides
Deploy default configuration
Deploy demo landing zone archetypes
Deploy custom Landing Zone Archetypes
Deploy connectivity resources (Hub and Spoke)
Deploy connectivity resources (Virtual WAN)
Deploy identity resources
Deploy management resources
Assign a built-in policy
Create and assign custom RBAC roles
Set parameter values for Policy Assignments
Deploy connectivity resources with custom settings (Hub and Spoke)
Deploy connectivity resources with custom settings (Virtual WAN)
Deploy with Zero Trust network principles (Hub and Spoke)
Deploy identity resources with custom settings
Deploy management resources with custom settings
Expand built-in archetype definitions
Create custom policies, initiatives and assignments
Override module role assignments
Control policy enforcement mode
Policy assignments with user assigned managed identities
Deploy using module nesting
Deploy using multiple module declarations with orchestration
Deploy using multiple module declarations with remote state
Frequently Asked Questions
Troubleshooting
Raising an issue
Feature requests
Contributing to code
Contributing to documentation

Clone this wiki locally

Assignment scopes and excluded scopes

CSV Assignment Parameters
Policy Exemptions

Policy Assignments

This chapter describes how Policy Assignments are handled by EPAC. Policy Assignments are the actual assignments of Policies and Policy Sets to scopes in Azure

Assignment JSON structure

Assignment JSON is hierarchical for efficient definitions, avoiding duplication (copy/paste) of JSON. Each branch of the tree is cumulative. Each tree node must include a nodeName - an arbitrary string exclusively used by EPAC to display an error location. EPAC concatenates a leading / and the nodeName entries encountered in the tree to create a "breadcrumbs" trail; therefore, we recommend that you use / to help separate the concatenated nodeName . The following partial and invalid assignment tree would create this error message.

JSON Schema

The GitHub repo contains a JSON schema which can be used in tools such as VS Code to provide code completion.

To utilize the schema add a $schema tag to the JSON file.

Every tree branch must accumulate a definitionEntry (or definitionEntryList ), Assignment naming ( name and displayName ) and scope element.
The elements parameters , overrides , resourceSelectors , notScope , enforcementMode , metadata , userAssignedIdentity , managedIdentityLocations , additionalRoleAssignments and nonComplianceMessages are optional.
For Policy Sets with large numbers of included Policies you should use a spreadsheet (CSV file) to manage effects (parameterized or effect overrides ), parameters and optional nonComplianceMessages . We recommend the CSV approach for Policy Sets with more than 10 included Policies.
EPAC continues to support deprecated elements initiativeId , initiativeName and ignoreBranch , Consider using their replacements policySetId , policySetName and enforcementMode instead.
Role Assignments for user-assigned Managed Identities (UAMI) are not managed by EPAC, and will not generate a roles-plan.json file.
additionalRoleAssignments are used when a resource required is not in the current scope. For example, a Policy Assignment that requires a Event Hub to be managed in a subscription not contained in the current management group.

The tree is not required to be balanced. The number of levels is not restricted; however, anything beyond 3 levels is unnecessary in real scenarios and would be difficult to read and manage as the depth increases.

Assignment Element and Metadata

Each Assignment is required to have a name which is used in it's resource id. EPAC also requires a displayName . The description is optional. For the allowed location assignment you specify the component with:

Multiple assignment naming components in a tree branch are string concatenated for each of the three fields.

Azure has a limit of 24 characters for the concatenated name string. EPAC displays an error if this limit is exceeded.

Defining metadata

metadata is sometimes used to assign categories for changes. Do NOT specify EPAC-reserved elements roles and pacOwnerId . For the final metadata EPAC creates the union of instances in the entire tree branch.

Not recommended : Adding assignedBy to the metadata overrides the deployedBy value from the global-settings.jsonc file normally used for assignedBy . It defaults to "epac/$pacOwnerId/$pacSelector" .

Metadata for Role Assignments

Role assignments do not contain a metadata field. Instead, the description field is used to populate the deployedBy value. The description field is populated with the Policy Assignment Id, reason and deployedBy value. This is useful for tracking the source of the Role Assignment.

Reasons is one of:

Role Assignment required by Policy - Policy definition(s) specify the required Role Definition Ids.
additional Role Assignment - from filed "additionalRoleAssignments" in the Policy Assignment file.
additional cross tenant Role Assignment - from filed "additionalRoleAssignments" with crossTenant set to $true in the Policy Assignment file.

Assigning Policy Sets or Policies

Assigning a single policy or policy set.

Each assignment assigns either a Policy or Policy Set. In EPAC this is done with a definitionEntry or a definitionEntryList . Exactly one occurrence must exist in any collated tree branch. For each entry, you need to specify one of the following:

policyName - custom Policy. Specifying just the name allows EPAC to inject the correct definition scope.
policySetName - custom Policy Set. Specifying just the name allows EPAC to inject the correct definition scope
policyId - resource id for builtin Policy.
policySetId - resource id for builtin Policy Set.

displayName is an optional field to document the entry if the Policy name is a GUID. Builtin Policies and Policy Sets use a GUID.

Assigning multiple Policies or Policy Sets

Using definitionEntryList allows you to save on copy/paste tree branches. Without it, the number of branches would need to be duplicated as many times as the list has entries.

Each entry in the list creates an Assignment at each leaf of the tree. Since assignments must have unique names at a specific scope, the Assignment naming component must be amended for each list entry. In this sub-component you can decide if you want to concatenate the string by appending or prepending them by specifying append boolean value.

In the above example one of the children (leaf node) has the following Assignment name.

This example generates two assignments at the "prod" leaf per scope:

/providers/Microsoft.Management/managementGroups/ Contoso-Prod /providers/Microsoft.Authorization/policyAssignments/ pr-asb
displayName = "Prod Azure Security Benchmark"
description = "Prod Environment controls enforcement with Azure Security Benchmark Initiative."
/providers/Microsoft.Management/managementGroups/ Contoso-Prod /providers/Microsoft.Authorization/policyAssignments/ pr-nist-800-53-r5
displayName = "Prod NIST SP 800-53 Rev. 5"
description = "Prod Environment controls enforcement with NIST SP 800-53 Rev. 5 Initiative."

scope is required exactly once in each tree branch. Excluded scopes ( notScope ) are cumulative from global-settings.json and the entire tree branch; however, once a scope is defined notScope may not be defined at any child node.

Both scope and notScope are specific to an EPAC Environment using the pacSelector name , e.g., epac-dev and tenant .

notScope works the same. In addition "*" means all EPAC Environments.

Managed Identities and role assignments

Policies with a DeployIfNotExists or Modify effect need a Managed Identity (MI) and role assignments to execute remediation task. EPAC calculates the necessary role assignments based on the roleDefinitionIds in the Policy definition. By default EPAC uses a system-assigned Manged Identity. The team maintaining EPAC recommend system-assigned identities; however, your organization may have role assignment reasons to use user-assigned Managed Identities.

Defining managedIdentityLocations

Policy assignments requiring a Managed Identity (system-assigned or user-assigned) require a location managedIdentityLocations . You must specify the location based on EPAC Environment or use "*" to use the same location for all of the EPAC Environments. You can specify them in global-settings.jsonc or at any node in the tree. The last (closest to the leaf node) is the one chosen if multiple managedIdentityLocations entries are encountered in a tree branch.

Defining optional additionalRoleAssignments

In some scenarios you will need additionalRoleAssignments ; e.g., for diagnostics settings to Event Hubs, the target resource might be in a different Management Group and therefore the Managed Identity requires additional role assignments. You must specify the additionalRoleAssignments based on EPAC Environment or use "*" to use the same additionalRoleAssignments for all of the EPAC Environments. If the pacEnvironment under deployment is specified in the additionalRoleAssignments, the "*" assignments will be ignored.

If the additional assignment is to made to a managing tenant in the sceenario where the pacEnvironment under deployment is a manganged (lighthouse) tenant, you must specify ""crossTenant": true" for that assignment. Ensure all necessary ABAC permissions are in place for the executing SPN.

User-assigned Managed Identities

Azure Policy can use a user-defined Managed Identity and EPAC allows you to use this functionality. You must specify the user-defined Managed Identity based on EPAC Environment or use "*" to use the same identity for all of the EPAC Environments (only possible in single tenant scenarios). Within each EPAC Environment entry, you can specify just the URI string indicating to use the same identity even if we are using a definitionEntryList , or in the case of a definitionEntryList can assign a different identity based on the definitionEntryList by specifying a matching policyName , policyId , policySetName or policySetId .

Defining parameters , overrides and nonComplianceMessages

Utilizing a csv file to define parameters , overrides and noncompliancemessages.

Assigning single or multiple security and compliance focused Policy Sets (Initiatives), such as Microsoft cloud security benchmark, NIST 800-53 R5, PCI, NIST 800-171, etc, with just JSON parameters becomes very complex fast. Add to this the complexity of overriding the effect if it is not surfaced as a parameter in the Policy Set . Finally, adding the optional nonComplianceMessages further increases the complexity.

To address the problem of reading and maintaining hundreds or thousands of JSON lines, EPAC can use the content of a spreadsheet (CSV) to create parameters , overrides and optionally nonComplianceMessages for a single Policy assignment definitionEntry or multiple Policy definitions ( definitionEntryList ).

This approach is best for large Policy Sets such as Azure Security Benchmark, NIST 800-53, etc. Smaller Policy Sets should still be handled with JSON parameters , overrides and nonComplianceMessages .

Implement these steps as documented in Managing Policy Assignment Parameters with a CSV file .

Generate the CSV file form your already deployed Assignment(s) or Policy Set(s).
Modify the effect and parameter columns for each type of environment types you will use.
Modify the Policy Assignment file to reference the CSV file and the column prefix.
Update the CSV file with the new effect and parameter values.

Defining parameters with JSON

parameters have a simplified JSON structure. You do not need the additional value indirection Azure requests (EPAC will inject that indirection).

Too enable definitionEntryList , parameters not present in the Policy or Policy Set definition are quietly ignored.

Advanced Elements

Defining overrides with json.

overrides are in the same format as documented by Azure . They are cumulative in each tree branch. The selectors element is only used for Assignments of Policy Sets. They are not valid for Assignments of a single Policy.

If using definitionEntryList , you must add the policyName , policyId , policySetName or policySetId as used in the definitionEntryList item.

Defining nonComplianceMessages with JSON

Assign a non-compliance message to the assignment, or individual non-compliance messages if the assignment is for an Policy Set. This value is an array of objects - each containing a message, and in the case of an initiative a policyDefinitionReferenceId. See this link for details.

If you use single definitionEntry , place them normally. If you use a definitionEntryList place them in the respective list entry.

Defining resourceSelectors

resourceSelectors may appear anywhere in the tree and are cumulative in any branch. They follow the standard Azure Format .

Defining enforcementMode

enforcementMode is similar to the deprecated ignoreBranch ; it deploys the assignment and sets the assignment to Default or DoNotEnforce . DoNotEnforce allows a what-if analysis. enforcementMode may appear anywhere in the tree. Definitions at a child override the previous setting.

Example assignment files

Simple policy assignment (allowed locations).

In the simple case an assignment is a single node with no difference in assignment , parameters , and definitionEntry across multiple scopes. In many scenarios "Allowed Locations" is such a simple Assignment. Such Assignments do not have child nodes, just the root node. Example

nodeName is required for error messages; it's value is immaterial. EPAC concatenates them in the current tree branch.
definitionEntry specifies that the custom Policy Set general-allowed-locations-policy-set from our starter kit. displayName has no meaning - it is for readability and in this instance is superfluous.
assignment fields name , displayName and description are used when creating the assignment.
This assignment has no metadata . You don't need an empty collection. EPAC will add pacOwnerId and roles metadata . Do not add them manually.
enforcementMode is set to default - it is superfluous.
parameters are obvious. Note: you don't add the value layer Azure inserts - EPAC takes care of that.
During Policy resource development (called epac-dev ) the Assignment is deployed to an EPAC development Management Group Epac-Mg-1 .
During Policy prod deployments ( tenant -wide), it is deployed to the tenant Management Group Epac-Mg-1 .
No notScope entries are specified.

Security-Focused Policy Assignment with JSON parameters

In the following example we named our root node ( nodeName ) /security/ . Since it is only used in case of error messages produced by EPAC during planning it's actual value doesn't matter as long as it's unique.
We use a definitionEntryList to create two assignments at every leaf (six assignments total).
For assignment string concatenation we append the strings in the definitionEntryList to the strings in the child nodes. You can see this best when you look at the description string in the child nodes. It will form a sentence when concatenated by append ing the definitionEntryList assignment field description .
The parameters specified in the children are specific to the IaC environment types and their scope . Note: a real assignment would define many more parameters. The set here is abbreviated since the actual set could easily exceed a hundred entries for each of the IaC environments. We'll see in the next example how to simplify large Policy Set parameters with a CSV file.

Inverted Policy Assignment (Tag Inheritance and Required Tags)

As mentioned above sometimes it is advantageous (to reduce the number of repetitions) to turn a definition on its head:

Common parameters , scope , definitionEntryList (with two Policies) at the root ( nodeName is /Tags/ ).
Start of the assignment strings ( append is defaulted to false ). Again look at description which will be a concatenated sentence.
The children define the tagName parameter and the second part of the strings for assignment . The set of parameters is the union of the root node and the child node.
This creates six Assignments (number of Policies assigned times number of children).

Non-Compliance Messages in a Policy Definition Assignment

Non-compliance messages in a policy set definition assignment, non-compliance messages in a policy set definition assignment with a definitionentrylist.

This browser is no longer supported.

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

Azure Policy assignment structure

8 contributors

Policy assignments are used by Azure Policy to define which resources are assigned which policies or initiatives. The policy assignment can determine the values of parameters for that group of resources at assignment time, making it possible to reuse policy definitions that address the same resource properties with different needs for compliance.

For more information on Azure Policy scope, see Understand scope in Azure Policy .

You use JavaScript Object Notation (JSON) to create a policy assignment. The policy assignment contains elements for:

display name
description
resource selectors
enforcement mode
excluded scopes
policy definition
non-compliance messages

For example, the following JSON shows a policy assignment in DoNotEnforce mode with dynamic parameters:

All Azure Policy samples are at Azure Policy samples .

Display name and description

You use displayName and description to identify the policy assignment and provide context for its use with the specific set of resources. displayName has a maximum length of 128 characters and description a maximum length of 512 characters.

The optional metadata property stores information about the policy assignment. Customers can define any properties and values useful to their organization in metadata . However, there are some common properties used by Azure Policy. Each metadata property has a limit of 1,024 characters.

Common metadata properties

assignedBy (string): The friendly name of the security principal that created the assignment.

createdBy (string): The GUID of the security principal that created the assignment.

createdOn (string): The Universal ISO 8601 DateTime format of the assignment creation time.

parameterScopes (object): A collection of key-value pairs where the key matches a strongType configured parameter name and the value defines the resource scope used in Portal to provide the list of available resources by matching strongType . Portal sets this value if the scope is different than the assignment scope. If set, an edit of the policy assignment in Portal automatically sets the scope for the parameter to this value. However, the scope isn't locked to the value and it can be changed to another scope.

The following example of parameterScopes is for a strongType parameter named backupPolicyId that sets a scope for resource selection when the assignment is edited in the Portal.

updatedBy (string): The friendly name of the security principal that updated the assignment, if any.

updatedOn (string): The Universal ISO 8601 DateTime format of the assignment update time, if any.

evidenceStorages (object): The recommended default storage account that should be used to hold evidence for attestations to policy assignments with a manual effect. The displayName property is the name of the storage account. The evidenceStorageAccountID property is the resource ID of the storage account. The evidenceBlobContainer property is the blob container name in which you plan to store the evidence.

Resource selectors

The optional resourceSelectors property facilitates safe deployment practices (SDP) by enabling you to gradually roll out policy assignments based on factors like resource location, resource type, or whether a resource has a location. When resource selectors are used, Azure Policy will only evaluate resources that are applicable to the specifications made in the resource selectors. Resource selectors can also be used to narrow down the scope of exemptions in the same way.

In the following example scenario, the new policy assignment is evaluated only if the resource's location is either East US or West US .

When you're ready to expand the evaluation scope for your policy, you just have to modify the assignment. The following example shows our policy assignment with two more Azure regions added to the SDPRegions selector. Note, in this example, SDP means to Safe Deployment Practice :

Resource selectors have the following properties:

name : The name of the resource selector.

selectors : (Optional) The property used to determine which subset of resources applicable to the policy assignment should be evaluated for compliance.

kind : The property of a selector that describes which characteristic narrows down the set of evaluated resources. Each kind can only be used once in a single resource selector. Allowed values are:

resourceLocation : This property is used to select resources based on their type. Can't be used in the same resource selector as resourceWithoutLocation .

resourceType : This property is used to select resources based on their type.

resourceWithoutLocation : This property is used to select resources at the subscription level that don't have a location. Currently only supports subscriptionLevelResources . Can't be used in the same resource selector as resourceLocation .

in : The list of allowed values for the specified kind . Can't be used with notIn . Can contain up to 50 values.

notIn : The list of not-allowed values for the specified kind . Can't be used with in . Can contain up to 50 values.

A resource selector can contain multiple selectors . To be applicable to a resource selector, a resource must meet requirements specified by all its selectors. Further, up to 10 resource selectors can be specified in a single assignment. In-scope resources are evaluated when they satisfy any one of these resource selectors.

The optional overrides property allows you to change the effect of a policy definition without modifying the underlying policy definition or using a parameterized effect in the policy definition.

The most common use case for overrides is policy initiatives with a large number of associated policy definitions. In this situation, managing multiple policy effects can consume significant administrative effort, especially when the effect needs to be updated from time to time. Overrides can be used to simultaneously update the effects of multiple policy definitions within an initiative.

Let's take a look at an example. Imagine you have a policy initiative named CostManagement that includes a custom policy definition with policyDefinitionReferenceId corpVMSizePolicy and a single effect of audit . Suppose you want to assign the CostManagement initiative, but don't yet want to see compliance reported for this policy. This policy's 'audit' effect can be replaced by 'disabled' through an override on the initiative assignment, as shown in the following sample:

Overrides have the following properties:

kind : The property the assignment will override. The supported kind is policyEffect .

value : The new value that overrides the existing value. The supported values are effects .

selectors : (Optional) The property used to determine what scope of the policy assignment should take on the override.

kind : The property of a selector that describes what characteristic will narrow down the scope of the override. Allowed value for kind: policyEffect is:

policyDefinitionReferenceId : This specifies which policy definitions within an initiative assignment should take on the effect override.

Note that one override can be used to replace the effect of many policies by specifying multiple values in the policyDefinitionReferenceId array. A single override can be used for up to 50 policyDefinitionReferenceIds, and a single policy assignment can contain up to 10 overrides, evaluated in the order in which they're specified. Before the assignment is created, the effect chosen in the override is validated against the policy rule and parameter allowed value list (in cases where the effect is parameterized ).

Enforcement mode

The enforcementMode property provides customers the ability to test the outcome of a policy on existing resources without initiating the policy effect or triggering entries in the Azure Activity log .

This scenario is commonly referred to as "What If" and aligns to safe deployment practices. enforcementMode is different from the Disabled effect, as that effect prevents resource evaluation from happening at all.

This property has the following values:

If enforcementMode isn't specified in a policy or initiative definition, the value Default is used. Remediation tasks can be started for deployIfNotExists policies, even when enforcementMode is set to DoNotEnforce .

Excluded scopes

The scope of the assignment includes all child resource containers and child resources. If a child resource container or child resource shouldn't have the definition applied, each can be excluded from evaluation by setting notScopes . This property is an array to enable excluding one or more resource containers or resources from evaluation. notScopes can be added or updated after creation of the initial assignment.

An excluded resource is different from an exempted resource. For more information, see Understand scope in Azure Policy .

Policy definition ID

This field must be the full path name of either a policy definition or an initiative definition. policyDefinitionId is a string and not an array. The latest content of the assigned policy definition or initiative is retrieved each time the policy assignment is evaluated. It's recommended that if multiple policies are often assigned together, to use an initiative instead.

Non-compliance messages

To set a custom message that describes why a resource is non-compliant with the policy or initiative definition, set nonComplianceMessages in the assignment definition. This node is an array of message entries. This custom message is in addition to the default error message for non-compliance and is optional.

Custom messages for non-compliance are only supported on definitions or initiatives with Resource Manager modes definitions.

If the assignment is for an initiative, different messages can be configured for each policy definition in the initiative. The messages use the policyDefinitionReferenceId value configured in the initiative definition. For details, see policy definitions properties .

This segment of the policy assignment provides the values for the parameters defined in the policy definition or initiative definition . This design makes it possible to reuse a policy or initiative definition with different resources, but check for different business values or outcomes.

In this example, the parameters previously defined in the policy definition are prefix and suffix . This particular policy assignment sets prefix to DeptA and suffix to -LC . The same policy definition is reusable with a different set of parameters for a different department, reducing the duplication and complexity of policy definitions while providing flexibility.

For policy assignments with effect set to deployIfNotExist or modify , it's required to have an identity property to do remediation on non-compliant resources. When using identity, the user must also specify a location for the assignment.

A single policy assignment can be associated with only one system- or user-assigned managed identity. However, that identity can be assigned more than one role if necessary.

Learn about the policy definition structure .
Understand how to programmatically create policies .
Learn how to get compliance data .
Learn how to remediate non-compliant resources .
Review what a management group is with Organize your resources with Azure management groups .

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

IMAGES

Create custom roles in Azure AD role-based access control
Create an Role assignment policy
Use Microsoft Entra groups to manage role assignments
55. Create and Manage User Role Assignment Policy in Exchange 2019
Assign Azure roles using the Azure portal
12 RACI Matrix Presentation Charts Templates with Project

VIDEO

Create an Role assignment policy
Role Assignment #conversation #relationship #dating #marriage #cooking #TheHOTC #HOTC #HOTCPodcast
NUR541 Unit 4 Assignment Policy Platform Video
GCU PSA
How To Create Role And Permissions For Team Members ?
Unit 4 Assignment Policy Platform Video Presentation

COMMENTS

Role assignment policies in Exchange Online
Create role assignment policies Use the EAC to create role assignment policies. In the EAC, go to Roles > Admin roles and then click Add role group. In the Add role group window, click Set up the basics section, configure the following settings and click Next: Name: Enter a unique name for the role group.
Manage role assignment policies
For detailed syntax and parameter information, see Set-RoleAssignmentPolicy.. Add a role to an assignment policy Use the EAC to add a role to an assignment policy. In the EAC, navigate to Permissions > User Roles.. Select the assignment policy you want to add one or more roles to, and then click Edit.. Select the check box next to the role or roles you want to add to the assignment policy.
New-RoleAssignmentPolicy (ExchangePowerShell)
Description. When you create an assignment policy, you can assign it to users using the New-Mailbox, Set-Mailbox, or Enable-Mailbox cmdlets. If you make the new assignment policy the default assignment policy, it's assigned to all new mailboxes that don't have an explicit assignment policy assigned to them. You can add management roles to the ...
Using Azure policies to audit and automate RBAC role assignments
Create a custom RBAC role for policy deployments and add it to your policy definition; Create an assignment for the custom policy; The example scenario is very specific and the policy definition is created to match this particular scenario. You can use the solution provided in this post as a basis to create something that fits exactly to your ...
55. Create and Manage User Role Assignment Policy in Exchange 2019
Microsoft Exchange 2019 Beginners Video Tutorials Series:This is a step by step guide on How to Create and Manage User Role Assignment Policy in Exchange Ser...
How to manage Microsoft 365 user role assignments and administrative units
Follow the steps below to assign the Global Administrator role to a user or group. Navigate to https://admin.microsoft.com and authenticate as a global admin user. On the left pane, expand the "Roles" section and click on "Role assignments". On the main section click on the "Global Administrator" role.
A Beginner's Guide To Role-Based Access Control on Azure
The way you control access to resources using RBAC is to create role assignments. This is a key concept to understand - it's how permissions are enforced. A role assignment consists of three elements: security principal, role definition, and scope. User - An individual who has a profile in Azure Active Directory.
Exchange Role Based Access Control: Management Roles
The more sensible approach is to create a custom RBAC role and assign it to that user, or to a role group that the user can be made a member of. The easiest way to create a custom role is by using the Exchange Admin Center. In the permissions section under admin roles, click the icon to create a new role group.
Role Based Permissions in Exchange Server 2016
NOTE: Only end-user roles can be assigned to role assignment policies. Create new Role Group: Open EAC and Navigate to Permissions à User Role à Click on . In the New Role Group window provide the name, description for the Role Assignment policy and select the Roles needs to be provided and click on Save: PowerShell command for Role ...
Manage Azure Role Assignments Like a Pro with PowerShell
Learn how to manage Azure Role assignments using PowerShell snippets and simple commandlets. Discover examples for listing all role assignments, adding and removing assignments for users or service principals, creating custom roles, and more. Plus, check out a script that combines some of these examples into a single function. Written by Vukasin Terzic.
Set-RoleAssignmentPolicy (ExchangePowerShell)
Description. You can use the Set-RoleAssignmentPolicy cmdlet to change the name of an assignment policy or to set the assignment policy as the default assignment policy. For more information about assignment policies, see Understanding management role assignment policies. You need to be assigned permissions before you can run this cmdlet.
Add or remove roles from a role assignment policy
Add or remove roles from a role assignment policy. Step 1: Sign in to Office 365 admin center. Step 2: Navigate to the Exchange admin center. Step 3: Go to Permissions > User roles, select the role assignment policy, and then click Edit. Step 4: Select the check box next to the role. Step 5: Click Save. Need Support?
Create an azure policy to block role assignments to certain principal
There should be an exception for certain identities that are be allowed to create role assignments for users and groups. The policy below works, for existing role assignments. Existing role assignments to groups/users created by the specified IDs are compliant. Existing role assignments to users/groups created by other principals are not compliant.
Allow Users To Manage Distribution Groups Without Creating New Ones
Create New Role Assignment Policy. Let's create a new Role Assignment Policy called DG-Management. We want to mirror the existing Default Role Assignment Policy, as a mailbox can only be assigned a single Role Assignment policy and we need to ensure that the user can perform all required activities on their mailbox.
az role assignment
Name Description Type Status; az role assignment create: Create a new role assignment for a user, group, or service principal. Core GA az role assignment delete
Azure RBAC: role assignments and ARM templates
Azure role-based access control (Azure RBAC) helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to. Designating groups or individual roles responsible for specific functions in Azure helps avoid confusion that can lead to human and automation errors that create security risks.
Azure policy not creating roles for managed identity when deployed
The role assignment must be made for the managed identity created by the policy assignment. If you create the policy assignment from the portal, I believe this is done automatically for you. An ARM template in DevOps will require a manual definition. The policy assignment therefore must also be deployed with a role assignment.
Assign Azure roles using the Azure portal
On the Role tab, select a role that you want to use.. You can search for a role by name or by description. You can also filter roles by type and category. If you want to assign a privileged administrator role, select the Privileged administrator roles tab to select the role.. For best practices when using privileged administrator role assignments, see Best practices for Azure RBAC.
[Examples] Create Custom Policies Policy Sets and Assignments
In order to assign your custom policies or policy sets, you need to create policy assignment files. The first step is to create a policy_assignments subdirectory within /lib. NOTE: Creating a policy_assignments subdirectory within \lib is a recommendation only. If you prefer not to create one or to call it something else, the custom policies ...
Policy Assignment Files
Metadata for Role Assignments. Role assignments do not contain a metadata field. Instead, the description field is used to populate the deployedBy value. The description field is populated with the Policy Assignment Id, reason and deployedBy value. This is useful for tracking the source of the Role Assignment. Reasons is one of:
Details of the policy assignment structure
The policy assignment can determine the values of parameters for that group of resources at assignment time, making it possible to reuse policy definitions that address the same resource properties with different needs for compliance. Note. For more information on Azure Policy scope, see Understand scope in Azure Policy.