role assignment policies in exchange online

This browser is no longer supported.

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

Role assignment policies in Exchange Online

• 15 contributors

A role assignment policy is a collection of one or more end-user roles that enable users to manage their mailbox settings and distribution groups in Exchange Online. End-users roles are part of the role based access control (RBAC) permissions model in Exchange Online. You can assign different role assignment policies to different users to allow or prevent specific self-management features in Exchange Online. For more information, see Role assignment policies .

In Exchange Online, a default role assignment policy named Default Role Assignment Policy is specified by the mailbox plan that's assigned to users when their account is licensed. For more information about mailbox plans, see Mailbox plans in Exchange Online .

User roles and Outlook Web App policies are now available in Exchange admin center.

Role assignment policies are how end-user roles (as opposed to management roles) are assigned to users in Exchange Online. There are several ways you can use role assignment policies to assign permissions to users:

New users :

Change the end-user roles that are assigned to the default role assignment policy.

Create a custom role assignment policy and set it as the default. Note that this method only affects mailboxes that you create without specifying a role assignment policy or assigning a license (the license specifies the mailbox plan, which specifies the role assignment policy).

Specify a custom role assignment policy in the mailbox plan. For more information, see Use Exchange Online PowerShell to modify mailbox plans .

Existing users :

Assign a different license to the user. This will apply the settings of the different mailbox plan, which specifies the role assignment policy to apply.

Manually assign a custom role assignment policy to mailboxes.

The available end-user roles that you can assign to mailbox plans are described in the following table:

* This feature isn't available in all regions or organizations.

What do you need to know before you begin?

Estimated time to complete each procedure: less than 5 minutes.

The procedures in this topic require the Role Management RBAC role in Exchange Online. Typically, you get this permission via membership in the Organization Management role group (the Microsoft 365 or Office 365 Global administrator role). For more information, see Manage role groups in Exchange Online .

To open the Exchange admin center (EAC), see Exchange admin center in Exchange Online . To connect to Exchange Online PowerShell, see Connect to Exchange Online PowerShell .

Changes to permissions take effect after the user logs out and logs in again.

View roles assigned to a role assignment policy

Use the eac to view roles assigned to a role assignment policy.

In the EAC, click Roles > Admin roles . All of the role groups in your organization are listed here.

Select a role group. The details pane shows the Name , Description , and add the Permissions of the role group.

Use Exchange Online PowerShell to view roles assigned to a role assignment policy

To view the roles assigned to a role assignment policy, use the following syntax:

This example returns the roles that are assigned to the policy named Default Role Assignment Policy.

For detailed syntax and parameter information, see Get-ManagementRoleAssignment .

Note : To return a list of all available end-user roles, run the following command:

Add or remove roles from a role assignment policy

Use the eac to add or remove roles from a role assignment policy.

In the policy properties window that opens, do one of the following steps:

To add a role, select the check box next to the role.

To remove a role that's already assigned, clear the check box.

If you select a check box for a role that has child roles, the check boxes for the child roles are also selected. If you clear the check box of the parent role, the check boxes for the child roles are also cleared. You can select a child role by clearing the check box of the parent role and then selecting the individual child role.

When you're finished, click Save .

Use Exchange Online PowerShell to add roles to a role assignment policy

Adding a role to a role assignment policy creates a new role assignment with a unique name that's a combination of the names of the role and the role assignment policy.

To add roles to a role assignment policy, use the following syntax:

This example adds the role MyMailboxDelegation to the role assignment policy named Default Role Assignment Policy.

For detailed syntax and parameter information, see New-ManagementRoleAssignment .

Use Exchange Online PowerShell to remove roles from a role assignment policy

