Finally it was announced and Microsoft has decided to discontinue some of its very popular products such as Forefront Threat Management Gateway 2010 together with some others listed below:
- Forefront Protection 2010 for Exchange Server (FPE)
- Forefront Protection 2010 for SharePoint (FPSP)
- Forefront Security for Office Communications Server (FSOCS)
- Forefront Threat Management Gateway 2010 (TMG)
- Forefront Threat Management Gateway Web Protection Services (TMG WPS)
It also should be mentioned that among all of these, Forefront Protection 2010 for Exchange Server (FPE) will still be there but will be bound to Office365 and will be called Exchange Online Protection.
I still remember the rumor about a year ago about this decision but it was not confirmed then. Now that is is confirmed, there are still questions left on why Microsoft has made this strategic decision especially the decision to discontinue TMG which is a very popular product. It is now being used by a lot of companies as a gateway software for so many different purposes. It was the successor of popular Microsoft ISA Server 2006 and now all have been discontinued to be any further developed.
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
- 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.
- 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:
It’s been a while Microsoft has been working on its Forefront products and they have been really successful in offering products that are of great help to increase the security of the network environment and systems both on the server-side and client-side.
I personally love them all and have more experience working with Forefront Threat Management Gateway 2010 and truly enjoyed all the better features it has in comparison with ISA Server 2006. When you have the experience of working with a product for quite a long time and wish for some added functionalities, once the new product is out and gives you all of them, that’s when you have a really good feeling. I guess Forefront products give you exactly the same kind of feeling.
Now Forefront Endpoint Protection 2012 Beta is out. Before we go a little bit further with the features, let me give you an overview on what it is. FEP helps businesses efficiently improve endpoint protection while decreasing the costs. It is built on System Center Configuration Manager allowing businesses to use their existing client management infrastructure to manage the endpoint protection. Right now this beta version is compatible with System Center Configuration Manager 2012.
But let’s see what’s new in this new beta release of FEP:
- Supporting System Center Configuration Manager 2012
- Improved real time alerts and reports
- Role-based management
- User-centric reports (post beta)
- Easy migration from FEP 2010/ConfigMgr 2007
- Support for FEP 2010 client agents
FEP 2012 provides protection against known and unknown threats using advanced techniques such as behavior monitoring, network inspection system and heuristics. It also has a real-time cloud-based update system through Spynet service helping it to stay up-to-date.
If you need more information on FEP you can click here
I hope you will be among the early adopters of FEP 2012.