Considerations for the TMG Firewall in Supporting Services (Part 2)

If you would like to read the other parts in this article series please go to:

In Part 1 of this series, we talked about supporting DNS. I promised you that we’d look next at supporting authentication services, but that’s such a broad topic that it’s going to take more than our allotted word count to do it justice, so Part 2 will only begin that multi-faceted conversation.

When it comes to authentication discussions surrounding the TMG firewall, it’s can be like a gift that just keeps giving. The reason for that is that everyone has an opinion on this subject and sometimes the discussions can get a little heated when those opinions are in conflict. In that light, keep in mind that some of the things I’m going to be discussing today (or, in fact, almost every day) will consist of my own opinions that are based on using the ISA and then TMG firewalls for over a decade and helping others to deploy, configure, manage and troubleshooting the ISA/TMG software. I’ll try to explain those opinions, along with the opposing views, as objectively as possible.

There are many different aspects to the TMG firewall and authentication, and one article or even one series on the subject isn’t going to be enough to go into the level of detail that would give you a truly comprehensive understanding of all the intricacies that are involved. I think of this set of articles as a consciousness raiser, in which I’ll bring up some issues that you may have thought about before, or that you once thought about but which subsequently fell off your radar, and that maybe you’d like to revisit.

The TMG authentication considerations that we’re planning to tackle in these next few articles will include the following:

Domain member versus Workgroup
Authentication for outbound connections
Authentication for inbound connections
Authentication for non-Windows clients

Let’s get started with that first and probably most controversial one.

Domain Member versus Workgroup

Of all the authentication and authorization topics that get heads a spinning, this has to be the number one on my list. I can’t count the number of questions I’ve received about this over the years. Should the TMG firewall be a domain member? It depends who you ask. If you ask my husband, Tom Shinder (who is pretty opinionated himself), he’s likely to tell you that you’re a fool if you don’t make the TMG firewall a domain member. His rationale is that you significantly reduce the level of security the TMG firewall can provide when you put the firewall in a workgroup. Yes, he understands that the potential attack surface might be greater in this scenario, but if you take a holistic approach to security, you’ll realize that you end up on the positive side of the ledger when you join the TMG firewall to the domain.

Not everyone agrees with this reasoning, though. The other contingent believes that when you join the TMG firewall to the domain, you expose your entire Active Directory infrastructure to potential attackers and therefore the TMG firewall should never be joined to a domain. In fact, you’ll find this to be a common configuration policy in many enterprise networks.

However, the reason that this is a common configuration on enterprise networks may be related more to the fact that the domain join decision is not being made by people who thoroughly understand the TMG firewall. Instead, the decision is made by the “security guys” or “network guys” (or gals) who sometimes have little or no experience with the TMG firewall and don’t really know how it works or understand its underlying security architecture. All they (think they) know is that “Microsoft is not secure, Active Directory is Microsoft, and software firewalls can’t be as secure as hardware firewalls, etc.” Because of this historical baggage, the hapless TMG firewall admins are forced to deploy the TMG firewall in workgroup mode, or some similar implementation where they configure a separate domain infrastructure just for the TMG firewalls, defeating the purpose of making the TMG firewall a member of the corporate domain.

I’m not here to tell you what’s right or wrong. Tom has already done that in his article Debunking the Myth that the ISA Firewall Should Not be a Domain Member. And I recognize that what’s right in some or most cases might not be the optimal choice in special circumstances. But what I would like to lay out for you here are some of the major considerations you should take into account when you start thinking about whether or not to join your TMG firewall to a domain. Keep these things in mind when you make the decision:

