In a perfect world where we could deploy least privilege to all communications moving through the Forefront TMG firewall, the TMG firewall would not be a member of the domain, yet we would have all the security features and capabilities that we have with a domain joined TMG firewall. However, that’s not the case now, nor do I believe it will it be the case in the near future, including the RTM release of the Forefront TMG.
So, when deciding about what the more secure solution is, you have to take in account the entire security picture, and then choose the option that affords you the most overall security. You can’t just look at one issue, deem that issue “unsecure” and then ignore the loss of security when you don’t consider the entire list of security features and capabilities when you dismiss a single configuration option as unsecure.
For example, some consider the domain member Forefront TMG firewall to be unsecure. However, that’s because they’re looking at only a single factor. If the “expert” who made this offhand assessment were to assess the entire security configuration, he might decide that domain membership is actually an overall more secure configuration.
Consider the following information in the Forefront TMG Help File that can be found at http://technet.microsoft.com/en-us/library/cc441665(TechNet.10).aspx :
- When access rules require internal clients to authenticate for outbound access, Forefront TMG can authenticate domain user accounts against an Active Directory directory service domain controller. Web proxy requests in a workgroup environment can be authenticated against a RADIUS server.
- Firewall client requests automatically include user credentials. To authenticate these requests, Forefront TMG should belong to a domain. In a workgroup environment, you can authenticate requests with user accounts that are mirrored to accounts stored in the local Security Accounts Manager (SAM) on the Forefront TMG server, but this requires some administrative overhead for secure management.
- To authenticate inbound requests to internal Web servers using domain account credentials or certificate authentication, Forefront TMG must belong to a domain. In a workgroup environment, a RADIUS or SecurID server can be used for authentication.
- To authenticate virtual private network (VPN) requests using domain account credentials or certificates, Forefront TMG must belong to a domain. In a workgroup environment, a RADIUS server can be used for authentication.
- You can configure VPN client user mapping to map users of operating systems other than Microsoft Windows to domain user accounts. User mapping is only supported when Forefront TMG is installed in a domain.
- In a domain, you can lock down the Forefront TMG server using Group Policy, rather than by configuring only a local policy.
- In a domain environment, if Active Directory is compromised, for example by an internal attack, the firewall can also be compromised, because a user with Domain Administrator rights can administer every domain member, including the server running Forefront TMG. Similarly if the firewall is compromised, the domain in which Forefront TMG is located is also at risk. By default, the Domain Admins group is in the Administrators group on the Forefront TMG server.
Regarding the last issue, I would consider the fact that the firewall might be compromised by a compromised domain or enterprise admin account to be the least of my problems should such an event occur. But then again, I have to remain true to least privilege and admit that this does add to the problems of a compromised domain admit account.
However, when looking over the list from the Help file, you can see that domain membership confers a significant amount of security that would be lost, or more difficult to maintain, if the TMG firewall were not a domain member.
HTH,
Tom
Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: [email protected]
MVP — Microsoft Firewalls (ISA)