Pro Exchange 2013 SP1 PowerShell Administration: For Exchange On-Premises and Office 365 (2014)

Chapter 10. Security

Most organizations operating Exchange Server have it running 24/7. Yet expecting Exchange Server to run perfectly all the time is unrealistic; without proper management and without securing its components, you’re going to encounter problems. Particularly, security doesn’t end at the edges of your company’s office building or data center. Depending on the scenario, you may need to arrange protocols and safety measures for communications with parties over the public network—communications that, by default, are open and readable to others.

Since Exchange 2007, Exchange Server has been positioned by Microsoft as “secure by default.” With the Trustworthy Computing (TwC) initiative started in 2002, Microsoft began integrating security development lifecycle (SDL) principles into their development process. These efforts have involved a security review for each feature and component, during which even elementary aspects like default settings have been discussed.

This is in contrast with earlier versions of Exchange Server, for which companies developed “hardening guides” to reduce the product’s potential attack surface. Effectively, this meant locking down the operating system, but doing that could be quite challenging, as Exchange Server depended on and was built upon its operating system, such as the Internet Information Server (IIS).

This “secure by default” approach not only meant changes in default settings like the POP3 service; it also instigated architectural changes or introduced features such as the Role Based Access Control (RBAC) in Exchange 2010, the Mailbox servers’ self-signed certificates to secure internal communications, and reintroduction of S/MIME support in Exchange Server 2013 SP1.

Of course, implementing on-premises security measures is only part of the solution. End users nowadays expect to be able to work anywhere, including when traveling or from home, as part of the bring-your-own-device movement, whereby employees use personal devices to access corporate data. So there is needed a corporate mentality that couples access with security, as well as an awareness by all that security is vitally important.

In this chapter, we will discuss the following security-related features:

· Role-Based Access Control

· Split permissions

· Secure/multipurpose Internet mail extensions (S/MIME)

Note With a product as complex as Exchange Server, and as it is so intertwined with security matters, there’s the question of how best to cover the subject in a book such as this. We chose to consider security in context with other topics rather than to handle all aspects of it in a single “security” chapter. So if you are looking for discussion of publishing Exchange, protocol authentication, or SSL offloading, those can be found in Chapter 3; the topic of mail flow is covered in Chapter 4, and message hygiene is the subject of Chapter 6.

Role-Based Access Control

Earlier versions of Exchange Server had a limited permissions and delegation model, grouped around a few security groups (three in Exchange 2003, five in Exchange 2007), and the approach was simplistic and task orientated. For finer-grained permissions, organizations had to resort to measures like using ACLs to restrict permissions in Active Directory, which in turn could lead to complications when upgrading to a newer version of Exchange. Meanwhile, the predecessor of its role-based access control saw daylight as Authorization Manager, which was made available for Windows Server 2003 and was a role-based security framework for .NET applications.

The security feature Role Based Access Control (RBAC) was introduced with Exchange 2010. It is, as the name implies, a role-based access control permissions model that continues into Exchange 2013. It allows for fine-grained control over the Exchange environment, without the need to manipulate Active Directory objects. It even goes as far as to offer the ability to control and limit access not only on the cmdlet level but on the parameter level as well.

Note Exchange servers holding the Edge Transport server role are not part of RBAC security, since it typically is not a member server in the Exchange domain.

The implementation of RBAC revolved around the Universal Security Group (USG) Exchange Trusted Subsystem. That group is effectively the Exchange ecosystem that not only has full access rights on every Exchange object in the organization but also has permission to manage objects on the Active Directory level by being a member of the administrators local security group and the Windows Permissions Security Group. All installed Exchange 2013 servers are members of the Exchange Trusted Subsystem.

Note For full reference to permissions granted to the Exchange Trusted Subsystem, visit http://bit.ly/Ex2013DeployPerms. As a result of the permission structure, you can not use AdminSDHolder protected accounts, such as administrator accounts, for daily operations, as the AdminSDHolder process will reset the permissions on those accounts every hour. This prevents the Exchange Trusted Subsystem from managing those accounts properly, like registering an ActiveSync device. Often, a quick fix is to enable the “Include inheritable permissions from this object’s parent” setting on the object, but this is not recommended and the setting will be reset by the AdminSDHolder process. For more information on the AdminSDHolder process, see http://bit.ly/AdminSDHolder.

Through the RBAC system, you are effectivly proxying your actions through Exchange Server, which, based on the RBAC configuration, determines what you are allowed to do and not do. This goes not only for administrators but also for end users. An example of the latter is having the ability to manage distribution groups or modify properties, such as your display name.

The RBAC model is based on the concept of assigning who can do what and where, as follows:

· A role is a set of tasks one can perform (what).

· A role group is a collection of roles (who).

· To limit the scope of roles, one can assign scopes (where).

While Exchange 2013 contains several predefined roles and role groups that suffice for most organizations, it allows the creation of custom roles and custom role groups. These custom roles can be assigned through EAC or EMS (see Figure 10-1). Creating custom elements for RBAC can only be done through the EMS.

Figure 10-1. Options for role-based access control in EAC

The basic RBAC configuration of administrator or user roles employing predefined objects or changing memberships can be accomplished by using EAC. These options are located in EAC Permissions Admin Roles. User roles function to manage assignment policies, which are discussed later in this chapter.

WARNING The practice of loading the PowerShell snap-in modules directly from PowerShell or through scripts is not supported. This not only bypasses RBAC but it also may result in non-working Exchange cmdlets, since you might be missing certain permissions in your current security context when compared to the effective permissions provided by the Exchange Trusted Subsystem through RBAC.

To properly load an Exchange Management Shell that will honor the RBAC configuration, you have two options:

1. Call the RemoteExchange.ps1. You adjust the Exchange path accordingly , for example,

"C:\Program Files\Microsoft\Exchange Server\v15\bin\RemoteExchange.ps1"
Connect-ExchangeServer -auto

If you want to connect to a specific Exchange server, use the parameter ServerFqdn, for example:

Connect-ExchangeServer -ServerFqdn ams-exch01.contoso.com

2. Connect to Exchange remotely by setting up a remoting session, as follows:

$Session= New-PSSession -ConfigurationName Microsoft.Exchange-ConnectionUri <Server FQDN>/PowerShell/

Import-PSSession $Session

Caution Depending on the locally present PowerShell modules, data from remote PowerShell sessions may be returned as type string. This prevents you from further processing that information directly using methods provided by the PowerShell object or cmdlets; for example, mailbox sizes may return something like 3.495 MB (3,665,004 bytes), and you may not be able to directly call the conversion methods like .ToMB() or .ToGB().

After defining the management roles (what), management scopes (where), and role groups (who), you can now connect these pieces of the puzzle by using management role assignments.

Caution RBAC objects are stored in Active Directory. Take replication latencies into account when making changesto RBAC configuration.

The Basic RBAC Components

The components used in the RBAC model and their relationships are shown in Figure 10-2. The next section discussses these components, their relationships, and how to put them into action.

Figure 10-2. Components of the RBAC

Note To manage RBAC, with the exception of unscoped management roles, you need to be assigned the Organization Management role group. Be careful, though, as the Organization Management role group is managed by the Organization Management role group, and you could create a situation whereby you lock yourself out.

You must know the concepts, components, and possibilities before you can start customizing RBAC to meet the specific requirements of your organization. When planning for RBAC customization at a high level, keep the following in mind:

· Determine the organizational structure. In most cases, job responsibilities follow the hierarchy of the organization. Distinguish between role levels—for example, senior versus junior.

