When designing/deploying Exchange within a dispersed environment with segregated Exchange or Active Directory administration it’s important to consider the functionality of Role Based Access Control (RBAC) within Exchange and the function of the Trusted Subsystem. This is directly applicable to how ‘Local Administrators’ are defined for all Exchange Servers within the environment.

As you’ll find, all commands that are executed in either the Exchange Management Shell or the Exchange Management Console are not executed under the security context of your user account. Instead the RBAC components of Exchange take the commands and evaluate it against the Role Group(s) that you have been assigned and any policies that have been granted. If authorized to do so the commands are then executed against Windows, AD or Exchange under the security context of the Exchange server, a member of the “Exchange Trusted Subsystem”.

The Exchange Trusted Subsystem is a highly privileged universal security group that has access to read or modify all Exchange related objects and attributes within Active Directory, effectively making the Exchange Trusted Subsystem an organization-wide Exchange Super user. Because of this local administrator privileges over all of your Exchange servers should be highly restricted to only the most trusted administrators in your organization.

Effectively speaking, this means that anyone that has local administration privileges over a single Exchange server within your organization should be considered, by extension, a full Exchange Organization Administrator as well as Local Administrator against all other Exchange servers.

I've made statements in the past regarding which names are required on your CAS certificates and sometimes get funny responses when I state that you don’t need the internal NetBIOS/FQDN host names on the certificate. Fact is depending on your deployment they may not be required (and in fact there are some arguably good reasons to leave them off). So if you’re interested here is how it’s done here is more detail, for the sake of this discussion I'm going to focus on CAS role only.

The names to use on the cert for this example are mail.domain.com and the second is autodiscover.domain.com (and those are the only names used). Externally connectivity is through ISA which has the CASes published as a web-farm, internally the CASes are shared using a load-balancer; both use the same certificate. All services are published using a SINGLE listener in ISA. Split-brain DNS allows clients internally versus externally to end up where they need to be.

Let’s have a look at the setup:

First, for those that are familiar with the autodiscovery process, domain-joined/domain-connected Outlook clients will query AD for SCP records used for autodiscovery; AD returns a list of in-site and out-of-site CAS URIs Outlook can use for autodiscovery (for non domain-joined/domain-connected clients autodiscover.domain.com is used first). The records that the CASes use are published by Exchange based off the AutodiscoveryserviceinternalURI:
>Get-ClientAccessServer | fl autodiscoverserviceinternalURI
AutoDiscoverServiceInternalUri : https://mail.domain.com/Autodiscover/Autodiscover.xml

This was done on all CASes in your “internet site” (the ones behind the load balancer), the net result is Outlook gets X SCP records (where X equals the number of CASes) that all point to the same place (the load balancer).