role assignment policy exchange

Get the Reddit app

A vast community of Microsoft Office365 users that are working together to support the product and others.

role assignment policy

Id like some help with the Role assignment policy in exchange.

Users can now make, delete, add members, leave, certain distribution groups.

I would like them to being able to do that but i dont want people to be able to create and delete distribution groups.

When making the policy there is only an option for off/on and not, i would like them to add and remove people but not edit/make/delete the group itself.

Anyone know if this is fixable with a powershell command or is there a better way of doing this?

Many thanks in advance!

By continuing, you agree to our User Agreement and acknowledge that you understand the Privacy Policy .

Enter the 6-digit code from your authenticator app

You’ve set up two-factor authentication for this account.

Enter a 6-digit backup code

Create your username and password.

Reddit is anonymous, so your username is what you’ll go by here. Choose wisely—because once you get a name, you can’t change it.

Reset your password

Enter your email address or username and we’ll send you a link to reset your password

Check your inbox

An email with a link to reset your password was sent to the email address associated with your account

Choose a Reddit account to continue

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 Commented 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
• Where does Postgres fit in a world of GenAI and vector databases?
• Featured on Meta
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Bringing clarity to status tag usage on meta sites

Hot Network Questions

• DATEDIFF Rounding
• Using Thin Lens Equation to find how far 1972 Blue Marble photo was taken
• Are quantum states like the W, Bell, GHZ, and Dicke state actually used in quantum computing research?
• Should I report a review I suspect to be AI-generated?
• Worth replacing greenboard for shower wall
• What to do when 2 light switches are too far apart for the light switch cover plate?
• My visit is for two weeks but my host bought insurance for two months is it okay
• Using "no" at the end of a statement instead of "isn't it"?
• Is there a phrase for someone who's really bad at cooking?
• Can I use a JFET if its drain current exceeds the Saturation Drain Current from the datasheet (or is my JFET faulty)?
• Parse Minecraft's VarInt
• Command-line script that strips out all comments in given source files
• What would be non-slang equivalent of "copium"?
• How can judicial independence be jeopardised by politicians' criticism?
• How does the summoned monster know who is my enemy?
• Is it possible to have a planet that's gaslike in some areas and rocky in others?
• Regression techniques for a “triangular” scatterplot
• Optimal Bath Fan Location
• Why is PUT Request not allowed by default in OWASP CoreRuleSet
• Using conditionals within \tl_put_right from latex3 explsyntax
• The size of elementary particles
• Why is "on " the optimal preposition in this case?
• Does Vexing Bauble counter taxed 0 mana spells?
• What happens if all nine Supreme Justices recuse themselves?

• Skip to primary navigation
• Skip to main content
• Skip to primary sidebar
• Skip to secondary sidebar

OpenTechTips

Short Guides for IT Enthusiasts

How to Clone a Role Assignment Policy in Microsoft Exchange

November 21, 2020 - by Zsolt Agoston - last edited on January 30, 2021

This script is for cloning a Role Assignment Policy in Exchange.

For example, if you want to allow certain users to add/remove members to the distribution groups they own, you need to enable the "MyDistributionGroups" option in the role assignment policy that is assigned to the user mailboxes, but you probably don't want to alter the default one.

This case it's simple to clone the default policy, make changes to that cloned version and assign it to only those mailboxes that needs it.

Now you can edit the new policy and assign it as needed with the Set-Mailbox -RoleAssignmentPolicy cmdlet.

Reader Interactions

Comments 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.

To provide the best experiences, we and our partners use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us and our partners to process personal data such as browsing behavior or unique IDs on this site and show (non-) personalized ads. Not consenting or withdrawing consent, may adversely affect certain features and functions.

Click below to consent to the above or make granular choices. Your choices will be applied to this site only. You can change your settings at any time, including withdrawing your consent, by using the toggles on the Cookie Policy, or by clicking on the manage consent button at the bottom of the screen.

Allow Users To Manage Distribution Groups Without Creating New Ones–Exchange 2013 Redux

In a previous Exchange 2010 post we discussed a scenario where users were delegated the capability to create Mail Enabled Contacts in Active Directory using a custom Role Based Access Control ( 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.

How can we solve the challenge of allowing users to managed Distribution Groups that they own, but also prevent them from removing them or adding new ones?  Well, it’s a similar story to the previous blog – we will create a custom RBAC Role!  This was covered in a previous post for Exchange 2010 , and this blog entry will focus upon Exchange 2013.  The process is the same, screenshots have been updated to reflect Exchange 2013.

Exchange admins are generally familiar with RBAC that relates to their administrative activities.  This is managed via Management Roles.  One thing that is a little different is that the RBAC configuration for items related to users managing their 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.  Multiple Role Assignment Policies may be present within an Exchange organisation.  A mailbox can only have a single Role Assignment Policy assigned at any given time.  You may want to have multiple Role Assignment Policies to address business requirements.  If not explicitly called out, then mailboxes will pick up the default Role Assignment Policy when created or moved from Exchange 2007 to Exchange 2010/2013.

The scenario for this post is that we want to have three levels of delegated end-user management for distribution groups.  This is typical within larger businesses.  There will be users who will edit absolutely no distribution groups.  A separate collection of users can edit the distribution groups that they own, and finally a smaller group of users who are able to edit/create/remove owned distribution groups.  If the vase majority of users fall into the first category and can edit zero distribution groups, then we can simply use the default Role Assignment Policy for that purpose.  Then as noted here , we will need to create a Role Assignment Policy to allow creation/removal of owner distribution groups.  We also need to created a third Role Assignment Policy, and that is the purpose of this post.

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 the Role Assignment Policy which allows editing existing distribution groups.

This is a simple test lab with one DC, one Exchange 2013 CAS server and one Exchange 2013 mailbox server.  Just to prove that this has been working out of the gate, the lab was provisioned with Exchange 2013 RTM.  After testing completed it was upgraded to Exchange 2013 CU8 to validate behaviour.  Note that at this time Exchange 2013 RTM/CU1/CU2/CU3 are not supported , and you must be on a recent update.

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's roles to a PowerShell variable.  We 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.

The $Roles variable now contains the following Roles:

MyTeamMailboxes MyDistributionGroupMembership My Marketplace Apps MyBaseOptions MyContactInformation MyTextMessaging MyVoiceMail

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

Create Custom Management Role

All the Management Roles that can be assigned to a Role Assignment Policy  are typically prefixed with “My” to indicate that they are for end-user RBAC.  To achieve our desired results, we need to work with the Management Role called MyDistributionGroups .

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 discussed in the RBAC Primer article , the built-in RBAC roles are read only so we need to make a writable copy.  This is what we are doing with the New-ManagementRole cmdlet, note that we specify the parent role so it knows what it is copying, and this is remembered.

New-ManagementRole -Name "Edit-Existing-DG-Only"  -Parent MyDistributionGroups -Description "Can edit existing Distribution Groups only"

Update 9-11-2016   Added the -Description parameter based on comment feedback.  Upto you if you want to use it or note.

Once we have our writeable Management Role Edit-Existing-DG-Only , we can edit it to remove the New-Distributiongroup and Remove-DistributionGroup cmdlets.  The removal is done using the Remove-ManagementRoleEntry cmdlet.

If we now check to see what cmdlets are contained in the Edit-Existing-DG-Only Management Role, the ones we removed are no longer present.

Note there is no New-DistributionGroup cmdlet listed.

If we compare this to the original read only Management Role, MyDistributiongroups, we can see that the New-DistributionGroup and Remove-DistributionGroup cmdlets remain there as we are unable to remove them.  That is why we made a new Management Role, so we could edit it.

Now that we are happy with the contents on the new Management Role, lets assign it to our new Role Assignment Policy.

Assigning New Management Role To Role Assignment Policy

To  assign this custom Management Role to our new Role Assignment Policy we can use either PowerShell or Exchange Admin Center.

Exchange Admin Center

In EAC, navigate to the Permissions, then User Roles section.  Edit the new Role Assignment Policy called DG-Management.  Initially it should look like the below image (assuming that you did not already use PowerShell to assign the Management Role.

Select only the Edit-Existing-DG-Only Management Role.  This is the one highlighted in the image below.

Hit save to commit the change.

Now that we have created a new Role Assignment Policy, Created a custom Management Role and assigned the custom management role it is time to test it out.

We will assign the new Role Assignment Policy to a test mailbox.

Assigning Custom Role Assignment Policy To Test Mailbox

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.

We can assign the Role Assignment Policy via PowerShell or Exchange Admin Center.

Open up the properties of the test mailbox, and go to the Mailbox Features section.  In the Role Assignment Policy dropdown, select the DG-Management policy.

Testing & Validation

Now that user-1 has been explicitly assigned the Role Assignment Policy DG-Management , we can open up the EAC as that user and review the options presented to user-1.

When user-1 opens up the EAC, they have the below capabilities.  Note that there is no New or Delete button under “Public Groups That I Own”.  This is the red highlight box.

Thus, they are not able to create or delete distribution groups.  The above screenshot was from the RTM build of Exchange 2013.  After upgrading the CAS and Mailbox servers in this lab to CU8 the behaviour is the same.

When the above screenshots were taken, user-1 was not the manager of any distribution groups so the groups that I own pane was empty.  After creating a new distribution group called DG-1, and assigning user-1 as the owner, this group then appears in the groups that I own pane.  This is indicated with the red arrow below:

Reference – Default Role Assignment Policy With MyDistributionGroups Enabled

Just as a reference to compare the screens above, let’s remind ourselves what simply adding the MyDistributionGroups Management Role to the default Role Assignment Policy looks like.  First we switch the user back to the default Role Assignment Policy, and then add

Logging back on to EAC, note that there is now a plus and delete icon. This is displayed as the New-Distributiongroup and Remove-DistributionGroup cmdlets are present in the MyDistributionGroups Management Role.

Command Reference

All the commands used to create the DG-Management Role Assignment Policy are listed here for simplicity.  The Role Assignment Policy is called DG-Management and the custom management role is called Edit-Existing-DG-Only

Note On Assigning Role Assignment Policies

If you do not explicitly state which Role Assignment Policy should be used when creating  or moving a mailbox to Exchange 2010/2013 from Exchange 2007, Exchange will use the one marked as default.  Note it is not necessarily the one called “Default Role Assignment Policy”.  That 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 custom Role Assignment Policy that you want 95% of the users to have since it’s your base standard, then you can mark the custom one as the default.  The one called default is no longer the default.  That’s all a bit zen, no?

For example:

Rhoderick Milne [MSFT]

Rhoderick, I came across this very need to allow group owners to modify their groups, while not being able to create new groups or remove current groups. I have followed your example, and may I say it worked like a charm. The caveat to this is I was hoping to tighten the permissions even more. I am hoping to restrict all distribution group management to strictly membership control. Meaning allow owners to add/remove users to the group, but nothing else. No changing of the alias, displayname, delivery options, etc. In my new role "Restricted-DG-Management" in which I copied the items from the MyDistributionGroups to get the full list of Management Role Entries. I then did the following very meticulously: Removed... New-DistributionGroup Entry (Removed the "+" icon from OWA) Removed... Remove-DistributionGroup Entry (Removed the "Trash" icon from OWA) Removed... Set-Group Entry (Greyed some fields - but that is it, but not all) Removed... Set-DynamicDistributionGroup Entry (did nothing, but none of my dynamic groups will have owners so I'm removing it anyway) Removed... Set-DistributionGroup Entry. This is where it all went down hill. I no longer had ANY visibility of the "Groups I Own" at all within OWA so that I could edit them. I now only have the "Distribution Groups I Belong To" section. I can easily back out of this by removing the new role and what not, but that isn't my "concern".

For each management role entry I removed, I noted the cmdlet parameters that was associated.

As it stands, not being able to modify membership via OWA but strictly through Outlook isn't the "worst" solution, but I was just wondering if what I am trying to achieve is even possible.

Can we use RBAC to restrict group management to just group membership? I do NOT want users to be able to change email addresses, names, alias or anything other than who is in the group.

Using Exchange 2016. I appreciate your time.

But this is totally possible, guys! Just remove the specific Parameters from the specific ManagementRoleEntry, eg.:

Set-ManagementRoleEntry MyDistributionGroupsEditMembersOnly\Set-DistributionGroup -Parameters "Alias" -RemoveParameter

...will remove the availability of "Alias" parameter and in most cases will gray out the related edit field in GUI (DisplayName being so far the only one not being grayed out; still throws an error when you click "Save").

I've run into the same issue...currently have an open ticket with Microsoft about it but I'm not optimistic about a solution!

Yea I am not optimistic either. It seems a very particular/specific set of permissions that I could see as a very real request, but maybe not one so largely practiced that MS has invested any time into it. I would love to hear how it goes for you.

For reference, these are the permissions that remain on my new custom management role, unfortunately it seems like the permissions can't be accessed/utilized in OWA because the Set-DistributionGroup entry was removed.

Add-DistributionGroupMember Get-DistributionGroup Get-DistributionGroupMember Get-EligibleDistributionGroupForMigration Get-Group Get-Recipient Remove-DistributionGroupMember Update-DistributionGroupMember

As predicted Microsoft's answer was "It's behaving as designed." So for some reason they think it's reasonable that an owner should also be able to edit all the properties of a DG as well as the membership!

I've been spending some time trying to find a third party application that provides a friendly web interface to do this while limiting the permissions of the owner. Unfortunately the only one I've found designed specifically for this is being sold by a company that isn't responding to my requests for a demo. All others are part of a larger identity management solution as a value add.

Thanks for the update Jay. It is quite frustrating, but as you said, it is a predicted response. 🙁 I also have done some research on how this could be doable, and also found it to be bundled in ID management products - more unfortunate news as we won't be going that route. Thanks again!

I’ve been spending some time trying to find a third party application that provides a friendly web interface to do this while limiting the permissions of the owner.

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.

MSExchangeGuru.com

Learn Exchange the Guru way !!!

• Contact us -MS Exchange Guru
• MSExchangeGuru on YouTube

Role Based Access Control in Exchange 2013

Role Based Access Control model (RBAC) was introduced in Exchange server 2010 as a permission model where administrator doesn’t require modifying and managing the access control list (ACLs) with ADUC like in legacy versions.

In 2013, RBAC allows us to control both administrator and end users tasks. Using RBAC we can assign the roles to administrators and users, depending on the roles they hold in the organization.

RBAC has two primary and one advanced method to assign the permissions as below:

• Management Role groups
• Management Role Assignment Policies
• Direct User Role assignment

Management Role Groups:

Management Role Group is a Universal Security group used in RBAC permission model to assign the major administrative rights to Administrators and specialist users such as organization management, recipient management etc in exchange 2013.

Components of Role Groups which defines what Administrator/specialist users can do:

• Management Role Group: This is a Special USG where we can add/remove members. And we can assign the roles on it.
• Management Role: This is a container of the management Role entries which defines the task.
• Management Role Assignment: This is a link between management role and assignee.
• Management Role Scope: Defines the scope of impact of a management role in a role assignment.

Management Role Assignment Policies:

Management Role Assignment Policies are related to end user permissions. This includes what an end user can do with their mailbox, distribution list, setup voice mail, configure inbox rules etc. Every user in Exchange 2013 including Administrator assigned with a default Role assignment Policy. We can modify the default Role assignment policies and decide what it should include and whom to assign.

Direct User Role Assignment:

Direct User Role assignment is an advanced, where in we can assign the management roles directly to a user or USG without using Role groups or Role assignment policies. This is little complex as we need to assign this individually.

Exchange 2013 includes approximately 86 roles that you can use to grant permissions. Refer http://technet.microsoft.com/en-IN/library/dd638077(v=exchg.150).aspx to find the list of built in roles.

We will see how Create role groups in Exchange 2013:

Open EAC à Permissions à Admin Roles à Click on + and select New

Provide the Name, Roles that group members can handle and members for the group and finish.

We will see how to create the Management Role Assignment Policies in Exchange 2013:

Open EAC à Permissions à User Roles à Click on + and select New

Provide the Name, description and we can select what are the permission needs to be provided to the end users by selecting the available options as below and Save:

Ratish Nair

Microsoft MVP | Exchange Server

Posted August 13th, 2014 under Exchange 2013 . RSS 2.0 feed. Leave a response , or trackback .

4 Responses to “Role Based Access Control in Exchange 2013”

[…] Role Based Access Control in Exchange 2013 – […]

Hi everyone, it’s my first pay a quick visit at this site, and piece of writing is in fact fruitful designed for me, keep up posting such articles or reviews.

Thank you Micah

Leave a Reply

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

Recent Comments

• Exchange 2016: URLs Configuration Script « MSExchangeGuru.com on Exchange 2013: URLs Configuration Script
• [Exchange 2016] Débloquer un lot de migration en « synchronisation » on Exchange Hybrid: Batch Migration
• Sysadmin Today #38: Email Security on Exchange 2016 Anti-Spam configuration
• Exchange 2016 Dynamic distribution Group returning all users using filter RecipientContainer « MSExchangeGuru.com on Create Dynamic distribution Groups in Exchange 2016
• Monthly IT Newsletter – November 2017–January 2018 – Guy UC World on How to Use Task Scheduler to schedule PowerShell Scripts
• Collab365 Global Conference November 1st 2017
• Global Azure Boot Camp 2018 – April 21, 2018
• Los Angeles Microsoft Exchange Server User Group – 3rd Thursday of the Month

Other cool places

• Flipping Bits
• Lets Exchange
• MSExchangeTeam
• PowerWindows

Theme by BytesForAll

This browser is no longer supported.

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

Exchange Server permissions

• 11 contributors

Microsoft Exchange Server includes a large set of predefined permissions, based on the Role Based Access Control (RBAC) permissions model, which you can use right away to easily grant permissions to your administrators and users. You can use the permissions features in Exchange Server so that you can get your new organization up and running quickly.

Disabling permissions inheritance on Active Directory (AD) objects, in an AD domain that is prepared to host Exchange, isn't supported. The removal of Exchange-related permissions on AD objects will cause Exchange tasks and functions to break or may lead to unknown issues.

Role-based permissions

In Exchange Server, the permissions that you grant to administrators and users are based on management roles. A role defines the set of tasks that an administrator or user can perform. For example, a management role called Mail Recipients defines the tasks that someone can perform on a set of mailboxes, contacts, and distribution groups. When a role is assigned to an administrator or user, that person is granted the permissions provided by the role.

There are two types of roles, namely administrative roles and end-user roles:

Administrative roles : These roles contain permissions that can be assigned to administrators or specialist users using role groups that manage a part of the Exchange organization, such as recipients, servers, or databases.

End-user roles : These roles, assigned using role assignment policies, enable users to manage aspects of the mailbox and distribution groups that they own. End-user roles begin with the prefix My .

When the roles are assigned to administrators and users, it gives them the permissions to perform tasks by making cmdlets available for them. Because the Exchange admin center (EAC) and the Exchange Management Shell use cmdlets to manage Exchange, granting access to a cmdlet gives the administrator or user the permission to perform the task in each of the Exchange management interfaces.

Role groups and role assignment policies

Roles grant permissions to perform tasks in Exchange Server, but you need an easy way to assign the roles to administrators and users. Exchange Server provides you with the following methods to help you do that:

Role groups : Role groups enable you to grant permissions to administrators and specialist users.

Role assignment policies : Role assignment policies enable you to grant permissions to end users to change settings on the mailbox or distribution groups that they own.

For more information about role groups and role assignment policies, see the following sections.

Role groups

Every administrator that manages Exchange Server needs to be assigned at least one or more roles. Administrators might have more than one role because they may perform job functions that span multiple areas in Exchange. For example, one administrator might manage both recipients and Exchange servers. In this case, that administrator might be assigned both the Mail Recipients and Exchange Servers roles.

To make it easier to assign multiple roles to an administrator, Exchange Server includes role groups. Role groups are special universal security groups (USGs) used by Exchange Server that can contain AD users, USGs, and other role groups. When a role is assigned to a role group, the permissions granted by the role are granted to all the members of the role group. This feature enables you to assign many roles to many role group members at once. Role groups typically encompass broader management areas, such as recipient management. They're used only with administrative roles, and not with end-user roles.

It's possible to assign a role directly to a user or USG without using a role group. However, that method of role assignment is an advanced procedure and isn't covered in this topic. We recommend that you use role groups to manage permissions.

The following figure shows the relationship between users, role groups, and roles.

Roles, role groups, and role group members

Exchange Server includes several built-in role groups, each one providing permissions to manage specific areas in Exchange Server. Some role groups may overlap with others. The following table lists each role group with a description of its use. If you want to see the roles assigned to each role group, click the name of the role group in the "Role group" column, and then go to the "Management Roles Assigned to This Role Group" section.

If an administrator is a member of more than one role group, Exchange Server grants the administrator all the permissions provided by those role groups.

Built-in role groups

If you work in a small organization that has only a few administrators, you might only ever use the Organization Management role group, and none of the other role groups. If you work in a larger organization, you might have administrators who perform specific tasks administering Exchange, such as recipient or server management. In those cases, you might add one administrator to the Recipient Management role group, and another administrator to the Server Management role group. Those administrators can then manage their specific areas of Exchange Server but won't have permissions to manage areas they're not responsible for.

If you can't find a built-in role group that fits the jobs your administrators need to do, you can create role groups and add roles to them. For more information, see Work with role groups later in this topic.

Role assignment policies

Exchange Server provides role assignment policies so that you can control what settings your users can configure on the mailboxes and distribution groups they own. These settings include their display name, contact information, voice mail settings, and distribution group membership.

Your Exchange Server organization can have multiple role assignment policies that provide different levels of permissions for the different types of users in your organizations. Some users can be allowed to change their address or create distribution groups, while others can't. It all depends on the role assignment policy associated with their mailbox. Role assignment policies are added directly to mailboxes, and each mailbox can only be associated with one role assignment policy at a time.

Of the role assignment policies in your organization, one is marked as default. The default role assignment policy is associated with new mailboxes that aren't explicitly assigned a specific role assignment policy when they're created. The default role assignment policy should contain the permissions that should be applied to the majority of your mailboxes.

Permissions are added to role assignment policies using end-user roles. End-user roles begin with My and grant permissions for users to manage only the mailbox or distribution groups they own. They can't be used to manage any other mailbox. Only end-user roles can be assigned to role assignment policies.

When an end-user role is assigned to a role assignment policy, all of the mailboxes associated with that role assignment policy receive the permissions granted by the role. Therefore, you can add or remove permissions to sets of users without having to configure individual mailboxes. The following figure shows that:

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.

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.

Roles, role assignment policies, and mailboxes

The Default Role Assignment Policy is included with Exchange Server. As the name implies, it's the default role assignment policy. If you want to change the permissions provided by this role assignment policy, or if you want to create role assignment policies, see Work with role assignment policies later in this topic.

Work with role groups

To manage your permissions using role groups in Exchange Server, we recommend that you use the Exchange admin center (EAC). When you use the EAC to manage role groups, you can add and remove roles and members, create role groups, and copy role groups with a few clicks of your mouse. The EAC provides simple dialog boxes, such as the new role group dialog box, shown in the following figure, to perform these tasks.

New role group dialog box in the EAC

If none of the role groups included with Exchange Server have the permissions you need, you can use the EAC to create a role group and add the roles that have the permissions you need. For your new role group, you'll need to:

Choose a name.

Select the roles you want to add.

Add members.

After you create the role group, you manage it like any other role group.

If there's an existing role group that has some, but not all, of the permissions you need, you can copy it and then make changes to create a role group. Copying an existing role group lets you make changes to it without affecting the original role group. As part of copying the role group, you can add a new name and description, add and remove roles to and from the new role group, and add new members. When you create or copy a role group, you use the same dialog box that's shown in the preceding figure.

Existing role groups can also be modified. You can add and remove roles from existing role groups, and add and remove members from it at the same time, using an EAC dialog box similar to the one in the preceding figure. By adding and removing roles to and from role groups, you turn on and off administrative features for members of that role group.

Although you can determine which roles are assigned to built-in role groups, we recommend that you copy built-in role groups, modify the role group copy, and then add members to the role group copy.

Work with role assignment policies

To manage the permissions that you grant end users for them to manage their own mailbox in Exchange Server, we recommend that you use the EAC. When you use the EAC to manage end-user permissions, you can add roles, remove roles, and create role assignment policies with a few clicks of your mouse. The EAC provides simple dialog boxes, such as the role assignment policy dialog box, shown in the following figure, to perform these tasks.

Role assignment policy dialog box in the EAC

Exchange Server includes a role assignment policy named Default Role Assignment Policy. This role assignment policy enables users whose mailboxes are associated with it to do the following:

Join or leave distribution groups that allow members to manage their own membership.

View and modify basic mailbox settings on their own mailbox, such as Inbox rules, spelling behavior, junk mail settings, and Microsoft ActiveSync devices.

Modify their contact information, such as work address and phone number, mobile phone number, and pager number.

Create, modify, or view text message settings.

View or modify voice mail settings.

View and modify their marketplace apps.

Create team mailboxes and connect them to Microsoft SharePoint lists.

If you want to add or remove permissions from the Default Role Assignment Policy or any other role assignment policy, you can use the EAC. When you open the role assignment policy in the EAC, select the checkbox next to the roles you want to assign to it or clear the checkbox next to the roles you want to remove. The change you make to the role assignment policy is applied to every mailbox associated with it.

If you want to assign different end-user permissions to the various types of users in your organization, you can create role assignment policies. You can specify a new name for the role assignment policy, and then select the roles you want to assign to the role assignment policy. After you create a role assignment policy, you can associate it with mailboxes using the EAC.

If you want to determine which role assignment policy is the default, you need to use the Exchange Management Shell. When you change the default role assignment policy, any mailboxes that are created will be associated with the new default role assignment policy if one wasn't explicitly specified. The role assignment policy associated with existing mailboxes doesn't change when you select a new default role assignment policy.

If you select a checkbox for a role that has child roles, the checkboxes for the child roles are also selected. If you clear the checkbox for a role with child roles, the checkboxes for the child roles are also cleared.

For detailed steps about how to create role assignment policies or make changes to existing role assignment policies, see the following topics:

Manage role assignment policies

Change the assignment policy on a mailbox

Additional resources

Traditional approaches to IT governance like network-based discovery, blocking, & lengthy approval processes have proven ineffective.

Expert Techniques to Protect and Preserve Your System and Backup Integrity with Security MVP Viktor Hedberg

The power of email signatures—a critical marketing and sales tool—is often overlooked, leaving employees to manually update their own, risking brand inconsistency.

Stop OWA Users Autoforwarding Email

Published: May 05, 2020

• Microsoft 365
• Exchange Online

SHARE ARTICLE

Autoforwarding is badness.

Allowing users to forward their email outside Exchange Online is bad, especially if they don’t keep a copy of the forwarded messages in their mailbox. Apart from removing email from the controls imposed by data governance policies, it creates a risk that confidential information travels outside the organization, including when an attacker hacks into a mailbox and set forwarding on without the knowledge of the mailbox owner. This is done to understand the traffic that the hacked user receives in preparation to execute a business email compromise attack .

In this two-part series, I first look at how to restrict OWA users from creating autoforward addresses using RBAC. The second article describes some other blocks that apply to all clients to stop email leaking from the organization.

Who’s Autoforwarding?

Forwarding is a server function, so once a user sets up a forwarding address in OWA, any email coming into the mailbox is forwarded. To find out if mail is currently being forwarded, run the command:

You can take steps to resist attacks by coaching users, but it’s better to cut off the ability to forward email. We can do this by creating a new user role assignment policy that doesn’t include the cmdlet parameters needed by a user to create an autoforward.

How to Set an Autoforward Address

The OWA option to autoforward messages from Exchange Online (or on-premises) is in the Mail section of OWA Settings (Figure 1).

After an autoforward address is set, OWA informs the user in what’s now called the OWA Account Manager in the menu bar (Figure 2).

Role Based Access Control and Exchange

The new OWA boasts an enhanced interface, and the Role-Based Access Control (RBAC) mechanism that’s existed since Exchange 2010 underpins that sparkling new appearance, just like it does the Exchange Admin Center (EAC).

RBAC works by enabling access to PowerShell cmdlets and their parameters. If you can’t run a cmdlet or pass a value in a parameter, you lose access to a feature. The role assignment policy applied to a mailbox is composed of a set of roles, each of which control access to one or more features. Clients like OWA use RBAC to know when a feature is available to a user. If their mailbox is blocked from a feature because the assigned policy doesn’t include the right access, the user doesn’t display the feature. It’s a simple and effective system. At least, it is in concept.

You can create and assign user role assignment policies through the Permissions section of EAC. The UI works well if you want to exclude a big chunk of functionality like the ability to select personal retention tags. It doesn’t allow you to trim functionality more surgically, such as allowing people to manage distribution lists that they own while removing the ability to create new lists. PowerShell must be used to make these kinds of changes.

Create a New RBAC Role

RBAC for Exchange Online works based on restricting users to being able to run cmdlets down to the parameter level. Administrators can run all cmdlets and all parameters because of the roles they hold. Normal users have a more restricted set of role assignments, so they can do less. For example, to set up an autoforward address in PowerShell, you run the Set-Mailbox cmdlet using a command like:

Therefore, to stop users being able to create an autoforward address, we need to remove the ability to run the Set-Mailbox cmdlet with the ForwardingSmtppAddress parameter.

The first step to implement a block with RBAC is to create a new management role using the existing MyBaseOptions role as a template. This means that all the options supported in MyBaseOptions , including the ability to set up an autoforward address, are inherited by the new role.

Disabling Cmdlet Parameters in a Role

We don’t want to remove all access to Set-Mailbox because this cmdlet is used to manage other settings like setting an out-of-office notification, but we want to disable access to the parameters used in the OWA option. Here’s how to remove the two parameters from the cmdlet in the options allowed in the new management role.

Creating a Role Assignment Policy

We now have a tailored role and need to combine it with the other roles that users typically receive in a user role assignment policy to create a new policy. This command creates a new user role assignment policy that combines the base roles and our customized role.

Note: If the basic roles have been updated, those changes are carried forward into the new policy. You can check the assignments by opening the policy in EAC (Figure 3).

The alternative approach is to update the default user role assignment policy through EAC so that it looks like Figure 3. The downside is that such a change will affect every mailbox to which the policy is assigned (often every mailbox in the organization). You might not want to do this, which is why a new policy might be the best option.

Applying the New User Role Assignment Policy

User role assignment policies are applied to mailboxes by running the Set-Mailbox cmdlet. Here we assign the policy to one mailbox.

It takes a little while before the new policy is effective. When it is, the user won’t be able to set a forwarding address because OWA will note the policy doesn’t include the necessary cmdlet parameters and will suppress the UI (Figure 4).

PowerShell makes it easy to assign policies to large numbers of mailboxes at one go. Here we find the set of mailboxes that have an autoforward address and assign the new policy to them. At the same time, we remove the existing autoforward address to prevent any other messages flowing outside the organization. This is an important step because the assignment of the policy disables the ability to set new forwards. It does nothing to remove any existing forwarding addresses.

At this point, it would probably be a good idea to send a polite note to the owners of the affected mailboxes to tell them the good news that email will remain inside the organization.

As a final check, to discover what mailboxes have our new policy, run:

If necessary, an administrator can reset the autoforward on the mailbox by running Set-Mailbox (example below) or by updating the mailbox through EAC . RBAC doesn’t apply in these administrative contexts.

Part One of the Solution

Stopping OWA users creating autoforwarding addresses is a good first step in preventing automatic forwarding of messages outside the organization. However, it’s only the first step. Other clients and applications have their own ways to automate forwarding, so it’s important to take a coherent approach to the problem.

The next step is to consider what other barriers can be erected to stop automatic forwarding. That’s in article 2 of this series.