· Define the roles in the organization by detailing their responsibilities and tasks. Categorize the roles—for example, support, sales.

· Attempt to map the roles to corresponding management roles. Identify the gaps as potential new management roles.

· Document the permissions requirements for each position.

The What Component

The “what” component is set by the management roles and management role entries. A management role defines the job, with its set of cmdlets and parameters that can be used. Exchange 2013 SP1 has 85 predefined management roles. You can obtain a list of these by using Get-ManagementRole.

Management role entries consist of cmdlets and parameters. When the management role entry is part of a management role, that management role can use those cmdlets in combination with its parameters. Exchange 2013 SP1 has 2,005 management role entries. Note that the parameters can be a subset of the parameters that would normally be available. You can obtain a list ofcurrent management role entries for particular management roles using Get-ManagementRoleEntry -Identity "<Management Role>\*". Alternatively, you can query theRoleEntries attribute of the management role. To view all the management role entries, use “*” as the management role—for example, Get-ManagementRoleEntry -Identity "*\*".

Using Management Roles and Management Role Entries

Let’s inspect the management role named “Reset Password.” We can retrieve the management role object and view its attributes by using the following command, with results shown in Figure 10-3:

Get-ManagementRole -Identity "Reset Password" | fl
Get-ManagementRoleEntry -Identity "Reset Password\*"
Get-ManagementRole -Identity "Reset Password" | Select -ExpandProperty RoleEntries | fl

Figure 10-3. View of the summoned management role entry

The latter two cmdlets show that the Reset Password management role permits use of the cmdlet Set-Mailbox, together with the parameters Password, ResetPasswordOnNextLogon, or RoomMailboxPassword.

Creating Custom Management Roles

As mentioned, you can create custom management roles by using the New-ManagementRole cmdlet. In Exchange 2013, there are two types of management roles: normal and unscoped. The normal management role requires you to specify an existing role, termed “the parent.” This can be a predefined management role or a custom management role. The parent is used as a template but also as a limiter. This means that, while you can remove any superfluous cmdlets or parameters from the custom management role, you cannot add cmdlets or parameters that are not part of the parent management role.

Caution When you assign a Set-* cmdlet to a management role, you also need to assign the corresponding Get-* cmdlet. That is, you need to be able to view things in order to be able to configure them.

In this example, you will create a simple custom role for mail recipients. This predefined role is used for managing mail-enabled objects in the organization. You use this command:

New-ManagementRole -Name 'NL Mail Recipients' -Parent 'Mail Recipients'

You can verify the capabilities of this new custom role, which will be identical to the capabilities of the mail recipients role, by using:

Get-ManagementRoleEntry -Identity 'NL Mail Recipients\*'

Now, suppose you want to remove the capability of using one of the role entries. To do that, you use the Remove-ManagementRoleEntry cmdlet, specifying <Management Role>\<Management Role Entry>, like this:

Remove-ManagementRoleEntry -Identity 'NL Mail Recipients\Set-UserPhoto'

Caution When stripping role entries from a custom management role that will be using EAC, be careful not to remove the Set-ADServerSettings cmdlet. This cmdlet is used during initialization of the session to enable the View Entire Forest option to discover the permissions of the currently logged-on user.

Adding or Removing Parameters

A bit contrary to the verb-noun PowerShell principle is the method of adding or removing parameters. To accomplish those tasks, you need to use the Set-ManagementRoleEntry cmdlet. Together with specifying Parameter with the parameters you want added or removed, you need to use -AddParameter or -RemoveParameter, depending on whether you wish to add or remove those parameters from the role entries. For example, if you want to remove the ability to use the preview parameter with Set-UserPhoto, you use this command:

Set-ManagementRoleEntry -Identity 'NL Mail Recipients\Set-UserPhoto'
-Parameter Preview -RemoveParameter

To reinstate this preview parameter, you use:

Set-ManagementRoleEntry -Identity 'NL Mail Recipients\Set-UserPhoto'
-Parameter Preview -AddParameter

To quickly retrieve roles that use certain cmdlets, parameters, scripts, or script parameters, you can use the Get-ManagementRole cmdlet in conjunction with the parameters Cmdlet, CmdletParameters, Script, or ScriptParameters. You can also use GetChildrento retrieve roles that are “children” of the parent role or use Recurse to return a role and all its offspring. For example, this returns all roles that allow Set-Mailbox:

Get-ManagementRole -Cmdlet Set-Mailbox

This cmdlet will return all roles allowing use of a parameter called EmailAddresses with any cmdlets:

Get-ManagementRole -CmdletParameters EmailAddresses

And this cmdlet will return all roles that allow running a script:

Get-ManagementRole -Script *

Unscoped Top-Level Management Roles

A special kind of management role is the unscoped top-level management role. This is a management role whose purpose is to provide administrators or specific user accounts with the permission to execute scripts or non-Exchange cmdlets. As the name implies, unscoped roles are scopeless, as they have no parent role attached, whereas regular management roles are attached to parent management roles.

To create an unscoped management role, you need to be assigned to the Unscoped Role Management Group. To quickly assign the administrator account to this group, you use:

New-ManagementRoleAssignment -Name 'Unscoped Role Management-Administrator'
-User 'Administrator' -Role 'Unscoped Role Management'

If you want to grant permission to the group, you use the SecurityGroup parameter instead of User, and you specify the group name; for example,

New-ManagementRoleAssignment -Name 'Unscoped Role Management-Organization Management'
-SeurityGroup 'Organization Management' -Role 'Unscoped Role Management'

Note that you need to restart the EAC of the EMS session for the new permission to become effective. It is best practice to name the management role assignment by combining the name of the management role group and the user or group you have assigned the role group to. When not specified, this combination will be used as the Management Role Assignment.

Now, you specify the switch UnScopedTopLevel when using the New-ManagementRole cmdlet; for example,

New-ManagementRole -Name 'Maintenance Scripts' -UnscopedTopLevel

Since you did not use a template, the unscoped management role will initially be empty. We have seen before how we can add role entries to management roles. Unscoped management roles are special, in that you can assign scripts or non-Exchange cmdlet permissions to them. The scripts you want to use must reside in the $exinstall\RemoteScripts folder, though. When the default Exchange installation folder is used, $exinstall\RemoteScripts will point to the location C:\Program Files\Microsoft\Exchange Server\v15\RemoteScripts.

Note The scripts you want to use via unscoped management roles need to reside in the $exinstall\RemoteScripts folder on each relevant Exchange server—for example, on all servers or only on those within a specific site, depending on your scenario.

To allow the execution of scripts via management role entries for an unscoped management role, you use the following syntax:

Add-ManagementRoleEntry -Identity '<role name>\<script filename>' -Parameters <param1, param2,..> -Type Script -UnscopedTopLevel

Note You need to specify all required parameters. You cannot use a wildcard to accept a parameter.

For example, to allow the unscoped role ExManScripts to execute the script HealthCheck.ps1 using the parameter Notify, you first make sure that HealthCheck.ps1 is present in the Remote Scripts folder. Next, you use the following cmdlet to allow it through a role entry:

Add-ManagementRoleEntry -Identity 'Maintenance Scripts\HealthCheck.ps1'
-Parameters 'Notify' -Type Script -UnscopedTopLevel

Caution When adding scripts to role entries, know that the cmdlet only performs basic validation for the parameters specified. It is not dynamic, so any changes to the script or removal of the script will not be detected, and you need to manually correct the related role entries.

