So it would seem that a statement I made during TechEd US last week in Boston has mildly stirred a bit of controversy -- no surprise there, I guess, heh. One of my presentations gave an overview of what's new in ISA Server 2006 (download your copy of the release candidate or try it out in some virtual labs). An important new feature is expanded support for additional authentication methods on web listeners and web publishing rules. You can now select LDAP, SecureID, and other one-time password mechanisms, and finally make real use of client certificates through support for Service4User2Proxy in Windows Server 2003 Kerberos.
I made the statement that this additional flexibility makes it easier to build your ISA Server standalone -- rather than domain-joined -- and still enjoy the improved security benefits of authentication delegation. Tom Schinder, our beloved ISA Server MVP, prolific author, and host of the fine www.isaserver.org community site, attended the presentation. It was my apparent preference for standalone servers that Tom disagrees with -- and he wrote about it in a whitepaper on his site.
I have enormous respect for Tom. ISA Server's popularity and success is due in large part to his unflagging dedication and support. He's an entertaining writer, from whom you can not only learn something new but enjoy yourself while doing it. Plus, he advocates improved security that addresses modern threats and rails against the old guard unwilling to give up their stone knives and bearskins.
In this particular case, though, either Tom misunderstood my point or I misstated my point -- it doesn't really matter which. My preference is that, indeed, your ISA Servers should belong to your account domains. In his paper, Tom puts forth some very well-reasoned arguments for doing this -- arguments for which there is very little room to disagree. I don't believe I ever said "the ISA Server should never be a domain member" during the presentation, but honestly I don't remember now.
Yet there's a certain reality among many of the customers I work with, a reality that simply won't abide any firewall having access to account information. This reality is exactly the kind of fossilized thinking that Tom (and I) become so disgusted with. The fact is, ISA Server is one of the strongest, most resilient firewalls on the market. In the seven years since ISA Server 2000 was released, only ten security bulletins were issued for it, and of those, only three are marked critical. In the three years since ISA Server 2004 was released, zero security bulletins have been issued. ISA Server is some of the best code Microsoft has ever created. I have yet to learn of customers experiencing attacks that compromise either an ISA Server or a network protected by one.
Still, all this evidence isn't enough to convince the old guard. Very rarely do we see ISA Server replacing older, less capable firewalls in an organization. What we do see is a slow (too slow) migration toward using ISA Server in the DMZ, configured to publish resources in the internal network. And it is the intrusion of, yes, a Microsoft firewall into the realm of the "networking guys" that requires a delicate dance even still today. I've been advocating this architecture since 2002; you'd think these days we wouldn't even have to discuss DMZs as anything other than the paleo-networking artifacts they are, huh? (And I used to be one of those "networking guys.")
ISA Server's ability to remain standalone while still enabling authentication delegation solves two rather intractable problems: it protects internal web servers from attack while simultaneously existing in a configuration that the networking guys will grudgingly allow. Tom's excellent arguments in favor of domain membership reveal the deployment scenarios probably more common in his consulting work: using ISA Server as a forward proxy. The customers I have conversations with typically use that DMZ-located ISA Server only for reverse proxy. So it's from that viewpoint that I talk about standalone ISA Servers during presentations at conferences.
Tom, you and I are approaching the problem from different experiences, that's all. We are in violent agreement here, and that's a good thing. 🙂