Stopping Users Updating OWA Autosignatures

Don’t Mess with Your Corporate Autosignature

On February 20, I wrote about the topic of generating corporate auto-signatures for OWA. It is easy to create good-looking autosignatures and store them in user mailboxes for OWA to apply (Outlook is a different proposition). The logical question that follows is how to stop users changing their corporate-generated autosignature?

Historically, Role-based access control (RBAC) has been the go-to method when control is needed over an OWA feature. Microsoft introduced RBAC to Exchange 2010 as the control mechanism for access to features. RBAC is used today in both Exchange Online and Exchange on-premises and variations are used to control access to options in admin portals like the Microsoft 365 admin center and Microsoft 365 compliance center.

OWA and RBAC

Settings in a user role assignment policy control the elements of the user interface OWA displays to mailboxes covered by the policy. Basically, if the policy allows OWA to display the user interface for users to edit and save their autosignature, they see the option in OWA settings (Figure 1). But if we change the policy to remove the ability to update signatures, they won’t.

User Role Assignment Policies

Office 365 tenants come with an out-of-the-box user role assignment policy (called “Default Role Assignment Policy”) which enables access to all OWA settings. Mailboxes are assigned this policy by default unless an administrator changes the assignment.

You can edit the default role assignment policy to remove access to autosignatures, but it’s usually a better idea to create a new role assignment policy and edit that, just in case you make a mistake and remove access some features that you want to keep.

Tailoring Roles

Before we create a new policy, we must create a new RBAC role to block autosignatures. Exchange breaks down the ability of users to access OWA features into a set of roles, assembled to form a policy. Each role is composed of a set of role entries. Think of a role entry as a definition of a PowerShell cmdlet and its parameters. Once a user is assigned a role, they can run the cmdlets defined in the role entries. For instance, if a role entry includes the Set-Mailbox cmdlet and some (but maybe not all) of its parameters, the user can run Set-Mailbox and use the set of allowed parameters. They run the cmdlet by using an OWA option or in PowerShell.

The connection between RBAC and cmdlets means that we must know what cmdlet is used to update autosignatures if we want to block it. As explained in my previous article, the Set-MailboxMessageConfiguration and several of its parameters are used to manipulate autosignatures. To stop users updating autosignatures, we must remove their access to those parameters.

Creating a Customized Role

The two commands shown below create a new management role based on the out-of-the-box MyBaseOptions role (which control many OWA settings). The new management role inherits all the settings from MyBaseOptions, so we then amend the settings by removing the parameters used by Set-MailboxMessageConfiguration to update autosignatures.

New-ManagementRole MyBaseOptions-NoSignatures -Parent MyBaseOptions

Set-ManagementRoleEntry MyBaseOptions-NoSignatures\Set-MailboxMessageConfiguration -Parameters AutoAddSignature, AutoAddSignatureOnReply,AutoAddSignatureOnMobile, SignatureTextOnMobile, SignatureText, SignatureHtml, UseDefaultSignatureOnMobile -RemoveParameter

When users are assigned a policy containing the customized role, they will be unable to update signatures. However, we need to take one more step to stop OWA displaying the user interface for signatures. We do this by removing the right to run the Get-MailboxMessageConfiguration cmdlet. Without this cmdlet, OWA can’t fetch details of existing autosignature settings from the mailbox. Here’s the code to remove the entry from the role:

Remove-ManagementRoleEntry MyBaseOptions-NoSignatures\Get-MailboxMessageConfiguration

Creating a New User Role Assignment Policy

To make the new role effective, we must include it in a user role assignment policy and assigned to mailboxes. This code creates a new policy composed of our customized role and all the other default roles normally assigned to users through a policy. For instance, the MyProfileInformation role allows users to edit details of their profile while MyDistributionGroups allows users to create and edit distribution lists.