Now, assume you have a special-purpose account called sa_ExScripts, which you will use to run these scripts. For purposes of this example, you will create a role group called ExScripts with the ExManScripts management role, and you will add the sa_ExScripts account as a member:

New-RoleGroup -Name 'RunMaintenanceScripts' -Roles 'Maintenance Scripts'
Add-RoleGroupMember -Identity 'RunMaintenanceScripts' -Member 'sa_ExScripts'

The output of the previous cmdlets is shown in Figure 10-4.

Figure 10-4. Creating an unscoped top-level management role with script

Tip If the user executing the Add-RoleGroupMember cmdlet is not part of the ManagedBy property of the role group (i.e., accounts that can manage their membership), you need to specify the BypassSecurityGroupManagerCheck switch. This will bypass the built-in group management checks.

You may notice that there are two assignments created, each with a different role assignment delegation type:

· The user creating the roles gets a DelegationOrgWide type assignment. This assigment is automatically created after creating the management role, and it allows the role assignee (the creator) to delegate permissions for the role.

· The assignment created using New-RoleGroup is a regular type assignment. This allows the role assignee to execute the role entries associated with that role group.

Now, when sa_ExScripts opens a remote EMS session as shown in Figure 10-5, it will have only the HealthCheck.ps1 script at its disposal. You can quickly test this using the Connect-ExchangeServer cmdlet, with the User and Prompt parameters to provide the account name, and let it prompt for the password. The Auto switch is added to make it connect to any available server.

Connect-ExchangeServer -Auto -User 'contoso\sa_ExScripts' -Prompt

Figure 10-5. Limited cmdlets owing to RBAC configuration

Note that as shown in Figure 10-5, you can omit all regular PowerShell commands from the Get-ExCommand output. You accomplished this by filtering on the command ModuleName, excluding commands offered through Microsoft PowerShell* modules, as follows:

Get-ExCommand | Where { $_.ModuleName -NotLike 'Microsoft.PowerShell.*' } Note also that you allowed only the role to execute the script. There is no single Exchange cmdlet available. If you want to be able to execute cmdlets from your script or directly, you need to allow them as well, doing so by adding them as role entries using New-ManagementRoleEntry. This may take a while to set up, as you need to go through scripts to collect information on cmdlet and parameter usage, but it grants you fine-grained control over permissions, which should make your security officer happy and may prevent disasters from occurring by powerful unscoped top-level management roles.

Caution When allowing execution of scripts through role entries, you need to allow used cmdlets and parameters as well. Otherwise, these cmdlets and parameters will not be available in the context of the unscoped management role, and your script will not work properly.

As mentioned earlier, in addition to using unscoped management roles to assign permissions to run scripts, you can use them to grant permissions to execute non-Exchange cmlets. To grant these kinds of permissions via management role entries for an unscoped management role, you use the following syntax:

Add-ManagementRoleEntry -Identity <role name>\<cmdlet name>
-PSSnapinName <snap-in name> -Parameters <param1, param2, ..> -Type Cmdlet -UnscopedTopLevel

If you want to add a non-Exchange cmdlet, you specify the cmdlet as well as the PowerShell snap-in that contains the cmdlet you want to grant permission to. For example, assume you want to grant permission to use a cmdlet named Get-QADUser with the parameter Identity. The cmdlet is part of the snap-in Quest.ActiveRoles.ADManagement. You can create a management role entry as follows:

Add-ManagementRoleEntry -Identity 'Maintenance Scripts\Get-QADUser' -Parameters 'Identity' -PSSnapinName Quest.ActiveRoles.ADManagement -UnscopedTopLevel

Caution To control access to non-Exchange cmdlets, the snap-ins you want to control via unscoped management roles need to be installed and registered on all relevant Exchange servers.

The cmdlet to remove the script or non-Exchange cmdlet management role entries for unscoped management roles is similar to removing normal management role entries; for example,

Remove-ManagementRoleEntry -Identity 'Maintenance Scripts\HealthCheck.ps1'

Finally, should you want to remove user-defined management roles, you use Remove-ManagementRole. Note that only user-defined management roles can be removed. But before you can remove a management role, you first need to remove any dependencies on that management role or use the Recurse parameter to perform a cascaded delete on the roles and child roles; for example,

Remove-ManagementRole -Identity 'My Custom Role' -Recurse

If you want to remove an unscoped top-level management role, don’t forget to specify the parameter UnScopedToplevel as well; for example,

Remove-ManagementRole -Identity 'ExManScripts' -UnScopedTopLevel

The Where Component

The “where” component determines where the cmdlets are allowed to run from an Active Directory perspective; that is, the scope. This scope can be as broad as an organizational unit, an Active Directory site, or the entire Exchange organization. It can also be more specific, such as be only certain recipients, Exchange servers, or Exchange databases. You can limit the operational usage of cmdlets by using scopes.

RBAC defines two types of management scopes:

· Regular or non-exclusive scopes define which objects in Active Directory can be accessed—for example, on Organizational Unit (OU) or the server level.

· Exclusive scopes are like regular scopes except that they include access to Active Directory objects. Only members of groups with exclusive access can access those Active Directory objects; others will be denied access.

When defining scopes, be aware of the following:

· When you create a custom management role, it will inherit the non-exclusive scope configuration of the parent management role. These inheritable scopes are called implicit, as they are set by the parent.

· Custom scopes are called explicit scopes, as they are not inherited.

There’s more on implicit and expliciet scopes later in the chapter.

Note Unscoped top-level management roles have no scopes defined. The scope properties of these roles will state “Not Applicable.”

Regular Scopes

There are two types of scopes you can configure: recipient and configuration. And for each of these, you can configure a read or a write scope. Recipient refers to recipient objects, such as mailboxes, distribution groups, or mail-enabled users. Configuration refers to Exchange configuration objects, such as Exchange servers or databases. Each role can have the following types of scopes configured:

· Recipient Read Scope Determines which recipient objects the assignee is allowed to read from Active Directory.

· Recipient Write Scope Determines which recipient objects the assignee is allowed to create or modify from Active Directory.

· Configuration Read Scope Determines which configuration objects the assignee is allowed to read from Active Directory.

· Configuration Write Scope Determines which configuration objects, such as Exchange servers or databases, the assignee is allowed to create or modify from Active Directory.

Note The write scope cannot exceed the boundaries of the related read scope or, in other words, you cannot configure what you cannot view.

Implicit scopes are predefined for the management roles and are stored in the properties ImplicitRecipientReadScope, ImplicitRecipientWriteScope, ImplicitConfigReadScope, and ImplicitConfigWriteScope of the management role objects. Child management roles inherit the parent’s management scopes. When a management role is used in a management role assignment, the implicit scopes of the management role apply to the assignment unless the assignment has explicit scopes defined (which will be explained a bit later). A configured explicit scope will override the implicit scopes, making it an uninheritable explicit scope. The only exception to this override rule is implicit read scopes, which always prevail over explicit scopes. Table 10-1 lists all the available implicit scope definitions.

Table 10-1. Implicit Scope Definitions

Explicit scopes are user-configured scopes that override implicit write scopes. Explicit scopes are defined on the management role assignment level, allowing implicit roles to be used consistently and persisting through inheritance while allowing for exceptions that are configured explicit scopes.

Management role assignments have specific properties for predefined relative scopes. Those scopes are a subset of the implicit scopes that are relative to the role assignee. Possible options for predefined relative scopes are a subset of the implicit scopes, as follows:

· Organization allows assignees to modify recipients in the entire Exchange organization. For example, if a role allows configuration of the display name and user photo, this scope will allow configuring those properties for all recipients in the Exchange organization.

· Self allows assignees to modify their own properties. For example, if a role allows configuration of the display name and user photo, having this scope assigned will extend that action only to the assignee.

· MyDistributionGroups allows assignees to create and manage distribution groups where they are configured as owner.

Predefined relative scopes are assigned to management role assignment objects using the RecipientRelativeWriteScope property.

Finally, when the implicit scopes, optionally in combination with a predefined relative scope, meet your requirements, you can use a custom scope. This allows you to define specific targets, such as particular organizational units, recipients, or databases. As with predefined relative scopes, custom scopes override the implicit scopes with the exception of the read scope. To create reuseable custom scopes, you can define and assign management scope objects. This also makes them more manageable. (There’s more on management scopes later in the chapter.)

You can define these types of custom scopes:

1. OU scope targets recipients within the configured OU. It is configured through the RecipientOrganizationalUnitScope property of management role assignment objects.

2. Recipient filter scope uses a management scope object to filter recipients based on properties such as recipient type, department, manager, or location by using an OPATH filter. The filter is configured through the RecipientRestrictionFilter property of the management scope object, optionally in combination with RecipientRoot to define the filter starting point. Then, the management scope is given to a management role assignment using the assignment’s CustomRecipientWriteScope property.

Note When you specify an alternative root location for the recipient filter scope using RecipientRoot, you need to specify RecipientRoot in canonical form, not the distinguished name. For example, OU=nl,DC=contoso,DC=com will not work,contoso.com/nl will.

3. Configuration scope uses a management scope object to target specific servers based on server lists or filterable properties, such as the Active Directory site of server role, or to target specific databases based on database lists or filterable database properties.

· Server scopes on management scope objects are configured using the SeverRestrictionFilter parameter using an OPATH filter, or the ServerList parameter. Note that server configuration objects, like receive connectors or virtual directories, can be managed if the related server is in-scope.

· Database scopes on management scope objects are configured using the DatabaseRestrictionFilter parameter using an OPATH filter, or the DatabaseList parameter. Database configuration settings like quota settings, maintenance schedule, or database mounting can be managed if the related database is in-scope. Also, if the database is in-scope, the assignee can create mailboxes in that database.

Caution When you move or rename organizational units in Active Directory, make sure you process these changes in applicable scopes as well.

To create a new management scope object, you use the New-ManagementScope cmdlet and give it a name using the Name parameter. Additionaly, depending on whether you want to provide a recipient scope or server scope, you provide the corresponding parameters and the filter value itself. For example, to create a scope for all recipients who are members of a certain group named Staff and only target the recipients below a top-level OU named NL in consoto.com, you would use:

New-ManagementScope -Name 'NL-Staff' -RecipientRoot 'contoso.com/NL'
-RecipientRestrictionFilter {membergroup -eq 'cn=Staff,ou=Users,dc=contoso,dc=com'}

To create a scope for the Active Directory site London, you would use:

New-ManagementScope –Name 'Site London' –ServerRestrictionFilter {ServerSite –eq 'CN=London,CN=Sites,CN=Configuration,DC=contoso,DC=com'}

To create a scope for a fixed set of servers using ServerList, you use:

New-ManagementScope –Name 'Servers Amsterdam' –ServerList AMS-EXCH01,AMS-EXCH02

To create a scope for a databases starting with ’NL-*’, you use:

New-ManagementScope –Name 'Databases NL' –DatabaseRestrictionFilter {Name -like 'NL-*'}

Note Recipient or server filters use OPATH filters to define recipient or configuration—that is, server or database—restrictions. More information on scope filtering can be found at http://bit.ly/RBACScopeFilters.

Exclusive Scopes

As mentioned earlier, along with regular scopes there are exclusive scopes. Exclusive scopes target a specific set of recipients or configuration objects in Active Directory, which then become inaccessible for other management role assignments when accessing the same type of object. This is true even if those other assignments have that object in-scope. For example, if you define an exclusive recipient assignment for a top-level OU named NL, other assignments will be blocked from NL tree access, including assignments with the organization scope. A sample scenario would be for high-profile recipients, for which you could create a separate exclusive manage-recipient role assignment, blocking management of these recipients by others.

To create an exclusive scope, you use the Exclusive switch when creating or reconfiguring a management role assignment. For example, to create an exclusive scope using a recipient filter for all recipients located in the VIP OU tree, you use this command:

New-ManagementScope -Name 'Exec Recipients' -RecipientRoot 'contoso.com/VIP' RecipientRestrictionFilter {Name -like '*'} -Exclusive

Now suppose you want to assign a group called Exec Admins the role of Mail Recipients, using the scope you’ve just created. You would use the ExclusiveRecipientWriteScope instead of the CustomRecipientWriteScope for the exclusive scope:

New-ManagementRoleAssignment -SecurityGroup 'Exec Admins' -Role 'Mail Recipients' -ExclusiveRecipientWriteScope 'Exec Recipients'

The reason for using ExclusiveRecipientWriteScope is to confirm that you are specifying an exclusive scope. If you use CustomRecipientWriteScope, Exchange will notify you that the scope you have specified is exclusive. This way, Exchange not only takes care of configuring the CustomRecipientWriteScope with the scope you provided but it also sets the RecipientWriteScope to the ExclusiveRecipientScope type to indicate that the scope is exclusive.

You can check the assignment using Get-ManagementRoleAssignment, knowing that Exchange will use the <Role>-<Role Assignee Name> as the assignment name. If that name already exists, it will append sequence numbers. To check, you use this command; Figure 10-6 shows an example of the possible output:

Get-ManagementRoleAssignment -Identity 'Mail Recipients-Exec Admins' | fl

Figure 10-6. View of the management role assignment

As Figure 10-6 shows, members of the Exec Recipients group are now the only users allowed to manage recipients in the Board OU (and below). Mail recipients on the organization level—that is, administrators with organization management membership inclusive—cannot do so.

Note Exclusive scopes can overlap. Objects that are part of multiple exclusive scopes can be managed by assignees of those scopes.

The Who Component

The “who” component defines who receives the permissions. This information is stored in the Management Role Groups, or just the Role Groups, which are the Universal Security Group (USG) with special flags to indicate they are role groups. By assigning role groups to one or more management roles, you are effectively granting those role groups the permissions that are part of the management role’s list of management role entries.

Note A Management Role Group is a Universal Security Group with msExchCoManagedByLink and msExchVersion configured, and with msExchRecipientTypeDetails set to 1073741824.

Table 10-2 lists all built-in role group definitions, as well as short descriptions of the capabilities of members of those role groups.

Table 10-2. Built-in Role Groups

Create a Role Group

Of course, you can create your own role group. To create a role group, you have to be a member of the Organization Management Role Group. To manage a role group, you have to be the manager of the role group, which is determined by the ManagedBy property. Alternatively, you can use the BypassSecurityGroupManagerCheck to bypass internal checks that might be blocking you from managing the role group if you are not the currently configured role group manager.

To create a role group, you use the New-RoleGroup cmdlet, giving the role group a name and optionally assigning to it one or more existing management roles using the Roles parameter, as follows:

New-RoleGroup -Name 'UM Mailbox Manager' -Roles 'UM Mailboxes'

