I’m a big fan of making the ISA firewall a member of the domain when it’s appropriate. When it is appropriate? Whenever you need to authenticate users for either inbound or outbound access control. While this reasoning flies in the face of clueless auditors with clipboards and checkboxes, the fact is that an ISA firewall that is a domain member is almost always going to provide more security than a non-domain member, or definitely more security than a PIX or some other hardware firewall.
However, many businesses are hamstrung by auditors or “network guys” who make it their never ending quest to subvert your attempts at enhancing network security. Because these people were most likely “grandfathered” into the business, it’s hard to teach these dogs new tricks. Because of this, sometimes you have to compromise optimal network security in order to get an incremental improvement over what the “port openers and closers” can provide.
The new ISA firewall now allows you to use LDAP queries to AD domain controllers to authenticate users for Web publishing rules. This feature allows you to leverage AD groups for authenticating incoming connections to OWA, OMA, ActiveSync, SharePoint Portal Server, and any other Web site you publish through the ISA firewall and not require that the ISA firewall be a domain member. While the level of security this provides over a domain member is nil, it does apply a balm to the superstitious minds of router guys who think they understand network security.
However, one big thing that the LDAP authentication feature allows for is querying multiple DCs in unrelated domains. This is something you can’t do when the ISA firewall is a domain member, and thus the LDAP feature included in the new ISA firewall definitely has some things going for it! For example, check out the figure below.
In this figure you see that I have created two LDAP Server Sets. Each set contains a collection of domain controllers for their respective domains. In this example, there is no trust relationship at all between the domains. There is a set for the MSFIREWALL and TACTEAM domains and these domains have no relationship to each other. They are in different forests and there are no trusts. However, I want the ISA firewall to be able to authenticate users in both domains to access a published Web site.
The 2006 ISA firewall allows you to do this by creating Logon Expressions so that when the expression is matched, the authentication requests are forwarded to the correct domain controllers. You can see in the figure about that I’ve created two simple log on expressions:
TACTEAM\* for the TACTEAM DC LDAP Server Set
MSFIREWALL\* for the MSFIREWALL DC LDAP Server Set
The ISA firewall then checks the user logon credentials against these strings to determine what DC the authentication request is forwarded to. Pretty cool, eh?
Thomas W Shinder, M.D.
MVP — ISA Firewalls