We had a short, but interesting conversation regarding whether or not you should put the ISA firewall in a forest separate from the corporate network and then create a one-way trust so that the ISA Firewall forest trusts the corporate network forest. Jason Jones brought this up because we generally don’t recommend such a configuration because it adds to complexity of deployment and creates a number of management headaches that are often hard or impossible to solve.

However, it made me think about how important it is to be consistent. I’m a big advocate of least privilege. It’s least privilege that should guide all of our security decisions when working with the ISA and TMG firewalls. It’s the problems with least privilege that drives me insane regarding the Exchange Team’s ISA guidance, and their lack of support for putting the Client Access Server (CAS) in an authenticated access DMZ segment.

So, if I’m so strong regarding least privilege regarding Exchange Server topologies, it should make sense that I would be a major advocate of putting the ISA/TMG firewall in it’s own forest and creating a one-way trust. And now that I think of it, it does make sense.

However, it makes sense if you have the hardware and software resources to support the configuration. I still consider the security advantages of this configuration to be nominal in 98% of the cases where the ISA/TMG firewalls are deployed. However, for the 2% where it makes sense, it’s worth marshalling the hardware and software resources to make this trusting forest configuration happen.

What are examples of such a deployment? Tim Mullen helped with this. Suppose you log in as admin to the ISA/TMG firewall? Those credentials can be retrieved (given the right set of configuration and management mistakes). What if you were an ISP supporting multiple clients with write access to directory structures? In that case, you have a more complex authentication situation, where joining the ISA/TMG firewall to a single domain doesn’t work, since you would otherwise require that the other domains set up trusts with one another.

So, like all guidance, you have to consider the relative costs and benefits of least privilege. Configuring firewall rules to support Exchange and other servers has very low cost — you don’t need to buy new software, you just need to configure the correct rules. The low cost in this scenario makes it worthwhile to impose least privilege in all cases where it’s just a matter of configuring firewall rules.

However, putting the ISA Firewall in a separate forest has much higher cost, and thus you should consider this the option of choice only if the costs are outweighed by the security advantages, such as the scenario where there are multiple other forests that the ISA/TMG firewall need to authenticate with.

The bottom line is that guidance is just that — guidance. You need to take the entire deployment requirements into consideration and come up with the best solution given the exigencies you’re presented with. That’s why you hire consultants like me, Tim and Jason Jones (and Jim Harrison, if he ever decides to leave Microsoft) to help you make the right decision based on these exigencies.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)