Stop OWA Users Autoforwarding Email

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:

Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {ForwardingSmtpAddress -ne $Null} -ResultSize Unlimited | Format-Table DisplayName, ForwardingSmtpAddress, DeliverToMailboxAndForward -AutoSize

DisplayName                   ForwardingSmtpAddress         DeliverToMailboxAndForward
-----------                   ---------------------         --------------------------
Vasil Michev (Technical Guru) smtp:[email protected]                              True
Ståle Hansen                  smtp:[email protected]                      True
Eoin Redmond                  smtp:[email protected]

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

Image 1 Expand
Forwarding Option OWA
Figure 1: Forwarding option in OWA Settings (image credit: Tony Redmond)

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

Image 2 Expand
OWA Forwarding On
Figure 2: OWA tells the user that forwarding is on (image credit: Tony Redmond)

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:

Set-Mailbox -Identity Kim.Akers -ForwardingSmtpAddress [email protected] -DeliverToMailboxAndForward $True

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.

New-ManagementRole MyBaseOptions-NoForward -Parent MyBaseOptions

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.

Set-ManagementRoleEntry MyBaseOptions-NoForward\Set-Mailbox -RemoveParameter -Parameters DeliverToMailboxAndForward, ForwardingSmtpAddress

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.

New-RoleAssignmentPolicy -Name PolicyWithNoEmailForward -Roles MyContactInformation, MyRetentionPolicies, MyMailSubscriptions, MyTextMessaging, MyVoiceMail, MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation, MyBaseOptions-NoForward -Description "User role assignment policy that restricts the assignees from being able to autoforward email outside the organization"

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

Image 3 Expand
OWA RBAC Policy
Figure 3: Details of the new user role assignment policy (image credit: Tony Redmond)

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.

Set-Mailbox -Identity James.Ryan -RoleAssignmentPolicy PolicyWithNoEmailForward

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

Image 4 Expand
OWA No Forward
Figure 4: No forwarding option is available in OWA settings (image credit: Tony Redmond)

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.

Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {ForwardingSmtpAddress -ne $Null} |
Set-Mailbox -RoleAssignmentPolicy "PolicyWithNoEmailForward" -ForwardingSmtpAddress $Null -DeliverToMailboxAndForward $False

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:

Get-mailbox -RecipientTypeDetails UserMailbox | ?{$_.RoleAssignmentPolicy -eq "PolicyWithNoEmailForward"} | Format-Table DisplayName, RoleAssignmentPolicy

DisplayName                   RoleAssignmentPolicy
-----------                   --------------------
Kim Akers                     PolicyWithNoEmailForward
Vasil Michev                  PolicyWithNoEmailForward
Ståle Hansen                  PolicyWithNoEmailForward
Eoin Redmond                  PolicyWithNoEmailForward

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.

Set-Mailbox -Identity Kim.Akers -ForwardingSmtpAddress [email protected] -DeliverToMailboxAndForward $True

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.