If you’re going to set up TMG firewall arrays in a workgroup environment, you’re almost certainly going to need to increase your administrative overhead. This includes but isn’t limited to mirroring user accounts across machines that are members of the array, since they can’t leverage a single authentication repository as they could if they were domain members.
Do you like Enterprise Management Services Replication? Well, that’s not going to work in workgroup mode, because you can only have a single server doing the job of EMS. That means if you’re interested in scalability and availability, workgroup mode isn’t for you; domain membership is your friend.
An interesting limitation that many people might not be aware of relates to automatic proxy configuration for TMG client systems. In the past, we would configure the client systems to use the correct web proxy by taking advantage of the WPAD entry in DHCP or DNS. While that works very nicely, it has turned out to be a bit of a security issue.
Learn more about WPAD security concerns here. Because of this, recent versions of the Windows DNS server have a default configuration where it will not answer queries for WPAD (or ISATAP too). TMG integrates with Active Directory so that web proxy configuration information is stored in the Active Directory database. Domain member client systems are able to get that information from Active Directory and configure their web proxy settings without having to call a DHCP or DNS server for that information. However, if you deploy a workgroup-only TMG firewall or firewall array, you’re going to end up on the losing side of this deal.
Domain members can use Kerberos to authenticate to one another. All you have to do is join the machines to the domain and Kerberos authentication “just works”. If your TMG firewall array doesn’t belong to a domain, then it won’t be able to leverage Kerberos for machine authentication. Well, that could be a bit of a problem, since firewall array members need to share information with one another and they’re not going to trust just any computer with that information. In order to establish the required trust in this scenario, you’ll need to install machine certificates on each member of the workgroup-based TMG firewall array. Those certificates will need to be issued by a certification authority that all the array members trust. It can be a commercial CA or your private CA; either one will work fine. In most cases, a private CA is appropriate. Of course, without a domain, you won’t be able to leverage Active Directory Group Policy and Enterprise CAs to automatically reissue certificates. That could lead to some downtime issues if you happen to forget that your certificates are about to expire.
Speaking of certificates, you also need them for inbound and outbound SSL inspection. If you want to automatically renew those certificates and get the CA certificate automatically placed into the Trusted Root Certification Authority store, then you’ll need the firewalls to be domain members. Otherwise, you’re going to have to manually manage all those certificates. Do you know how often expired certificates lead to service outages? Very often. Do you really want to risk it? If not, just join your TMG firewalls to the domain.
Active Directory Group Policy is something else to think about. In a domain, you can use it to set a standard security configuration for all of your TMG firewalls. Just create a Group Policy Object (GPO), configure it with your security settings that you want to apply to all Internet facing hosts, and then connect that Group Policy Object to the Organizational Unit (OU) to which your firewalls belong. It’s that easy to deploy your desired configuration setting. Do you need to add a new firewall? All you have to do is put it into the OU. It’s not nearly so easy with workgroup-based firewalls, where you’re going to have to handle all of those security configuration settings manually. Who wants to do that?
Here’s one many of you probably haven’t thought about, but it’s a configuration that’s getting more popular. Did you know that you can VPN into the TMG firewall from a device other than Windows? With more and more Apple and Linux-based mobile client devices out there, it’s becoming a common scenario. However, in order to authenticate the user of that device, you’re going to have to configure User Mapping on the TMG firewall. It’s not that hard to do, and it will allow you to use your Android and iOS tablets and smart phones to connect to the TMG firewall. However, in order to achieve this user account mapping, the TMG firewall has to be a domain member. If your TMG firewalls are set up in workgroups, no User Mapping for you.
I do want to throw a bone here for those of you who don’t want to join your firewalls to the domain. The most likely cause for domain compromise is from an insider attack (actually, insider attacks are the most common reason for compromise, period). The problem with this when the TMG firewall is a domain member is that if the domain is compromised, and the TMG firewall is a member of the compromised domain, the firewall can then be compromised. The default setting is that only domain administrators can are in the Admins Group on the TMG firewall, which improves security to a certain extent.

Summary

I hope this article gave you a few points to think about (or argue with) in regard to the question of domain membership for your TMG firewalls. In the next article in this series, we’ll continue the authentication discussion and address the next bullet points regarding particular authentication scenarios (outbound, inbound and for non-Windows clients). See you then! –Deb.

If you would like to read the other parts in this article series please go to: