When performing SSL and TLS hardening on Microsoft Forefront Threat Management Gateway (TMG) 2010 or Forefront Unified Access Gateway (UAG) 2010 servers, disabling SSL 3.0 and TLS 1.0 is often required to meet regulatory and compliance guidelines for security. However, disabling SSL 3.0 and TLS 1.0 causes the SQL Server (ISARS) and SQL Server Express services to fail on start up.
Switching from SQL logging to text file logging can be employed as a workaround. However, when using text file logging, generating historical reports in the TMG management console is no longer supported.
To restore full functionality for SQL logging and reporting when SSL 3.0 and TLS 1.0 are both disabled, an update to the local security policy of the server is required. Open the Local Security Policy editor by clicking on the Start button and navigating to Administrative Tools and Local Security Policy. Expand Local Policies and click on Security Options. Double-click on System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing. Click Enabled and then click OK.
Restart the computer for the changes to take effect. Once complete, all SQL services should start and run without issue.
Note: If Remote Desktop Services (RDS) is used to manage the Forefront TMG firewall it will be necessary to install update KB3080079.
The Windows Sysinternals utilities are essential tools for troubleshooting Windows platforms and systems. The tools are being updated constantly, and recently a 2nd edition of the book “Troubleshooting with the Windows Sysinternals Tools” was released. This is an important reference for anyone using these tools to perform Windows troubleshooting. Order your copy today!
With the demise of isatools.org a few years ago, many ISA Server and Forefront TMG 2010 administrators have reached out to me to ask where they can find the ISAinfo tool that was previously found on that site. If you’re not familiar with ISAinfo, it was a great utility used for viewing the ISA or TMG configuration by parsing the configuration export. This tool is tremendously useful for providing support, as it includes all of the information required to provide context for troubleshooting. In addition it is an excellent documentation tool.
So, if you’re looking for a reputable location from which to download this tool, look no further. I’ve placed the isainfo.zip file along with the checksums for file verification on my public OneDrive. Enjoy!
Recently the Performance Analysis of Logs (PAL) tool was updated and now includes a threshold file for Forefront UAG 2010. PAL is an essential utility that can make troubleshooting performance issues or capacity planning dramatically easier. I’ve written about using PAL on Forefront TMG 2010 in the past, and using PAL with Forefront UAG 2010 will be very similar. You can download the latest release of PAL at pal.codeplex.com.
Today I confirmed a bug in Service Pack 2 (SP2) for Forefront TMG 2010 that was discovered by Jason Jones. If you have deleted the default Internet Access network rule and replaced it with something else, installing SP2 for Forefront TMG 2010 mysteriously restores this rule. Unfortunately it places the default Internet Access rule ahead of your custom rule which in most cases will cause serious problems. This bug only affects Forefront TMG 2010 configurations where the default Internet Access network rule has been specifically deleted. If you’ve altered this rule in any way, those changes are unaffected.
Before Forefront TMG SP2 installation…
After Forefront TMG SP2 installation…
Frequently I am asked to review Forefront TMG 2010 firewall logs for suspicious behavior. Often times a security administrator will express concerns about many instances of denied requests by clients attempting to connect to Forefront TMG’s web proxy service. On busy TMG firewalls there may be hundreds or even thousands of instances where the following access denied record appears in the Web Proxy logs:
Status: 12209 Forefront TMG requires authorization to fulfill the request. Access to the Web Proxy filter is denied.
On a Forefront TMG 2010 firewall where web access rules require authentication, this behavior is expected and by design. It does not indicate an attack of any type on the Forefront TMG firewall or its web proxy service. The root cause for the flood of access denied messages has to do with how the Web Proxy client behaves when accessing resources via an authenticating web proxy like the Forefront TMG 2010 firewall. When a Web Proxy client sends its initial request for a resource it will always attempt to do so anonymously. Only when prompted for authentication by the firewall will the web proxy client provide the credentials of the logged on user.
Consider a scenario where Forefront TMG is configured to only allow authenticated users to access the Internet. The firewall policy might look something like this:
Below is a network trace taken from a client attempting to access http://www.bing.com/ through a TMG firewall as configured above.
We can see that the first three packets of the trace are the TCP three-way handshake taking place between the web proxy client and the Forefront TMG firewall. Once a connection to the web proxy listener has been established, in packet 8 the client sends an HTTP GET request for http://www.bing.com/. In packet 13 you’ll see that the Forefront TMG firewall denied the request and replied with an HTTP 407 response, indicating that proxy authentication was required. This was done because the Forefront TMG firewall did not have any access rules which would allow the anonymous request. It did, however, have access rules that might apply to this request, depending on who the user is. This response also includes which authentication methods the web proxy listener is configured to accept.
In packet 15 the web proxy client again submits its HTTP GET request for http://www.bing.com/, this time indicating that it would like to use the NTLM Secure Service Provider (SSP). In packet 16 the Forefront TMG web proxy denies the request yet again and replies with another HTTP 407 response, this time including the NTLM challenge. In packet 17 the client submits an HTTP GET request for http://www.bing.com/ and supplies the credentials in the form of an NTLM response.
As you can see, each time a web proxy client requests a resource through a Forefront TMG firewall that requires NTLM authentication the client is actually denied twice during the transaction before being successfully authenticated and allowed access. If this sounds like a lot of overhead for authenticated proxy traffic, you are right. Denying each request twice consumes additional resources on the Forefront TMG firewall and introduces some latency for clients as well. In addition, the burden of authenticating the user is placed on the TMG firewall when using NTLM, as the firewall itself must contact a domain controller to authenticate the user. You can reduce the authentication load on the Forefront TMG firewall considerably by enabling Kerberos authentication. When the Forefront TMG firewall is configured to use Kerberos there is only a single denied request and HTTP 407 response. The client must then contact a domain controller and obtain a Kerberos ticket to present to the TMG firewall to gain access to the resource. Information on how to configure Microsoft ISA Server and Forefront TMG 2010 to use Kerberos authentication can be found here.
HTTP response codes – http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
NTLM challenge/response – http://en.wikipedia.org/wiki/NTLM
An intrusion detection and prevention system (IDS/IPS) is an essential component of a modern secure web gateway. The Network Inspection System (NIS) in Forefront Threat Management Gateway (TMG) 2010 is a unique implementation of IDS/IPS. NIS is focused specifically on detecting and preventing attacks on Microsoft operating systems and applications. NIS uses signatures that are developed by the Microsoft Malware Protection Center (MMPC) and are distributed through Windows Update or WSUS.
NIS in Forefront TMG 2010 provides protection by performing low-level network protocol inspection. Each packet is analyzed for protocol state, message structure, and message content. When a packet is received, NIS will inspect it only after the firewall policy has allowed it, and only after any associated web or application filters have processed it.
There is one caveat, however. A custom protocol is not subject to NIS inspection by the Forefront TMG firewall unless it is associated with a standard protocol. Often a Forefront TMG firewall administrator will create a custom protocol for a standard protocol that uses a non-standard port. One of the most common protocols to be configured to use non-standard ports is the HTTP protocol. For example, if an administrator defines a custom protocol to support a web-based application that uses the non-standard TCP port 62112, by default NIS will not inspect this traffic even though the communication is HTTP, a protocol which NIS normally inspects when it takes place over the standard TCP port 80.
To apply Forefront TMG NIS inspection to a custom protocol it must first be associated with a standard protocol. In our example we’re using HTTP over a non-standard port, so we need to associate our custom protocol with the Web Proxy Filter.
Next, associate the custom protocol with a standard protocol definition, in this case HTTP Proxy.
Once complete, Forefront TMG NIS inspection will be applied to the custom protocol and policy will be enforced according to the current NIS configuration.
Forefront TMG NIS additional information: