Installing the ISA Firewall in a Trusting Domain - Think Again
In a recent blog post I mentioned that I had softened a bit on my stance regarding the configuration where the ISA Firewall was placed in a forest different from the user forest. In the past I really didn’t think about the core advantage of putting the ISA Firewall in a different forest. The key issue is that putting the ISA Firewall in a different forest from the user forest is least privilege. Since least privilege should guide all your network and computer security decisions, and in order to be consistent, I had to change my opinion regarding the value of putting the ISA Firewall in a trusting forest of its own.
However, you do need to be aware of another security issue when the ISA firewall (and the Forefront TMG firewall) is in a separate forest. That issue is that you cannot take advantage of user (client) certificate authentication at the ISA Firewall. Given how important user certificate authentication is in creating secure Web Publishing Rules, you need to take this into consider.
Security decisions have to be made within the entire security context and how decisions result in the overall security posture of the solution. The miniscule amount of security gained by putting the ISA Firewall in a trusting forest is far overshadowed by the significant security gains you get with user certificate authentication.
Given the relative advantages and disadvantages from a security viewpoint, it’s clear that making the ISA Firewall a member of the user domain is a far more secure solution.
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)
Jason Jones Says:
June 18th, 2008 at 5:46 am
Hi Tom,
You also lose the ability to use Kerberos Contrained Delegation (KCD) which is a key features of ISA Server when used in Active Directory environment, even if certificates are not in use.
As you know, KCD currently only works cross-domain and not cross-forest, so by placing ISA in a separate forest, you also lose the ability to use KCD for published servers in the user forest.
You also need to consider the relative complication introduced by this model as this could acutally reduce security if people are not fully aware of the secure deployment options (and appropriate mitigations) when using forest trusts.
Given all of the above, I would tend to agree with your conclusion…
However, I have seen this solution work well when you are using ISA to specifically protect an extranet which is using a separate forest architecture. In this design, making ISA a member of the extranet forest is the correct thing to do as the servers being published are also in the same forest. In this sceanrio, the lack of internal forest KCD is acceptable as the servers you likely need KCD for are in the extarnet forest anyhow, which will work just fine.
Cheers
JJ
tshinder Says:
June 18th, 2008 at 8:43 am
Hi Jason,
Excellent points! I completely forgot about the KCD feature.
But like I said and as you reinforced, you have to look at the entire security landscape before making any hard and fast decisions. That’s what we get paid the big money for!
Thanks!
Tom