Adventures with Forefront TMG

We wanted to be able to block users from accessing non business related websites, but only wanted the restriction to be in effect when the user was actually clocked in to their project.  Web surfing on breaks and lunch has always been allowed at our company, and we didn’t want to restrict this, just restrict unauthorized use during work.

We decided to look at Microsoft’s Forefront Threat Management Gateway server, or TMG.  This product has the ability to set various filters for web blocking, and might be suitable for our needs.  Just one problem:

How do we make Forefront aware of a specific user’s “status”, as to whether they are clocked in or out?

Forefront can apply its filtering rules based on the IP address or network segment from which the request originates.  It can also filter based on the user name of the person asking for the website.  Unfortunately, there do not seem to be any other external “triggers” that can be used, so we determined that we would try it using AD authentication.

We set up and configured a test TMG environment, and joined it to our domain.  (For a very helpful step-by-step instruction on how to get TMG up and running, take a look at Raihan Al-Beruni’s blog HERE.)

Once it was configured, we did the following:

1.       Created two rules under Firewall Policy in TMG.  One was the “Allow” rule, essentially letting any traffic through.  The other was the “Deny” rule, which restricted users to only accessing sites related to our business
2.       Created two Groups in AD, one called “Filtered” and the other “Non Filtered”
3.       Under the Properties of the Allow rule, we set the Users to be members of the “Non Filtered” group
4.       Under the Deny rule, the “Filtered” group
5.       Apply all the settings, and then add our test user to the “Filtered” group
6.       Test access for the test user.  Success! They could only access the sites allowed by the rule.

Unfortunately, this is where we hit our first snag.  We moved the user from the “Filtered” to the “Non Filtered” group, and… they were still filtered.  A 2^nd test user in the “Non Filtered” group had regular access.  Looking at the TMG logs we could see that the rules were being applied. 

TMG appeared to be only pulling the AD group membership information when it encountered a new name.  Eventually, after several hours in some cases, the membership was re-authenticated, and the appropriate rule was applied.  But this was not going to work for someone who was clocking out for a 15 minute break!

Some further experimentation showed that the “TMG Client” software for the desktop was designed to handle some authentication duties.  So, we experimented with adding the Client.

That was the trick!  A change in AD Group membership was reflected instantly on the TMG server, and the client’s access was adjusted accordingly.

Except…it was instant only if the change was applied to the same DC that the TMG server uses.  Otherwise, we had to wait for AD replication, which could take several minutes.

However, we now have a solution.  A TMG Server with the appropriate rules, and the TMG client on the desktop, and we can change a user’s access as often as we wish.  And there can be as many different rules as we have projects.  We have complete flexibility regarding what sites are filtered and what sites are allowed.