03 Mar 2010 01:03:46 am
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.
30 Oct 2009 04:58:34 pm
25 Aug 2008 01:14:54 am
Good news from our friends at Microsoft. They are continuing to test & update their patch to this issue (which as I mentioned already requires some changes to the way the shares are created).
Currently the plan is to release an interim fix available for SP1 RU3, and to incorporate the fix to an upcoming SP1 RU.
NOTE: as of now they are not planning on making the fix available to any builds prior to SP1 RU3, so make sure you update now so you can take advantage of this fix when it’s released.
13 Aug 2008 08:21:03 pm
I’ve been working with the folks @ MSFT on this issue and figured I would post a brief update.
The Exchange code is getting modified to pass a 503 struct which allows them to pass the name of the node the share should be created against (in this case \\nodename as well as \\cmsname).
There is a fix and it is currently undergoing testing, but has not been released as of yet.
02 Jul 2008 12:35:34 pm
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).
Next I need to make sure EWS uses the right URLs so that Availability, etc. work correctly:
>Get-WebServicesVirtualDirectory | fl internalURL, externalURL
InternalUrl : https://mail.domain.com/EWS/Exchange.asmx
ExternalUrl : https://mail.domain.com/EWS/Exchange.asmx
The rest of the URL configuration for things like OWA, OAB, etc. can all be done from the Management Console:
>Get-OwaVirtualDirectory "owa (Default Web Site)" | fl internalURL,externalURL
InternalUrl : https://mail.domain.com/owa
ExternalUrl : https://mail.domain.com/owa
>Get-OabVirtualDirectory | fl internalURL, externalURL
InternalUrl : http://mail.domain.com/OAB
ExternalUrl : https://mail.domain.com/OAB
For those who want a nice visual of how Outlook builds the profile using AutoDiscovery internally versus externally I've included a couple of slides from TechEd last year as a reference: