If you would like to read the next parts in this article series please go to:
- TMG Firewall Options for Scalability and High Availability (Part 1)
- TMG Firewall Options for Scalability and High Availability (Part 3)
Introduction
In my previous article in this series about TMG firewall high availability, I discussed the topic of enterprise arrays and how you can use CARP for outbound load balancing. In this article we’ll finish up with that topic by talking a little about enterprise configuration storage and enterprise policies and then next time, we’ll go on to discuss multiple ISP support.
Enterprise array overview
As I mentioned in the previous article, you can have two types of TMG firewall arrays. One is the standalone array and the other is the enterprise array. The standalone array is a “standalone” because that array can only be managed within itself. It can’t be a part of a centralized management solution where multiple arrays are managed. One of the machines that is a member of the array becomes the “array manager” and on the array manager machine is the configuration settings for the entire array. Note that both the standalone and the enterprise arrays represent a single logical firewall configuration – where all the members of the array share a common configuration. The difference is where the configuration is stored. For the standalone array, that configuration information is stored in Active Directory LDS database on the array manager.
It’s quite a bit different for the enterprise array. In an enterprise array, there is no array manager. Instead, the array is managed from an Enterprise Management Server (EMS). The configuration for the array (in fact, for all the arrays that are managed from the EMS), is stored in an Active Directory Lightweight Directory Service (AD LDS) database. Note that for both the standalone array and the arrays that are managed by an EMS, Active Directory LDS is installed on all the members of the array. However, when the array member joins the array, the database is disabled, except in the case of the array manager for a standalone array. In both cases, all array members will contact the array manager to obtain configuration settings.
In most cases when you configure an array to be managed by an EMS, all the machines in the array, as well as the EMS machine, are going to be domain members. This greatly simplifies the configuration and arguably can make the entire configuration more secure. However, there are times when you will need to make both the EMS and the arrays members non-domain members. That means all the machines participating in the configuration will need to be workgroup members.
Configuration storage
The machine that contains the configuration database is often referred to as the CSS or “configuration storage server” (not to be confused with the acronym for Cascading Style Sheet that’s commonly used in web development circles). The CSS can be an original CSS, or you can create a backup CSS to enable high availability of the CSS so that in the event that the original CSS goes down, you’ll have another one that can take over the disabled CSS.
The enterprise configuration enables you to create enterprise policies, which is something that you can’t do when you have only a single TMG firewall. The difference between non-enterprise policies and enterprise policies is that the non-enterprise firewall policies can only be applied to a single TMG firewall. Sort of. That’s not entirely true, because you can export the firewall policy from a single TMG firewall and import that policy to another TMG firewall. But that’s a high overhead procedure and doesn’t make it very easy to ensure that the policy is consistent across multiple TMG firewalls. In contrast, when you create an enterprise TMG firewall policy, that policy will be automatically applied to all of the machines in an array, and can also be applied to machines that are in different arrays. This allows you to create a single firewall policy and then automatically deploy it to literally thousands of array members at the same time.
Division of responsibilities
Enterprise policies are categorized roughly based on the duties of the particular firewall array. We all know that the TMG firewall is the Swiss Army Knife of firewalls, in that it can do so many things that you sometimes forget how many different roles and functions a TMG firewall can perform. However, just because the TMG firewall can do a lot of different things doesn’t mean you should have a single TMG firewall or firewall arrays doing all of those things. It’s much more efficient, from both a management and an operations point of view, to split out your arrays based on specific functionalities that those arrays will perform.
Those duties can be logically split between the core features sets that the TMG firewall can perform. These are:
- VPN server and site to site VPN gateway
- Inbound access server that allows inbound access to services based on web publishing rules and server publishing rules
- Outbound access server, which controls what users on the corporate network can access on the Internet
This essentially means that arrays should be configured as:
- VPN arrays
- Inbound arrays
- Outbound arrays
This is a good way to deploy your arrays because you often find that TMG firewall administrators have specialized skills in one of these areas. Your VPN team might manage VPN connectivity not just for TMG firewalls, but for other firewalls or VPN concentrators as well. Another team might be responsible for the inbound access configuration, as the inbound web proxy will sometimes require some specialized knowledge about the web applications that are published to the Internet, and this requires a higher level of sophistication about the HTTP protocol and the protocols that use HTTP as a transport. Finally, the outbound access scenario will require the administrator to have a higher level of insight into what protocols are required in order to access external resources, what applications are used on the corporate network to reach external resources, and what sites can be considered safe versus unsafe.
Enterprise policies and administration
When you split out your TMG firewalls in this way, you can take advantage of the types of policies that you can create with the TMG enterprise arrays. It is therefore not a coincidence that the types of enterprise policies that you can configure are based on these three categories; you can create enterprise firewall policies for VPN settings, enterprise firewall policies for outbound access settings, and enterprise firewall policies for inbound access settings. It all makes sense.
But who can create these policies? Is there a single firewall administrator level of access? That used to be the case with previous versions of the TMG firewall, but now there is some level of gradation in terms of administrator accounts that can be used to access the TMG enterprise management interface. The three types of administrators include:
- Enterprise Administrator – this administrator has total control of the configuration environment and can make any type of change to the array and enterprise management configuration.
- Enterprise Auditor – this administrator does not have the full “rule of the roost”. In contract, this level of administrator is able to see the configuration for the enterprise management environment and can also view the configuration of all the arrays that are managed by the EMS. However, this is a “look, but don’t touch” scenario, because while the enterprise auditor can view all of the settings, the enterprise auditor is not allowed to make any kind of change to the configuration.
- Enterprise Policy Editor – Enterprise administrators can assign administrators permissions for specific enterprise policies, thus limiting enterprise-level administration to a specific policy. Enterprise Policy Editors can create rules for the specific enterprise policy, but cannot create new enterprise policies.
At this point it’s important to note that while you can take advantage of the power of enterprise policies to apply policies to multiple arrays, you also have the option for more granular control over the policies that are applied to arrays by configuring policies that only apply to a particular array. This allows you to fine tune your firewall policy on specific arrays if you find that you need to. Note that enterprise policies can be configured to be applied either before array level rules or after array level rules. You have that option when configuring firewall policies on your arrays.
One thing to keep in mind when considering enterprise arrays is that arrays have some important information that is kept within the array so that certain types of connection states remain consistent. The two most important scenarios in this regard are for VPN and outbound web proxy when CARP is being used. In the VPN example, array members need to inform other members of the array that a VPN tunnel exists for a site to site VPN connection. This enables the arrays to route traffic to the array member that is the owner of the tunnel. In the outbound web proxy scenario, the array members forward outbound web proxy requests to the appropriate array member that is responsible for the requested URL and return the result to requestor, while also storing the results on the array member that is responsible for the URL.
Summary
In this second part of our series on planning for high availability with the TMG firewall, we expanded on our previous discussion of the enterprise array configuration. You saw that you can use enterprise arrays to distribute firewall policy to multiple array members in the most efficient way possible. We also discussed some important things you need to understand about array operations so that you can plan how to split out array functionality in the best way. In the next article, we’ll spend some time on the multiple ISP support. See you then! –Deb.
If you would like to read the next parts in this article series please go to:
- TMG Firewall Options for Scalability and High Availability (Part 1)
- TMG Firewall Options for Scalability and High Availability (Part 3)
