ADC Lessons Learned the Hard Way

What happens when a federation, each with its own domain, separated by firewalls within a single forest, attempts to implement the Active Directory Connector in a federated fashion? The perception was that this deployment model would be more secure, because each department could control their instance of the ADC and firewalls could be left in a "secure" state. 

This turned out not to be true. When you install the ADC in a domain, a group is created, called "Exchange Services." This group contains the account under which the ADC runs. So, in a federation of multiple departments, we had multiple copies of this group. Normally, that wouldn't be a problem. However, this group inherits "Full Control" permissions at the Exchange Organization Level, required for the ADC to do its work. You can probably do the math, but a customer can end up with 20-50 of these groups, each individually owned and operated, each of which has full control over the Exchange environment. The reality is that the custmer makes themselves less secure by distributing the ADC services across all domains, than had the firewalls been opened for a single group of owner-operators to manage the ADC. 

Several options were pursued to try and change the default permissions or add explicit deny ACLs to various groups or individuals, but each option essentially rendered Exchange less supportable (from a PSS perspective) and none of them were fool proof against the Rouge Administrator that wanted full control over the Exchange environment. As a result, it become nessary to follow these additional steps.

1. An account, called "ADC Service Account Access" will be created for each domain and 5.5 site.
2. Permissions Admin ACLs will be set for this account on the Org, Site and Config containers in Exchange 5.5.
3. Any CAs that require reconfiguration to use the new credentials will be updated.
4. Departments will open the firewalls so that the central ADC Server can talk to both Exchange 5.5 and AD Domain Controllers (in conjunction with what's configured on the Connection Agreements for authentication).
5. The CAs operated by the agency will be moved to the central ADC in the root domain.
6. The CAs will be tested at their new location.
7. The ADC at the agency site will be uninstalled.
8. The "Exchange Services" group in the agency's domain will be deleted.
9. Exchange 2003 Setup Procedures can begin.

The net effect of all this is that the federation will be able to better secure their Exchange 2003 environment, by limiting global full control to a smaller number of trusted individuals. The lesson learned however, is one that shows up repeatedly in my posts. Complexity is not security. Sometimes, it's better to make some small adjustments in perceived security for the greater good of achieving real security. This lesson had to be learned the hard way. Departments who were reluctant to open a few ports and IPs in their firewalls ended up with a security model that had zero centralized control or permission-level security.   

I know that Microsoft's products aren't specifically designed for the truly federated collaborative environment, where no single group has political top-level control (but maybe on group assumes technical top-level control). I've always told my customers that deploying our products in this manner is like taking a Ford Escort four-wheeling over stumps. Yes, it will work, but the Escort wasn't really designed for off-roading.

What I and other consultants dealing with federations, am missing, and I hope to bridge the gap of, is more comprehensive documentation on exacly how our products work, why we make certain recommendations best practices and what could be the implication of failing to follow such practices in real life, particularly in federated models. Federations have been a true test of the flexibility of our products since 1999, and when our customers follow best practices, our products can perform well and with reasonable security (but not total isolation). But when we fail to provide full coverage of the technical limitations of our products, our customers can find themselves in an unsecure state, technically, but perceived secure state politically. Technical security should always trump political security and it is my responsibility to to ensure that my customers engage in these discussions with the proper level of knowledge.