Occasionally I am asked the following question – how can I protect the messaging environment from a rogue administrator? There are essentially two concerns being asked in this question:
Sometimes this discussion leads to a discussion about only the chosen backup architecture. The reality is that whether you implement Exchange Native Data Protection or a third-party backup solution, a backup, by itself, does not protect you from rogue administrators; it only mitigates the damage they potentially cause. Any administrator that has the privileged access to the messaging data (whether it be live data and/or backup data), can compromise the system. Therefore, some operational changes must be implemented within the organization in order to reduce the attack surface of an administrator who has gone rogue.
Important: This article is not intended to be a comprehensive set of instructions on how to restrict administrators. Instead, this article will highlight the principles and techniques that can be used.
The Microsoft Security Response Center published the Ten Immutable Laws of Security. They are:
These guiding principles are a cornerstone in how we secure Office 365 and are equally applicable to on-premises deployments.
Exchange relies on Active Directory, storing configuration data within the configuration partition and storing recipient data within the domain partitions. The forest administrators, who are members of either the Enterprise Admins group or the root Domain Admins group, control all aspects of the directory and control data stored in the directory (though they sometimes delegate specific rights to others so others can perform very specific actions that are usually narrowly scoped within a forest). Likewise, domain administrators in each domain partition own their respective recipient data. Companies normally restrict forest-wide and domain-wide actions to be exclusively performed by forest administrators because of the risk that configuration changes can have broad adverse impact.
Many organizations today operate an Active Directory model with a least-privilege administrative model. If you are not operating in this fashion, this should be a top priority for your organization. Remember, any member of the Enterprise Admins or Domain Admins can alter messaging configuration settings on recipients and/or the Exchange configuration, without utilizing the Exchange Management Tools. For more information, see Best Practices for Securing Active Directory.
In addition to operating Active Directory in a least-privilege manner, it is important to implement background checks and other processes to determine the trustworthiness of your administrators, otherwise Law #6 cannot be mitigated. In addition, you may want to consider investing in an identity management solution, like Forefront Identity Manager, to manage and audit administrative permission requests and approvals.
Exchange administrators have a wide variety of tools that they potentially can utilize to manage a messaging environment. The preferred method is via Remote PowerShellas Exchange can then authorize access and audit any actions performed. However, if an Exchange administrator is granted additional permissions in Active Directory (e.g., the ability to modify any attribute on a user), then the administrator can utilize other tools (e.g., LDP, ADSIEdit, local PowerShell, scripts, etc.) to modify recipient and/or configuration data, bypassing the authorization and auditing checks built into the system.
To effectively mitigate any possibility of modifications that could occur outside of the Remote PowerShell framework, it is imperative to follow Best Practices for Securing Active Directory, as previously mentioned. Often times, Exchange administrators are not evaluated with the same rigor as Active Directory administrators; therefore, Exchange administrators must not be granted permissions in Active Directory that allow them to circumvent Remote PowerShell (e.g., recipient modification).
If Active Directory privileges are accurately and narrowly scoped, a rogue administrator will have difficulty making unauthorized changes no matter which tool he/she tries to use.
Exchange leverages Remote PowerShell which is a feature within PowerShell that lets admins run commands on remote systems. Remote PowerShell enables the functionality utilized by Exchange to audit cmdlet execution and enforce authorization through RBAC.
One way to ensure that administrators can only manage the messaging environment through Remote PowerShell is to not allow the installation of the Exchange Management Tools on administrator workstations. Administrators are then forced to use the Exchange Admin Center or to connect to Exchange using Remote Shell.
In addition, PowerShell 3.0 and higher provides robust audit capabilities when module logging is enabled. PowerShell Module logging captures pipeline execution events for specified modules, and records this data in Windows PowerShellEvent log. Among the events logged, Event ID 800 (Pipeline Execution Details) provides command line commands and a script name if one is used. If a script was used, the ScriptName value will be populated with the file name of the script that was executed and an event will be logged for each line in the script, with each event including the command from that line. The data recorded in the event log can be collected, analyzed, and provide auditing data by which an organization can determine what PowerShell operations are occurring in the environment.
An Exchange administrator has the necessary privilege to access and destroy Exchange data. The best way to protect the messaging data from an administrator is to:
The majority of Exchange management tasks are accomplished via Remote PowerShell. As a result, the only time an Exchange administrator needs local administrative access to the Exchange server is to perform system updates (installing driver updates, installing Exchange cumulative updates, operating system updates, etc.). Therefore, local administrative access can be restricted and granted only when needed, for a specific period of time, after which access is revoked.
Without local administrative access, administrators will be unable to obtain certain information about the Exchange server health that they may need to appropriately manage the environment. Therefore, administrators should be granted access to the following:
In addition, local administrative access on the administrator’s workstations should also be removed. This ensures that administrators can only run approved applications and cannot bypass any security mechanisms you may put into place to audit and monitor their actions. For more information on running Windows in a least privileged manner, see Applying the Principle of Least Privilege to User Accounts on Windows.
By removing local administrative access, Laws #2 and #3 are mitigated.
AppLocker provides organizations with a strong defense in the prevention of malicious software and unapproved applications from affecting your server environment. AppLocker can be used to limit the software that Exchange operators can use so that only an approved list of applications (e.g., Exchange Management Tools, approved PowerShell scripts, etc.) will run on a server where AppLocker policy enforcement is in effect. For more information, see the TechNet article on AppLocker.
AppLocker allows you to mitigate Law #1.
Both Exchange 2010 and Exchange 2013 include Role Based Access Control (RBAC), a mechanism by which administrators are authorized to perform certain administrative tasks. RBAC provides the capability for very granular control of managing the messaging environment – for example, restricting access to a particular cmdlet or to a particular property of a cmdlet.
For more information on RBAC, please see the following articles:
While Administrator Audit Logging will record the actions taken by administrators, it does not prevent the administrators from performing destructive actions if they are authorized to do so. Using RBAC, organizations can reduce the attack surface area by removing access to destructive cmdlets. A destructive cmdlet is any cmdlet that can access, modify, or delete messaging data.
The below table identifies cmdlets and parameters that may be considered destructive (e.g., Remove-Mailbox). Each cmdlet should be evaluated to determine how it is used in your environment and whether it should be removed from day-to-day usage.
Cmdlet | Parameters | Roles |
Add-ResubmitRequest | Databases | |
Disable-Mailbox | Mail Recipients | |
Move-ActiveMailboxDatabase | MountDialOverrride | Databases |
Mount-Database | Force | Databases |
Remove-AcceptedDomain | Remote and Accepted Domains | |
Remove-ActiveSyncDeviceAccessRule | Organization Client Access | |
Remove-ActiveSyncDeviceClass | Organization Client Access | |
Remove-ActiveSyncMailboxPolicy | Recipient Policies | |
Remove-ActiveSyncVirtualDirectory | Exchange Virtual Directories | |
Remove-AddressBookPolicy | Address Lists | |
Remove-AddressList | Address Lists | |
Remove-ADPermission | Active Directory Permissions | |
Remove-AuthRedirect | Organization Client Access, Organization Configuration | |
Remove-AuthServer | Organization Client Access | |
Remove-AutodiscoverVirtualDirectory | Exchange Virtual Directories | |
Remove-AvailabilityAddressSpace | Federated Sharing, Mail Tips, Message Tracking, Organization Configuration | |
Remove-ClassificationRuleCollection | Data Loss Prevention | |
Remove-ClientAccessArray | Organization Client Access | |
Remove-ClientAccessRule | Organization Client Access | |
Remove-CompliancePolicySyncNotification | Data Loss Prevention | |
Remove-ContentFilterPhrase | Exchange Servers, Transport Hygiene | |
Remove-DatabaseAvailabilityGroup | Database Availability Groups | |
Remove-DatabaseAvailabilityGroupConfiguration | Database Availability Groups | |
Remove-DatabaseAvailabilityGroupNetwork | Database Availability Groups | |
Remove-DatabaseAvailabilityGroupServer | Database Availab ility Groups, Exchange Servers | |
Remove-DataClassification | Data Loss Prevention | |
Remove-DeliveryAgentConnector | Exchange Connectors | |
Remove-DistributionGroup | Distribution Groups, Security Group Creation and Membership, ExchangeCrossServiceIntegration | |
Remove-DlpPolicy | Data Loss Prevention | |
Remove-DlpPolicyTemplate | Data Loss Prevention | |
Remove-DynamicDistributionGroup | Distribution Groups | |
Remove-EcpVirtualDirectory | Exchange Virtual Directories | |
Remove-EdgeSubscription | Edge Subscriptions | |
Remove-EmailAddressPolicy | E-Mail Address Policies | |
Remove-ExchangeCertificate | Exchange Server Certificates | |
Remove-FederatedDomain | Federated Sharing | |
Remove-FederationTrust | Federated Sharing | |
Remove-ForeignConnector | Federated Sharing | |
Remove-GlobalAddressList | Address Lists | |
Remove-GlobalMonitoringOverride | Organization Configuration, View-Only Configuration | |
Remove-GroupMailbox | ExchangeCrossServiceIntegration | |
Remove-HybridConfiguration | Database Copies, Federated Sharing, Mail Recipients | |
Remove-IntraOrganizationConnector | Federated Sharing | |
Remove-JournalRule | Journaling | |
Remove-Mailbox | Mail Recipient Creation | |
Remove-MailboxDatabase | Databases | |
Remove-MailboxDatabaseCopy | Database Copies | |
Remove-MailContact | Mail Recipient Creation, ExchangeCrossServiceIntegration | |
Remove-MailUser | Mail Recipient Creation, ExchangeCrossServiceIntegration | |
Remove-MalwareFilterPolicy | Transport Hygiene | |
Remove-MalwareFilterRule | Transport Hygiene | |
Remove-ManagedContentSettings | Retention Management | |
Remove-ManagedFolder | Retention Management | |
Remove-ManagedFolderMailboxPolicy | Retention Management | |
Remove-ManagementRole | Role Management, UnScoped Role Management | |
Remove-ManagementRoleAssignment | Role Management, UnScoped Role Management | |
Remove-ManagementRoleEntry | Role Management, UnScoped Role Management | |
Remove-ManagementScope | Role Management | |
Remove-MapiVirtualDirectory | Exchange Virtual Directories | |
Remove-Message | Transport Queues | |
Remove-MessageClassification | Transport Rules | |
Remove-MigrationEndpoint | Migration | |
Remove-MigrationUser | Migration | |
Remove-MobileDeviceMailboxPolicy | Recipient Policies | |
Remove-OabVirtualDirectory | Exchange Virtual Directories | |
Remove-OfflineAddressBook | Address Lists | |
Remove-OrganizationRelationship | Federated Sharing | |
Remove-OutlookProtectionRule | Information Rights Management | |
Remove-OutlookProvider | Organization Client Access | |
Remove-OwaMailboxPolicy | Recipient Policies, Mail Recipients | |
Remove-OwaVirtualDirectory | Exchange Virtual Directories | |
Remove-PolicyTipConfig | Data Loss Prevention | |
Remove-PowerShellVirtualDirectory | Exchange Virtual Directories | |
Remove-PublicFolder | Public Folders | |
Remove-PublicFolderDatabase | Databases | |
Remove-ReceiveConnector | Receive Connectors | |
Remove-RemoteDomain | Remote and Accepted Domains | |
Remove-RemoteMailbox | Mail Recipient Creation | |
Remove-ResourcePolicy | WorkloadManagement | |
Remove-ResubmitRequest | Databases | |
Remove-RetentionPolicy | Retention Management | |
Remove-RetentionPolicyTag | Retention Management | |
Remove-RoleAssignmentPolicy | Role Management | |
Remove-RoleGroup | Role Management | |
Remove-RoleGroupMember | Role Management | |
Remove-RoutingGroupConnector | Exchange Connectors | |
Remove-RpcClientAccess | Organization Client Access | |
Remove-SendConnector | Send Connectors | |
Remove-ServerMonitoringOverride | Exchange Servers, View-Only Configuration | |
Remove-SettingOverride | Organization Configuration | |
Remove-SharingPolicy | Federated Sharing | |
Remove-SiteMailboxProvisioningPolicy | Team Mailboxes | |
Remove-StoreMailbox | Databases | |
Remove-ThrottlingPolicy | Recipient Policies, WorkloadManagement | |
Remove-TransportRule | Transport Rules, Data Loss Prevention | |
Remove-UMAutoAttendant | Unified Messaging | |
Remove-UMCallAnsweringRule | UM Mailboxes | |
Remove-UMDialPlan | Unified Messaging | |
Remove-UMHuntGroup | Unified Messaging | |
Remove-UMIPGateway | Un ified Messaging | |
Remove-UMMailboxPolicy | Database Copies, Unified Messaging | |
Remove-WebServicesVirtualDirectory | Exchange Virtual Directories | |
Remove-WorkloadManagementPolicy | WorkloadManagement | |
Remove-WorkloadPolicy | WorkloadManagement | |
Remove-X400AuthoritativeDomain | Remote and Accepted Domains | |
Set-Mailbox | Database, ArchiveDatabase | Disaster Recovery |
Set-MailboxDatabaseCopy | ReplayLagTime | Database Copies |
Set-TransportConfig | Journaling, Organization Transport Settings | |
Search-Mailbox | DeleteContent | Mailbox Search, Mailbox Import Export |
Set-ResubmitRequest | Databases | |
Update-HybridConfiguration | Database Copies, Federated Sharing, Mail Recipients | |
Update-MailboxDatabaseCopy | Database Copies, Databases |
Note: The above table does not include the cmdlet list identified in the section “Removing Access to Data Access Cmdlets” below, but they should also be considered as those cmdlets provide access to messaging data.
For example, if I wanted to ensure that my administrators cannot remove database copies and manipulate the lagged database copy’s configuration, I could remove those cmdlets by using RBAC in the following manner:
$ORoleGroup = Get-RoleGroup “Organization Management"
New-RoleGroup "Protected Organization Management" -Roles $ORoleGroup.Roles
$SRoleGroup = Get-RoleGroup “Server Management"
New-RoleGroup "Protected Server Management" -Roles $SRoleGroup.Roles
Get-ManagementRoleAssignment -RoleAssignee "Protected Organization Management" -Role "Database Copies" -Delegating $false | Remove-ManagementRoleAssignment
Get-ManagementRoleAssignment -RoleAssignee "Protected Server Management" -Role "Database Copies" -Delegating $false | Remove-ManagementRoleAssignment
New-ManagementRole –Parent "Database Copies" –Name "Protected Database Copies"
Remove-ManagementRoleEntry "Protected Database Copies\Remove-MailboxDatabaseCopy"
Additionally, you can also remove access to the ReplayLagTime parameter from the Protected Database Copies role, thereby ensuring administrators cannot disable the lagged database copy.
Set-ManagementRoleEntry "Protected Database Copies\Set-MailboxDatabaseCopy" –Parameters ReplayLagTime -RemoveParameter
New-ManagementRoleAssignment –SecurityGroup "Protected Organization Management” –Role “Protected Database Copies"
New-ManagementRoleAssignment –SecurityGroup "Protected Server Management” –Role “Protected Database Copies"
$OrgAdmins = Get-RoleGroupMember "Organization Management"
$SrvAdmins = Get-RoleGroupMember "Server Management"
$OrgAdmins | ForEach {Add-RoleGroupMember "Protected Organization Management" –Member $_.Name}
$SrvAdmins | ForEach {Add-RoleGroupMember "Protected Server Management" –Member $_.Name}
You can repeat the appropriate steps for each destructive cmdlet that needs to be restricted. Use the following cmdlet to determine which roles contain the desired cmdlets:
Get-ManagementRoleEntry "*\<cmdlet>" | fl name,role
A lagged database copy is a rolling point-in-time (up to 14 days) copy of the database. Lagged database copies were first introduced in Exchange 2007 and have evolved considerably since then. Lagged database copies are part of The Preferred Architecture. While the primary reason for deploying a lagged database copy is protection against rare, catastrophic logical corruption events, lagged database copies can be used to recover mailboxes and/or items that have been deleted by a rogue administrator. By implementing the access control mechanisms previously discussed, the lagged database copy is protected from destruction by a rogue administrator.
There are several mechanisms you can implement to mitigate unwarranted data access within your messaging environment. These mechanisms include auditing, using Bitlocker to encrypt the disk drives, and removing access to certain cmdlets that enable administrators to gain access to user data.
There are several different forms of auditing that can be implemented in the messaging environment. Within Exchange, you can enable Administrator Audit Logging. Administrator Audit Logging captures all operations that are performed within the Exchange Management Shell (EMS) or Exchange Admin Center (EAC).
By default, all cmdlets, except Get- or Search- cmdlets are logged in the audit logs. You can change the cmdlet logging via Set-AdminAuditLogConfig; for example, since Search-Mailbox includes the ability to delete content, you will want to add that cmdlet to the list. Audit logs are stored in an arbitration mailbox. Reports can be accessed via the Search-AdminAuditLog, New-AdminAuditLogSearch cmdlets, or via EAC.
In addition to auditing the actions taken by Exchange administrators managing the service, you will also want to audit server operation events (e.g., logon events). For more information, see the Windows Server Security Auditing Overview article and the Audit Policy Recommendations article for securing Active Directory.
Another way to reduce the attack surface area is to use Bitlocker to ensure that operators with physical access to the servers cannot remove disk drives and access the data contained on them.
As mentioned previously, separation of roles is imperative, otherwise Law #7 cannot be mitigated. As Bitlocker recovery information is stored in Active Directory (specifically the msFVE-RecoveryInformation attribute), delegation of this data must not be granted to Exchange admin istrators.
Using RBAC, organizations can reduce the attack surface area by removing access to cmdlets that allow access to mailbox data. The below table identifies cmdlets that grant access to data, or enable administrators to hide their tracks. Each cmdlet should be evaluated to determine how it is used in your environment and whether it should be removed from day-to-day usage.
Cmdlet | Roles |
Add-ADPermission | Active Directory Permissions |
Add-MailboxFolderPermission | Mail Recipients |
Add-MailboxPermission | Mail Recipients |
Add-PublicFolderClientPermission | Public Folders |
Export-Mailbox | Public Folders |
Export-Message | Transport Queues |
New-MailboxExportRequest | Mailbox Search, Mailbox Import Export |
New-MailboxSearch | Mailbox Search, Legal Hold |
New-MoveRequest | Move Mailboxes |
New-InboxRule | Mail Recipients |
Search-Mailbox | Mailbox Search, Mailbox Import Export |
Set-AdminAuditLogConfig | Audit Logs |
Set-InboxRule | Mail Recipients |
Set-JournalRule | Journaling |
Set-MailboxExportRequest | Mailbox Search, Mailbox Import Export |
Set-MailboxFolderPermission | Mail Recipient Creation |
Set-MailboxSearch | |
New-TransportRule | Transport Rules, Data Loss Prevention |
New-JournalRule | Journaling |
New-MailboxRestoreRequest | Mailbox Search, Legal Hold |
To remove access to the above cmdlets, follow steps 1-7 from the “Removing Access to Destructive Cmdlets” section.
Over time, administrators will require access to restricted cmdlets to perform a necessary operation (e.g., disabling mailboxes, removing unnecessary transport rules, etc.). There are many ways you could go about this. For example, you could simply build RBAC roles for each individual cmdlet (and/or property) that you restrict; when elevation is required, you add the administrator to the appropriate role group, granting them access, and then remove the administrator when the task is complete. Or you could develop a process and workflow that includes the following:
Exchange Online implements a variety of mechanisms to prevent rogue administrators from accessing or destroying data.
Perry Clarke and Vivek Sharma recently discussed Lockbox, a mechanism we use to enforce no standing access, in the article From Inside the Cloud: Who has access to your data within Office 365?
In particular, Exchange Online personnel do not have persistent access to the service or servers; instead, administrators (who have undergone background checks) have to request specific access (to servers, cmdlets, etc.) and can only perform the requested tasks during a specified timeframe. Additionally, for requests for elevation to a role with access to customer data, approval must be performed by another human being and the ability to approve this type of request is restricted to a smaller set of more senior personnel.
We also use other mechanisms to protect the service and customer data. For example, Bitlocker is used to encrypt all disks that contain customer data. When the disks are end-of-life they are shredded, thereby ensuring the data cannot be accessed.
While this article covers the basics, there are many other mechanisms you can implement in your environment to reduce the surface attack area within your messaging environment. For more information about security mechanisms protecting Exchange Online that can be used in on-premises deployments, see the MEC session Exchange Online service security investments: you CAN and SHOULD do this at home.
Ross Smith IV
Principal Program Manager
Office 365 Customer Experience
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.