Use the procedure from the Use Exchange Online PowerShell to view roles assigned to a role assignment policy section earlier in this topic to find the name of the role assignment for the role that you want to remove (it's a combination of the names of the role and the role assignment policy).

To remove the role from the role assignment policy, use this syntax:

This example removes the MyDistributionGroups role from the role assignment policy named Default Role Assignment Policy.

For detailed syntax and parameter information, see Remove-ManagementRoleAssignment .

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.

Description : Enter an optional description for the role group.

Select the roles that you want to assign to the policy.

In the Add permissions section, select the roles and click Next . Roles define the scope of the tasks that the members assigned to this role group have permission to manage.

In the Assign admins section, select the users to assign to this role group and click Next . They'll have permissions to manage the roles that you assigned.

In the Review role group and finish section, verify all the details, and then click Add role group .

Click Done .

Use Exchange Online PowerShell to create role assignment policies

To create a role assignment policy, use the following syntax:

This example creates a new role assignment policy named Contoso Contractors that include the specified end-user roles.

For detailed syntax and parameter information, see New-RoleAssignmentPolicy .

Modify role assignment policies

You can use the EAC or Exchange PowerShell to Add or remove roles from a role assignment policy .

You can only use Exchange Online PowerShell to specify the default role assignment policy that's applied to new mailboxes that aren't assigned a license or a role assignment policy when they're created.

Otherwise, all you can do in the EAC or Exchange Online PowerShell is modify the name and description of the role assignment policy.

Use Exchange Online PowerShell to specify the default role assignment policy

To specify the default role assignment policy, use the following syntax:

This example configures Contoso Users as the default role assignment policy.

Note : The IsDefault switch is also available on the New-RoleAssignmentPolicy cmdlets.

For detailed syntax and parameter information, see Set-RoleAssignmentPolicy .

Remove role assignment policies

You can't remove the role assignment policy that's currently specified as the default. You first need to specify another role assignment policy as the default before you can delete the policy.

You can't remove a role assignment policy that's assigned to mailboxes. Use the procedures described in the Use Exchange Online PowerShell to modify role assignment policy assignments on mailboxes section to replace the role assignment policy that's assigned to mailboxes.

Use the EAC to remove role assignment policies

In the EAC, go to Roles > Admin roles .

Select the role group and click Delete .

Click Confirm in the confirmation window.

Use Exchange Online PowerShell to remove role assignment policies

To remove a role assignment policy, use the following syntax:

This example removes the role assignment policy named Contoso Managers.

For detailed syntax and parameter information, see Remove-RoleAssignmentPolicy .

View role assignment policy assignments on mailboxes

Use the eac to view role assignment policy assignments on mailboxes.

In the mailbox properties window that opens, click Mailbox features . The role assignment policy is shown in the Role assignment policy field.

Use Exchange Online PowerShell to view role assignment policy assignments on mailboxes

To see the role assignment policy assignment on a specific mailbox, use the following syntax:

This example returns the role assignment policy for the mailbox named Pedro Pizarro.

To return all mailboxes that have a specific role assignment policy assigned, use the following syntax:

This example returns all mailboxes that have the role assignment policy named Contoso Managers assigned.

Modify role assignment policy assignments on mailboxes

A mailbox can have only one role assignment policy assigned. The role assignment policy that you assign to the mailbox will replace the existing role assignment policy that's assigned.

Use the EAC to modify role assignment policy assignments on mailboxes

In the EAC, click Recipients > Mailboxes , and do one of the following steps:

Multiple mailboxes : Select multiple mailboxes of the same type (for example, User ) by selecting a mailbox, holding down the Shift key, and select another mailbox farther down in the list or by holding down the Ctrl key as you select each mailbox. In the details pane (that's now titled Bulk Edit ): click More options > click Update . In the Role Assignment Policy section, select the role assignment policy in the window that appears > click Save .

Use Exchange Online PowerShell to modify role assignment policy assignments on mailboxes

To change the role assignment policy assignment on a specific mailbox, use this syntax:

This example applies the role assignment policy named Contoso Managers to the mailbox named Pedro Pizarro.

To change the assignment for all mailboxes that have a specific role assignment policy assigned, use the following syntax:

This example changes the role assignment policy from Default Role Assignment Policy to Contoso Staff for all mailboxes that currently have Default Role Assignment Policy assigned.

Additional resources

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

Azure Active Directory / Exchange Online

Microsoft launches role-based access control for applications.

Table of Contents

RBAC for Applications Only for Exchange Online

On December 1, Microsoft launched the public preview of role-based access control (RBAC) for applications for Exchange Online. The new functionality extends the RBAC model introduced in Exchange 2010 to control access by Azure AD apps to Exchange data, or as Microsoft says, “ resource-scoped permissions ” that “ better protect access to your tenant’s data .” Of course, although Exchange Online is a massive Microsoft 365 workload, it’s not the only source of data that needs similar protection. Alas, that isn’t available yet, so you’ll have to wait for RBAC permissions to extend to SharePoint Online, Teams, Yammer, Planner, etc.

RBAC for applications will eventually replace application access policies (see below). Today, the public preview shows some ragged edges in terms of the integration between Exchange Online and Azure AD that Microsoft say they’ll fix before general availability. Even with some bumps to navigate, the new functionality is a welcome addition that extends tenant control over their data, which is always a good thing.

It’s worth making the point that RBAC for Applications does nothing to stop administrators interacting with mailboxes at an administrative level (setting properties and so on). RBAC for Applications is all about controlling app access to mailbox contents.

Application Access Policies

Application access policies seemed like a good idea when Microsoft introduced them in 2019. An application access policy is a protocol-agnostic mechanism to allow or deny an app access to a set of mail-enabled objects with security principals (usually defined as mailboxes in a security group). The mechanism is effective but has two significant limits. First, Exchange Online supports 300 application access policies per tenant. Second, access is all or nothing. Once a policy grants an app access to mailboxes, the app can use all available Exchange Web Services (EWS) and Microsoft Graph APIs to interact with mailbox data.

Three hundred policies sounds like a lot. It is, especially in an environment where management of these policies is a manual process. The limit is probably acceptable for small to medium tenants but becomes an issue in enterprise tenants where more automated operations are common.

Several factors have increased the use of registered Azure AD apps with PowerShell:

• Microsoft has deprecated basic authentication for many email connection protocols. Exchange Online still supports the SMTP AUTH protocol, but scripts that use SMTP AUTH to send email will need to upgrade to a Graph-based method to create and send email eventually.
• Microsoft will deprecate the Azure AD and Microsoft Online Services (MSOL) PowerShell modules in June 2023 . The advice given to tenants is to replace the cmdlets from these modules with Microsoft Graph APIs (including the Microsoft PowerShell Graph SDK).
• PowerShell scripts that use Microsoft Graph APIs gain access via registered Azure AD apps.
• Although multiple PowerShell scripts can use a single app, the need to restrict Graph permissions means that, in many instances, an app supports a single script. An app permission policy can apply to multiple apps but only if apps use the same permissions with the same set of mailboxes.

Given these factors, it’s obvious how quickly a tenant might reach the limit for application access policies.

A New Approach

With the experience of application access policies in mind, Microsoft decided to take a different tack with RBAC for Applications. The new model allows administrators to grant permissions to an Azure AD app to access data via a role assignment. Administrators can then restrict permissions to certain target resources by applying a management scope, which tells Exchange Online what mailboxes an app can and cannot access.

Being able to control apps like this is important. The transition toward scripts that make Graph requests to interact with data means that there’s been an explosion of Azure AD apps in many tenants. Unless an app is restricted by an application access policy, the script that it runs has free rein over what data it can access. To some, this is the natural order. After all, if an administrator connects to Exchange Online interactively in a PowerShell window, they can access the configuration and all the management objects in the tenant. The difference with Graph-based scripts is that you can access user data. For instance, a script can use the Graph Mail.Send API to send email from any mailbox. That’s not a good thing, which is why controls are necessary.

Testing RBAC for Applications

To test RBAC for Applications, I used the mailbox report script . This script reads the folders and items from a mailbox using the Graph Mail.Read permission. Without limits, the script can read items in any mailbox.

To begin, I registered a new Azure AD app. The authentication method used by the app doesn’t matter (app secret or certificate-based). To validate that the script works as expected, assign the Mail.Read application permission to the app and grant administrator consent. You should now be able to run the script to read data from any mailbox.

Now revoke the Mail.Read permission from the app. This is an important step because you’re going to replace the access granted through the administrator consent to use the permission with a permission managed by Exchange Online. If you leave the Mail.Read permission in place, it will supersede the control available through RBAC for Applications.

Defining a Service Principal Object

To use RBAC for Applications, Exchange Online must know about an application. Exchange Online uses a service principal object for this purpose. This is somewhat confusing because Azure AD apps have service principals that represent the app. In Azure AD, security principals hold the permissions assigned to apps. A similar model exists in Exchange Online, where the service principal object represents an Azure AD application. RBAC for Applications extends the RBAC model used by Exchange to allow administrators to assign management roles to apps via their service principals. The roles define what actions the app can take, like reading or sending email.

You can only create new service principal objects via PowerShell . Before running the New-ServicePrincipal cmdlet, you need to know the application identifier and service principal identifier for the app. One way to do this is to open the app overview in the enterprise applications section of the Azure AD admin center and copy the values from there (Figure 1).

As everything happens in PowerShell, you can also fetch the object identifiers and store them in variables.  Here’s what I did:

With the identifiers, we can run New-ServicePrincipal to create the service principal object:

Creating a Management Role Scope

Next, we create a management role scope to tell Exchange Online what mailboxes the app can access. If you’re used to mailbox filtering , there’s nothing new here as you can use any of the filterable mailbox properties to create a scope. This example creates a very simple scope to find any mailbox that has the “Manager” value in CustomAttribute1:

Before testing, make sure that some mailboxes come within the management role scope by updating their attributes. For example:

To validate that the scope finds the expected set of mailboxes, use the same filter with the Get-EXOMailbox cmdlet:

Creating a Management Role Assignment

To bring everything together, we create a management role assignment to connect the management scope with the requested access (the role). You can see that the role assigned is “ Application Mail.Read ,” which corresponds to the Graph Mail.Read permission required to read the contents of user mailboxes.

RBAC for Applications also supports the use of Azure AD administrative units for management role assignments. In these commands, we list the administrative units available in Azure AD and use one in a role assignment to allow the app to send mail from the mailboxes of the users within the administrative unit:

Available Roles for RBAC for Applications

Running the Get-ManagementRole cmdlet exposes the set of permissions supported by RBAC for Applications. All permissions granted by RBAC for Applications are application rather than delegate permissions.

Many of these permissions are among the set of high-priority permissions that hackers attempt to exploit. It’s a good idea to include apps governed by RBAC for Applications in the periodic reviews of apps and permissions.

Waiting for Caching

After creating the management role assignment, the situation should be:

• The registered Azure AD app identified in the service principal object has no Graph permissions. You can confirm this by examining the roles specified in the access token granted by the Graph . The access token should contain no trace of the Graph permission that the app will gain through the role assignment.
• A management scope or Azure AD administrative unit is available to identify target mailboxes.
• The management role assignment will allow the Azure AD app to run the permission specified in the management role assignment against the target mailboxes.

Exchange Online caches permissions so it can take up to 30 minutes before the management role assignment is effective. To avoid the effect of caching, restart your PowerShell session to make sure that Exchange Online uses the latest entitlements.

The Test-ServicePrincipalAuthorization cmdlet allows administrators to test that an app can access a target mailbox. For example, this test returns a False result, meaning that the selected mailbox is outside the management scope.

After allowing caching to happen, test that Exchange Online allows the app to access the in-scope mailboxes and blocks attempted access (403 Forbidden error) when the app tries to open mailboxes outside the scope.

Marching to General Availability

Microsoft expects RBAC for Applications to reach general availability sometime in the first half of 2023. When the feature reaches that point, I expect Microsoft will improve the current rough edges around RBAC for Applications, like the interaction with Azure AD apps and permissions, and perhaps even create some UX in an admin portal. Once RBAC for Applications is generally available, Microsoft will proceed with the depreciation of application access policies. Until that happens, the two mechanisms can run side-by-side.

Early tests show that RBAC for Applications is a good way to control app access to mailboxes. The generally available version will be easier to use, but there’s no good reason not to use PowerShell commands to configure access today. Like regular RBAC, once you get your head around what must be done, it’s straightforward.

The Microsoft 365 Kill Chain and Attack Path Management

An effective cybersecurity strategy requires a clear and comprehensive understanding of how attacks unfold. Read this whitepaper to get the expert insight you need to defend your organization!

About the Author

Tony Redmond

Hi Tony, very well written article ! question which of the roles Get-ManagementRole | Where-Object {$_.Name -like “Application *”} would map exactly to the full_access_as_app Exchange Web Service permission scope? Would that be Application EWS.AccessAsApp ? I’m also a bit confused about the returned access token (The registered Azure AD app identified in the service principal object has no Graph permissions.). Traditionally when using the client credentials flow I would I would define the https://outlook.office365.com/.default scope so that the access token returned would contain all the app-level permissions the admin has consented to (that is, the roles claim would contain permissions that the requesting app has been given permission to call), now with the RBAC approach one has to remove the consent from the Entra ID app registration… how would that be reflected in the access token then? Thank you !

First, the intention is that you don’t use an all-encompassing permission like EWS.AccessAsApp. Instead, you should use granular, limited permissions to access the information you need. There is no equivalent of the EWS full_access_as_app permission (which Microsoft is seeking to remove ASAP ).

The app will only have Graph permissions if they are assigned to the app… what permissions do you mean? Maybe I am not following the question. Perhaps this example of using an app running with a managed identity that uses a limited calendar read permission to access specific mailboxes using RBAC for applications: https://practical365.com/rbac-for-applications-azure-automation/

‘ what permissions do you mean?’ I mean the permissions consented in Entra app registration for the given app. If one adds permissions and provides consent, the returned access token in a client credential flow will have them within its claims for example:

“roles”: [ “full_access_as_app” ],

Now the articel states to remove the permission consent in my case for full_access_as_app. How will the returned token satisfy any permissions if they are removed from the app registration?

The whole point of RBAC for Applications is that the app secures its permissions through Exchange Online rather than Entra ID. What you’re describing is the classic Entra ID flow to grant an access token with permissions listed in the token claims. When RBAC for applications is used, Exchange recognizes the permission granted to the service principal and allows the app to use that permission (in the example I cited, Calendar.Read). The permission does not appear in the access token because Exchange Online controls the access to the mailboxes. Only specific permissions are available with RBAC for Applications and full_access_as_app is not one of these.

Okay, that makes sense. Is there any modification then needed within the application code itself or will this just work fine out of the box?

If your app only needs to use the permissions supported by RBAC for applications, everything should work as if the app is assigned consented Graph permissions by Entra ID. I certainly haven’t hit any major problems that weren’t due to my own ineptitude.

Thank you for clarifying ! really enjoy your posts, keep them coming 😊!

I will do my best to continue to throw light into the shadowy parts of Microsoft 365…

I just wanted to say thanks for this great blog/posts about sending mail via Graph with PowerShell. Its been greatly helpful in some of my efforts to modernize some older workflows.

Keep up the great work!

Leave a Reply Cancel reply

Latest articles.

PowerShell Serialization Payload Signing in Exchange Server

In this article, Jaap Wesselius discusses PowerShell serialization, what PowerShell serialization payload signing is, why this is important, and how to manage it.

Using the Microsoft AuditLog Query Graph API (Preview)

The unified audit log is the source of a lot of information about a Microsoft 365 tenant. The Search-UnifiedAuditLog cmdlet is available to search the audit log and now we have the AuditLog Graph API. This article explains how to use the new API to query and retrieve audit records from the log.

• Microsoft Graph

PowerShell, Teams, and Exchange News with Special Guest MVP Michel De Rooij: The Practical 365 Podcast S4 E17

On the show this week, we're joined by fellow Microsoft MVP and long-term PowerShell, Exchange and Microsoft 365 expert, Michel De Rooij to discuss PowerShell, GitHub Copilot, Teams, and more!

• Exchange Online

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

How to enforce office 365 custom "role assignment policy" applied default to all new emails to be created?

I have created a RoleAssignmentPolicy called "DisabledForwardingRoleAssignmentPolicy" via Exchange admin center --permissions-- user roles .

I would like to apply "DisabledForwardingRoleAssignmentPolicy" default to all new emails accounts to be created.

In gui of Exchange admin center, there seems to be no way to do this. So I did this by longing to office 365 in powershell.

The command successfully executed. and when I verify it via Get-RoleAssignmentPolicy it says DisabledForwardingRoleAssignmentPolicy is default .

But when I create a new email and when i go to recipients --mailboxes-- select user and mailbox features--- Role assignment policy , still the default policy is applied.

I have to change it manually to DisabledForwardingRoleAssignmentPolicy

What I'm missing here? Please shade a light.

• email-server
• microsoft-office

You need to run "Set-MailboxPlan" cmdlet to change the default role assignment policy to the customize one.

First, run "get-mailboxplan" to confirm which plan your license is used, as below:

Then, run "Set-MailboxPlan" to change the RoleAssignmentPolciy to the customize one:

• You are truly a great resource to serverfault. thanks a lot for your time testing it before posting. I was googling and no correct path was found. It worked. –  user879 May 30, 2018 at 5:21

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged email exchange email-server microsoft-office mailbox ..

• The Overflow Blog
• How to succeed as a data engineer without the burnout
• How do you evaluate an LLM? Try an LLM.
• Featured on Meta
• New Focus Styles & Updated Styling for Button Groups
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network

Hot Network Questions

• Change of Variables for Multivariate Integral
• Cryptic Acrostic 7: An Ode to "Mr. Malaprop"
• CVE-2024-31497, nonces and random numbers: Can someone explain, please?
• How can my book purchase get the most money to an author?
• What are some tracing disassemblers for the Z80
• Ways to Say "Forcibly Inducted"
• Finding the equivalent title/position of "Oberassistent II" in both the US and in the Italian university system
• Group Completion of a monoid (Braid groups)
• How to combine multiple pure conditions with an AND operator?
• Removing polygons that look like lines in QGIS
• To what extent can US police lie to a suspect?
• Isn't Camus' philosophy just a violation of Occam's Razor?
• Help with Star Battle puzzle
• Sampling frequency of ADC and maximum frequency of input signal
• What kind of lightbulb is pictured here, having a clear bulb window and 4 yellow vertical rods?
• What power lets you modify game actions? (Power Profiles are weird)
• Cahn Ingold Prelog rule question with isotopes
• Will SpaceX ever make a Heavy version of Starship Super Heavy
• Stack - implementation in Java
• What options do I have for latex-free interior house paint?
• Complex Integral ML Lemma
• How to make a device to randomly choose one of three possibilities, with caveat that sometimes one of them is not available?
• Could the theory of evolution become common knowledge in a society with medieval technology?
• The fifth son at the seder

All about Microsoft 365

ExO RBAC improvements #1: Limiting application access

Exchange has long been the prime example of a workload with granular and robust permissions model. Thus, it comes as no surprise that the Azure AD role-based access control (RBAC) model follows most of the principles introduced by Exchange. With all its customizability however, the RBAC model had some issues addressing the application permissions model introduced by the Graph API, where the service principal, under which the various operations were being executed, gains unscoped, directory-wide permissions.

To address such scenarios, Exchange Online introduced support for application access policies back in 2019. Later on, the EWS application permissions scenario was also addressed. Other workloads added their own implementations of similar controls, such as the Sites.Selected method for SharePoint Online and the resource-scoped consent model for Teams, to an extent. Yet, such implementations are not without their own issues, and in the case of Exchange certain limitations were quickly identified. So instead of making further investments in application access policies, Microsoft decided to bring the application experience as part of the existing Exchange RBAC model.

Meet Role Based Access Control for Applications in Exchange Online , currently in public preview. In a nutshell, the feature allows you to treat application access in a manner similar to how you assign user permissions. To that end, you need to decide on the set of permissions needed (the Management Role), the principal to grant them to (a Service principal object in this case) and the set of objects against said permissions will be valid (the Management Scope). The new bits here are support for service principal objects, i.e. the object representing an Azure AD integrated app within your directory, and the introduction of new, service principal specific management roles.

Incidentally, we’ve already covered all those new bits individually. At the time I wrote said article, management role assignment was not yet available for SP objects, but I speculated this will be coming in the future. And so, the time has come. For the time being, you will still need to manually create a matching service principal object for any application you plan to restrict access on, by means of using the New-ServicePrincipal cmdlet. Going forward, Microsoft is promising that this step will no longer be needed. Here’s an example on how to use the cmdlet. You will need to specify the client ID (application ID) value, via the – AppId  parameter, as well as the object ID, via the – ServiceId parameter:

If you do not know the values for said parameters, you can obtain them from either the Azure AD blade > App registrations > Overview page, or via PowerShell ( Get-MsolServicePrincipal ,  Get-AzureADServicePrincipal  or  Get-MgServicePrincipal  cmdlet, depending on which module you prefer). Do note that the  New-ServicePrincipal  does NOT validate the values, so make sure you double- and triple-check them.

The other part of the puzzle is the set of Management Roles you can assign. Microsoft has created a set of such roles, corresponding to the (most used) Graph API permissions. You can obtain a list of all supported roles by filtering them via the IsServicePrincipalRole value of True. Alternatively, you can look for all roles with the “Application” prefix. Do note that the list does not include all application permissions scopes available in the Graph!

After this introduction/refresher, how do we go about replacing an existing application access policy with a matching role assignment? The task boils down to determining the set of objects the application access policy was scoped to, creating a matching management scope and creating a management role assignment for the corresponding service principal. If you are not using application access policies but only interested in creating a management role assignment for a SP, just skip the next paragraph. The process remains the same, we simply need to provide the required information, instead of “borrowing” it from the properties of an existing application access policy.

Let’s start by looking at the application access policy details. The Identity property gives us the ClientID of the application, as well as the object to which it’s scoped. The only other bit of information we need is the type of policy, determined by the value of the AccessRight property.

We can use the New-ServicePrincipal cmdlet to create a matching object within ExODS (see example above).

Next, we need a management scope. Few notes are due here. With application access policies, the scope was either a single mailbox/mail user object or a set of objects, designated by their membership of a mail-enabled security group. Using “standard” Exchange management scopes, we have a lot more flexibility as you can use a variety of properties and operators to build the recipient filter. If you simply want to match the scope of the application access policy, use the MemberOfGroup property as follows:

where we’ve used the GUID obtained from the application access policy configuration. The Get-Recipient cmdlet can be used to “resolve” said GUID to the matching object within the directory, and after that we can leverage its DistinguishedName value to prepare the Recipient filter.

You might have noticed however that the application access policy was configured in “deny” mode, i.e. it was preventing the application from performing any operations against members of the specified group, while all other objects within the directory were valid targets. Thus, we need to amend our management scope query to exclude members of this group, i.e. use the “opposite” filter query:

Once you are satisfied with the set of object returned by the query, proceed with creating the matching management scope:

It’s worth mentioning that only direct members of the group will fall under the scope of the filter (or out of it, when we use the -ne operator). In other words, nested groups are not supported. You can however use regular distribution groups and Microsoft 365 Groups in addition to mail-enabled security groups. In addition, you can create a scope based on membership of an administrative unit, but we will cover this in another article.

With that, we have all the building blocks to create a management role assignment that will restrict access for the given application. We have an object representing the application and the set of objects against which access will be granted. The last thing to decide on is what permissions the app will get, in other words which Management role(s) to assign to it. While in the case of application access policies this was configured entirely on Azure AD side, with the extensions to the Exchange RBAC model you can control the set of permissions independently, by assigning one (or more) of the service principal roles we listed above.

The management role assignment is done by executing the New-ManagementRoleAssignment cmdlet. Use the newly introduced – App parameter to specify the service principal object and the – Role parameter to assign the corresponding management role. The – CustomResourceScope parameter is optional one and serves to designate the management scope, if you plan to use one. Without it, the newly created management role assignment will allow the application to act upon any object within the tenant. Combining those, we can now create the new role assignment:

In effect, we have mirrored the behavior of the existing application access policy, which restricted the given app to act on every object within the directory, excluding members of the specified group. In addition we’ve ensured that only specific Graph API operations can be executed, independent of any permissions the app has been granted on Azure AD side. If we want to provide the app with unrestricted access, we can create a management role assignment for the Application Exchange Full Access role instead and remove the management scope, if needed.

It’s worth clarifying that the Exchange RBAC permissions do not override application access policies, thus you need to carefully consider the settings you configure. What Microsoft suggests (and I concur with) is to remove the application access policy once a matching role assignment has been created. If both an application access policy and management role assignment are in effect for the same app, the resulting experience can be a bit confusing. In a nutshell, both sets of restrictions are applied in a logical OR configuration, as detailed in the official documentation .

Once the new role assignment is created, it’s worth running some additional checks to ensure everything is configured as it should be. The best approach would be to test the application itself, but Microsoft has also provided a new cmdlet that should help diagnose some issues, namely Test-ServicePrincipalAuthorization . You run the cmdlet by providing the id of the service principal you want to test, and optionally a resource to test against, such as a mailbox name. Here are some examples:

In summary, the Exchange Online’s RBAC model has been extended to cover some application-specific scenarios, by means of adding support for delegating management roles to service principal objects. Not only this approach unifies the application scenario with the existing RBAC controls, it also addresses the shortcomings of the application access policies feature, which was our only option to restrict application access until now, and adds some additional possibilities on top of it. While the feature is still in preview and there are some rough edges, Microsoft is already planning to address them, and most importantly provide an UI. And, unlike some of the recent announcements on Microsoft side, we’re getting all this for free, without requiring any add-on licenses or new SKUs. Amen.

One last thing before closing – you cannot use exclusive scopes for app permissions. Just in case I’ve neglected to answer some question, here’s a link to the official announcement , as well as the preview documentation . Next, we will look into assigning “regular” management roles to service principal objects, which allows us to limit CBA scenarios, as well as the added support for management scopes based on administrative units. Stay tuned!

5 thoughts on “ ExO RBAC improvements #1: Limiting application access ”

Many thanks for this>

My module does not know -RecipientAdministrativeUnitScope parameter. Any tips? Do I need a preview module perhaps?

As answered over email, -RecipientAdministrativeUnitScope is parameter for the New-ManagementRoleAssignment cmdlet, not New-ManagementScope.

• Pingback: Limiting application access for Security and Compliance Center scenarios - Blog
• Pingback: ExO RBAC improvements #3: Limiting access in CBA scenarios | Blog
• Pingback: ExO RBAC improvements #2: Support for administrative units | Blog

Leave a Reply Cancel reply

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

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

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

SENSASI55 LINK RESMI SITUS SLOT ONLINE INDONESIA

Item added to your cart

SENSASI55 Link Resmi Slot Online dan Togel Online Terpercaya

Couldn't load pickup availability

SENSASI55 provider slot online dan bandar togel nomor 1 di Indonesia, sudah resmi dan terpercaya. Daftarkan diri anda sekarang juga, karena Sensasi55 sedang bagi-bagi bonus langsung khusus 1000 new member tiap bulannya.

• Choosing a selection results in a full page refresh.
• Opens in a new window.

Microsoft 365 Scripts

Microsoft 365 scripts repository.

m365scripts.com

Configure and Manage Outlook Web App Policies

Microsoft Outlook on the w eb ( previously known as Outlook Web App ) is widely used and easily access ible through web browsers to communicate efficiently from anywhere . Configuring Outlook on the w eb mailbox policies is essential to control the availability of settings and features for Outlook users . Every organization has a default mailbox policy named O waMailboxPolicy – Default that is applied to all user mailboxes. Admins can create different policies for v arious types of users. However, remember that a mailbox can have only one O WA mailbox policy.

Managing Outlook on the web mailbox policies can be done through the Exchange admin center (EAC) or PowerShell. Let’s explore the detailed steps of each method.

Manage Outlook Web App Policies Using Exchange Admin Center

Manage outlook web app policies using powershell.

Before proceeding , remember that you need to be assigned the ‘Organization Man a gement’ or ‘Recipient Management’ role group to configure OWA polic ies in Exchange Online. Also, this OWA policy is appl icable for Outlook on the web and new Outlook for Windows users.

By using Exchange a dmin c enter , you can create, configure, and delete Outlook on the w eb mailbox policies efficiently. You can enable or disable features for end users related to communication, security, user experience, time management, etc. , including work hours and location , password change, email signature , and more.

Create OWA Mailbox Policy in Exchange Online

To create a new Outlook on the web policy in Exchange Online, you can follow the steps below.

• Sign in to the Exchange admin center .
• Navigate to Roles–>Outlook web app policies .
• Select the ‘ New OWA policy ’ option.
• Name your policy and click Next .
• In the ‘Features’ page, all the features will be selected by default, except for a few user experience features. You can turn off any feature by unchecking the box based on your needs. Then, click Next .
• On the ‘File Access’ page, you can control how users access and view email attachments. If you don’t want to allow users to access files from public or shared computers, you can uncheck the box and click Next .
• Review the policy and select ‘ Create ’.
• After successful creation, choose ‘ Done ’.

Note: Setting features in the ‘Features’ page will override the Outlook on the web virtual directory settings.

Then, your custom OWA policy will appear on the Outlook web app policies page.

If you want to adjust the org-wide default OWA policy, you can click on the ‘OwaMailboxPolicy-Default’ and choose ‘ Manage features ’ or ‘ Manage access ’ in the right pane to modify the settings. Then, select ‘ Save changes ’ to save your modifications. The same will be applied to custom policy modifications.

Controlling ‘Offline access’ will not be available when creating a new OWA policy. You need to configure Offline access by modifying the policy after creation. By default, Offline access will be set to ‘Always’.

Apply or Remove OWA Mailbox Policy on a Mailbox

To assign or remove an Outlook Web App mailbox policy for single and multiple user mailboxes, do the following steps.

• Navigate to Recipients–> Mailboxes in the EAC.
• To assign or remove the OWA policy for a single mailbox, choose the desired mailbox.
• In the details pane, click ‘ Manage email apps settings ’ under the ‘Email apps & mobile devices’ category in the ‘General tab’.
• Outlook on the web is enabled by default. If you want to assign a custom policy, remove the default OWA policy under ‘ Outlook web app mailbox policy ’.
• Then, type the first letter of your custom policy and select the respective policy from the suggested lists. Click Save to assign the policy to the user.
• To remove or disable the OWA policy for a user, simply move Outlook on the web toggle to disable it on the same page and click Save .
• To assign or remove the OWA policy for multiple mailboxes, select the required mailboxes.
• Select Edit–> App settings .
• Enable Outlook on the web setting.
• Then, type the first letter of the OWA mailbox policy and select it from the suggested list.
• Click Save to assign the policy to the users.
• To remove an OWA policy from multiple users, you can disable Outlook on the web setting on the same page.

Delete OWA Mailbox Policy in Exchange Online

To delete an Outlook on the web mailbox policy using the Exchange admin center, follow the steps below.

• Navigate to Roles–> Outlook web app policies in the EAC.
• Select the desired OWA policy and click Delete .
• Then, select ‘ Confirm ’ in the right pane to give your confirmation for policy deletion.

Note: You can’t select multiple policies and bulk delete using EAC. You need to manually choose each policy and delete them separately .

Though you can view, configure, assign, and delete OWA policy using the Exchange admin center, there are certain drawbacks that admins might get frustrated with.

• Firstly, you can’t assign or remove users while creating the policy itself. You need to select users and remember the policy name to type the first letter for assigning a policy.
• Bulk creation or bulk deletion of OWA policy is not possible using EAC which is truly challenging.

To overcome these challenges, you can go with Exchange Online PowerShell to manage Outlook Web App policies more efficiently. Let’s dive into detail.

Before proceeding, you must connect to Exchange Online PowerShell .

View OWA Mailbox Policy Using PowerShell

To retrieve a summary of all the Outlook W eb A p p po licies available in your organization, run the below cmdlet.

To retrieve detailed information about an OWA policy , run the below cmdlet.

Create an Outlook Mailbox Policy Using PowerShell

To create a mailbox policy for Outlook on the web , run the cmdlet below.

Note: If you create a policy, all the features and access settings are enabled by default. If you want to modify any of them, you can use Set-OwaMailboxPolicy cmdlet.

To modify an OWA policy , you can use the below cmdlet.

You can replace [Settings] with the required parameters and their values you wish to modify. Let’s see how to disable the password change feature below.

Assign or Remove Outlook Mailbox Policy for Bulk Users

When assigning an OWA policy for bulk users, you can assign it to a specific department, or specific mailboxes based on your needs.

Case 1: To assign an OWA policy for users in a specific department , run the below cmdlets. Let’s see how to assign it to your organization’s managers.

The above cmdlets retrieve the managers and assign the specified OWA mailbox policy to them.

Case 2: To assign an OWA policy for specific mailboxes , run the below cmdlets. Before proceeding, you must create a text file with a list of required user accounts.

For bulk removal of OWA policy assignments from users, you can utilize the same cmdlet specified above and modify the value of the “-OwaMailboxPolicy” parameter with $null instead of giving the policy name.

Assign or Remove Outlook Mailbox Policy for Individual Users

To assign an OWA mailbox policy for a single user , you can use the below cmdlet.

To remove an OWA mailbox policy from a user, replace the policy name with $null as shown below.

Remove an OWA Policy Using PowerShell

To remove an Outlook mailbox policy from the organization , use the below cmdlet.

To remove an OWA policy for a specific tenant in your organization, run the below cmdlet.

Note: Confirm attribute is used to avoid getting confirmation for policy deletion.

I hope this blog helps you manage Outlook on the w eb mailbox policies right from creation, assignments, and deletions efficiently. Drop your que ries in the comment section. Happy scripting!

Related Posts: