Thursday, August 4, 2011

Microsoft Forefront Threat Management Gateway - traps for young players pt. i

While rolling out a TMG infrastructure recently, I have come across a bunch of issues. I’ll be making some documentation of them below, as I haven’t found much on Google that seemed to indicate the issues I have been having.


Issue #1 – Wrong certificate on Web Listener

At the start of the project I wanted to stage all my publishing rules on the reverse proxy TMG, so I created everything with all the right settings, except for the SSL certificate that would be used in production. No problem, I thought, I’ll use the built in TMG server cert until I get the real ones, and just swap them out in the Listener properties.



This was not straightforward. I loaded the correct UC cert and changed the properties of the listener to use this cert for the defined IP address - it all looked good in the TMG console, but when I browsed to the published OWA site, I found that it was using the TMG server certificate. The only way I could fix was to delete the publishing rule and associated listener. And then export the UC cert with key - reimported, recreated everything and it worked.


Issue #2 - WA - LDAPS authentication not working, only non-secure LDAP on Workgroup TMG


I installed the Enterprise CA cert on the workgroup member TMG server, this allowed TMG to trust DC for LDAPS.


Issue #3 Reinstalling TMG fails on Reporting Services

I had to reinstall two TMGs as we had to change network template from single NIC to Back Firewall. I uninstalled everything, but could not reinstall.

I had to uninstall SQL client, manually delete all SQL folders under Program File folders and uninstall ADLDS
After this TMG reinstalled just fine.

Issue # 4 Published CRM issues 

CRM published through TMG was not working at all to start with – this was caused by the bridging of https 443 traffic to http 5555 – the firewall saw the 5555 traffic as unidentified traffic and denied it.

This turned out because I had “Enable Forefront TMG Client support for this network” disabled (Networking -> Networks -> Internal Properties -> Forefront TMG Client)

Once this was working, I found that CRM was popping up a Windows Authentication box, instead of the CRM Forms logon.

This was because the "Internal Network" in the IFD configuration is blank on the CRM server, so the CRM Server thinks our connections in via the TMG are from internally, therefore it is expecting Kerberos authentication to be used rather than forms authentication.

Still, the connection was bad, sometimes I would get “Internet Explorer cannot display the webpage”, and when I was logged on it would time out rather quickly.

What I found to help was to disable HTTP Compression, the compression filter and the caching filter.

CRM is still a little bit niggly, but a lot better :)


Issue #5 TMG HTTPS Inspection blocks Skype

When using TMG as the forward proxy, HTTPS inspection kills Skype. I have found no answer for why on the internets, but my theory is that it is not the inspection of the traffic itself, but that when this rule is enabled, TMG must verify the certificates at the destination and because these maybe self signed then it will simply not initiate the connection. This would explain why you can’t set a source exemption for this rule and have it work

I am sure there will be more to come in another post.