Joining Forefront TMG to a Domain or Workgroup…

It’s been always a big question whether the firewall protecting the network should be joined to the Active Directory domain or not? There are so many arguments going on around this topic. In this post, I am focusing more on Forefront Threat Management Gateway 2010 as our firewall and we are going to discuss the pros and cons of adding it to a domain or workgroup.

Type of Installation

PROS

CONS

Domain-Member
  • More control for user access in forward and reverse proxy scenario.
  • Applying Group Policy settings on the TMG server from the central DC and therefore hardening the server running our firewall.
  • Using Kerberos authentication when publishing different servers and therefore increasing the security.
  • Support for authentication using client certificates as the main method of authentication.
  • In case the TMG server is in the perimeter network separated from the internal network by another firewall, there should be more ports open on that firewall to allow the communication between the DC and the TMG.
Workgroup-member
  • If the firewall is compromised, the directory services might not be affected.
  • Even if Active Directory is compromised, the firewall might not be compromised because it isn’t part of the domain.
  • Doesn’t give you the ability to use the domain users and accounts to be used in integration with the TMG.
  • Client certificates can not be used as the main method of authentication.
  • User accounts are created on the firewall itself to allow intra-server communication.
  • Doesn’t support Active Directory Group Policy.
  • TMG client authentication requires account mirroring on TMG

What mentioned above was just a pretty simple comparison which can be found everywhere. But now I want to extend this discussion by first clarifying whether the domain controller and our AD environment will be at risk if we add the TMG to the domain and make it a domain member server. I personally believe in a simple configuration, joining a TMG server to the domain could expose the network to some sort of security risks and depending on the knowledge of the attacker, there could be further attacks on the domain controller and also the other services.

This type of attack usually happens when there is only one layer of TMG firewall between the outside network and the internal network. In a two-level TMG firewall design, we will have more flexibility playing around with the rules inside TMG. In a two-level firewall or what we call as a back-to-back firewall design we can join the front-end TMG firewall to the domain so that we can make use of all the domain features for the clients connecting to the front-end TMG. We also can join our back-end TMG firewall to a workgroup. In this case even if the front-end TMG is owned by an attacker, there still will be a back-end TMG a head of the attacker to get to the main network and the DC.

The question that might come up here is that the back-end TMG still has some ports open so that the front-end TMG can communicate with the DC in the network and you might wonder whether having that back-end TMG is useful at all? And the answer is YES, it is useful since just opening a port on a firewall to let the authentication traffic through doesn’t expose any security risk to the network. A firewall can stop a lot of different types of attacks and therefore that back-end TMG can protect the whole network environment even if the front-end domain-member TMG is owned by the attacker.

In this post I just tried to give you some insights. I suggest whenever you are thinking of integrating any service or software or product with Active Directory, do not panic because of potential security risks but try to analyze the situation and what you want to implement and take every step very carefully and consider even very small risks, then maybe you will realize that the integration of services and products with AD is not that scary…

You want to learn more? Check out my new book below and have access to great and practical tutorials and step-by-step guides all in one book. 

To get more information about the book click on the book below:

1

Cheers


How many TMG Servers do I need in my network?!!

It might probably have happened to you that you wanted to design your perimeter network but were wondering how many TMG firewalls were needed to be placed in your network.

Even if you can find an answer to this question, there are so many other questions that pop into your mind about the hardware specifications of the server on which TMG is to be installed. Questions like:

-What should be the processor type?

-How many processors do I need to place on my server?

-The number of cores per processor?

-Number of disks for web caching per server?

If you have all these and even more questions in your mind when deploying TMG, you don’t need to worry since Microsoft has released a tool called Forefront TMG Capacity Planning Tool that pretty simply gives you all the details of the servers that you need to place in your design in addition to all those numbers and statistics that you need.

In order to run this tool you need to have Office Excel installed on your machine and once you double click on the file you will go through a wizard that ask you some questions about some of your criteria and requirements. Below you see a picture of the first page:

Then after you go to the next step, you will see a page asking about the features and functions that you need to have on your TMG:

In the next step, you can choose a calculation method to calculate the information that you need based on the hardware that you have, the number of users or the bandwidth available:

Then in the next step you can see a very complete report answering all the questions that you had in mind regarding the deployment of the TMG and the number and the hardware specifications of the servers.

You can download this tool from here.

Wish you all the best

Deploying the network edge on a virtual environment – Part 3

Now that you have some background knowledge on the concept of a virtualized network edge, we will go a little bit deeper and in this post I will try to illustrate different scenarios where we put TMG in our network:

1- TMG as an Edge Firewall

An edge firewall is a firewall placed on the edge of the network connecting the LAN to the Internet and is capable of inspecting any traffic that enters or exits the network.

As it is shown in the illustration, we will install the TMG on a Guest VM on Hyper-V and will disconnect the parent OS from the internet.

We need to create two virtual NICs on the Guest VM. One of the virtual NICs is connected to the physical server’s NIC linked to the LAN and the other virtual NIC is connected to the physical server’s NIC linked to the Internet.

Notes: The connection between the virtual NIC and the physical NIC is established through a Virtual Switch on each side. So keep in mind that in this scenario we will need to have two virtual switches.

2- TMG as a Three-Legged Firewall

A three-legged firewall is a type of firewall that is connected to three different network segments namely LAN, DMZ (Perimeter Network) and the Internet.

As precisely depicted in the illustration, everything looks and is configured the same as when we had an edge TMG firewall with the only difference that we need to have a new and third Virtual NIC on the Guest VM running TMG which is connected to the DMZ section of the network.

There goes to scenario here:

  • The DMZ is on the same Hyper-V Server. In this case we are going to have a specific virtual switch for our DMZ section. This switch is connected to the TMG on one side and to the virtual NICs of the Guest VMs from the other side. This way we can have a link between the TMG and the Guest VMs which are placed in DMZ.
  • The DMZ is not on the same Hyper-V server and is on another server or servers. The picture below can describe things a little bit better. In this scenario we still have the DMZ virtual switch but this virtual switch is not straight connected to the other DMZ Guest VMs; instead it is connected to them through the physical NIC of the server.

Notes: I don’t explain more on this scenario to avoid confusion; because I believe the picture is clearly showing what I am trying to say.

3- TMG as a Back-to-Back Firewall

In this scenario we have two TMGs both installed on two different Guest VMs. One of them is playing the role ofa frontier firewall connected to the Internet through a Virtual Switch; and the other TMG is playing the role of aback-end firewall connected to the LAN through another Virtual Switch.

Both of these Guest VMs running TMG, from the other side, are connected to a DMZ Virtual Switch. This virtual switch is also connected to the other VMs in the DMZ.

Notes: Again like the previous scenario, the DMZ section could be either on the same Hyper-V Server or on another server or servers. It totally depends on your design.

Here I just talked about the design and not the configuration on the TMG and VMs. Basically there are a number of things that need to be configured correctly if you want to get these scenarios up and running. In the next and most probably the last post of this series, I will talk about the configuration with all the details.

Some months ago I also had a deep dive session in Microsoft Virtualization and Security Summit 2010 and it was on deploying TMG on a virtualized environment. Below you can see my presentation slides shared for your use.

You want to learn more about this topic? Check out my new book below and have access to great and practical tutorials and step-by-step guides all in one book:

To get more information about the book click on the book below:

1

Wish you all the best

Cheers