One of the hallmarks of Forefront Threat Management Gateway (TMG) 2010 is the graphical user interface (GUI) management console. The TMG GUI is intuitive and discoverable, making administration of configuration settings and firewall policy much easier than many of its competitors. The TMG GUI management console is installed along with TMG services, and optionally can be installed on a separate management workstation if desired. TMG also provides a rich and robust API, which is accessible via the Component Object Model (COM). Through this API it is possible to view and modify any configuration setting in TMG. In fact, that is essentially what happens under the covers when an administrator makes changes in the GUI. Interestingly there are a number of important configuration changes that are not accessible via the GUI, and can only be viewed or changed programmatically.
Arguably this is the most common setting on the TMG firewall that is not available via the GUI. Forefront TMG is configured, by default, to inspect all HTTP communication and to ensure that it is valid and RFC compliant. An exception has to be made for SSL and TLS protected HTTP communication because, by default, the TMG firewall is unable to inspect this traffic. TMG handles encrypted HTTP traffic fundamentally differently than it does regular HTTP traffic. With standard HTTP, the TMG firewall terminates the session and with all of the communication in the clear, it is capable of performing application layer traffic inspection. With SSL and TLS, application layer data is encrypted, so the TMG firewall tunnels this traffic to the destination instead of terminating and inspecting it. As a security precaution, TMG is configured only to allow uninspected SSL and TLS traffic on TCP ports 443 and 562 by default. If you have an application that communicates using SSL or TLS on a different port, you must explicitly configure TMG to allow this traffic. This setting is not in the GUI, and is only available via COM.
More details about managing TMG tunnel port ranges, along with the VBScript code to view, update, and delete SSL tunnel port ranges can be found here.
Forefront TMG 2010 includes 59 system policy rules that allow essential infrastructure communication, remote system management, name resolution, logging, Active Directory communication, and much more. By default, all traffic allowed or denied by system policy rules is logged. In an effort to reduce log noise, administrators may wish to disable logging for some system policy rules. You’ll quickly notice that disabling logging for system policy rules doesn’t work in the GUI. If you attempt to disable logging for a system policy rule you will be greeted with an error message like this.
It is possible to disable logging for system policy rules using the COM interface. More information about disabling TMG system policy rule logging and VBScript sample code can be found here.
One of the most common configuration mistakes I encounter is when administrators enable the Require all users to authenticate option on the web proxy listener.
Many TMG administrators believe they are improving security for the TMG firewall by enabling this setting. Also, vendors who provide third-party integration for TMG and don’t understand how TMG works often recommend this setting to resolve an issue with their product. This is not a recommended setting and should be avoided whenever possible. However, TMG still lets you enable this setting if you really want to, even after objecting with a warning message when you check the box! If you still insist on doing this, you can expect unintended consequences such as firewall client operability issues. Thankfully Microsoft provides a workaround for this particular issue. Here again, this setting is not available in the GUI and must be performed using COM.
Details about this configuration and VBScript sample code can be found here.
In its default configuration, Forefront TMG performs name resolution requests on behalf of web proxy clients. For example, when a client configured to use the TMG firewall as an explicit proxy, a request for www.example.com will not be resolved to an IP address by the client itself, but instead will be sent to TMG and TMG performs the DNS lookup. In web proxy chaining scenarios, it might be desirable not to have the downstream proxy perform this request, but instead have the upstream server handle it. Here again, this is not a setting that is available in the GUI.
Additional details regarding this scenario and the VBScript code to disable name resolution on a TMG firewall in a web proxy chaining scenario can be found here.
For web proxy requests, if the TMG firewall is unable to identify an access rule for which the user has permission, it will deny the request and return an access denied message to the user. There are some scenarios in which it might be desirable to override this default behavior. For example, a help desk administrator may need to access a web site that is available only to administrators while logged on as a standard user. Another example is where users access the Internet from a kiosk that is logged in using a non-privileged account. As opposed to simply denying the request, it would be helpful if the TMG web proxy would prompt for authentication in the event it is unable to process the request with the originally presented credentials. As this setting is not available in the GUI, it will be necessary to make this change programmatically using the COM interface.
Details about this setting along with sample VBScript code to make the change are available here.
Forefront TMG 2010 includes a feature that allows for the inspection and detection of viruses and malicious software downloaded through the TMG firewall. When TMG inspects this content it is stored in memory or on disk. There are a variety of configuration parameters for these temporary storage settings including the amount of memory that is used, the maximum amount of disk space that can be used globally and per client, and the location where temporary files are stored on disk. Accessing these settings is not possible using the GUI and must be viewed and/or changed using the COM API.
All of the details for managing temporary storage settings including VBScript code to view and change these parameters is available here.
Forefront TMG 2010 has been with us for quite a while now, and it really is beginning to show its age. One of the biggest challenges with managing TMG programmatically is that it lacks native support for PowerShell. Unfortunately, TMG is old enough to have been designed before Microsoft began its effort to enable PowerShell management across all of its platforms and applications. Fortunately, the underlying operating system, Windows Server 2008 R2, does provide some PowerShell support. In fact, it is possible to perform almost anything you can do with COM in PowerShell by using the New-Object cmdlet to instantiate TMG’s FPC COM object.
For example, here’s a simple PowerShell script that retrieves the TMG version.
$FPC = New-Object -ComObject FPC.Root
$Server = $FPC.GetContainingServer()
Using this basic principal you can essentially “powershell-ify” any VBScript code you have for TMG. It also has the added advantage of PowerShell tab completion, which makes COM methods and properties much more discoverable.
The Forefront TMG 2010 GUI is an absolute pleasure to work with compared to other solutions, especially those with command-line only administration options. The GUI is highly intuitive, easily discoverable, and self-documenting. However, there are times when it becomes necessary to drop down to the command line to make necessary changes that aren’t exposed via the GUI. TMG exposes a COM API for which administrators can leverage to perform many system administration and configuration tasks, and I’ve outlined just a few of them in this month’s article. If you’re resourceful and would like to learn more about managing and configuring TMG programmatically, you can find Forefront TMG’s FPC COM object fully documented here.
To those astute readers who counted 6 settings in this article, bonus points to you! I had originally set out to document 5 of them, but added an additional one at the last minute. Consider that last tip a parting gift from me, as this will be my last article for ISAserver.org. It’s definitely a bittersweet article for me to write, as I’ve been writing about TMG for ISAserver.org for 5 years now. Sadly, as Microsoft has abandoned this wonderful product, it’s time to move on and write about other things. I’ll be taking a break from regular writing to take some time off and peruse some other writing interests. I would like to extend my sincere and heartfelt thanks to the incredibly wonderful folks at TechGenix. Thanks for reaching out to me and giving me the opportunity to write about the product I love so much. Also, thanks so much to all of the ISAserver.org readers! I appreciate your support over the years. This is not goodbye as much as it is “see you later” though. I’ll still be authoring the WindowSecurity.com monthly newsletter and I’m sure you’ll find me writing for another TechGenix publication in the future. Take care!
Business email compromise cyberattacks have been on the rise, and now some allegedly prominent players…
Microsoft continues to leverage its hot Microsoft Teams. With an eye on the popularity of…
Exchange 2019 and 2013 coexistence can be achieved, but the road is winding and filled…
A powerful add-on for GitHub’s code-scanning feature lets you get your API code analyzed for…
Pray.com is one of the most popular faith-based apps, so a data leak is a…