Debunking the Myth that the ISA Firewall Should Not be a Domain Member
WHITE PAPER: Debunking the Myth that the ISA Firewall Should Not be a Domain Member
By Thomas W Shinder MD, MVP
Discuss this article on the Web Boards at http://tinyurl.com/oxfus
At last week’s TechEd I had the opportunity to view a number of sessions and one of those was about the new ISA firewall, ISA 2006, given by Steve Riley. If you haven’t had a chance to see Steve talk, you should do yourself a favor and make it a point to see one of his live presentations. Steve is a very dynamic and animated speaker and he really knows how to rile up the troops by hoisting up straw men for a knock down drag out fight. One thing I can always say about Steve’s talks is I always leave the room thinking about something I hadn’t thought about before entering the room that day.
However, sometimes Steve makes my life difficult because he gets ahead of himself. In the most recent rendition of Steve’s “what can I say today to make Tom’s life more difficult” he stated that “the ISA Server should never be a domain member”. When I heard that, my jaw dropped, my vision began to blur and turn black, images of man’s inhumanity to man came to mind and I had to be shaken back into a normal level of consciousness by good friend Chris Gregory.
Why did I have this cataclysmic reaction to what Steve said? For the last two years I’ve been trying to communicate to ISA firewall admins that a domain member machine is more secure and more flexible than a non-domain member machine and that they do themselves and their companies a disservice by not joining the ISA firewall to the domain. This is a significant issue and not something to be taken lightly because there is a serious security hit you take when you don’t join the ISA firewall to the domain.
This has inspired me to write a long winded, but detailed and thoughtful, analysis on the domain versus non-domain membership debate for ISA firewall arrays. I do this because I can’t get on stage and oracularly state “no ISA firewall should ever be a workgroup member”, get away with it, and then have Steve later answer to the 1000 attendees who say to him “I understand that the ISA firewall should NEVER be a workgroup member, how do I do X and Y and Z”.
I recently gave a talk to a group a high-powered firewall consultants on this issue and prepared some PowerPoint slides on this topic. Since I’m sitting in a cramped airplane seat right in front of the exit row (which means I can put my seat back), I’m going to copy and paste the PointPoint slides into this document so that I can remember the outline of my discussion 🙂
This white paper will discuss the advantages and disadvantages of domain and workgroup configurations for ISA firewall arrays. I’ll follow up with a second white paper and describe scenarios where ISA firewall arrays must be domain members, when they should be domain members, and when it doesn’t matter if they’re domain members or not. That paper will also include a description of some of the psychiatric and “layer 8” issues influencing whether or not the ISA firewall array is joined to the Active Directory domain.
Should ISA Firewall Arrays be Placed in a Domain or Workgroup?
Should the ISA firewall array be placed in a domain or a workgroup? That is the question. Is it nobler to place the ISA firewall in a workgroup where you can avoid the catcalls of clueless compliance managers, “hardware” firewall know-nothings, or “network guys” who think of network security as “port opening and closing”, or should you bear the slings and arrows of the same harridan housewives and carping screws for placing the ISA firewall in the domain, where you can get a higher level of overall security and substantially improve your security position?
Let’s look at the following:
- The advantages of domain membership
- The disadvantages of domain membership
- The advantages of non-domain (workgroup) membership
- The disadvantages of non-domain (workgroup) membership
In this article I’ll focus on the ISA firewall’s Enterprise Edition, as this version of the ISA firewall is more likely to be deployed in enterprise environments where the ISA firewall admin has to interface with IT infrastructure groups with antiquated and fossilized misconceptions about network security. In a future article I’ll discuss with you the serious problem we have today regarding the hijacking of network security by these “network guys” and how it harms every level of network information security today.
The Advantages of Domain Membership
There are many advantages to domain membership. These are outlined in the figure below.
- Granular User/Group based access control
When the ISA firewall is a domain member, you can exert granular user and group based access controls over all communications moving to and through the ISA firewall. This includes all communications moving inbound and outbound to and from the corporate network. You can use domain groups and you don’t need to create Ad Hoc ISA firewall groups, which is what you need to do when using RADIUS authentication. While it’s true that ISA 2006 adds the ability to use LDAP authentication to enable Active Directory group enumeration, that feature only works for Web Publishing Rules, and does not enable the same function for outbound access control via ISA firewall Access Rules. LDAP authentication may also be problematic because it may increase the risk of account lockout. Without making the ISA firewall a domain member, you have to depend on the RADIUS kludge for outbound access control for Web protocols and you get no user/group based access control for any other protocols.
- No need to create array accounts for intra-array communications
ISA firewall array members need to authenticate with one another for intra-array communications. This takes place transparently when the ISA firewall array members are part of the domain. When the ISA firewall array member isn’t a domain member, you need to create mirrored accounts on the array members. Since there is no password synchronization among workgroup members, you need to manually change the password of these accounts on each array member. If you have 4 ISA firewall arrays, each containing 31 members, you’ll have to make sure to reserve some time for password change day. Another problem is that you won’t be able to manage the machines from a remote workstation by transparently logging into the array; instead, you’ll need to enter your username and password each time, which will make the “shoulder surfers” in your organization quite happy. There are other problems too, as you’ll see later.
- Full support for user certificate authentication
User certificate authentication (unfortunately referred to as “client” certificate authentication) enables a user to present a user certificate to authenticate to the ISA firewall in Web Publishing scenarios. This is a powerful authentication scheme, because these certificates can be installed on smart cards and other devices to prevent the need for transmitting user credentials over the wire. You have full support for user certificate authentication when the ISA firewall is a domain member. You have no support for user certificate authentication when the ISA firewall is not a domain member. I can hear what you’re thinking – I’ll create a separate domain for my ISA firewall array in the same forest as the user domain, and then create a one-way trust. This is a common physic applied to those wounded by the superstition of “domain members ISA firewalls aren’t secure” canard. While the physician of this solution may be applying a soft touch, that’s all you’ll get from it because you still won’t be able to use user certificate authentication in a workgroup configuration.
- Full support for Microsoft Operations Manager (MOM)
MOM is a powerful tool for monitoring and reporting your ISA firewall’s heath and configuration status. While it’s possible to configure the MOM agent to work on non-domain members, there are installation, configuration and management issues that are problematic on non-domain members. On the other hand, monitoring domain member ISA firewalls with MOM is a no-brainer; it’s easy to setup, configure and manage. Easy setup, configuration and management means fewer errors while leads to better security.
- Full support for the Firewall Client
I can’t say enough good things about the Firewall client. The Firewall client enables transparent remoting of connections to the ISA firewall for all network connections made by Winsock applications. Think of the Firewall client as a generic Winsock proxy. With the Firewall client you can log user name, application name, machine name, and much more for every connection made by a user for any protocol used to connect to a resource through the ISA firewall. The Firewall client provides you granular user/group based access control over any protocol and that information is stored in the ISA firewall’s log files for compliance management and network forensics. You can’t get this kind of information logged if you use any other firewall on the market today. But if you wish to avail yourself of the profound benefits the Firewall client provides, the ISA firewall has to be a domain member. If your ISA firewall is a workgroup member, then the Firewall client represents just a missed opportunity to secure your network infrastructure and be an IT hero because you won’t be able to use it.
- Full support for Group Policy Management
Every Windows admin knows Group Policy is a key component of a well-managed and secure Windows network. When the ISA firewall arrays are members of an Active Directory domain, you can create Group Policy objects that control machine configuration on all members of an ISA firewall array. This makes it easy to centralize core OS security administration and configuration that would have to be otherwise manually configured on each array member. This is a significant benefit, as there can be literally thousands of machines participating in hundreds of ISA firewall arrays throughout the organization. Do you really want to do that configuration separately for each server in each workgroup? Without joining the ISA firewall’s to the domain, you lose out on centralized security management, which not only reduces your overall level of security but also increases administrative overhead. No good.
- Array admins can log in transparently from any Active Directory managed machine in the domain
As mentioned earlier, when the ISA firewalls array members are part of the domain, you can manage that array from any workstation that is part of the same or trusted domain. This has two major advantages. First, it’s more convenient. Since it’s more convenient, you won’t avoid performing crucial ISA firewall management tasks that you might hesitate doing if typing in the 37 character ISA firewall admin password is a burden (this is a realistic scenario and one I’ve seen more than once) and second, you avoid having to type in the password multiple times per day, so that shoulder surfers don’t have a chance to figure out the password during one of your log on attempts.
- Infinitely easier to deploy and manage
Easy is a double-edge sword, especially when we’re talking about security. On the one hand, there’s easy like a “hardware firewall” where they just let everything outbound and allow any kind of response from a remote server, as long as someone made an initial connection request to that server, or like SBS wizards that magically do stuff that try to mitigate the security nightmare that is the Internet facing SBS device. On the other hand, there is “easy” that simplifies complex and laborious configuration for the knowledgeable admin who might make a typo or a “click-o” somewhere along the way.
It is this version of “easy” that domain membership provides the ISA firewall admin that makes the configuration more secure. Domain member ISA firewall arrays are very simple to setup and secure. On the other hand, workgroup member ISA firewall arrays are very complex to setup and there are many steps where errors can be made and where a mistake in any one of those steps could compromise not only the ISA firewall array, but potentially the entire network. I’ll go through some of the configuration gymnastics required to make workgroup-mode work later in this article.
Disadvantages of Domain Membership
In spite of how often the phrase “it’s all good” is used, the fact is that nothing is all good. Some things are better than others, some things are mostly good, other things are almost all good, but nothing is all good. That’s true for domain membership for ISA firewall array members. The figure below summarizes the “not all good” features of domain membership.
- If someone compromises the Active Directory, they can own the ISA firewall
You got to wonder where a person’s head is at when they confront you with this one. The domain membership naysayers claim that if the Active Directory is compromised, then the compromiser will be able to leverage that ownership of the Active Directory against the ISA firewall. Let me tell you, if your Active Directory is owned to that extent, I think the ISA firewall will be the least of your problems. Imagine the scenario where someone compromises the Active Directory and owns the domain admin account. That attacker now has access to all file servers, Web servers, database servers, Exchange Servers and whatever server you’d like to throw into the mix. Since the ISA firewall is likely configured to give members of the domain admins group HTTP access outbound, why would they need to do anything to the ISA firewall? They’ll download remote control software that works over HTTP to any server they like, do some neat tricks to determine what sites they need to impersonate to get through the ISA firewall’s list of trusted sites, and go to town. They’ll never need to touch the ISA firewall. Someone with legit domain credentials doesn’t need to mess with the ISA firewall (which would call undo attention to the wrong people – from the attackers point of view) to send out his ill-gotten gain if he owns the Active Directory.
- If the Firewall is owned, the Active Directory may become accessible
This one is about as whack as the last one. If the ISA firewall is owned to the extent that they can leverage the machine’s domain membership to attack the corpnet, then it really doesn’t matter whether the machine is a domain member or not. What can someone who owns the ISA firewall do when it’s a domain member? OK, the attacker will have access to the intradomain protocols to the DC. What will he do with them? I don’t know, you tell me. Gather user names? So what? Passwords provide security, not user names. No one has been able to tell me what an attacker can do with access to the intradomain protocols.
Sure, if the ISA firewall is owned, the attacker can change firewall policy to his heart’s content, but that’s true for workgroup mode ISA firewall’s as well, so the scenario doesn’t change based on domain membership. Also, unless the attacker is a script kiddie or click kiddie who’s interested in a worthless DoS attack (worthless from the point of view of stealing or destroying corporate information assets), the intruder wants to lie low and go under the ISA firewall’s radar. What the professional network criminal doesn’t want to do is call attention to himself by monkeying around with the ISA firewall, which is likely to be one of the most closely monitored devices on the network.
However, the entire discussion is moot, because after over 6 years of worldwide deployment, there hasn’t been a single case of a compromised ISA firewall when the ISA firewall was properly configured. At this point I’m going to temporize on what a “correctly configured” ISA firewall is, as that’s a long discussion in itself, although one of the features is that the ISA firewall array is in the domain. A good fellow at TechEd last week brought up this topic and pointed out that I’ve never really described what a properly configured ISA firewall was, at least in this context. I promise to provide you that information in the very near future. Needless to say, at this point concerns over “owned” ISA firewalls are for the Chicken Little’s in the crowd and hardware firewall sales guys and their “hypmotized network guy” acolytes.
- Domain Admins can admin the ISA firewall
It is true that domain admins can access and change the configuration of a domain joined ISA firewall array. Is this a real security issue? If you can’t trust your Active Directory domain administrators, who can you trust? Do you select domain admins off the street and slap a badge on them or do you do background checks, financial checks, criminal history checks, personal history checks, and whatever other checks you like to confirm that you can trust them since they hold the keys to the mint for all Microsoft networking servers and services at your company? I suppose that domain member SQL and Exchange Servers aren’t secure because domain admins can admin those servers. Only the most SANS infused kewl-ayd drinker would be concerned about this issue.
Advantages of a Workgroup
Just like nothing can be “all good”, nothing can be all bad. The same is true for workgroup mode, non-domain member ISA firewalls. The figure below summarizes the advantages of the non-domain member ISA firewall array.
- If the firewall is compromised, the attacker might not be able to get to the Active Directory
This is the flip side of the previous discussion. The operational word is might. The attacker might not be able to access the Active Directory. It all depends on the location of the ISA firewall. If the ISA firewall is going to do any kind of authentication, even if deployed as a unihomed reverse proxy in a “hardware” firewall’s DMZ, the attack can potentially gather valuable user credentials. The attacker can install a network sniffer and other more advanced tools on the unihomed ISA firewall in the “hardware” firewall’s DMZ and harvest valuable information that can lead to the stealing of credentials. No, I’m not going to tell you how to do it, it’s enough to know that it’s possible. Now that he has this information he can easily use out-of-band methods to get into the network and leverage this information.
Once again, remember that these are just flights of fancy, as there isn’t a documented case of a compromised ISA firewall that’s been properly configured and professional attackers (the ones you need to worry about) aren’t going to attack the ISA firewall because they need to do everything they can to remain unnoticed for as long as possible.
- Domain admins can’t admin the array
In workgroup mode, you configure user accounts that are used to admin the ISA firewall array and these accounts are mirrored on each firewall array member. Since these accounts are unlikely to have the same user names and passwords as any of the Active Directory domain admins, your dangerous and reckless domain administrators won’t be able to subvert network security by playing around with your ISA firewall configuration. In reality, domain admins are neither dangerous nor reckless and they are the most trusted computer operators in the organization. If you can’t trust your domain admins, your organization has much larger problems than the fact that they can admin the ISA firewall array.
- If the Active Directory is owned, the firewall won’t be affected
It’s true. If someone owns your Active Directory and the ISA firewall array is not a member of the domain, domain admin accounts won’t be able to change the ISA firewall configuration. Of course, he’s compromised and cratered your Exchange, SQL, SharePoint, and other Microsoft servers on the network, but the ISA firewall will keep humming. The workgroup mode ISA firewall array becomes the Nero of firewalls in the burning ashes of your network Rome and is the last man standing. At this point do you really care what the configuration of the firewall is? And if so, don’t you think that you’ll have pulled the plug on the Internet by the time you notice that all these servers are compromised? And will it really matter? The likelihood is that he’ll be able to leverage a valid user account to pass information outside the network without touching the ISA firewall configuration.
Disadvantages of Non-Domain Member ISA Firewalls
Now let’s get to the most interesting and important stuff – the disadvantages of the workgroup mode non-domain member ISA firewall array. Many of these are the converse of the advantages of the domain member advantages, but it’s worth restating things to make sure they sink in. The figure below summarizes these disadvantages (but doesn’t include all of them because there are more which I’ve included in the list under the figure).
- Requires server certificate on the CSS
In order for workgroup mode machines to authenticate with the CSS, there must be a server certificate on the CSS. Each ISA firewall array member and the CSS must have the CA certificate of the CA issuing the server certificate installed in it’s Trusted Root Certification Authorities machine certificate store. You won’t be able to use the Certificates MMC to do this, because the MMC requires all machines be in the same domain. So you get the pleasure of figuring out how to use the Web enrollment site or some other mechanism to generate the certificate. Remember to get the common/subject name right on the certificates or else everything is going to fall apart, as I’ll detail in the next bullet point. None of this is particularly hard (for me), but if you’re not a PKI guy, then get ready for Mr. Toad’s wild ride.
- Requires convoluted DNS changes
ISA firewall array members need to be able to resolve the name of the CSSs to communicate with them. However, the name of the CSS machine might not be the name on the certificate. For example, suppose you want to put the CSS on one of the workgroup mode ISA firewall array members. The firewall array members communicate with one another via the intra-array NIC. The firewall array member on which the CSS is installed already has his machine name registered in DNS and it resolves to the IP address on the internal interface of that machine. Since we can’t use the machine name, we need to use a common/subject name on the server certificate that is different than the machine name and enter a Host (A) record in the DNS for that name that resolves to the IP address on the intra-array NIC on that ISA firewall array member hosting the CSS. Not only that, but you’ll have to use the Windows Server 2003 Support tool, setspn, to register that name in the Active Directory. You don’t know about service principle names? Get ready to burn the midnight oil. Again, none is this is particularly hard to do (for me), but if you haven’t done this 500 times, it might be hard for you to remember all the moving parts.
- Must track certificate status to avoid expired certificates
Certificates expire, and they expire at the worst times. Unlike machine accounts in the Active Directory that never expire, your certificate on the CSS will expire and you won’t be happy when you can’t figure out why the ISA firewall array can’t communicate with the CSS until you’ve beat your head against the problem for 8 hours and realized it was a certificate expiration issue.
- Must use RADIUS or SecurID for authentication for reverse proxy (LDAP in ISA 2006)
Unlike the ISA firewall array that’s joined to the domain where you have a dizzying array of authentication options for reverse proxy authentication, with the workgroup mode ISA firewall, you get RADIUS and SecurID authentication (with ISA 2006 you’ll get RADIUS OTP and LDAP). When you have nothing to do, check out the ISA firewall logs for the number of RADIUS requests made during the average connection to your published OWA site. You won’t have to wonder why access to your OWA site is so slow. You’ve also introduced another point of failure if you introduce a dedicated RADIUS server (or even if the RADIUS service on a DC fails) or if the ACE server goes belly up. And remember with RADIUS you can’t leverage your domain groups for reverse proxy authorization; you’ll have to create your own ISA firewall Groups and populate them one user at a time in the ISA firewall console, or give up and just allow all authenticated users (not an ideal access control scenario).
In ISA 2006 you’ll be able to leverage Active Directory groups by querying DCs, but as mentioned previously, there is potentially an increased risk of an account lockout DoS using LDAP (unconfirmed at this time). And if you allow LDAP from the ISA firewall to the DCs, won’t the network guy “port openers” get as apoplectic as they would with the ports that need to be opened for full domain member access (this applies to the unihomed ISA firewall in a “hardware” firewall DMZ scenario).
- Can only use RADIUS for forward proxy
In a forward proxy scenario, the only authentication method available is RADIUS and that can only be used for Web connections. All other traffic must go through some other device which is unlikely to have the ISA firewall’s level of access and accountability controls. Now you’re at the mercy of whatever device is used to forward non-Web traffic outside the network. RADIUS for forward proxy scenarios suffers from the same limitations as mentioned above in the reverse proxy configuration.
- On-box accounts required for intra-array communications and firewall array management
As I mentioned earlier, you need to create separate accounts in the local SAM of each ISA firewall array member for intra-array communication and for firewall administration. While this isn’t much of a problem if you have a single two-member array, the situation gets a little stickier when you have 31 members in your array and you have dozens of arrays throughout your distributed world-wide network. And then there’s all the other stuff I’ve mentioned earlier regarding shoulder surfers, delays in configuration changes because you don’t want to retype a 67 character password, administrative overhead of maintaining what is essentially a separate and distinct directory infrastructure dedicated to your firewall arrays. What you end up with in the workgroup ISA firewall array configuration is a significantly higher level of administrative overhead and an overall lower level of security.
- Can’t use user certificate authentication
The inability to support user certificate authentication is one of the major security hits you take when installing the ISA firewall array in workgroup mode. If you want to avoid passing user name and password, you’re going to need to use SecurID, or if you’re on ISA Server 2006, then you can work with RADIUS one-time passwords. Lack of user certificate authentication is especially bad news for people who want to use user certificate authentication on their Windows Mobile devices.
During TechEd last week, I had a great conversion with a couple of smart guys who wanted to know how to make sure that only their managed Windows mobile devices can connect to their network through the ISA firewall. I suggested user certificate authentication and mapping a global user certificate to a Windows mobile account. If they didn’t join their ISA firewall to the domain, they wouldn’t be able to do this and could be left out in the cold in their efforts to increase security for their Windows Mobile infrastructure.
- No support for VPN user mapping when users connect from non-Windows VPN clients
ISA 2004 and 2006 have a very cool feature that allows you to map user authentication attempts from non-Windows VPN clients to user accounts contained in the Active Directory. For example, if you have a user logging in with a Apple VPN client, that user can log in with his AD user name and password and that log on attempt will be mapped to a user account in the Active Directory. As far as I know, no other VPN server supports this type of user account mapping. But if you install the ISA firewall array in workgroup mode, you’ll be like everyone else who doesn’t have an ISA firewall and VPN server and won’t have access to this exceptional ability to map VPN client connections to Active Directory user accounts for non-Windows clients.
- No support for user/group based outbound access control except for Web traffic
This is a big one and a major reason why the workgroup mode configuration significantly reduces your overall security posture. A workgroup mode machine is essentially a simple forward and reverse Web proxy device, at least within the context of security. For non-Web protocols, you get no more security from the ISA firewall than what you would get with a typical “hardware” firewall, which we know isn’t very much. Even worse, like a typical hardware firewall, the information contained in the firewall logs isn’t very comprehensive, and if I were to audit a network with a typical hardware firewall or workgroup mode ISA firewall, I would have to ding them on the abysmally low amount of useful information contained in the firewall log files (although the ISA workgroup mode would be superior to the typical “hardware” firewall because at least you have some useful information in the Web proxy logs). User and group based outbound access control is no longer a convenience or optional security measure.
If you are the victim of an inside job (which is the case for most network compromise scenarios), and you don’t have comprehensive logging of user name, machine name, application name information in your logs, you’re going to have to answer for your lack of due diligence and explain exactly why you can’t provide the authorities and investigator this information. If you do find yourself in this situation, don’t try to fool the examiners with explanations like “hardware firewalls are more secure” or “domain members aren’t secure” because their one-two punch will put your b*tt out to lunch.
- ONLY ONE CSS SUPPORTED!
The configuration storage server (CSS) contains all the ISA firewall array configuration information. Information about ISA firewall array configuration is pulled from the CSS into the local registry of each firewall array member. All firewall configuration and management tasks are done at the CSS, not directly with any ISA firewall array member. If the ISA firewall array cannot contact a CSS, the ISA firewall array will continue to provide comprehensive stateful packet and application layer inspection, but you will not be able to make changes to the current configuration until the ISA firewall array can contact a CSS. When the CSS is installed in a workgroup (for example, when the ISA firewall array is in workgroup configuration and the CSS is installed on one of the firewall array members) you can install only a single CSS for the entire array. This could be problematic if you want to install an array of 31 ISA firewalls.
In contrast, if the CSS were contained on a domain member, then you could configure multiple CSSs for failover and fault tolerance and avoid the embarrassing situation where you’re asked to make changes to the firewall configuration only to find yourself having to explain that you installed the CSS on a workgroup member in spite of comprehensive information on why you should have installed it on a domain member.
In this white paper I went over the advantages and disadvantages of making the ISA firewall array members part of a workgroup or an Active Directory domain. Through a careful analysis of these relative advantages and disadvantages, it became clear that making the ISA firewall array members part of the Active Directory domain provides a vastly more secure and more flexible firewall configuration than making the firewall array part of a workgroup. In the analysis we are able to come to the solid conclusion that the overall security posture provided by a domain member ISA firewall is higher than a workgroup mode ISA firewall. While this conclusion flies in the face of the average network infrastructure guy who doesn’t understand network and application security, it’s clear that when you take all the salient factors into account, we can’t justify the “tribal knowledge” on which the average network infrastructure IT group uses to come to their false conclusions regarding domain membership.
Discuss this article on the Web Boards at http://tinyurl.com/oxfus