Users or groups can be directly added to the role group at creation time using -Members; or you can manage the members of a role group by using Add-RoleGroupMember or Remove-RoleGroupMember, respectively. For example, to add a user Olrik to UM Mailbox Manager, you use:

Add-RoleGroupMember -Identity 'UM Mailbox Manager' -Member 'Olrik'

The New-RoleGroups cmdlets allows you to specify management roles using the Roles parameter, scopes using the various available Scope parameters, and desired role group members using the Members parameter. This way, you can accomplish role assignments using one cmdlet, assuming the building blocks are in place or built in, as the scope and management role definitions. It will also allow you to (re)configure the ManagedBy property of the role group, which will determine who can manage the role group membership. For example, you could use the following cmdlet:

New-RoleGroup -Name 'Exec Recipient Management' -Roles 'Mail Recipients','UM Mailboxes'
-CustomRecipientWriteSope 'Exec'Recipients -ManagedBy 'Olrik' -Members 'Philip','Francis'

This will accomplish the following:

1. A new role group named Exec Recipient Management is created.

2. Users Philip and Francis are added as members of this role group.

3. User Olrik is configured as manager of the role group.

4. The following management role assignments are created, where each assignment will configured with Exec Recipients as CustomRecipientWriteScope:

· Mail recipients-Exec Recipient management

· UM mailboxes-Exec Recipient management

Linked Role Groups

When it’s required in a multi-forest environment—for example, with an Exchange resource forest and an account forest where all the users and group accounts reside—you can create linked role groups. This allows you to create role groups that are linked to the Universal Security Group (USG) in the trusted forest. Two-way trusts are not required.

Assuming the trust has been set up correctly, you can create a linked role group with the following command:

New-RoleGroup -Name '<Role Group Name>-Linked' -LinkedForeignGroup <Name of foreign USG> -LinkedDomainController <foreign DC fqdn> -LinkedCredential (Get-Credential) -Roles <Roles>

You can then use the Roles property of the role groups to get a list of roles to assign to the linked role. For example, to create a linked role group for the Server Management Role Group, you use the following:

New-RoleGroup -Name 'Server Management-Linked'
-LinkedForeignGroup 'Server Management Admins' -LinkedDomainController dc1.users.contoso.com
-LinkedCredential (Get-Credential) -Roles (Get-RoleGroup -Identity 'Server Management').Roles

Tip To convert existing built-in role groups to linked role groups, use the procedure described at http://bit.ly/ConvertToLinkedRoleGroups.

Putting it All Together: Management Role Assignments

After defining the management roles (the what), the management scopes (the where), and the role groups (the who), you can now connect these pieces of the puzzle by using management role assignments. Some of the earlier examples showed how to use New-ManagementRoleAssignment to assign a user or USG to a management role. Besides direct role assignments, end users can be granted permission through role assignment policies. But before moving onto management role assignments, let’s briefly look at the relevant parameters that are available. (Note that you need to assign the management role using either Computer, SecurityGroup, User, or Policy parameters as the assignee, as these are required but mutually exclusive.) Here’s an overview of the possibilities:

· The optional Name parameter can be used to specify the name of the management role assignment. If a name is not provided, Exchange will use the <Role>-<Role Assignee Name> as assignment name. If that name already exists, it will start appending sequence numbers.

· The Computer parameter specifies the computer account to assign the management role to.

· The SecurityGroup parameter specifies the management role group or Universal Security Group to assign the management role to.

· The User parameter specifies the name or alias of the user to assign the management role to.

· The Policy parameter specifies the name of the management role assignment policy to assign the management role to. The IsEndUserRole property of the specified role needs to be $true, indicating it is a user role.

· The Role parameter specifies the management role to assign.

· The CustomConfigWriteScope parameter specifies the regular management scope for configuration objects. If CustomConfigWriteScope is specified, you cannot use ExclusiveConfigWriteScope.

· The CustomRecipientWriteScope parameter specifies the regular management scope for recipient objects. If CustomRecipientWriteScope is specified, you cannot use ExclusiveRecipientWriteScope orRecipientOrganizationalUnitScope.

· The delegating switch specifies if the user or USG are allowed to grant the assigned management role to other accounts.

· The ExclusiveConfigWriteScope parameter specifies the exclusive management scope for configuration objects. If ExclusiveConfigWriteScope is specified, you cannot use CustomConfigWriteScope.

· The ExclusiveRecipientWriteScope parameter specifies the exclusive management scope for the recipient objects. If ExclusiveRecipientWriteScope is specified, you cannot use CustomRecipientWriteScope orRecipientOrganizationalUnitScope.

· The RecipientOrganizationalUnitScope parameter specifies the OU to scope the role assignment. Use the canonical form when specifying the OU, for example domain/OU/subOU.

· The RecipientRelativeWriteScope parameter specifies the type of restriction to apply to the recipient scope. Valid options are Organization, MyGAL, Self, MyDistributionGroups, and None.

· The UnScopedTopLevel switch needs to be specified if the role provided is an unscoped top-level management role.

These are the most common options available with New-ManagementRoleAssignment to create management role assignments. Now let’s look at a few examples to see how to create these assignments using management roles, management scopes, and role groups.

Assume you have administrators who have the task of managing recipients in the top-level OU called NL. These administrators are named in the USG NL Admins. Since you only want to filter on an OU, specifying the RecipientOrganizationUnitScope parameter will suffice for accomplishing this, as shown in Figure 10-7:

New-ManagementRoleAssignment -SecurityGroup 'NL Admins' -Role 'Mail Recipients' -RecipientOrganizationalUnitScope 'contoso.com/NL'

Figure 10-7. Creating a role assignment with recipient OU scope

Now, assume you want those NL administrators to only manage recipients in the NL OU who are located in the Amsterdam office. Before you can assign a scope to a role assignment, you need to define the scope, as follows:

New-ManagementScope -Name 'OU-NL_Amsterdam' -RecipientRoot 'contoso.com/NL'
-RecipientRestrictionFilter { City -eq 'Amsterdam' }

You can now adjust the previously created assignment and have it use the configured management scope as CustomRecipientWriteScope:

Set-ManagementRoleAssignment -Identity 'Mail Recipients-NL Admins'
-CustomRecipientWriteScope 'OU-NL_Amsterdam'

To retrieve information regarding effective permissions, you can use Get-ManagementRoleAssignment with the EffectiveUsers switch. This will return what users are granted the permissions given by a management role through the role groups, assignment policies, and USGs that are assigned to them. For example, to return all assignments where the account AdminNL has effective permissions, you would use:

Get-ManagementRoleAssignment -GetEffectiveUsers | Where { $_.EffectiveUserName -eq 'AdminNL' } | Select EffectiveUserName, Role, RoleAssignee, Identity

In Figure 10-8, you can see that there is an assignment for the Mail Recipients role, for which the AdminNL user has permissions through the role assignee, which in this case is a USG.

Figure 10-8. Results showing effective permissions with Get-ManagementRoleAssignment

Tip Use Get-ManagementRoleAssignment with the EffectiveUsers switch to return effective user permissions for the role assignments.

Policies for Role Assignments

End users can automatically be assigned permissions by way of role assignment policies. One policy is present by default: the default role assignment policy. This policy contains relative scopes that, when enabled, allow users to manage certain elements of their mailbox related to their Active Directory account or other items, such as distribution groups owned by the user. The default policy gets assigned when new mailboxes are created. Of course, when required, you can modify the default policy or create your own explicit role assignment policy.

These role assigment policies can be managed through the EAC, via Permissions User Roles. When opening up the default role assignment policy, as shown in Figure 10-9, you will notice several end-user roles that control what a user is or is not allowed to configure on his own mailbox or related objects like distribution groups managed by the mailbox owner.

Figure 10-9. Using the EAC to manage user roles

To display the current default assignment policy from the EMS, use Get-RoleAssignmentPolicy; for example,

Get-RoleAssignmentPolicy | Where { $.IsDefault }

The property Roles contains the roles assigned and the property RoleAssignments has the role assignments that have been created by the policy. To inspect which assignments were created, as well as the scopes that were used in making the assignments, you store the currently configured default assignment policy in a variable. Then, you use the RoleAssignments property of that policy to perform a Get-ManagementRoleAssignment for each assignment, which will return the scope information as well:

$RAP=Get-RoleAssignmentPolicy | Where { $_.IsDefault }
$RAP.RoleAssignments | Get-ManagementRoleAssignment | ft Role,Recipient*Scope,Config*Scope

As you can see in Figure 10-10, there are some built-in roles used specifically for the assignment policy. The available user roles can easily be displayed by filtering on the IsEndUserRole property, as shown in Figure 10-11; for example,

Get-MangementRole | Where { $_.IsEndUserRole } | ft Name,*Scope

Figure 10-10. View of role assignments created by the default role assignment policy

Figure 10-11. Built-in user roles and implicit scopes

These built-in user roles contain the role entry information that determines which cmdlets the assignee is allowed to run. However, take a look at Table 10-3 for a quick overview of these roles and their purposes.

Table 10-3. Built-in User Roles

To create a new default assignment policy, you use New-RoleAssignmentPolicy; for example,

New-RoleAssignmentPolicy -Name 'Limited Configuration'
-Roles MyBaseOptions,MyAddressInformation,MyDisplayName

The previous cmdlet created an explicit policy. To create the same assignment policy making it the default policy, you specify the IsDefault switch:

New-RoleAssignmentPolicy -Name 'Limited Configuration'
-Roles MyBaseOptions,MyAddressInformation,MyDisplayName -IsDefault

When you want to reconfigure an existing assignment policy as the new default policy, you use Set-RoleAssignmentPolicy and specify IsDefault; for example,

Set-RoleAssignmentPolicy -Identity 'Limited Configuration' -IsDefault

To add to and remove roles from an assignment policy, you use New-ManagementRoleAssignment and Remove-ManagementRoleAssignment, respectively.

To configure an assignment policy for a mailbox, you use the Set-Mailbox cmdlet with the RoleAssignmentPolicy:

Set-Mailbox -Identity 'Philip' -RoleAssignmentPolicy 'Limited Configuration'

To retrieve all mailboxes that have a specific assignment policy configured, you use the following:

Get-Mailbox -ResultSize Unlimited | Where { $_.RoleAssignmentPolicy -eq 'Limited Configuration'}

To remove an assignment policy, you use Remove-AssignmentPolicy, as follows:

Remove-RoleAssignmentPolicy -Identity 'Limited Configuration'

Monitoring and Reports

Provided administrator audit logging is enabled, you can use EAC or EMS to report on changes in role membership groups or role assignments. To verify the status of administrator audit logging, you use the following:

Get-AdminAuditLogConfig | Select AdminAuditLogEnabled

The AdminAuditLogEnabled property indicates if administrator audit logging is enabled. If it is not enabled, you can use the following cmlet to enable the administrator audit logging:

Set-AdminAuditLogConfig -AdminAuditLogEnabled $true

To report on changes in role group membership via EAC, you use the Compliance Management Auditing Run an Administrator Role Group Report option. This will bring up a dialog box, as shown in Figure 10-12, where you can enter some details to narrow the search further.

Figure 10-12. Running a report on an administrator role group

This EAC option only reports on changes. Alternatively, in EMS, you can search the administrator audit logs for entries related to RBAC cmdlets by using SearchAdminAuditLog. For example, to search changes related to role assignment policy that might have occurred in the last seven days, you use something like:

Search-AdminAuditLog -Cmdlets New-RoleAssignmentPolicy,Set-RoleAssignmentPolicy
-StartDate (Get-Date).AddDays(-7)

To search for role assignments created or modified in the last 24 hours, you use the following:

Search-AdminAuditLog -Cmdlets New-ManagedRoleAssignment,Set-ManagedRoleAssignment
-StartDate (Get-Date).AddDays(-1)

Note: there’s more on administrator audit logging in Chapter 9.

Split Permissions

In most deployments, Exchange Server is installed using the shared permissions model that is the default installation mode. In shared permissions mode, you are able to create and manage security principals in Active Directory through EMS cmdlets. This is because Exchange Trusted Subsystem is a member of the Exchange Windows Permissions Security Group, which has permissions in Active Directory for doing such things as creating user or group objects.

Note Having the Windows Permissions Security Group assigned Active Directory permissions, and assigning permissions to the Exchange Trusted Subsystem directly, makes implementation of split permissions or changing the mode a simple process.

More specifically, in shared mode, the following management roles are used under the hood to create security principals in Active Directory:

· Mail recipient creation role, assigned by default to the organization management and recipient management role groups.

· Security group creation and membership role, assigned by default to the organization management role groups.

However, depending on your organization’s security requirements, or the way your IT infrastructure is managed, you may need stricter management of security principals in Active Directory. For example, creating a new mailbox automatically also creates a new user object in Active Directory. When that is not desired, you might consider implementing a split permissions model.

If your organization is considering implementing a split permissions model, you have two options:

· RBAC split permissions. This model is recommended over Active Directory split permissions. The model is flexible and security principal management remains under RBAC control. Exchange Trusted Subsystem is still member of Exchange Windows Permission USG. Exchange servers, services, and specific groups can manage security principals such as distribution groups or role groups. The Exchange tools keep working. Configuring RBAC split permissions is a manual process.

· Active Directory Split Permissions. This model isolates management of Exchange configuration and Active Directory security principals. Exchange Trusted Subsystem will not be a member of Exchange Windows Permission USG. This may result in your having to use separate tools for managing Exchange and Active Directory security principals, includes managing distribution groups. Finally, third-party products might not work, as they do not have (implicit) permissions on the Active Directory level. Configuring AD split permissions is an automated process.

Note When considering split permissions, sometimes delegation of the task of installing Exchange Server is discussed, as this might be a remote worker or contractor; this is when the Delegated Setup role group comes into play. Exchange administrators can provision placeholder information in Active Directory by using setup.exe /NewProvisionedServer:<server name>. After that, members of the Delegated Setup role group, with local administrator permissions to install both prerequisites and Exchange Server, can deploy that server by runningsetup.exe. If you want those administrators to do some configuration on the server, you need to add them to the Server Management role group or create an assignment using a scope for confinement.

RBAC Split Permissions

Implementing split permissions on the RBAC level is relatively simple and makes good use of RBAC features. In shared permissions mode, the Mail Recipient Creation role and the Security Group Creation and Membership management roles are used to create security principals in Active Directory.

Enabling RBAC split permissions is a manual process and will effectively transfer the permission for creating security principals to a user-defined role group, rather than using the built-in Organization Management and Recipient Management role groups. Assuming you have not enabled Active Directory split permissions, you proceed as follows to configure the RBAC split permissions:

1. Create a role group that will contain AD administrators who have permission to create security principals.

2. Make regular and delegating role assignments between Mail Recipient Creation role and the new role group. You do the same for Security Group Creation and Membership role groups.

3. Remove the regular and delegating role assignments between Mail Recipient Creation and the Organization Management role groups and Recipient Management role groups. You do the same for Security Group Creation and Membership role groups.

4. Optionally, you reconfigure the ManagedBy property of the role group, as this will initially contain the creator.

For example, assuming ADAdmins is the name of the designated group as mentioned in step 1, with permissions to create and manage security principals in Active Directory, you run the following set of cmdlets to enable RBAC split permissions:

New-RoleGroup -Name 'ADAdmins' --Roles 'Mail Recipient Creation',
'Security Group Creation and Membership'

New-ManagementRoleAssignment -Role 'Mail Recipient Creation'
-SecurityGroup 'ADAdmins' -Delegating

New-ManagementRoleAssignment -Role 'Security Group Creation and Membership'
-SecurityGroup 'ADAdmins' -Delegating

Get-ManagementRoleAssignment -RoleAssignee 'Organization Management'
-Role 'Mail Recipient Creation' | Remove-ManagementRoleAssignment

Get-ManagementRoleAssignment -RoleAssignee 'Recipient Management'
-Role 'Mail Recipient Creation' | Remove-ManagementRoleAssignment

Get-ManagementRoleAssignment -RoleAssignee 'Organization Management'
-Role ' Security Group Creation and Membership' | Remove-ManagementRoleAssignment

Set-RoleGroup -Identity 'ADAdmins' -ManagedBy 'ADAdmins'

Note that now only members of the role group—that is, AD Admins—will be able to create security principals such as mailboxes (which implies creating a security principal in Active Directory). The following cmdlets become unavailable: New-Mailbox, New-MailContact, New-MailUser, New-RemoteMailbox, Remove-Mailbox, Remove-MailContact, Remove-MailUser and Remove-RemoteMailbox. Certain features in EAC or OWA/ECP might become unavailable or nonfunctioning, owing to the aforementioned cmdlets not being available.

Tip If you want the AD Admin role group to also manage Exchange attributes on new objects, assign the Mail Recipients role.

Active Directory Split Permissions

At some point, anyone who has installed a new Exchange 2013 organization using GUI mode must have seen the dialog that is shown in Figure 10-13.

Figure 10-13. Active Directory split permissions option

Note You cannot enable Active Directory split permissions when you have installed Exchange on a domain controller, but this is generally not recommended anyway.

With Active Directory split permissions, the Recipient Management and Organization Management roles will not be able to create security principals in Active Directory, such as users (for mailboxes) or groups (for distribution lists). When configured, the Active Directory administrators are responsible for creating security principals in Active Directory. Exchange administrators, being Recipient or Organization Management group members, will be responsible for configuring and managing the Exchange attributes on those security principals, like mail-enabling an existing security principal.

Note You can switch Active Directory split permissions mode by running setup.exe /ActiveDirectorySplitPermissions:[true|false], specifying true or false depending on whether you want to enable or disable the split permissions, and /PrepareAD or/PrepareAllDomains, depending on your domain model and choice of wanting to prepare all domains at once.

The AD split permissions model is implemented through the Setup wizard by checking the Apply Active Directory Split Permissions mode or when running setup.exe /PrepareAD /ActiveDirectorySplitPermissions:true from the command line. Depending on whether you are enabling Active Directory split permissions during the initial setup of Exchange 2013 or are switching from shared permissions or RBAC split permissions mode, enabling Active Directory split permissions results in the following changes:

1. An organizational unit named Microsoft Exchange Protected Groups is created.

2. The Exchange Windows Permissions USG is created, or when it already exists, is moved to this Microsoft Exchange Protected Groups.

3. When the Exchange Trusted Subsystem USG is a member of the Exchange Windows Permissions Group, it is removed from that group.

4. When they exist, any nondelegating role assigment to the Mail Recipient Creation and Security Group Creation role groups and the Membership role group is removed.

5. Any existing access control entries (ACEs) assigned to the Exchange Windows Permissions USG are removed from the domain object—for example, CN=contoso,CN=com. This is repeated for all domains in the forest, depending on use of the /PrepareAllDomainsswitch.

After enabling the Active Directory split permissions model, the following cmdlets will be accessible, but cannot be used to create or manage distribution groups: Add-DistributionGroupMember, New-DistributionGroup, Remove-DistributionGroup, Remove-DistributionGroupMember, and Update-DistributionGroupMember.

You’ll also find that the following cmdlets will be unavailable: New-Mailbox, New-MailContact, New-MailUser, New-RemoteMailbox, Remove-Mailbox, Remove-MailContact, Remove-MailUser, and Remove-RemoteMailbox. Certain features in EAC or OWA/ECP might become unavailable or non-functioning as well, owing to the aforementioned cmdlets not being available or not functioning, depending on the operation you are trying to run.

S/MIME

S/MIME is a standard for certificate-based signing and encryption of email messages. It is an endpoint solution, and it is built on top of public key infrastructure (PKI) technology. Exchange 2013 RTM lacked S/MIME support. However, the Exchange Server 2013 Service Pack 1 reintroduced support for S/MIME in Outlook WebApp (OWA). All recent versions of Outlook contain S/MIME support, and Windows Phone 8.1 adds support for S/MIME as well. There’s more background information on PKI at http://bit.ly/AboutPKI.

By encrypting messages, you maintain confidentiality while the message is transported on the public network. The only one able to read the message is the intended recipient. However, to send someone an encrypted message, the sender must know the public certificate of the receiver. That public certificate is then used to encrypt the message. So, the only one able to decrypt that message is the one owning the private key, which normally is the intended receiver. Some mail clients allow you to always include the public key with your messages, which then enables the receiver to encrypt future messages should he or she choose to do so. The encryption and decryption process is shown in Figure 10-14.

Figure 10-14. E-mail encryption and decryption process

Note S/MIME encrypted messages are readable only for the intended receiver. Since these messages are not readable by the indexer (treated as “unknown”), they cannot be searched and cannot be discovered.

Exchange 2013 SP1 supports triple-wrapped messages. This means that signed messages are encrypted after the message is signed. This is the highest form of security with S/MIME, but it does increase message size.

Caution S/MIME is an ActiveX control and is supported by Internet Explorer 9 and above. Currently, S/MIME is unsupported for Firefox, Opera, or Chrome. S/MIME is also not supported on OWA for devices.

After the sender signs a message and it is encrypted, the receiver can be sure that message was actually sent by the reported sender (non-repudiation), and that the message has not been tampered with. Signing e-mail requires owning the private key of the certificate.

Caution Be advised that, when using non-public certificates for signing or encryption, you need to properly manage those certificates, expired ones included, as loss may result in an inability to decrypt and thus read messages.

To use S/MIME for signing messages, you must have installed a certificate on the client or device. For encrypting the messages, you need the public certificate of the receiver as well. Certificates can be installed manually or distributed through the Global Address List (GAL). For mobile devices, you can use mobile device management solutions like the Windows Phone Enterprise Feature Pack for Windows Phone 8.1 devices or the System Center Configuration Manager.

Note When using GAL distribution via Office 365, a hybrid configuration is required. In such a configuration, you need to set up DirSync to provision the certificates through the on-premises user certificate attribute in Active Directory to Azure Active Directory for Office 365. This setup also allows organizations with a mix of on-premises users, as well as users hosted in Exchange Online, to exchange S/MIME messages.

Configuring S/MIME in Exchange 2013 SP1

