次の方法で共有


Should your ISA Server be in your domain? Film at 11!

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. :)

Comments

  • Anonymous
    January 01, 2003
    PingBack from http://blogs.isaserver.org/shinder/2006/06/21/steve-riley-responds-to-why-the-isa-firewall-should-be-in-the-domain-article/
  • Anonymous
    June 21, 2006
    The comment has been removed
  • Anonymous
    June 22, 2006
    The comment has been removed
  • Anonymous
    June 22, 2006
    The comment has been removed
  • Anonymous
    June 24, 2006
    (to Tony)

    This is exactly the sort of "old guard" thinking that is being debunked by both Steve & Tom.

    The tired old "heterogeneous vs. homogenous" argument is irrelevant to the question of ISA domain membership, and in fact, only serves to confuse an already volatile issue.

    In fact, ISA services do not operate in any domain context and as such, offer no acceess to the domain.  Go back and read Steve's response; while there have been some few security patches for ISA 2000 (now in extended support hint) and none for ISA 2004; the fact still remains that no ISA server has ever been compromised outside of a lab.

    You can argue theoretical ideas all you want; the fact remains that ISA installed on a domain member is no less "secure" than ISA installed on a WG machine.
  • Anonymous
    June 29, 2006
    The comment has been removed
  • Anonymous
    June 30, 2006
    Maybe one day, when people stop viewing software and product selection as a religion, then the scornful laughs will disappear. Of course, that means that the "specialists" -- or, more accurately, shamans -- will have moved on to idyllic pastures populated only by sheep who never argue.

    Even your pen testers display some reluctance. They say, you write: "very rarely do we manage a successful attack" against "a properly configured ISA Server." I would be very curious indeed to learn of an attack that DOES succeed against a properly configured ISA Server...
  • Anonymous
    July 06, 2006
    The comment has been removed
  • Anonymous
    July 18, 2006
    When I read Tom's white paper, I must admit that I was a little disturbed! "How could the two foremost authorities on ISA disagree on an issue I thought should not be moot", I asked myself. I have 'known' Tom from his isaserver.org forum and had the privilege to exchange a few e-mails with him whilst deploying my own ISA 2004 last year. Indeed, all my deployments are largely due to his whitepapers. As you will have guessed, the ISA servers are in the domain. I also attended the TechEd presentations by Steve and Jesper in Jo'burg last year, and boy, was I impressed!

    All I can say is that I am delighted that the two gurus (you really are) are reading from the same script. I am also looking forward to the next series of articles from Tom on how to properly configure an ISA server.
  • Anonymous
    August 07, 2006
    The comment has been removed