New-RoleAssignmentPolicy -Name PolicyWithNoSignatures -Roles MyContactInformation, MyRetentionPolicies, MyMailSubscriptions, MyTextMessaging, MyVoiceMail, MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation, MyBaseOptions-NoSignatures -Description "User Role Assignment Policy to block users editing autosignatures"

Assign to Mailboxes

We can now apply our new user role assignment policy to mailboxes for testing. This is done by running the Set-Mailbox cmdlet:

Set-Mailbox -Identity Kim.Akers -RoleAssignmentPolicy PolicyWithNoSignatures

To check the set of mailboxes assigned the new policy, run:

Get-Mailbox |? {$_.RoleAssignmentPolicy -eq "PolicyWithNoSignatures"}

Testing that OWA Respects the Block

The block should become effective 15 minutes or so after the mailbox is updated with the new role assignment policy. Log into the mailbox with OWA and open the options pane. Select the View all Outlook settings link to open the fly-out window with access to all settings and go to the Compose and reply section. You should see that OWA can no longer edit the autosignature settings (Figure 2).

The Downside of Removing the Get-MailboxMessageConfiguration Cmdlet

Eagle-eyed readers will notice that some other settings have disappeared from the Compose and reply section. This is because the Get-MailboxMessageConfiguration cmdlet returns many settings like the message format to use for new messages, the font and font size to use, and the color of text. Settings are also affected in other sections, like Layout (message organization). When you remove the ability of a user to run Get-MailboxMessageConfiguration, they lose access to everything the cmdlet returns, not just autosignatures.

The same problem would not arise if OWA used Set-MailboxMessageConfiguration to control the display of the autosignature setting. Set-MailboxMessageConfiguration is a granular cmdlet with individual parameters to control different settings, so you can trim parameters to control access to specific settings.

OWA Mailbox Policy Solves the Problem

Although RBAC doesn’t work as well as expected, OWA mailbox policies are another way to tackle the problem. OWA mailbox policies control many (but not all) aspects of how the client work. You can work with OWA mailbox policies through the Permissions section of the Exchange admin center (EAC) or PowerShell. Figure 3 shows how to disable autosignatures by unchecking the email signature box in the features section of a policy. You can either update an existing OWA mailbox policy or create a new one (better for testing).

If you want to use PowerShell, you need to set SignaturesEnabled to $False in the policy. Here’s how to create and update an OWA mailbox policy with PowerShell:

New-OWAMailboxPolicy -Name "Block Access to autosignatures"
Set-OWAMailboxPolicy -Identity "Block Access to autosignatures" -SignaturesEnabled $False

Whether you use EAC or PowerShell to block signatures in an OWA mailbox policy, don’t forget to assign the modified policy to the mailboxes you want to control. You can assign the policy by updating mailbox properties with EAC, but it’s likely that you’ll want to update multiple mailboxes and that’s when PowerShell shines. The command to assign an OWA mailbox policy to a mailbox is:

Set-CASMailbox -Identity Kim.Akers -OWAMailboxPolicy "Block Access to autosignatures"

Again, wait for 15 minutes to allow the Exchange Online servers to pick up the new policy and then test that the block is effective.

The OWA mailbox policy is enough to block users from changing autosignatures. You don’t need to update RBAC role assignments unless you also want to stop users running the Set-MailboxMessageConfiguration cmdlet in a PowerShell session. You can make your mind up how likely it is that users will decide to master PowerShell to mess with corporate autosignatures.

RBAC Fails but Another Method Succeeds

RBAC is a powerful mechanism for controlling user access to individual features. In Exchange Online, RBAC depends on the underlying cmdlets and parameters. Usually, RBAC is the best way to stop user access to features, but in this situation, the limitations of the Get-MailboxMessageConfiguration cmdlet created some unfortunate side-effects when implementing a block on autosignatures. Fortunately, OWA mailbox policies came to the rescue and implemented the block we wanted.

---

This is an example of how the probing minds of the Office 365 for IT Pros writing team tease out issues. Benefit from their work by subscribing to the Office 365 for IT Pros eBook!