Wednesday, February 29, 2012

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 business2.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” group4.Under the Deny rule, the “Filtered” group5.Apply all the settings, and then add our test
user to the “Filtered” group6.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 2nd 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.