Before configuring, let’s have a quick look at mobile device mailbox policies, better known through their old name, Exchange ActiveSync mailbox policies. These allow you to create a policy whereby you configure a set of options for mobile devices, which you then assign to mailboxes. After that, mobile devices configured to connect to those mailboxes can satisfy any compliance settings and will receive those settings, such as allowing use of cameras or enforcing mandatory password use for lock screens.

The mobile device mailbox policy also has options for several S/MIME-related settings:

· AllowSMIMEEncryptionAlgorithmNegotiation specifies whether the messaging application on the mobile device can negotiate the encryption algorithm if a recipient’s certificate doesn’t support the specified encryption algorithm. Possible values areBlockNegotiation, OnlyStrongAlgorithmNegotiation, and AllowAnyAlgorithmNegotiation.

· AllowSMIMESoftCerts specifies whether S/MIME software certificates are allowed.

· RequireEncryptedSMIMEMessages specifies whether you must encrypt S/MIME messages.

· RequireEncryptionSMIMEAlgorithm specifies what required algorithm must be used when encrypting. Possible values are TripleDES, DES, RC2128bit, RC264bit, or RC240bit.

· RequireSignedSMIMEAlgorithm specifies what required algorithm must be used when signing a message. Possible values are SHA1 or MD5.

· RequireSignedSMIMEMessages specifies whether the mobile phone must send signed S/MIME messages.

The default settings of the default mobile device mailbox policy can be displayed by using the following:

Get-MobileDeviceMailboxPolicy | Select Name,*MIME*

Running this cmdlet returns the selected MIME-related pieces of information from the mobile device mailbox policy, as shown in Figure 10-15.

Figure 10-15. Display of default mobile device mailbox policy S/MIME settings

To change an option, use Set-MobileDeviceMailboxPolicy -Identity <Policy Name>, followed by the parameter and value. For example, to change the required algorithm used for encryption, you use:

Set-MobileDeviceMailboxPolicy -Name 'Default' -RequireEncryptionSMIMEAlgorithm RC240bit

You can use EAC to assign policies with SMIME options created from PowerShell. Alternatively, you can use:

Set-CASMailbox -Identity <Mailbox ID> -ActiveSyncMailboxPolicy <MDM Policy ID>

Next to the MDM policy, there is also the option to configure how SMIME operates in OWA, utilizing the Set-SMIMEConfig cmdlet. You can display current settings using Get-SMIMEConfig.

Running the Get-SMIMEConfig cmdlet will show you the currently configured S/MIME settings, as shown in Figure 10-16.

Figure 10-16. Display of default S/MIME configuration

Note Configuring the S/MIME options using Set-SMIMEConfig requires membership in the Organization Management role group.

The following options can be configured using Set-SMIMEConfig:

· OWATripleWrapSignedEncryptedMail specifies whether signed and encrypted email messages in OWS are triple-wrapped. The default is $true.

· OWAAllowUserChoiceOfSigningCertificate specifies whether to allow users to select the certificate to use when they digitally sign email messages in OWA. The default value is $false.

· OWAAlwaysEncrypt specifies whether all outgoing messages are automatically encrypted in OWA. The default is $false.

· OWAAlwaysSign specifies whether all outgoing messages are automatically signed in OWA. The default is $false.

· OWASigningAlgorithms specifies the list of signing algorithms that are used by OWA to sign messages.

· OWAEncryptionAlgorithms specifies a list of algorithms that are used by OWA to encrypt messages.

· OWASignedEmailCertificateInclusion specifies whether the sender’s encryption certificate is included from a signed email message in OWA. The default value is $true. This means the public certificate is automatically included with signed messages, allowing the receiver to encrypt future messages for this sender.

Regarding the OWA encryption algorithms and OWA signing algrithms, you’ll notice a list of algorithms separated by a semicolon. Some algorithms support multiple key lengths (strengths). For those, you need to specify the key length in the format <ID>:<key length>. Table 10-4 lists the available encryption and signing algorithms.

Table 10-4. Supported Encryption and Signing Algorithms

So, assuming you want to configure RC2 128-bit, 3DES and AES256 for encryption, you would use:

Set-SMIMEConfig --OWAEncryptionAlgorithms 6602:128,6603,6610

To configure SHA1 for signing, you use:

Set-SMIMEConfig --OWASigningAlgorithms SHA1

Outlook Web Access and S/MIME

Assuming your secure email certificate is stored and available in Active Directory, you can proceed as follows to use S/MIME in Outlook:

1. Open Outlook Web Access.

2. Create a new email message.

3. Click … and select Show Message Options.

4. Select Encrypt This Message (S/MIME) or “Digitally Sign This Message (S/MIME), depending on what you want to achieve; see Figure 10-17.

Figure 10-17. Configuring the S/MIME options in OWA

5. When you return to the composition window, you may receive a warning, depending on whether you have already installed the S/MIME ActiveX control. The warning states: “Tip: You can’t sign or encrypt this message until you install the S/MIME control.” So, to install S/MIME, click the link and install the downloaded owasmime.msi package. You must relog for the installed control to work.

6. When you compose a message and select Encrypt or Sign, you will notice a key or certificate symbol at the right of the subject line; this indicates whether encryption or signing is selected for the current message.

Outlook and S/MIME

To be able to use S/MIME in Outlook, you proceed as follows:

1. If you have not installed your secure email certificate yet, do so now. It may be automatically distributed to you or you may need to manually install it. In the latter case, you open the certificate and import it to the personal certificate store of the user.

2. Configure Outlook to use the ceryou click Trust Center Settings, after which you select the Email Security pane, as shown in Figure 10-18.

Figure 10-18. Configuring the email security options in Outlook 2013

3. Click Settings to open up the dialog to configure the security settings. You provide a meaningful name for the setting you are going to create, and click Choose. A popup will appear where you can pick the secure email certificate to use. In the Change Security Settings window, you provide additional details like the algorithms to use and, last but not least, select whether you want to automatically send your certificates with signed messages so that the receiver may reply to you with encypted messages.

When you compose an email in Outlook, you can select the Options pane and select Encrypt or Sign to encrypt or sign the message, as shown in Figure 10-19.

Figure 10-19. Sending a S/MIME message using Outlook 2013

Windows Phone 8.1 and S/MIME

Assuming the secure email certificate is present on your device, either through provisioning or after manually installing it, you then configure S/MIME on the related account:

1. On your Windows Phone device, navigate to Settings Email + Accounts.

2. Select your Exchange account.

3. At the bottom of the account configuration window, you will spot two settings that are new in Windows Phone 8.1: Sign with S/MIME and Encrypt with S/MIME, as shown in Figure 10-20. Configure. You cannot configure S/MIME per message.

Figure 10-20. S/MIME usage in Windows Phone 8.1

4. Depending on whether you enabled encryption or signing, you will see a “Signed and encrypted message” notification when composing a message, also shown in Figure 10-20. This same notification will be displayed when receiving signed or encrypted messages.

Summary

This chapter discussed the Role Based Access Model (RBAC)in Exchange 2013 and its components, such as management roles, management scopes, and role groups, as well as special features like unscoped top-level management groups, and how these features can help you achieve granular permissions in your Exchange and Active Directory environments using a role-based model.

The chapter also showed how to enable and utilize the split-permissions model when business requirements require strict separation of tasks formanagement of the Exchange organization and Active Directory.

Finally, Chapter 10 surveyed the purpose of S/MIME, which was introduced with Exchange Server 2013 Service Pack 1, and how to configure it using Outlook or Windows Phone.