Configuring ISA Server For Incoming Ping Responses

Configuring ISA Server for Incoming Ping Responses
Dieter Rauscher [MVP ISA Server]

By default after installing ISA Server you cant ping the ISA Server's external interface. This is due to ISA Servers handling of incoming
ICMP ping query packets. They are all dropped. In most cases theres no need to change that behavior. I would say its one more little
security feature. Thereby ISA Server is hidden to intruders who use ping to detect server presence. Also, if you dont use any publishing
rules, your ISA wont be found by port scan attacks. When using publishing scenarios of course, it will be detected by specific port scans
or port attacks. But that is not topic of this article.
In exceptional cases it is necessary to configure the ISA Server to respond on external incoming ping requests. But my recommendation
is not to change the default setting unless youve a good reason.
Without any configuration you get this when pinging the external interface of the ISA Server:

(Dont wonder about Windows Version 5.2.3718. Its a second Windows Server 2003 in front of ISA Server.)
To understand my current environment here is my ipconfig:

To enable ping response, we need to create a new packet filter based on a predefined IP Packet Filter definition:

Type a name to identify your Packet Filter

Yes, we want to allow transmission.

The guys from Microsoft made our life easiertheres a predefined Filter available.

In the first step of this tutorial we use the default IP address. Well take a closer look to that screen in the next part.

Its up to you to set further restrictions. Only this computer means that only the typed-in IP address is able to get a ping response.

The last wizard screen provides a short summary.
Now lets do another ping if we made our work correct well get a different ping screen than above.

Great! It works!
As shown in ipconfig ISA Server has several external IP Addresses. Lets try to ping the second one (192.168.69.71):

Oh no! Something must be wrong..?
No. It's OK. Its normal. Remember, I mentioned at the screen Apply this packet filter to that well have a closer look at the other
options later. Now its time to do so.

As shown in the screen above both relevant IP Packet Filters (marked) are configured to use Default external IP address. Thats the point.
The default IP address of ISA is always the first IP address of the NIC. Dont be confused about the pre-defined Packet Filter ICMP
ping response (in). That packet filter is necessary to receive the ICMP ping replies for outbound ICMP ping query request from ISA
machine itself to the internet only.

If we want to use another IP, we have to configure two new IP Packet Filters.
First we define a IP Packet Filter ICMP outbound for all types and codes:

In the next screen we select Allow packet transmission.

Now its time to tell ISA that we want to get the second IP address published:

Finish wizard by clicking Next.
Let me show you the important screens for the second IP Packet Filter we need:

Lets have a look to the result:

How to create a packet filter for dropping ICMP Packets (Ping Requests)
by Ellis M. George [Published on 7 March 2001 / Last Updated on 21 May 2013]
How to create a packet filter for dropping ICMP Packets (Ping Requests).
Select the Internet Security and Acceleration Server Snap-In and expand the tree by left clicking.

Select Access Policy and left click to expand the tree. Select IP Packet Filters, the existing filters
should now be displayed in the right portion of the MMC screen. Right click on IP Packet Filters
and select NEW > Filter

The wizard screen will open, type in a name for the rule, something descriptive so that you will
know what the filter is supposed to do, then press next.

The wizard will now show a screen that will ask you which server(s) this rule should be applied
too. If the ISA is a stand alone you can either choose the all option or specify the local server,
and then click next.

The next wizard page will ask you to decide whether to block or allow packet transmission,
make your choice and then press next. (Choose Block to not allow packet transmission.)

The next page will ask you to specify what the filter is to do, for this example we will choose the
ICMP Ping Query, and press next.

This next page will ask you for the IP information for the ISA server or other computer in the
ISA array that this rule is to be applied. Make the choice for your particular situation and press
next.

This screen allows you to select which computer(s) you will apply this rule too. Since we are
dropping ICMP Ping Requests select the All Remote computers and press next.

The final screen shows the information of the packet filter you have created, you can now cancel
or click finish to apply the new rule to your array or server. This procedure can be used to create
various packet filters for your ISA Server or Array.

Publishing Exchange Outlook Web App (OWA) with Microsoft Forefront
Threat Management Gateway (TMG) 2010: Part 1 Preparing the Client
Access Server (CAS)
by Richard Hicks [Published on 20 July 2010 / Last Updated on 20 May 2013]
8
Preparing the CAS in order to publish Exchange OWA with Micrsoft TMG 2010.
If you would like to read the next part in this article series please go to Publishing Exchange
Outlook Web App (OWA) with Microsoft Forefront Threat Management Gateway (TMG) 2010
Part 2 Configuring TMG.
Introduction
Forefront Threat Management Gateway (TMG) 2010 includes support for publishing Microsoft
Exchange Outlook Web App (OWA) for Exchange 2010, as well as Outlook Web Access for
Exchange 2007, 2003, and 2000. In the first part of this two-part series we will go through the
steps required to prepare the CAS server for publishing with TMG. In part two we will focus on
actually publishing OWA using TMG.
Preparing the Client Access Server (CAS)
Before we can publish OWA using TMG, we need to make some configuration changes on the
Exchange CAS server. With Exchange 2010, Forms Based Authentication (FBA) is now the
default authentication method. Since TMG will be presenting its own authentication form to the
client and pre-authenticating the user at the edge, well need to configure Exchange OWA to use
NTLM authentication instead.
To change the authentication method for OWA, open the Exchange management console and
highlight Client Access under the Server Configuration node in the console tree.

Figure 1
Select the Outlook Web Apptab, and then right-click OWA (Default Web Site) and choose
Properties.

Figure 2
Select the Authentication tab, then choose the option to Use one or more standard
authentication methods:. For demonstration purposes I will choose Basic Authentication
(password is sent in clear text). Since this communication is protected using SSL encryption,
clear text passwords will not be visible on the network.

Figure 3
Select the Exchange Control Paneltab and then right-click the ECP (Default Web Site) and
choose Properties.

Figure 4

Select the Authetnication tab, then choose the option to Use one or more standard
authentication methods: and select Basic Authentication (password is sent in clear text).

Figure 5
Once complete, open an elevated command prompt and execute the iisreset /noforce command.

Figure 6
The last step in preparing the Exchange CAS is to obtain and install an SSL certificate for use by
OWA. To do this, open the IIS management console and highlight the root node in the console
tree.

Figure 7
In the main window, double-click Server Certificates.

Figure 8
In the Actions pane, click the Create Certificate Request link.

Figure 9
Complete the request form, making sure the Common Name field includes the Fully Qualified
Domain Name (FQDN) of the CAS server.

Figure 10
Note:
In our example we are using split DNS, so the external public-facing FQDN is identical to the
internal FQDN. If you are not using split DNS it will be necessary to make separate certificate
requests for each FQDN (internal and external).
Select the appropriate Cryptographic Service Provider and Bit Length that meet your
requirements. In most cases the defaults will be sufficient.

Figure 11
Specify a location to save the request file and submit the request to a Certificate Authority (CA).

Figure 12
Once the request has been processed by a CA, complete the request by clicking the Complete
Certificate Request link.

Figure 13
Specify the location of the certificate file issued by the CA and enter a descriptive name.

Figure 14
To use this certificate with TMG well need to export the certificate along with its private key.
Highlight the new certificate in the main window and In the Actionspane, click the Export
link.

Figure 15
Specify the location to save the file and enter a strong password.

Figure 16
To assign this new certificate to the OWA web site, highlight the root node in the console tree.

Figure 17
In the Actions pane click the Bindings link.

Figure 18
Highlight the HTTPS protocol and choose Edit

Figure 19
Select the new certificate from the dropdown list.

Allowing Norton AntiVirus software LiveUpdate through ISA Server
by Liran Zamir [Published on 17 March 2002 / Last Updated on 21 May 2013]
1
Many businesses use Norton AntiVirus servers to keep the companys servers and client
computers virus free. In order to keep the virus definitions updated, the Live-Update is used to
schedule virus definitions download to the main NAV server, which in turn, updates the client
computers.
Many businesses use Norton AntiVirus servers to keep the companys servers and client
computers virus free. In order to keep the virus definitions updated, the Live-Update is used to
schedule virus definitions download to the main NAV server, which in turn, updates the client
computers.

From my experience, some integrators seem to be having difficulties with the LiveUpdate
configuration on a network protected by ISA Server, so I decided to write this article.

The LiveUpdate feature requires both HTTP and FTP access to Symantecs web site.
In order to configure ISA to allow the main server to download definition updates, use the
following instructions:
1. Open the ISA management console.
2. Expand the Server -> Policy Elements -> Client Address sets in the ISA tree.
3. Create a Client address set named NAV Server. Enter the IP address of the server on which the
Norton AntiVirus Server is installed. If the NAV server is installed on the ISA Server itself (such as
in the case of SBS 2000), make sure that the IP address specified is the internal IP address of the
server (the private ISA server IP address).

4. Expand the Access Policy object, and create a new rule in Protocol Rules. This rule should allow
the specified client address set which was created in step 3 to access FTP and HTTP sites.

5. Install Symantec Norton Anti-Virus for Servers, include all the components recommended by
Symantec.
Open the Norton Antivirus Corporate Edition program.

From the File menu, select Live Update

Click on the Configure button, and move to the Proxy tab.
As shown in the picture below, select I want to customize my proxy settings for LiveUpdate.
Select both the HTTP Proxy and FTP Proxy.

Enter the ISA Servers private network IP address (internal) for both Proxy settings, use port
8080 for the HTTP Proxy, and port 21 for the FTP proxy. Apply the changes and click OK.

Click Next, and test the your ability to download the required updates.

6. To schedule a daily download of new virus definitions, open the Symantec System Center
console, expend the System Hierarch, and right click the Norton Server group (by default
named Norton Antivirus 1). Select All Tasks -> Norton AntiVirus -> Virus Definition Manager

In the Virus Definition Manager screen, select Update the primary Server Group only, in the
How servers retrieve virus definitions updates and click configure.

Select the required schedule for the definition download. In order to check if the settings work,
click Update Now.
If the update was successful, an event ID 16 should be logged in the servers application log,
which will inform you if the definitions are current (was able to connect, but no download was
required), or if the download of the virus definition file was successful.
Note! There is no need to configure the LiveUpdate proxy use from the Symantec System
Center.
7. Dont forget to additionally configure how Client computer retrieve the definition update. The
recommended way is to Update virus definitions from parent server.
That way, the new virus definitions will only be downloaded by the NAV server, and not by the
client computer.
Fixing the Symantec LiveUpdate Problem.
by Thomas Shinder [Published on 19 Dec. 2001 / Last Updated on 20 May 2013]
Some of you might have noticed that you cant update your virus definitions using the Norton
Antivirus LiveUpdate feature after installing ISA Server. I ran into this one myself a few weeks
ago. After a bit of head banging, I found a configuration that should work for everyone.
Some of you might have noticed that you cant update your
virus definitions using the Norton Antivirus LiveUpdate
feature after installing ISA Server. I ran into this one myself
a few weeks ago. After a bit of head banging, I found a
configuration that should work for everyone.
If you have problems getting Live Update to work, take a
look at the follow procedures.
Scenario 1: Browser Configured as a Web Proxy Client
Perform the following steps if you are using the Web Proxy
client configuration:
1. Click Start and point to Settings. Click on Control
Panel.
2. In the Control Panel, click on Symantec LiveUpdate.
3. In the LiveUpdate Configuration dialog box, select the
Internet Options in the Control Panel option.
Configuring ISA Server 2000 :
Building Firewalls for Windows 2000
By Deb and Tom Shinder

Amazon.com

4. Click on the Proxy tab. Select the I want to use my Internet Explorer proxy settings option.

5. Click Apply and then click OK.
Scenario 2: Browser Not Configured as Web Proxy Client
In this scenario your machine is configure as either a SecureNAT or a Firewall client. When a
SecureNAT or Firewall client sends a request to the ISA Server, the request can be handled by
the Web Proxy service, or it can be sent directly to the Web server. How the request is
dispatched depends on the configuration of the HTTP Redirector Filter. If you want to make life
easy, youll configure the HTTP Redirector filter to forward requests directly to the Web
server.
Note that, while configuring the HTTP Redirector Filter to send the requests directly to the
server will make life easier for you when it comes to dealing with LiveUpdate, it will ruin your
ability to force everyone to use the Web Proxy service. The reason is that if you want to force
everyone to use the Web Proxy client to access HTTP sites, you must configure the HTTP
Redirector filter to drop requests from SecureNAT and Firewall clients.
1. Click Start and point to Settings. Click on Control Panel.
2. In the Control Panel, click on Symantec LiveUpdate.
3. In the LiveUpdate Configuration dialog box, select the Internet Options in the Control
Panel option.
4. Click on the Proxy tab.
5. On the Proxy tab, select the I dont connect to the Internet through a proxy server option.
You select this option because the SecureNAT and Firewall clients are not aware of the Proxy
server, and you dont want the LiveUpdate feature to be aware of it either.

6. Now go to the ISA Server Management console at the ISA Server itself (I dont trust the ISA
MMC on remote computers; you can use Terminal Services though, if you want).
7. Expand your server name, then expand the Extensions node. Click on the Application Filters
node. Double click on the HTTP Redirector Filter entry in the right pane of the console.
8. In the HTTP Redirector Filter Properties dialog box, click on the Options tab.
9. On the Options tab, select the Send to requested Web server option. Click Apply and then
click OK.

You dont need to restart the server. Now go back to the SecureNAT or Firewall client on the
internal network, and enjoy the LiveUpdate feature, now that it works again!

How to use ISA Server Packet Filters.
by Thomas Shinder [Published on 28 Nov. 2001 / Last Updated on 20 May 2013]
ISA Server uses packet filtering to control inbound and outbound access to and from the external
interface of the ISA Server. Packet filtering is the ISA Server's first line of defense against
inbound attack. The ISA packet filtering feature supplements the RRAS packet filtering. If you
have RRAS packet filtering enabled, you should not use it to control inbound and outbound
access to and from the external interface of the ISA Server.
ISA Server uses packet filtering to control inbound and
outbound access to and from the external interface of the
ISA Server. Packet filtering is the ISA Server's first line of
defense against inbound attack. The ISA packet filtering
feature supplements the RRAS packet filtering. If you have
Configuring ISA Server 2000 :
Building Firewalls for Windows 2000
By Deb and Tom Shinder

RRAS packet filtering enabled, you should not use it to
control inbound and outbound access to and from the
external interface of the ISA Server.
In order for packet filtering to work, it has to be enabled.
Perform the following steps to see if packet filtering is
enabled on the ISA Server:

Amazon.com
1. Right click on the IP Packet Filters node in the left pane of the ISA Server Management console
and click Properties.

2. On the General tab put a checkmark in the Enable packet filtering checkbox to activate packet
filtering.

3. While youre there, you might want to enable IP Routing, if you wish internal SecureNAT clients
to have access to non-TCP/UDP protocols such as ICMP and GRE.
Packet Filtering is only available when you are running the Firewall Service. The Firewall
Service is present when you install ISA Server in either Integrated or Firewall only mode. If
you install ISA Server in Cache mode only, you will not be able to implement packet filtering.
You can find the ISA Server Mode right clicking on your server name in the left pane of the ISA
Management console and clicking the Properties command. Youll see the Mode in the
General tab.

When should I enable packet filtering and when do I create packet filters?

You should enable packet filtering in the following situations:
When the ISA Server is at the edge of the network
When you configure a trihomed ISA Server
When you need to run services and applications on the ISA Server
ISA Server at the Edge of the Network
When you enable packet filtering, ISA Server closes off all ports on the external interface that do
not have a packet filter explicitly created to allow inbound and/or outbound access. If you have
packet filtering enabled and you have no packet filters, then there will be no inbound or
outbound access unless you have created Protocol or Publishing rules.

Note that the absence of packet filters does not prevent inbound or outbound access to and from
the internal network. You should always use Protocol Rules to allow outbound access to external
network resource for internal network clients. You should Web Publishing and Server Publishing
Rules to allow inbound access from external network clients to internal network servers.

Packet filtering should always been enabled when the ISA Server is at the edge of the network.
When the ISA Server has an interface on the Internet, you can make sure that no ports have been
opened inadvertently by enabling packet filtering. By default, the only traffic that is allowed
when packet filtering is enabled are some ICMP packets required for basic network management,
and a DNS filter that allows the ISA Server to make DNS queries on the behalf of Web Proxy
and Firewall clients on the internal network.
Packet Filtering for DMZ Servers
If you create a trihomed ISA Server with a DMZ segment, you need to enable packet filtering
and configure packet filters. Traffic to and from the DMZ segment is controlled by packet filters.
If there is no filter that allows traffic into or out of the DMZ, then the traffic will be blocked at
the external interface of the ISA Server.

A special note regarding the configuration of the packet filters for the DMZ segment. A few
people have commented to me that when they configure a filter to allow All IP Traffic to and
from the trihomed DMZ segment, that it does not work. That is true. You must create individual
packet filters to move traffic into and out of the DMZ segment. However, ISA Server does create
dynamic packet filters so you do not have to create filters for response ports.
Packet Filtering for Services and App's on the ISA Server
Services and Applications running on the ISA Server require packet filters. For example, if you
want to run a mail client use as Outlook Express on the ISA Server itself, you must create a
packet filter for outbound access to TCP Port 25 and TCP Port 110 at a minimal in order to allow
access to external SMTP and POP3 servers. You can add other packet filters such as TCP 119 for
NNTP or TCP 143 for IMAP access.

An exception is when you configure the web browser running on the ISA Server itself. In this
case, you can configure the web browser to be a Web Proxy client. In this way, you can get
around creating a packet filter for outbound HTTP.
Be careful about your web proxy configuration on the Web Browser if you are using a dial-up
connection. The Web Proxy client configuration for the web browser on an ISA Server using a
dial-up connection is difference than the configuration for ISA Server's using a dedicated
connection. Check my article regarding this issue.
When Should I Not Create Packet Filters?

Packet filters should not be used for the following purposes:
To control inbound access to internal network servers
To control outbound access from ISA Server clients
I find that a lot of people posting on the message boards claim that they must create packet filters
to make their access policies work correctly. This is not the case in the vast majority of cases.
However, there are some special circumstances where you need to configure Packet Filters
instead of Protocol Rules to support outbound access.
Packet Filters and Inbound Access Control
Access to servers on the internal network is accomplished by using either Server Publishing or
Web Publishing rules. These rules allow you to "publish" servers to external network users.
When you create the publishing rules, ISA Server will open the ports required to allow access to
the internal servers.
There is a misconception that you need to manually enable packet filters for Server Publishing or
Web Publishing Rules to work. This is not true. You can confirm that the Publishing Rule has
opened up the port by running the command:
netstat na
In the output, scroll to the entries for the external interface of the ISA Server and see what ports
it is listening on. You should see the Port for the service that you published. If you don't see this
port opened, there may have been a server publishing failure.
You can use the following command to help you find a port of interest more quickly:
netstat na | find :25
Replace the 25 with the port number you are looking for in the print out.
Packet Filters and Outbound Access Control
Outbound Access Control for ISA Server clients should be done with Protocol Rules and Site
and Content Rules. However, only the Protocol Rules have influence on protocol access, since
Site and Content rules are focused only on site names.
When you create a Protocol Rule, ISA Server will allow inbound and outbound access to ports
specified in the rule. You should never need to create packet filters to support your Protocol
Rules. If the Protocol Rule is not working, then you should check for other factors that may be
causing this situation.
The only exception to the above is when you need to allow outbound access to non-TCP/UDP
protocols. Protocol Rules are based on Protocol Definitions. You can only create Protocol
Definitions for TCP and UDP based protocols. Therefore, if you need to allow outbound access
to protocols such as ICMP or GRE, you must create packet filters to allow SecureNAT clients
outbound access to these non-TCP/UDP protocols.
NOTE:
Keep in mind that while you can allow SecureNAT clients to access these non-TCP/UDP
protocols using packet filters, you cannot apply access controls. For example, if you enable
outbound PPTP through the ISA Server, ALL SecureNAT clients will have access to outbound
PPTP. The same is true for ICMP based protocols, such as PING. All SecureNAT clients will
have access to outbound ICMP and PING.
Something to keep in mind regarding Protocol Rules is that if you enable a rule that allows "All
IP Traffic, it will work differently depending on what type of client is accessing that rule.
Firewall Client computers will have outbound access to all TCP/UDP ports, but SecureNAT
clients only have access to the protocols that are specified in the Protocol Defintions that are
configured in the ISA Server.
Summary
Packet filters are used to control inbound and outbound access on the external interface of the
ISA Server. When packet filtering is enabled, a packet filter, Protocol Rule or Publishing Rule
must exist in order to allow traffic into and out of the ISA Server.
Packet filtering should be enabled when the ISA Server is on the edge of the network. You
should also enable packet filter when you create a Trihomed DMZ, since you must use packet
filters to control inbound and outbound access to and from the DMZ segment. Packet filters are
also used to allow applications and services on the ISA Server itself to work properly.
You should not use packet filters instead of, or to support, Protocol Rules and Publishing Rules.
The Rules themselves will allow inbound and outbound access required to open the ports
specified in the rules.

TMG Back to Basics - Part 2: Using the TMG Firewall Log Viewer
by Deb Shinder [Published on 14 Dec. 2010 / Last Updated on 20 May 2013]
This article provides an overview of the TMG firewall's logging features.
If you would like to read the other parts in this article series please go to:
TMG Back to Basics - Part 1: Server Publishing Rules
TMG back to Basics - Part 3: Protocol Definitions
TMG Back to Basics - Part 4: Network Objects
TMG Back to Basics - Part 5: Network Objects (Cont.)
TMG Back to Basics - Part 6: Reports
TMG Back to Basics - Part 7: SharePoint Server Publishing
TMG Back to Basics - Part 8: SafeSearch, URL Filtering and Certificate Revocation Options
Introduction
Continuing our Back to Basics series, this time were going to talk about how to use the TMG
Firewall log viewer. The TMG firewall, like the ISA firewall before it, is a product that can do
many good things. It can serve as a network firewall, forward and reverse web proxy server,
remote access VPN server, site to site VPN server, and web anti-malware and URL filtering
server; these are some of the key roles the TMG firewall can play on your network. But one
feature that might not be apparent to the new TMG firewall administrator is the powerful and
useful logging feature. In this article, well provide an overview of the TMG firewalls logging
feature.
Theres no better way to understand how it works than to see it in action. To begin our overview,
lets click the Logs & Reports node in the left pane of the TMG firewall console, as seen in
Figure 1 below.

Figure 1
In the Task Pane, on the Tasks Tab, youll see a number of options available for configuring and
running the logging function on the TMG firewall. Lets start by clicking the Configure
Firewall Logging link in the Tasks Tab, as seen in Figure 2 below.

Figure 2
This brings up the Firewall Logging Properties dialog box. On the Log tab, you can choose
what type of logging you want to enable. There are three options:
SQL Server Express Database (on local server)
DQL Database
File
The default setting is SQL Server Express Database (on local server). If you want to log to an
off-box SQL server, you would select the SQL Database option and then click the Options
button to configure what SQL database the TMG firewall would use for logging. If you want to
log to a flat file, you can select the File option and then select the file type; in this case, both
W3C extended log file format and TMG Log File format are available options.
So how do you decide which is best for you? File logging is faster than SQL logging, but you
have limited query abilities on flat file logging, so if you dont have an off-box SQL database
you want to use, I recommend that you use the default logging option. Click the Options button
to the right of the SQL Server Express Database (on local server) option, which is shown in
Figure 3.

Figure 3
In the Options dialog box, configure the location where you want to save the log files, as shown
in Figure 4. The default location is the Logs folder in the default TMG installation folder on the
local hard disk, but you can select another location by typing in the full path or browsing for it.
You can also configure log file storage limits. The defaults are:
Limit total size of log files is limited to 8 GB by default
Main free disk space is set to 512 MB by default this prevents the hard disk from becoming
full with log files
Main log storage limits by : Deleting older log files as necessary is the default setting when
storage limits are exceeded; you also have the option to discard new entries if you prefer to
keep the old entries
Delete files older than (days) is set to 7 by default
Notice that the Compress log files option is grayed out when we selected to log to a SQL or
SQL Express database. This is because you can only compress flat file logs.

Figure 4
Click the Fields tab, shown in Figure 5. Here you can specify which fields the TMG firewall will
log for each of the connections that are logged to the firewall service. If you find that your log
files are too large, one thing you can do to decrease the size is to reduce the number of fields that
are logged for the connections.

Figure 5
Note that similar options are available when you click the Configure Web Proxy Logging link
in the Tasks Tab on the Task Pane.
Now, we will click the Configure Log Queue link in the Tasks Tab on the Task Pane. This
brings up the Log Queue Storage Folder dialog box thats shown in Figure 6. Here you can
configure where you want to place the log queue. The log queue is a storage location for log
entries that need to wait for the firewall to format them properly. The purpose of the log queue is
to allow the TMG firewall to keep log entries that might have otherwise been lost because they
were coming in too quickly. With the TMG firewall log queue, these entries are quickly placed
in the queue and will wait there until the firewall is able to process the log entries.

Figure 6
Now click the View Log Status link in the Tasks Tab in the Task Pane. This will display the
Log Status dialog box, which is shown in Figure 7. You can view the following information
here:
Server shows the server where the log queue is being reported
Updated Up To shows the time to which the log file has been updated
Log Queue (KB) shows the number of log entries that are currently in the log queue
Status shows the status of the log queue
This is all useful information to check when you suspect that youre getting flooded by a virus or
worms.

Figure 7
Next, click the Define Log Text Colors link on the Tasks Tab in the Task Pane and you will see
the Define Log Text Colors dialog box thats shown in Figure 8. The default colors are listed
here for the most common log file entries of interest. Color coding of the log file entries makes
it much easier for you to get a quick visual representations of what how many entries of each
type there are, and to find the entries youre looking for. You can click the Color button if you
want to change the color of any of these entries. Another handy feature is that you can use the
Export Colors Scheme and Import Colors Scheme button to export and import color schemes
from other TMG firewalls.

Figure 8
The Hide IPv6 log entries link in the Tasks Tab on the Task Pane, shown in Figure 9, is a very
useful option. When you spend a lot of time reading TMG log files, youll find that there are a
very large number of IPv6 broadcasts on your network. These IPv6 entries can make the log file
very cluttered and hard to eyeball. When you click this button, the IPv6 entries will still be
logged, but they will be hidden from view so that its easier for you to view the log entries
without the IPv6 noise.

Figure 9
Now click the Edit Filter link in the Tasks Tab on the Task Pane. Here you will see that there
are three default values:
Log Record Type is set to firewall or web proxy filter. You typically will not change this.
Log Time is set to live you will sometimes want to change this
Action is set to not equal Connection Status this helps reduce the noise in the log file filter
In Figure 10 below, you can see that I have selected the Log Time entry and then clicked the
down arrow for the Condition drop down box. You will see here that there are many options for
filtering the time window for the log file entries you want to see. Note that after you change the
value, you will need to click the Update button to change the filtering value.

Figure 10
You can filter the log files by a large number of factors. In Figures 11, 12 and 13 below you can
see the options in the Filter by drop down list. When you select a value on this list, you then
click the Condition down arrow to select the condition and then you set the Value. After you do
these three things, you click the Add To List button so that it will appear in the list of filters.

Figure 11

Figure 12

Figure 13
In the Figure 14 below, I selected the Client IP entry in the Filter by drop down list. Then I
clicked the down arrow for the Condition drop down box. Here you can see that you have a
number of choices, which allows you to drill down to the entries that interest you the most.

Figure 14
After you make the selections you want for the log filter, click the Start Query button. After a
while, you will see in the status bar on the bottom on the console that the Query is done and it
will show you the number of log file entries that match the parameters of your query, as shown
in Figure 15.

Figure 15
The results of the query will appear in the console and the colors of the entries will match those
that you configured in the log colors dialog box we saw earlier. Notice that the names of the
fields are in the columns for each of the log file entries, as shown in Figure 16. You can scroll to
the right to see the details of each of the log file entries.

Figure 16
Note that the columns you see at first are the default fields configured to be displayed. If there is
a field that youre interested in and it doesnt appear, you can right click one of the columns and
click the Add/Remove Columns command, as seen in Figure 17 below.

Figure 17
This brings up the Add/Remove Columns dialog box. On the left side is a list of Available
columns, which you can see in Figure 18. Scroll through the list and find the field(s) that youre
interested in and then click the Add button to move it to the Displayed columns section. Click
OK and then return to the console. Now scroll to the right and youll see the information for
those columns you added listed for the log file entries you filtered. Nice!

Figure 18
When you click on a log file entry, you can see more details in the details section under the list
of the log file entries. In Figure 19 below you can see detailed information about the entry,
including valuable HTTP and proxy related information in the Additional information section.

Figure 19
Summary
In this Back to Basics article, we showed you a high level overview of the logging and log
filtering features that are included with the TMG firewall. As you can see, the TMG firewall logs
a great deal of information about each connection made to and through the TMG firewall. You
can use the log viewer to drill down to the entries that are of most interest to you and the filtering
process is comprehensive and very easy to configure. I hope you enjoyed this overview and if
you have any questions about how to use the logging and filtering feature included with the
TMG firewall, let me know! Write to me at dshinder@isaserver.org and Ill get back to you as
soon as I can. Thanks!
If you would like to read the other parts in this article series please go
Home
Articles & Tutorials
Miscellaneous
Fix for ISA stall when ODBC data source is unavailable.
by Jens Madsen [Published on 19 Dec. 2001 / Last Updated on 21 May 2013]
1
One weekend I had an ISA server failure due to the SQL server that is used for my logs was
unavailable. ISA server stalls its services if the ODBC data source becomes unavailable or when
it cant authenticate to the SQL server.

One weekend I had an ISA server failure due to the SQL server that is used for my logs was
unavailable. ISA server stalls its services if the ODBC data source becomes unavailable or when
it cant authenticate to the SQL server.
This gave me some problems since I couldnt get in remotely (ISA wouldnt let any traffic thru)
to change the ISA logging configuration and restart the services.
I found a way to have ISA reconfigure itself to use text logging and restart its services by using
alerts and events in case ISA cant connect or authenticate to its ODBC data source.
1. Reconfigure all three services in the Logs node to log to text files and save the configuration.
Do not restart the services since this is only a temporary configuration.

2. Start the registry editor (Regedit.exe) and export the following branch to the root of the c:
drive. Name the file txt-logs.reg:

Hkey_Local_Machine\Software\Microsoft\Fpc\Arrays\{GUID}\Logs
Verify that you have a registry file on your c: drive called: txt-logs.reg
3. Configure all three services in the Logs node back to log to your already defined ODBC data
source and save the configuration. (I assume you were already using an ODBC data source for
logging). Do not restart the services since the reconfiguration in step 1 was never in effect (we
didnt restart the services in that step).

4. Configure Invalid ODBC log credential alert in the Alerts node. On the General tab; make sure
that alert is enabled. The Events tab should be left unchanged (let the event fire on the first
occurrence). The Actions tab is where the important configuration is done. Check the Program
switch and enter regedit /s c:\txt-logs.reg in the Run this program field. This will let regedit
merge the registry branch we saved earlier back into the registry and reconfigure ISA to log to
text logs. The /s switch after regedit will do it in silent mode (you will not get an annoying dialog
on the screen telling you the branch was imported into the registry). Check the Stop selected
services switch, click on the Select button and make sure all three services are selected. Then
check the Start selected services switch, click on the Select button and make sure all three
services are selected. This will stop and then start all three services so that the reconfiguration of
the logging that was entered into the registry will take effect.

I tested this setup by all of a sudden just downing my SQL server. The alert came up which then
triggered the event that modified my registry and restarted the services. It worked beautifully.
There was only a short (seconds) interruption of the services.
Once the database server is again available I can reconfigure the ISA back to ODBC logging and
restart the services manually. Also the text logs can be imported back into your database server
using Access or Foxpro.
It might be a good idea to also send an e-mail alert in case this happens, since the re-
configuration and starting/stopping of the services is pretty transparent.
The reconfiguration options based on alerts are endless when you know where to pull the
configuration parameters out of the registry (and merge them in again).
Hope this is a helpful little trick.

SA 2006 Dashboard System Performance Monitoring DOA
by Debra Shinder [Published on 17 Oct. 2006 / Last Updated on 17 Oct. 2006]
During beta testing of the 2006 ISA Firewall I noticed that a few of the versions came with a
broken packet counting feature on the ISA Firewall monitoring Dashboard. I figured it was just a
beta bug and that it would be fixed in the RTM version of the 2006 ISA Firewall. In fact, I was
right about this, because there was a final version of the ISA Firewall, released during the beta
phase of the product, where the packet performance graphs worked correctly.
So what's the beef? The final beta version of the ISA Firewall apparently wasn't the one used in
the RTM product, because in the RTM ISA 2006 Standard Edition release, the packet graphs in
the System Performance area of the Dashboard no workie, as you can see in the figure below.

I'm posting this not to just complain, but to find out if anyone else has noticed the same thing,
and if so, has anyone found a "secret fix" to get the graphs working again. I'm sure it will be
fixed by ISA 2006 SP1, but if there's a way to get them working again before that, it would be
great!
Missing in Action -- Log Off When User Leaves Site
One of the nice features included with the ISA 2004 Firewall was the ability to publish an OWA
Web site and configure the Web listener for the rule to automatically log the user off when the
user moves to a different site in the same browser session.
For example, the user might be at an airport kiosk and log onto his email account using OWA.
Then the user might enter the URL to the www.foxnews.com site to check on the latest news. In
ISA 2004, if the user returned to the OWA site clicking the back button a few times, he would
have to log in again because the Web listener would be configured to log the user off when he
leaves the site.
Apparently, this feature was supposed to be included in the 2006 ISA Firewall, but somehow got
left on the cutting room floor. Why do I think it was supposed to be included with the new ISA
Firewall? Check out the screenshot below of the ISA 2006 Help File:

However, if you check out the dialog box that this Help File entry refers to, you'll see:

Perhaps there is a Registry entry that will enable this behavior? If so, I'm not aware of it.
Hopefully this setting will be returned to us with ISA 2006 SP1 is released.
SA 2006 Firewall Alerts -- Doing Their Job
Most of the books and instructional materials aren't very good at providing you a good look at a
live ISA Firewall and the alerting mechanism on a production ISA Firewall deployment. Because
of that, I thought I'd share a screenshot with you of one of my ISA Firewall's Alerts Section and
also it's performance console. Nothing really to teach here, but it gives you something neat to
look at :)

HTH,
How to setup SQL Logging in ISA Server.
by Nathan Obert [Published on 5 March 2001 / Last Updated on 21 May 2013]
1. Create service account in Active Directory/User Manager.
2. Open SQL Enterprise Manager

3. Create new database in SQL Server (SQL Enterprise Manager)

4. Create login in SQL Enterprise Manager, using NT Account from step #1.

5. Assign login 'db_owner' security of newly created database.

6. Locate SQL Files on ISA Server CD (g:\isa\*.sql)

7. Open all 3 files individually and run from Query Analyzer. This will create tables and
indexes.

8. Open Data Sources (ODBC) within Administrative Tools.

9. Create new System DSN by clicking on 'Add'.

10. Select SQL Server, and click 'Finish'.

11. Type in Name, and Description. Select your SQL server from dropdown. (click next)

12. Click Next

13. Select 'Change the default database to:' and select newly created database.

14. Click Next.

15. Click 'Test Data Source...'

16. Click 'OK'. As you can see everything is setup right so far.

17. Select 'Monitoring Configuration' and then 'Logs'.
The next steps involve reconfiguring the 3 components in the above screenshot.
18. Double click on each of the 3 components individually and configure as instructed below.

19. Select 'Database'
20. Make sure the DSN matches the one you just created.
21. Table name is 'FirewallLog' .
22. Click 'Set Account', and choose the account you created.
Note: In this example a local account was used, so no domain name is displayed.

23. Same as previous steps but Table Name is 'PacketFilterLog'.

24. Same as previous steps but Table Name is 'WebProxyLog'.

Sign in

The Private Cloud Man
Private Cloud Technologies, Architecture and more!
Options
Home
About
Email Blog Author
Share this
RSS for posts
Atom
RSS for comments
Search Blogs

Search this blog Search all blogs
Tags
Certificates
Contest
DA
DirectAccess
Fun
Infrastructure
IP-HTTPS
IPv6
IPv6 Transition Technology
ISATAP
NAP
Security
Split Tunneling
SSTP
Teredo
test lab guides
The Edge Man
TLG
TLGs
Tom Shinder
tomsh
Troubleshooting
UAG
UAG SP1 RC
Unfied Access Gateway
Archive
June 2013 (1)
April 2013 (1)
January 2013 (1)
November 2012 (1)
March 2012 (1)
May 2011 (1)
April 2011 (6)
March 2011 (6)
February 2011 (10)
January 2011 (14)
December 2010 (16)
November 2010 (13)
October 2010 (11)
September 2010 (2)
August 2010 (6)
July 2010 (4)
June 2010 (4)
May 2010 (4)
April 2010 (4)
March 2010 (6)
February 2010 (1)
TechNet Blogs The Private Cloud Man Considerations When Using Ping to Troubleshoot DirectAccess
Connectivity Issues
Considerations When Using Ping to Troubleshoot DirectAccess Connectivity Issues
Thomas W Shinder - MSFT
13 Jul 2010 7:06 PM
2
Youre learning about DirectAccess and you like what you see. The next step is to build out a
test lab. You can build out your own, or you can let me to the heavy lifting for you and use the
UAG DirectAccess Step by Step Guide over at http://technet.microsoft.com/en-
us/library/ee861167.aspx Youll save a lot of time by using the lab I put together for you, and
youll learn a lot about DirectAccess terminology and configuration issues.
When you do put your Test Lab together, youll find that there are a lot of technologies and a lot
of steps involved with making it work. The reason for this is that DirectAccess is really a
collection of product and platform technologies that work together to create a working remote
access solution that weve named DirectAccess. All the components of the solution need to be
configured correctly for it to work.
And that will likely be your first challenge when you start working with DirectAccess. Youll
have gone through all the steps in the Step by Step guide and BAM! It didnt work. Dont worry
a lot of the technologies are probably new to you. That means theres a good chance that you
missed a step. Ive done it, other DirectAccess experts have done it. Consider this a normal part
of the DirectAccess learning process. After youve gone through the test lab a few times, all the
concepts and technologies will fall into place in your mind and youll actually get to a place
where youll forget what it was like not to understand how all the DirectAccess pieces fit
together.
With that in mind, I wanted to take a few minutes to talk to you about using ping to test
DirectAccess connectivity. Were all accustomed to using ping to test connectivity issues this
is something firmly ingrained in all of our years with working with the Windows network
operating system. And while you definitely can take advantage of ping to help you troubleshoot
DirectAccess connectivity issues, there are a few things that you need to keep in mind about
ICMP and DirectAccess connectivity.
DirectAccess Tunnels are IPsec Tunnels
First, remember that DirectAccess uses IPsec tunnels between the DirectAccess client and
DirectAccess server to allow DirectAccess clients access to intranet resources. There are two
tunnels:
The Infrastructure Tunnel the purpose of this tunnel is to allow the DirectAccess client to a
subset of servers on the intranet that are required for name resolution (DNS servers) and
authentication (domain controllers) and health checking (NAP servers) and remediation (update
servers). There may also be other servers you want to include in this list, such as management
servers (Configuration Manager). The infrastructure IPsec tunnel is established after both
computer certificate and computer account (NTLMv2) authentication is successful. Enabling the
user account (normally computer account) access allows the Infrastructure tunnel to come up
before the user logs on.
The Intranet Tunnel the purpose of this tunnel is to allow the DirectAccess clients access to
the rest of the network. It should be clear that DirectAccess is not a firewall solution and should
not be considered one. DirectAccess is meant to replicate the intranet experience and the
DirectAccess client should be considered the same as any client on the intranet. For that reason,
there are no access controls places on the DirectAccess client after the DirectAccess client
authenticates with the DirectAccess server. The intranet IPsec tunnel is established after
computer certificate and user account (the logged on user) (Kerberos) authentication is
successful.
It is commonly said by DirectAccess experts (including myself) that all traffic moving through
the DirectAccess client to resources on the intranet is through one of these tunnels. This is true
for all traffic except ICMP traffic. In a UAG DirectAccess scenario, IPsec policy is configured to
exempt ICMP from IPsec authentication and encryption. Therefore when you ping a resource on
the intranet, you are sending those pings outside of the infrastructure and intranet IPsec
DirectAccess tunnels.
Now you might be asking yourself If the ping traffic isnt going through the DirectAccess
tunnels, how it is getting to the intranet? Thats a good question and unless youve been in the
IPv6 transition technology game for awhile, the answer is definitely not obvious.
A Tale of Two Tunnels
Take a look at the figure below. What I tried to draw here are two tunnels. The larger tunnel is an
IPv6 transition technology tunnel. IPv6 transition technologies can be used to allow the IPv6
communications between the DirectAccess client and DirectAccess server to be carried over the
IPv4 Internet. The DirectAccess client can use one of three IPv6 transition technologies over the
Internet: 6to4, Teredo or IP-HTTPS. The details of each these isnt important here.
What is important is to understand is that each of these IPv6 transition technologies tunnel IPv6
packets inside an IPv4 header. Inside of the IPv6 transition technology IPv4 tunnel is the IPsec
tunnel where IPsec is used to authenticate and encrypt the IPv6 packets. When you think about
DirectAccess tunnels, you should think of two tunnels the IPv6 transition technology tunnel
and the IPsec tunnel.

The above figure shows that ICMP messages are carried over the IPv6 transition technology
tunnel, but that they are outside the IPsec tunnel. The reason why we decided to do this is to
make Teredo work correctly, as Teredo requires ICMP access outside the IPv6 IPsec tunnel to
determine what type of NAT device the DirectAccess client might be located.
What are the Issues Related to ICMP Being Passed Outside the IPsec Tunnel?
Because of this decision, you need to be aware of a couple of issues:
Since the ICMP traffic is not encrypted, it can potentially be read by a device that is IPv6
transition technology aware. This information might be of interest to attackers or other curious
individuals. For information on this issue, please see http://technet.microsoft.com/en-
us/library/ee809059.aspx Be aware that if you force ICMP through the DirectAccess IPsec
tunnels, you will not be able to use Teredo.
When troubleshooting DirectAccess connectivity issues, the ability to ping resources on the
intranet indicates that the IPv6 transition technology is working, but does not provide any
information regarding whether or not the infrastructure or intranet IPsec tunnels were
established.
Before going into the details of ICMP traffic and troubleshooting, I wanted to point out where
the ICMP exemptions for IPsec traffic are configured. In the first figure below you can see the
Group Policy Object (GPO) for the DirectAccess servers. When you right click the Windows
Firewall with Advanced Security LDAP {GUID} entry and click Properties, youll see what
appears in the figure right below it in the Windows Firewall with Advanced Security dialog
box, on the IPsec Settings tab. In the IPsec exemptions frame, youll see the Exempt ICMP
from IPsec option is set to Yes.

ICMP, Ping and Troubleshooting DirectAccess Connectivity
Now lets take a look at what happens when the IPsec infrastructure and intranet tunnels fail. In
this example, I took a working DirectAccess setup and broke it by configuring the UAG
DirectAccess server to use the wrong root certificate for mutual computer authentication. Since
the root certificate configured in the UAG DirectAccess configuration points to a root CA that
didnt issue the computer certificates used for computer certificate authentication, all IPsec
tunnel connection attempts will fail.
One of the standard things we do when troubleshooting DirectAccess connections is to see if we
can ping the 6to4 address of the UAG DirectAccess server itself. You can get this address by
using the
netsh namespace show effectivepolicy
command on the DirectAccess client, as seen in the figure below.

Now that we have that address, lets try and ping it.

Yay! That worked and shows that we have IPv6 connectivity with the DirectAccess server. This
proves that at least the IPv6 transition technology is working enough so that we can ping the
UAG DirectAccess server side of the Teredo (in this example) tunnel. What it doesnt tell us is if
the other components that allow address to resources behind the UAG DirectAccess server are
functional.
To enable ICMP access to resources behind the UAG DirectAccess server, you will need to
know the IPv6 address of the resource you want to connect to. This can be an ISATAP address
or a native IPv6 address (or as well see later, a NAT64 address). It doesnt matter which type
what matters is the fact that the DirectAccess client only communicates with the DirectAccess
server and the networks behind it using IPv6 (except when NAT64/DNS64 is used, in which case
the communications are NATed by the UAG DirectAccess server, so that between the
DirectAccess client and the UAG DirectAccess server IPv6 is used and communications between
the UAG DirectAccess server and the IPv4 resource on the intranet, IPv4 is used).
We can go to the domain controller on the network and use ipconfig /all to check its ISATAP
address. In this example the ISATAP address of the domain controller (DC1) is
2002:836b:2:8000:5efe:10.0.0.1 so well ping that ISATAP IPv6 address from the DirectAccess
client on the Internet.

Yay again! It worked. Now we know that the Teredo tunnel between the DirectAccess client and
the DirectAccess server is up, and that the Teredo relay configured on the UAG DirectAccess is
working.
What About IPv4 Only Resources How Do I Ping Them?
What if youre not using ISATAP and youre not using native IPv6 addresses behind the UAG
DirectAccess server? This is a common scenario where you have an IPv4-only network behind
the UAG DirectAccess server. In this case, youre taking advantage of the UAG DirectAccess
servers NAT64/DNS64 capabilities. If you want to learn more about NAT64/DNS64, I highly
recommend you read Meir Mendelovichs excellent coverage of this subject over at
http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-
nat64-and-dns64-in-action.aspx
The problem we have to solve is how do we figure out what the NAT64 address is of an IPv4
only host? Well, the answer comes from an exceptional blog post by Ben Bernstein over at
http://blogs.technet.com/b/edgeaccessblog/archive/2009/10/13/deep-dive-into-uag-directaccess-
ipv6-and-directaccess.aspx
The UAG NAT64 address of an IPv4 only host is:
2002:WWXX:YYZZ:8001:[Hex of IPv4 address] /96 (the /96 means that the prefix is 96 bits
of the 128 bit IPv6 address)
The WWXX:YYZZ is the Hex representation of the first of the two consecutive IPv4 public
address on the UAG DirectAccess Server. You can figure this out if you like, but UAG has
already done this work for you. If you look in the figure above, you can see these components of
the IPv6 address:
836b:2: this is the WWXX:YYZZ Hex representation of the IPv4 address
8000: this is the value used to represent the ISATAP prefix (this is covered in more detail in
Bens article if you want more information in this)
What we can do is take this information and build out our NAT64 address for the IPv4 only
resource. First, we can define our prefix, which is:
2002:836b:2:8001 /96 (the 8001 value is used to represent the NAT64 prefix)
The last 32 bits of the address is Hex representation of the IPv4 only resource. In this example,
the IPv4 only resource has the IPv4 address 10.0.0.4. We convert to this to Hex:
10 = 0a in Hex (8 bits)
0 = 00 in Hex (8 bits)
Or 0a00:0004 (32 bits represented by two 16 bit blocks)
Now we can put our prefix and address together and get:
2002:836b:2:8001:0000:0000:0a00:0004 /96
You might be wondering where the 0000:0000 entry came from. First, you need to know that
each block (the value between the colons) represents 16 bits. There are eight blocks in a 128
bit IPv6 address. We defined the first 64 bits of the NAT64 prefix with the four blocks
2002:836b:2:8001. However, the NAT64 prefix is 96 bits, so we need to add another 32 bits to
the prefix to make it add up to 96. We can do this by adding two blocks of zeros. That gives us
the 96 bit prefix. Then we just append the Hex presentation of the 32 bit IPv4 address at the end.
NOTE:
There is something called zero suppression when describing IPv6 addresses where leading
zeros can be left out and where they can be replaced with a double colon ::. We dont need to
get into that now, but youll notice that is done automatically by the operating system when it
converts the WWXX:YYZZ and also in the ping responses.
Lets give it a try.

Yay for a third time! It worked again. This proves that we have ICMP connectivity to both IPv6
and IPv4 resources on the intranet. At this point we must be feeling pretty good, as weve
successfully pinged the UAG DirectAccess server and a IPv4 and IPv6 resources on the intranet.
But what about traffic isnt ICMP? A quick check can be done by using the web browser. In the
figure below Im using the ISATAP address of a web server on the intranet. Notice that if you
want to use IPv6 addresses in Internet Explorer, you have to surround them with brackets.

This connection fails because its using HTTP, which isnt ICMP. The reason for the failure is
that in order to transport HTTP, the DirectAccess IPsec tunnels must be available. And because I
broke IPsec, there are no tunnels. You can prove that to yourself by using the Windows Firewall
with Advanced Security console and finding no Main Mode or Quick Mode Security
Associations. There is a process to troubleshoot IPsec tunnel establishment failure, but thats not
why were here today :)
Summary
The key points I want you to remember from this article include:
DirectAccess uses two tunnels: IPv6 transition technology tunnels and an IPsec tunnels
ICMP is exempted from IPsec protection
You can ping the UAG DirectAccess server and resources behind it without establishing an IPsec
tunnel
If the IPsec tunnels do not come up, you will not be able to use any non-ICMP protocol to
connect to the the UAG DirectAccess server or resources behind it
The ability to ping gives you no information about IPsec tunnel establishment.
by Deb Shinder [Published on 30 Nov. 2010 / Last Updated on 20 May 2013]
3
TMG Back to Basics series, is a continuation of the "Controlling Internet Access: A short Primer
on TMG Access Rules" series for new TMG administrators. Weve already covered Web
Publishing Rules, Networks and Network Rules, and Access Rules.
If you would like to revert back to the "Controlling Internet Access: A short Primer on TMG
Access Rules" series please go to:
Controlling Internet Access: A Short Primer on TMG Access Rules (Part 1)
Controlling Internet Access: A Short Primer on TMG Access Rules (Part 2)
Controlling Internet Access: A Short Primer on TMG Access Rules - Part 3: TMG Firewall Web
Publishing Rule Basics
Controlling Internet Access: A short Primer on TMG Access Rules - Part 4: TMG Networks and
Network Rules
Introduction
If youre new to the TMG firewall, you might have wondered what Server Publishing Rules are
all about. The good news is that Server Publishing Rules are really simple they are essentially
reverse Network Address Translation rules that allow you to reverse NAT for a number of
protocols. However, Server Publishing Rules are more than just reverse NAT, because the TMG
firewall includes a number of Application Filters (essentially NAT Editors) to support complex
protocols, and there are also a number of security related application Filters that improve the
security of the reverse NAT.
In contrast to Web Publishing Rules, which can be extraordinarily complex, Server Publishing
Rules are typically very simple. Because of their simplicity, some TMG administrators prefer to
use Server Publishing Rules over Web Publishing Rules, even though a Web Publishing Rule
might be the better decision from a security point of view. For example, publishing Exchange
2010 can be very complex, and while there is a wizard that does part of the work for you, it
ignores the auto discovery feature that is so useful. Thus many people will do an SSL Server
Publishing Rule to publish Exchange instead of going through the major hassle of trying to Web
Publish Exchange.
In fact, because that scenario is so common, in todays example well create an SSL Server
Publishing Rule to show you exactly how its done. To begin creating a Server Publishing Rule,
click on the Firewall Policy node in the left pane of the console, and then click the Tasks Tab in
the Task Pane. On the Task Pane, click the Publish Non-Web Server Protocols link, as shown
in Figure 1.

Figure 1
This brings up the Welcome to the New Server Publishing Rule Wizard page, shown in Figure
2. In the Server publishing rule name text box, enter a number for the Server Publishing Rule.
In this example, well name the rule Complex SSL Site (well pretend, for purposes of this
example, that this is an Exchange CAS server that were publishing). Click Next.

Figure 2
On the Select Server page, shown in Figure 3, enter the IP address of the server on the internal
network that you want to publish. If you dont know the IP address, you can click the Browse
button.

Figure 3
When you click the Browse button, it will bring up the Find Internal IP Address dialog box
thats shown in Figure 4. Enter the name of the server you want to publish in the Server name
text box and click Browse. When the system finds the server, it will list the IP address in the IP
addresses list. Click OK after finding the IP address.

Figure 4
After you see the IP address on the Select Server page, shown in Figure 5, click Next.

Figure 5
On the Select Protocol page, as seen in Figure 6, select the protocol you want to allow to be
used by the published server. In this example, we want to allow SSL to the published server, so
we select the HTTPS Server protocol from the drop down list. Note that when publishing sites
using Server Publishing Rules, you use Server protocols, such as the HTTPS Server protocol
we used in this rule. Click the Properties button.

Figure 6
This brings up the Properties dialog box thats shown in Figure 7. Click the Parameters tab.
Here you can see the port or port ranges that are used by the protocol. When you use the built in
protocols, you typically wont want to change the ports. Here you get information about the
primary and secondary connections that are supported by the protocol. You also get information
about any Application Filters that are bound to the protocol. In this example, you can see that
this server has Bandwidth Splitter installed on it, and the Bandwidth Splitter Application Filter
appears in the Application Filters list. Click Cancel to dismiss this dialog box.

Figure 7
Click the Ports button. In the Ports dialog box shown in Figure 8, you can exercise more fine-
tuned control over the ports used by the Server Publishing Rule. In the Firewall Ports section,
you can use the default port for the protocol, or you can change the port. For example, the default
port used by the HTTPS Server protocol is TCP 443. However, if you wanted to use an alternate
port, you could select the Publish on this port instead of the default port option and name an
alternate port. As long as no other rule or application is listening on that port and IP address, itll
work fine.
You can also do port redirection if you like. In the Published Server Ports section, you see that
the default setting is to Send requests to the default port on the published server. In this
example, the HTTPS Server protocol uses the default port of TCP 443 so it would forward the
connection to that port on the published server. However, if you wanted to use another port on
the published server to accept SSL connections, you can change it to something else, and then
select the Send requests to this port on the published server option and enter the alternate
port. This is pretty user friendly stuff.
You can also control which source ports are used by the user who wants to connect to the
published server. In the Source Ports section, the default setting is Allow traffic from any
allowed source port. Since most applications are going to use a dynamically assigned source
port, this is generally the best way to go. However, if you want to improve the security for some
applications (such as RDP publishing), you could select the Limit access to traffic from this
range of source ports and then enter a limited range, and force the RDP client application to use
the ports you designate here.

Figure 8
Click Next after selecting the protocol that you want to publish on the Select Protocol page,
shown in Figure 9.

Figure 9
Before we move to the next page of the wizard, lets take a look at the Server Protocols that are
available to you out of the box. Remember, when you create Server Publishing Rules, you
need to use a Server protocol. When you click on the Firewall Policy node in the left pane of
the console and click the Toolbox tab (you cant do it right now because youre in the middle of
the wizard) and then click the Server Protocols node, shown in Figure 10, youll see a list of
Server Protocols that you can use in Server Publishing Rules. This is a pretty comprehensive list!
Of course, if the protocol you want to use isnt in this list, you can always create your own
Server Protocol by clicking on the New menu.

Figure 10
Now lets get back to the wizard. On the Network Listener IP Addresses page thats shown in
Figure 11, select the Network or Networks on which you want to listen for incoming requests. In
most instances youll want to accept incoming connections from the default External Network,
so youll put a checkmark in the External checkbox on this page. However, in most cases you
dont want to listen on all the IP addresses on the NIC. If you have more than one IP address
bound to the external interface, you should click the Addresses button and select the specific IP
address to which you want users to make the connection. If you have a NAT device in front of
the TMG firewall, then you should select the IP address to which the NAT device is forwarding
the connections when external users are trying to connect to the published server.

Figure 11
Review your settings on the Completing the New Server Publishing Rule Wizard page, shown
in Figure 12, and then click Finish.

Figure 12
After you click Finish, you can see the new Server Publishing Rule in the Firewall Policy list, as
seen in Figure 13.

Figure 13
Double click on the Server Publishing Rule you just created. There are a couple of tabs worth
taking a look at here, as they expose some options that you didnt have when you went through
the wizard. Click on the From tab, shown in Figure 14. Notice on the From tab that This rule
applies to traffic from these sources lists Anywhere. In most cases, youll want to leave it this
way. But what if you have some addresses or networks that you dont want to have access to the
published server through this rule? You can click the Add button in the Exceptions section and
enter those addresses. This gives you some measure of access control over which addresses can
connect through this Server Publishing Rule.

Figure 14
On the To tab, shown in Figure 15, notice the two options in the Request for the published
server section. The default setting is Requests appear to come from the original client. This
means that the published server will see the actual IP address from which the connection came
over the Internet. If you choose this option, the published server will need a route to the Internet
and its default gateway must provide access to such a route. If you dont want to provide the
published server a route to the Internet, you can select the Requests appear to come from the
Forefront TMG computer. When you select that option, the published server only needs a route
that enables it access to the internal IP address of the TMG firewall. However, when you select
that option, the source IP address for the incoming connections to the published server will be
the IP address on the internal interface of the TMG firewall and that address will appear in the
published servers log files.

Figure 15
Once youre done, click Apply at the top of the middle pane of the TMG firewall console and
save the changes to firewall policy. After that, connections to the published server will be
allowed on the protocol you selected for the rule.
Summary
In this article, part of our Back to Basics series for new TMG administrators, we went over the
topic of Server Publishing Rules. As you saw, Server Publishing Rules are very simple to put
together and allow you to enable reverse NAT to published servers on your intranet. There are a
number of Server protocols that you can use to create Server Publishing Rules right out of the
box, or you can create your own Server Protocols. Some of the Server Protocols have
Application Filters that make the protocol more secure, or that perform some level of protocol
validation. You also saw that you could customize the protocol and redirection behavior when
configuring the Server Publishing Rule. Have fun with Server Publishing Rules and let me know
if you run into any problem with them!
MG back to Basics - Part 3: Protocol Definitions
by Deb Shinder [Published on 4 Jan. 2011 / Last Updated on 20 May 2013]
1
This article reviews TMGs Protocol Definitions. All firewall rules require a Protocol Definition
as part of the rule configuration.
This week we continue our TMG Back to Basics series with a simple, but very important basic
TMG concept that you might not even be aware of: Protocol Definitions. The reason why you
might not be aware of Protocol Definitions is that Microsoft has done a great job of including a
number of Protocol Definitions in TMG right out of the box so that you dont even need to know
about them. But there are times when it is useful to be aware of this feature.
Protocol Definitions are a key feature of every firewall rule you create on the TMG firewall. The
Protocol Definition defines the protocol thats used to allow inbound or outbound access to or
through the TMG firewall. For example, if you create a rule that allows outbound access to the
HTTP and HTTPS protocols, that rule will include the Protocol Definitions for the HTTP and
HTTPS protocols. A Protocol Definition is required for all firewall rules, which includes Access
Rules and Web Publishing Rules and Server Publishing Rules.
Lets delve a little deeper into this. To view information about your Protocol Definitions, click
the Firewall Policy node in the left pane of the TMG firewall console. Click the Toolbox tab in
the Tasks Tab, then click the Protocols entry on the Toolbox tab. There you will see a number of
groups of Protocol Definitions, as shown in the figure below.

Figure 1
Click on the Common Protocols group. Here, as shown in Figure 2, you will see a list of
Protocol Definitions for the protocols that are most commonly used when configuring firewall
rules on the TMG firewall.

Figure 2
Scroll down the list of Protocol Groups. Click on the All Protocols group, as shown in Figure 3.
Here you will see a list of all the Protocol Definitions that are included in the TMG firewall right
out of the box. There are well over a hundred Protocol Definitions included and that selection
should support just about any protocol to which you would want to allow inbound or outbound to
or through the TMG firewall in typical scenarios. But there are special circumstances when
youll need to create your own definitions. Scroll through the list of Protocol Definitions to get
an idea of whats available. Being aware of whats available out of the box can save you time
when you are considering creating your own custom Protocol Definition. After all, why go to the
trouble of creating a new Protocol Definition if theres already one there that will serve your
purpose?

Figure 3
Now lets look at a specific definition. Double click the HTTPS Protocol Definition. This brings
up the HTTPS Properties dialog box thats shown in Figure 4. On the General tab, youll see
the name of the Protocol Definition and a short description of the protocol. Youll also see the
Associated Standard Protocol section, but it will be grayed out in most cases; well talk about
this feature later.

Figure 4
Now click on the Parameters tab. On the Parameters tab, shown in Figure 5, you can see the
Primary Connections, the Secondary Connections and the Application Filters sections. Well
talk about these sections in more detail later, too but you can see here which protocols, ports
and direction is associated with the protocol.

Figure 5
Speaking of directions for Protocol Definitions, check out Figure 6 below. Notice that there is an
SMTP Protocol Definition and a SMTP Server Protocol Definition. You might be wondering:
What is the difference?

Figure 6
Its all about direction. If you look at the Parameters of the SMTP Protocol Definition, shown
in Figure 7, youll see that the Direction is Outbound. When you create Access Rules, you will
always use a Protocol Definition that supports outbound protocols.

Figure 7
Now if you look at the SMTP Server Parameters, shown in Figure 8, youll see that the
direction there is Inbound. When you create Server Publishing Rules, you will always use a
Protocol Definition that has the Inbound direction. In addition, notice that there is an
Application Filter associated with the SMTP Server Protocol Definition. In this case, the SMTP
Filter is associated with the SMTP Server Protocol Definition. This means that some level of
application layer inspection will be applied to connections that match firewall rules that use the
SMTP Server Protocol Definition.

Figure 8
How to Create New Protocol Definitions
Now that youve seen some examples of existing Protocol Definitions, lets find out how you can
create your own custom Protocol Definitions. Why would you ever want to do this? Well, you
might need to create a custom definition if you have a new application that requires a protocol
that isnt included with the out of the box Protocol Definitions.
Luckily, its pretty simple. You start creating a new Protocol Definition by clicking the Toolbox
tab in the Task Pane and then clicking the Protocols section. Then click the New menu and click
Protocol, as shown in Figure 9 (the RPC Protocol is an advanced option that we wont cover in
this article).

Figure 9
This will bring up the Welcome to the New Protocol Definition Wizard page thats shown in
Figure 10. Enter a name for the new Protocol Definition in the Protocol Definition name text
box. In this example, well name the Protocol Definition Disambigulator Protocol and then
click Next.

Figure 10
On the Primary Connection Information page, as seen in Figure 11, you enter the protocol and
the port or ports required for the primary connection. The primary connection is the first
connection(s) made by the system initiating the connection to another host. Click the New
button.

Figure 11
This brings up the New/Edit Protocol Connection dialog box that you can see in Figure 12.
Here you must select the following:
Protocol type. You select from a list that includes TCP, UDP, ICMP and IP-Level. If you select IP-
Level you will need to enter the IP Protocol Number in the Protocol Number text box. If you
select the ICMP option, you will need to enter an ICMP Code and an ICMP Type. For TCP and
UDP protocols, you will need to enter a port or port range. For all protocols, you will need to
enter a direction.
Direction. Here you enter the direction. For all protocols except UDP, you need to select either
inbound or outbound. For UDP, you have more choices, as youll see in the next step.
Port Range. If you select TCP or UDP, you need to enter a port range here. If there is only a
single port, then enter the same port number in the From and To boxes.
ICMP Properties. If you are creating a new ICMP protocol, then you will need to enter an ICMP
type and code in the text boxes.

Figure 12
If you select a UDP protocol, then your choices for selecting a direction are different. As you can
see in Figure 13, our choices are Receive, Receive Send, Send and Send Receive. It can be hard
to know in advance which direction will work. In general, I will start with Receive or Send
(depending on the direction receive is equivalent to inbound and send is similar to outbound).
If that doesnt work, Ill use Receive Send or Send Receive. Its tricky in some cases, and you
might need to experiment with the direction for UDP protocols.

Figure 13
In this example, our protocol is a UDP protocol and its used for outbound connections so we
will select UDP and Send, as shown in Figure 14. This protocol uses a single port, which is
9966, so we enter that number in the From and To boxes in the Port Range section and then
click OK.

Figure 14
The Secondary Connections page, which you can see in Figure 14, is used for what we call
complex protocols. A complex protocol is one that requires new connections after the initial
connection. For example, the client might require a secondary inbound connection from the
server after it establishes its connection to the server using the primary connection protocol/port.
If thats the case, you will need to configure a secondary connection. Its important to note that if
you have a protocol that requires a secondary connection, the client type youre using is going to
matter. SecureNAT clients require an Application Filter to support complex protocols. However,
if youve deployed the Firewall Client (TMG client), then you dont need an application filter.
Application Filters are complex to develop, so its highly recommended that you deploy the
TMG client if you need support for secondary connections.

Figure 15
Okay, were at the end of the wizard. Lets review the settings on the Complete the New
Protocol Definition Wizard page thats shown in Figure 16 and click Finish.

Figure 16
Youre finished with the wizard, but youre not done yet. Go back to the Toolbox tab and click
the User-Defined group. Here you see a list of Protocol Definitions that you created. Double
click on the Protocol Definition you just created, as shown in Figure 17.

Figure 17
Notice on the General tab, shown in Figure 18, that you have the option to Associate this
protocol definition with this standard protocol. You would choose this option if you wanted
the TMG NIS to inspect this connection with signatures written for the protocol you select here.
In general, you wouldnt want to do this, but there might be situations where youd want to take
advantage of this option. One example might be when you want to support an alternate port for
HTTP or HTTPS connections that are being established outside of the web proxy filter.

Figure 18
On the Parameters tab thats shown in Figure 19, you can also associate an Application Filter
with the protocol. You need to be careful about doing this, though, since the filters are designed
for specific protocols and wont work if you assign them to Protocol Definition that doesnt
match the requirements of the filters. In general, you would not assign an application filter to a
custom Protocol Definition.

Figure 19
Summary
In this article, we covered Protocol Definitions. All firewall rules require a Protocol Definition as
part of the rule configuration. Protocol Definitions are generally designed to be either inbound or
outbound. Outbound Protocol Definitions are used for Access Rules and inbound Protocol
Definitions are used for Web and Server Publishing Rules. There are also complex Protocol
Definitions, where more than one connection is required to support the application. When using
complex protocols remember that SecureNAT clients require an application filter to support the
complex protocol, whereas Firewall clients do not require an application filter. You likely wont
often need to create new Protocol Definitions, but there might be times when you need to create
a custom Protocol Definition to support a new application or product. Let me know if you have
questions about Protocol Definitions and Ill get back to you as soon as possible. Thanks! Deb.
MG Back to Basics - Part 4: Network Objects
by Deb Shinder [Published on 1 Feb. 2011 / Last Updated on 20 May 2013]
In this article, well take a high level view of the Network Objects available with the TMG
firewall and also discuss how you might use them in common scenarios.
Introduction
Continuing our TMG Back to Basics series, this time were going to take a close look at
Network Objects. This is one TMG concept that doesnt get much attention. Although Network
Objects arent particularly exciting, they are critical to configuring all firewall rules on the TMG
firewall. If you dont have a Network Object to support the source or destination in a firewall
rule, then you wont be able to create the rule that you intend to create.
Network Objects allow you to configure source and destination settings for all firewall rules,
including publishing rules, on the TMG firewall. Network Objects are reusable software pieces
settings that allow you to define source and destination in a variety of ways. Those of you who
have been working with Microsoft firewall products for a while may remember that Network
Objects were first introduced with ISA Server 2004. The TMG firewall builds on the Network
Objects used in previous versions of the ISA firewall and significantly improves on them.
Working with Network Objects
To find the Network Objects, click the Firewall Policy node in the left pane of the TMG firewall
console, and then click the Toolbox tab in the Task Pane. Click the Network Objects section
header. Here you will see a list of the types of Network Objects available to you, as shown in
Figure 1. Each folder actually contains a number of Network Objects you can use to construct
TMG firewall rules.

Figure 1
Click the Networks folder. Here youll see a list of TMG Firewall Networks that are configured
on this machine, as shown in Figure 2. Remember that a TMG Firewall Network is required for
each NIC on your TMG computer. In addition, there are some default TMG Firewall Networks,
such as the VPN Clients network, which is dynamically constructed to include the IP addresses
used by remote access VPN client computers.
For more information on TMG Firewall Networks, check out my article here.

Figure 2
Now click on the Network Sets folder. This exposes the Network Sets that are currently
configured on this computer, as shown in Figure 3. A Network Set is a collection of Networks
that you can use when setting a source or destination on an Access Rule or Publishing Rule. The
default Network Sets include:
All Networks (and Local Host). This Network Set includes all IPv4 addresses. While this Network
Set can be useful for some troubleshooting scenarios, its a fairly dangerous Network Set to use
because if you create a rule that uses this Network Set as a destination, it includes the Local
Host Network, which is the TMG firewall itself and this could potentially open the firewall up to
unintended compromise.
All Protected Networks. This Network Set includes all TMG Firewall Networks except for the
default External Network. Essentially, this Network Set is defined by all TMG Firewall Network
that are behind the TMG firewall.
Forefront Protection Manager. This is not used, as Forefront Protection Manager was cancelled.

Figure 3
If you double click on All Protected Networks you will see the Properties dialog box for that
Network Set. Click the Networks tab, shown in Figure 4. Note that all Networks that do not have
a checkmark in the checkbox are included in the Network Set. This can be a little confusing at
first glance since the logical assumption would be that checked items are included.

Figure 4
Click the Computers folder. Here you see the Computer objects configured on the TMG
firewall, as shown in Figure 5. There are no default Computer objects. All computer objects are
custom objects and you need to create them yourself.

Figure 5
If you double click on one of the Computer objects, youll see that it consists of a name and an
IPv4 address, as shown in Figure 6.

Figure 6
Click on the Computer Sets folder. Here you see the Computer Sets that are currently
configured on the TMG firewall. There are a number of default Computer Sets, and the default
Computer Sets will vary based on which edition of the TMG firewall youre using. In other
words, the Standard Edition of the TMG firewall will have different default Computer Sets than
the Enterprise Edition of the TMG firewall. In Figure 7 below, youll notice that there are a
number of Forefront Protection Manager Computer Sets. These are not used because the
Forefront Protection Manager project was cancelled.
Some important Computer Sets that you should know about include:
Anywhere. This means, literally, anywhere which is the same as all IPv4 IP addresses.
Array Servers. This is automatically configured for you to include the IP addresses of all servers
that are part of the same array.
Enterprise Remote Management. This Computer Set includes the IP addresses of machines that
are allowed to remotely manage the array. This is not automatically populated except in the
situation where you use an EMS. In all other cases, you will need to enter the addresses
yourself.
Managed Server Computers. This is a predefined list of computers that are allowed to connect
to the EMS server.
You can double click on the other Computer Sets to see their intended purposes.

Figure 7
When you double click on one of the Computer Sets, you can see the details of the set, as shown
in Figure 8. A Computer Set can contain multiple entries, and each entry can be an IPv4 address,
a range of IPv4 addresses or even a subnet.

Figure 8
Click the Address Ranges folder. In the TMG firewall, there is a single default Address Range,
which is Anywhere (IPv6), as shown in Figure 9. Since TMG has very limited support for IPv6,
this Address Range is mostly often used to support DirectAccess on UAG DirectAccess servers.

Figure 9
When you double click on the Address Range, you can see that it includes the name of the
Address Range, the Start Address and the End Address, as shown in Figure 10.

Figure 10
Click the URL Sets folder next. There is a single default URL Set, shown in Figure 11, which is
not used as it was intended to be used to support Forefront Protection Manager scenarios because
yep, you remembered FPM was cancelled. All URL Sets now are custom URL Sets that you
need to create yourself. URL Sets are used in rules that use the HTTP or HTTPS protocols and
are applied only to Web proxy clients. If you want to set a source or destination in a firewall rule
that will not have Web proxy clients, then you should use Domain Name Sets instead of URL
Sets. In the past, URL Sets were useful for URL Filtering but with the new TMG Firewall URL
Filtering feature, URL Sets are typically used for highly customized access control settings on
firewall rules.

Figure 11
Now click the URL Categories folder. Here, as shown in Figure 12, you see a large number of
URL Categories that are used by the URL Filtering feature included with the TMG firewall.
These URL Categories are dynamically updated by the Microsoft Reputation Services servers on
the Internet and are not populated on the TMG firewall so you will not see the URLs in a
particular set when you look at the Properties dialog box of specific URL Category.

Figure 12
Click the URL Category Sets folder. Here you see a list of the default URL Category Sets,
shown in Figure 13. Each Category Set is a collection of other URL Categories. URL Category
Sets are intended to simplify the task of URL filtering for you, so that you dont have to pick and
choose multiple URL Categories yourself to get your desired result for web filtering.

Figure 13
Double click on one of the URL Categories and click the URL Categories tab in the Properties
dialog box. Here, as shown in Figure 14, you will see a list of all the URL Categories. The URL
Categories that belong to the set will have a checkmark in the checkbox next to the category.

Figure 14
Click the Domain Name Sets folder. Here you see a list of Domain Name Sets configured on
this computer, as shown in Figure 15. Domain Name Sets include domain names, which can also
include a wildcard on the high-order label in a domain name. Domain Name Sets are used by all
TMG client types: SecureNAT, web proxy and Firewall client (TMG client). There are also a
number of built-in domain name sets, which vary depending on whether youre using the
Standard or Enterprise Edition of the TMG firewall. Some of the Domain Name Sets are pre-
populated for you, such as the Sites Example from HTTPS Inspection.

Figure 15
You can see the details of a Domain Name Set when you double click on it, as shown in Figure
16. You can add more domain names to the list by clicking the Add button.

Figure 16
Click on the Web Listeners folder, as you can see in Figure 17. Note that there are no default
Web Listeners all Web Listeners are custom and you need to create the ones you need.

Figure 17

25. You are now done, here is an example SQL Query you can run to display ICMPs only.
MG Back to Basics - Part 5: Network Objects (Cont.)
by Deb Shinder [Published on 15 Feb. 2011 / Last Updated on 20 May 2013]
In this article we'll take a look at how you can create the more complex types of Network
Objects.
Intorduction
In the first part of this two part series on TMG Firewall Network Objects, we went over the
different Network Objects and what they represent. We also saw how you can create simple new
Network Objects.
Dont let that word scare you. Heres the good news: Each of the complex Network Objects
can be created by using a wizard. Wizards are available to create the following types of Network
Objects:
Network
Network Sets
URL Category Sets
Web Listener
Server Farm
Lets take a look at the information that youll need to know in order to create each of these.
The New Network Wizard
You can begin the process of creating a new Network by clicking on the Network entry in the
New menu. Remember that in TMG Firewall nomenclature, a Network represents a collection of
IP addresses that are directly reachable from a particular interface on the TMG firewall.
The first thing youll see is the Welcome to the New Network Wizard page. On this page, you
enter a name for the Network in the Network name text box. In this example, well name the
Network DMZ 2, as shown in Figure 1.

Figure 1
On the Network Type page, which you can see in Figure 2, you are given several different
Network types to choose from:
Internal Network. This is typically a Network that contains servers or clients that you want to be
protected by the TMG firewall. When you create an Internal Network, the Properties dialog box
of the Network will have all the options you see in the default Internal Network.
Perimeter Network. A Perimeter Network is similar to an Internal Network. In fact, there is no
practical difference between a Perimeter Network and an Internal Network both provide the
same options in their Properties dialog boxes. However, for accounting purposes, you will want
to choose the Perimeter Network option to make it clear that this is a DMZ network, and not an
Internal Network. The key difference here is that DMZ Networks typically will include Internet
facing devices.
VPN Site-To-Site Network. This is a special Network type that is used when you want to create a
site to site VPN connection between your TMG firewall and another firewall. Note that while
you can create the remote site Network from this wizard, you would more typically do it from
within the wizard that is used to create the site to site VPN.
External Network. An External Network is considered an unprotected Network and represents a
collection of IP addresses that reside outside of any of the TMG Firewall Protected Networks.
You would create an External Network if you want to add additional external interfaces on the
TMG firewall and then create routing table entries for specific destinations that can be reached
through the NIC that form the root of the External Network you created.
In this example, well select the Perimeter Network option.

Figure 2
On the Network Addresses page, which is shown in Figure 3, you configure the addresses that
define the Network. You can add the addresses in three different ways: by adding an adapter, by
adding a private address range, or by adding a custom address range. Weve found that in most
cases, the best way to create a new Network is to base it on a specific NIC. In this example, well
click the Add Adapter button. That brings up the Select Network Adapters dialog box. In this
dialog box, you need to put a checkmark in the checkbox next to the NIC that is the root of your
new Network.

Figure 3
Once youve done all this, you can then review the settings of the new TMG Firewall Network
on the Completing the New Network Wizard page, which you see in Figure 4. (Note that the
IP addresses are different because I already used the Guest Network for another TMG Firewall
Network).

Figure 4
You can then go to the Networking node in the left pane of the console and double click the new
Network. There youll see the Properties dialog box thats shown in Figure 5. Notice that this
Perimeter Networks Properties dialog box is the same as what you would find if you had created
an Internal Network.

by Deb Shinder [Published on 1 March 2011 / Last Updated on 20 May 2013]
3
TMG Back to Basics is a set of articles designed with the new TMG administrator in mind. We
continue our Back to Basic series today with a discussion of the TMG Reporting feature.
Introduction
The TMG reporting feature is one of the more interesting and impressive features included with
the TMG firewall, with which you can create interesting and informative reports without the
need to learn any query language. While the TMG reports are somewhat limited in their
configurability, youll find that these reports are likely to contain the information you need to
make key decisions regarding TMG firewall policies and your users.
Lets get started with reports. In the left pane of the TMG firewall console, click the Logs &
Reports node and then click the Reports tab. After you click the Reports tab, click the Tasks
Tab in the Task Pane. Here youll see the Tasks list that appears in Figure 1 below. Lets start by
examining what you can do after clicking the Configure Reporting Settings link.

Figure 1
In the Reporting Properties dialog box, the first tab is the Log Summary tab. All reports are
based on the information contained in Log Summaries. The default setting is to Enable daily
and monthly summaries option. Make sure this option is enabled if you want to generate daily
and monthly summaries. Weekly reports are based on the daily summaries.
The Generation time is the time during which the summary is created. Because the creation
process is processor intensive, its a good idea to set this so the summaries will be generated late
at night (assuming thats when the load on your server is lightest). In keeping with this, the
default setting is 12:30 A.M. You can also configure the Number of saved daily summaries
and Number of saved monthly summaries here, as shown in Figure 2. The number of
summaries saved will determine how far into the future you can create various types of reports.

Figure 2
On the Report Server tab, which is shown below in Figure 3, you can configure which of the
firewalls in a TMG firewall array is to be responsible for creating the reports. Only one machine
in the array will create the report, so you should choose the machine that has the most CPU
horsepower, since report generation is processor intensive.

Figure 3
Creating a Recurring Report
Now lets take a look at how you go about creating a report. On the Tasks Tab in the Task Pane,
click the Create a Recurring Report link. This brings up the Welcome to the Recurring
Report Job Wizard page thats shown in Figure 4. In the Report Job name text box on this
page, enter a name for the report. Since well be creating a weekly report here, well get really
creative and name the report Weekly Report. Click Next.

Figure 4
On the Recurring Report Job Scheduling page thats shown in Figure 5, you specify how often
and on what day of the week or month the report job is to run. You have three options:
Daily
Weekly, on this day every week
Monthly, on this day every month
Notice that the weekly and monthly options give you a choice of the day or date for report
generation. In this example, were creating a weekly report, so well select that option and then
choose Monday as the day to generate the report each week. Click Next.

Figure 5
On the Report Content page thats shown in Figure 6, you select which types of content you
want to appear in the report. By default, all of the listed categories of content are included. These
include the summary, web usage, application usage, traffic and utilization, security, malware
protection, URL filtering and Network Inspection System (NIS). For each of the content
categories, you can edit the details that will be included in that category by clicking the Edit
Report Details button.

Figure 6
When you click on the Edit Report Details button, youll see the Report Details dialog box for
that section, as shown in Figure 7. In the Subcategory section, you can click the down arrow to
configure a subsection. Then in the Report details for this subcategory section, you can
configure the Parameter Value.

Figure 7
Figure 8 below shows the configuration option for another subcategory.

Figure 8
Next, on the Send E-mail Notification page thats shown in Figure 9, you enter the details
required for the system to notify you by email that a report is available. These details include:
SMTP server the name or address of an SMTP server that can send email to the people to
whom you want notifications sent. Make sure there is a firewall rule on the TMG firewall that
allows outbound SMTP to the location of the SMTP server.
From the email address you want to assign to the TMG firewall.
To the email address(es) to which you want the notification to be sent.
Cc the email address(es) of anyone you want cc:d on the notification.
Message a message to be included in the email notification.
An example of how you would configure this is in the figure.

Figure 9
On the Report Publishing page, shown in Figure 10, put a checkmark in the Publish reports to
a directory checkbox. In the Published reports directory text box, enter the local or remote
location where you want to store the reports. If you store the reports on a file server, then click
the Set Account button to enter the user name and password of the user account who has
permissions to post to the file servers directory where the reports are stored.
Note that you dont have to do this if you are storing the reports on the TMG firewall, but if you
want to see the reports that are stored on the TMG firewall, you will need to access them at the
firewall itself and not through an SMB connection to the firewall from some other computer on
the network.

Figure 10
Review the settings on the Completing the Recurring Report Job Wizard page, as shown in
Figure 11, and click Finish.

Figure 11
Click the Apply button, shown in Figure 12, to save the changes.

Figure 12
User Activity Reports
Now lets see how to create a User Activity Report. This is a new feature included with the TMG
firewall that wasnt available with the ISA firewall. Click the Generate User Activity Report
link in the Tasks Tab in the Task Pane. This brings up the Welcome to the User Activity
Report Job Wizard, which is shown in Figure 13. In the Report Name test box, enter a name
for the report. In this example, well name the report Tom Shinders laptop, so we can keep tabs
on what Toms been up to. :)

Figure 13
On the Report Content page thats shown in Figure 14, youll see that the only option is User
Activity. Click Editor Report Details.

Figure 14
In the Report Details dialog box, which is shown in Figure 15, the only subcategory thats listed
is Web Sites, so you wont be able to see any information about any other types of servers the
user accessed. In the Report details for this subcategory section, you can edit the Parameter
Value for the Report Period and Users. For users, you can use user names or IP addresses. User
names only appear if you configured the client systems as Firewall or Web Proxy clients.

Figure 15
On the Send E-mail Notification page, which is shown in Figure 16, you enter the mail details
in the same way as described earlier.

Figure 16
On the Report Publishing page, which is shown in Figure 17, you once again enter the details in
the same way as described earlier.

Figure 17
Now review the settings on the Completing the User Activity Report Job Wizard page, shown
in Figure 18, and click Finish.

Figure 18
Remember to click the Apply button, shown again in Figure 19, to save the changes to the
firewall configuration.

Figure 19
Now right click the report name and click Generate and View Report, as shown in Figure 20. It
will probably take a minute or so for the report to generate.

Figure 20
You can watch the gears turn, as seen in Figure 21, while youre waiting!

Figure 21
After the report has been generated, it will be displayed automatically. Figure 22 below shows
the results of this report. Not very interesting, is it? It seems that Toms activities are all
business.

Figure 22
Viewing Reports
You can view reports after theyre created, by right clicking on the name of the report you want
to see and then clicking View Published Reports, as shown in Figure 23.

Figure 23
This will open the folder where you are saving the reports, as you can see in Figure 24. Double
click on the folder that contains the report you want to see.

Figure 24
In this example, find the file named Report in the folder that contains the report in which youre
interested and double click on it, as shown in Figure 25.

Figure 25
The report opens and shows a number of sections, as you can see in Figure 26.The figure shows
the sections that are contained in the default report.

Figure 26
Figure 27 shows an example of one of the sections; in this case, its the Top Applications
section, which shows which are the top used applications for connecting to the Internet. Note that
the Firewall Client must be installed on the client computers in order to get this information
about which applications are being used.

Figure 27
Figure 28 below shows an example of another section, which in this case is the Top URL
Categories section.

Figure 28
Summary
In this Basics article for new TMG admins, we provided you with a high level overview of
how to create reports on the TMG firewall. This included how to configure report settings,
including log summaries, and how to create recurring and user reports. Then we finished up by
looking at the categories of information contained in the default report and saw some examples
of the details of report categories.
by Deb Shinder [Published on 10 May 2011 / Last Updated on 20 May 2013]
1
We continue our "back to basics" series for the TMG firewall this week with some coverage of
basic SharePoint Server publishing.
Introduction
If youre new to the TMG firewall, you might not be familiar with the term publishing in this
context. When working with the TMG firewall, the term publishing is used to refer to the use of
either reverse web proxy or reverse NAT. When publishing SharePoint, youll be configuring the
TMG firewall to perform the reverse web proxy function.
The TMG firewall includes a wizard that makes publishing SharePoint sites very easy. The TMG
firewall can publish one SharePoint server or multiple SharePoint servers, or even SharePoint
web farms, with or without a load balancer. The TMG firewalls SharePoint Publishing Wizard
does a lot of configuration in the background that you dont see in the wizard interface, which
ensures that when you publish your SharePoint server, everything is set up automatically to
make sure that the users can access all components of your SharePoint solution.
Since this is part of our Back to Basics series, in this article on publishing SharePoint servers
well focus on a very simple scenario: a public access SharePoint server that doesnt require
users to authenticate and that hosts information that is available to everyone. In this simple
scenario, no authentication is required and no encryption is required. More complex scenarios
can involve a variety of authentication and encryption options and well address those in other
future articles. But for a back to basics article, well stick with the basics.
Setting up your SharePoint server is way beyond the basics of this article, but if you need help
with that, check out the comprehensive guidance on the Microsoft TechNet site.
After your SharePoint site is set up, you can then open the TMG firewall console and click on
the Firewall Policy node in the left pane of the TMG firewall console. In the Tasks Tab of the
Task Pane, click the Publish SharePoint Sites link.
This brings up the Welcome to the SharePoint Publishing Rule Wizard page. Enter a name for
the rule in the SharePoint publishing rule name text box. In this example, shown in Figure 1,
well name the rule TACTEAM SharePoint. Click Next.

Figure 1
On the Publishing Type page, you have three options:
Publish a single web site or load balancer. Use this option if you want to publish a single
SharePoint server or publish multiple SharePoint servers that are located behind a load
balancer.
Publish a server farm of load balanced web servers. Use this option when you want to publish a
farm of SharePoint servers and take advantage of the built in web farm publishing feature
included with the TMG firewall.
Publish multiple web sites. Use this option if you want to publish multiple SharePoint sites or
multiple sites located behind multiple load balancers
In this example, we want to publish a single SharePoint server, so well select the Publish a
single web site or load balancer option, as shown in Figure 2. Click Next.

Figure 2
On the Server Connection Security page, shown in Figure 3, you have two options:
Use SSL to connect to the published web server or server farm. Use this option if you want to
create a connection between the internal interface of the TMG firewall and the SharePoint
server that uses SSL encryption to secure the connection.
Use non-secured connections to connect the published web server or server farm. Use this
option if you want the connection between the internal interface of the TMG firewall and the
SharePoint server to be unencrypted.
For this example, well use the Use non-secured connections to connect to the published web
server or server farm option and click Next, but note that the SSL option is more secure.

Figure 3
On the Internal Publishing Details page, which is shown in Figure 4, enter the internal name of
the SharePoint site in the Internal site name text box. This is the name that internal clients use
to connect to the SharePoint server on the internal network. In this example, well use the name
sps.tacteam.net and click Next.

Figure 4
On the Public Name Details page, shown in Figure 5, always select the This domain name
(type below) option from the Accept requests for drop down list. In the Public name text box,
enter the name that external users will use to access the SharePoint site. In this example, well
use the name spspublic.tacteam.net and click Next.
Notice in the example that I dont use a strict split DNS infrastructure for publishing the
SharePoint site. If youve been a fan of ISAserver.org for a while, you might know that Tom is a
big fan of the Split DNS infrastructure. However, Tom will also tell you that a strict split DNS
infrastructure can cause some problems with DirectAccess and Ive seen that myself in my own
DirectAccess deployment. Therefore, well be using different host names to connect to the
SharePoint site, based on whether the user is located on the external or internal network.

Figure 5
A Web Listener is required to accept incoming connections for published servers. You can create
HTTP and HTTPS Web Listeners. In this example, we need to create an HTTP Web Listener.
On the Select Web Listener page, shown in Figure 6, click the New button.

Figure 6
On the Welcome to the New Web Listener Wizard page, which is shown in Figure 7, enter a
name for the Web Listener in the Web Listenername text box. In this example, well name the
Web Listener HTTP Listener, since it will be accepting only HTTP connections for the
published SharePoint site. Click Next.

Figure 7
On the Client Connection Security page, shown in Figure 8, you have two options:
Require SSL secured connection with clients. Use this option when you want to force external
clients to use SSL to connect to the external interface of the TMG firewall to reach the
SharePoint site, for better security.
Do not require SSL secured connections with clients. Use this option to allow unencrypted
connections to the TMG firewalls external interface to reach the SharePoint site behind the
TMG firewall.
In todays example, since were keeping everything basic, well select the Do not require SSL
secured connections with clients and click Next.

Figure 8
On the Web Listener Addresses page, shown in Figure 9, you specify which IP addresses are
used to accept connections for this Web Listener. In this example, well select External and then
click Select IP Addresses. Then well select the specific IP addresses for which we want this
Web Listener to accept connections.

Figure 9
You can see the IP address that was selected for this Web Listener in Figure 10 below. Notice
that you can configure the Web Listener to listen for incoming connections on other Networks,
including internal Networks. This would allow you to publish your SharePoint server to internal
clients too. This is very useful in many scenarios when you want to take advantage of the TMG
security benefits for access not only for external clients, but internal clients as well.

Figure 10
On the Authentication Settings page, shown in Figure 11, you can set the type of authentication
you want to require to access the published SharePoint site. In this example, were not requiring
any type of authentication, so well select the No Authentication option. Click Next.

Figure 11
On the Single Sign On Settings page, as shown in Figure 12, you can configure Single Sign On
to allow users to authenticate once with the TMG firewall and then access all published web sites
that use this web listener. Notice that the option isnt available at this time. The reason for this is
that weve configured this Web Listener to not require authentication. Click Next.

Figure 12
Review the settings on the Completing the New Web Listener Wizard page and then click
Finish, as shown in Figure 13.

Figure 13
On the Select Web Listener page, shown in Figure 14, click Next.

Figure 14
On the Authentication Delegation page, shown in Figure 15, you can configure the method the
TMG firewall uses to authenticate the session it opens with the published sites. When
authentication is required by the TMG firewall, you can configure the TMG firewall to delegate
credentials so that the user doesnt have to authenticate again with the published SharePoint site;
instead, the TMG firewall forwards the credentials it has already received by the user. In this
example, the users arent authenticating with the TMG firewall, so well select the No
delegation, and client cannot authenticate directly. There is also another option available that
enables the user to authenticate directly with the published SharePoint site, but this is a bad idea
since the session is not encrypted.

Figure 15
On the Alternate Access Mapping Configuration page, shown in Figure 16, you have two
choices:
SharePoint AAM is already configured on the SharePoint server. Use this option when you
have configured the AAM settings on the SharePoint site. I recommend that you always
configure the AAM settings on the SharePoint site in advance of publishing the SharePoint site
with the TMG firewall. While you can access some features of the SharePoint site without
configuring AAM, not everything will work. For the best experience, always configure AAM and
then select this option when you publish the SharePoint site.
SharePoint AAM is not yet configured.Also select this option if you are unsure if AAM is
configured.I recommend that in general, you should never use this option; configure AAM first
on the SharePoint site before publishing the site.
In this example well select the SharePoint AMM is already configured on the SharePoint
server and click Next.

Figure 16
On the User Sets page, shown in Figure 17, you can specify which users are allowed to connect
to the SharePoint site. In this example we will allow anonymous access, which is the same as All
Users. Click Next.

Figure 17
Review the settings on the Completing the New SharePoint Publishing Rule Wizard page,
shown in Figure 18, and then click Finish.

Figure 18
Summary
In this back to basics article, we reviewed the SharePoint publishing wizard and to run the
wizard in a very simple SharePoint publishing scenario where anonymous access is allowed and
no encryption is required. In a future article, well publish a SharePoint site that requires users to
authenticate with the TMG firewall and have the TMG firewall delegate credentials to the
published site. Well also discuss issues related to SSL bridging, and things you want to consider
regarding SSL bridging. See you then! Deb.
MG Back to Basics - Part 8: SafeSearch, URL Filtering and Certificate
Revocation Options
by Deb Shinder [Published on 14 June 2011 / Last Updated on 20 May 2013]
In this article, we will take a quick look at three key features in the TMG firewall - SafeSearch,
URL Filtering and Certificate Revocation.
If you would like to be notified of when Deb Shinder releases the next part in this article series
please sign up to our Real Time Article Update newsletter.
Introduction
This week I thought Id poke around the TMG firewall console to see if there were some
interesting options that I hadnt covered in my Back to Basics series. And lo, I did discover some
options that I havent addressed, including the Safe Search, URL Filtering and Certificate
Revocation options. So in this article, well take a look at these options and what you can do with
them.
When you open the TMG firewall console and click the Web Access Policy node in the left pane
and then click the Tasks Tab in the in tasks pane, youll see the Web Protection Tasks as
shown in Figure 1 below. The Web Protection Tasks that were most interested in today are:
Configure SafeSearch
Configure URL Filtering
Configure URL Category Overrides
Query for URL Category

Figure 1
SafeSearch
First lets click on the SafeSearch link. This brings up the General tab in the SafeSearch dialog
box, which is shown in Figure 2. Youll see that its s pretty simple dialog box. You have one
option here: Enable SafeSearch. But what does that mean? When you enable SafeSearch, the
TMG firewall will enforce strict filtering of adult content from search results delivered by
supported search engines. This makes it possible for you to automatically block adult-oriented
text, videos and images in the workplace. The supported search engines are those that are
included in the Search Engines URL Category.

Figure 2
When SafeSearch is enabled, TMG will step in every time a user does a search on a major search
engine, and modify the query string so that filtered results will be returned. The user cant
disable this in their browsers, so you maintain control over the web content that users can access,
which is increasingly important to avoid lawsuits and liability.
When you enable SafeSearch, it creates a firewall rule, as you can see in Figure 3 below. In this
example, the firewall rule is disabled because I disabled SafeSearch after initially enabling it.
The rule doesnt appear until you enable SafeSearch the first time. If you disable it later, the
TMG firewall will not remove the rule; it will just disable it. That makes it easy for you to switch
SafeSearch on and off when needed. If you enable SafeSearch again, the rule will change state
from disabled to enabled.

Figure 3
But what if there are some users in your organization who need to be exempt from the filtering?
Maybe they do research that gives them a legitimate reason to access adult content. Click the
Users tab, which is shown in Figure 4. On this tab, you can add users who will be excluded from
SafeSearch. When you click the Add button, it will bring up the Users Excluded From
SafeSearch dialog box. Note that these are user groups that you configure on the TMG firewall.
You can use Active Directory groups to populate these groups, but you do need to create the
groups first.

Figure 4
Thats about it for SafeSearch. Its very easy to configure it and works great! Id demo it for you,
but all you would see is a search results page that doesnt include any adult links.

URL Filtering Options
Next, well look at the URL Filtering options. Click on the Configure URL Filtering link in the
right pane of the TMG console. This brings up the General tab that you can see in Figure
5. Once again, there is only one option here: Enable URL Filtering. When URL Filtering is
enabled, access rules can be configured to allow or block traffic based on the URL categories
you select. Note that when this feature is enabled, information about the URL being reached is
sent to the Microsoft Reputation Services for categorization. The TMG firewall doesnt
download a database for this, it sends queries to the MRS database to determine to what category
each URL belongs. This is done over an SSL connection and Microsoft does not keep a record of
the URLs your users are accessing.

Figure 5
URL filtering gives you granular control over the types of content that users can access on the
web. There are a number of predefined category sets: Liability, Bandwidth, Business,
Communication, Entertainment, General Productivity, Information Technology, Lifestyles,
News/Reports, Purchasing, and Security. Each category set includes subcategories; for example,
those in the Liability category set include:
Alcohol
Gambling
Tobacco
Obscene/tasteless
Profanity
Violence
Weapons
Nudity
Pornography
Provocative attire
Mature content
Criminal activities
Dubious
Hacking/computer crime
Hate/discrimination
Illegal drugs
Illegal software
School cheating information
For more information about exactly what types of web sites fall under each of these
subcategories, see this link
Click on the Category Query tab. Here you can test to see what category a particular URL
belongs to. For example, in Figure 6 below you can see that I wanted to determine what category
the URL www.hotpants.com belongs to (I have no idea what kind of site this is so I recommend
that you dont go there). After entering the URL, click the Query button. In the Query Results
section you can see that this URL belongs to the Pornography category (big surprise!).

Figure 6
If you dont agree with Microsofts assessment of a particular category, you can click the Report
a URL to Microsoft Reputation Service as incorrectly categorized link. This brings up a web
page that allows you to enter the URL you want re-categorized, as seen in Figure 7 below. You
can also go there directly by visiting this link.

Figure 7
In the URL Filtering Settings dialog box, click on the URL Category Override tab, as shown in
Figure 8. Here you can add a URL to a different category than the one to which its
automatically added by Microsoft. Click the Add button and the URL Category Override
dialog box appears. Enter the URL in the Override the default URL category for this URL
pattern text box and then from the Move the URL pattern to this URL Category drop down
list, select the new category.

Figure 8
The License Details tab provides a space where you can enter your License agreement
number. You can test the TMG firewall for four months, but then youll need to enter a license
number to keep using the URL filtering feature. URL filtering is subscription-based and is part of
TMGs Web Security Service license, which also includes the Malware Inspection updates.

Figure 9
One more thing. If you create Deny rules, then you need to know about a new option available
for the rule that allows your users to temporarily override the deny rule. Double click on the rule
and click the Action tab, as shown in Figure 10. If you select Deny, you have the option to
Allow user override. When you enable the users to override, you can also set a limit on how
long that override lasts. When a user overrides the rule, the rule is temporarily disabled, and the
Web request continues in the firewall policy evaluation. If you click the Advanced button, you
can select the Display denial notification to user option and include text that the user will see
when the access to a site is denied. The other option is to redirect the user to another site.

Figure 10
URL filtering is important because, by blocking access to inappropriate web sites, you not only
reduce the risk of lawsuits and liability but you also increase security, because these types of
sites often host malware. Further, you conserve bandwidth for legitimate network usage, and you
improve productivity by denying users the opportunity to waste time on such sites. You can also
use URL filtering to block advertising, and you can use URL Filtering reports to track how the
organization uses the Web, determine which users visit which types of sites, and so forth.
Certificate Revocation
Finally, were going to move on to the Certificate Revocation options in TMG, which allow you
to control how TMG handles verification that incoming client and server certificates are not
revoked. If you click on the Web Access Policy node in the left pane of the console and click the
Tasks Tab in the Task Pane, and scroll down to the bottom of the Tasks Tab, youll see the
Configure Certificate Revocation link, as shown in Figure 11 below.

Figure 11
This brings up the Certificate Revocation dialog box thats shown in Figure 12. You have three
options here:
Verify that incoming client certificates are not revoked. This option is enabled by default. When
enabled, the TMG firewall will block access from web clients whose certificates are revoked; this
is typical for web publishing rules.
Verify that incoming server certificates are not revoked in a forward scenario. This is for
outbound access. If the destination web site or web proxy in front of the TMG firewall presents
a revoked certificate, the connection will fail. This is the default setting.
Verify that incoming server certificates are not revoked in a reverse scenario. This option,
which is disabled by default, applies to web publishing scenarios where you are using SSL to SSL
bridging. If the web server that youre publishing presents a revoked certificate, then the
connection request will fail when this option is enabled.

Figure 12
Summary
In this article, we took a quick look at three key features in the TMG firewall SafeSearch, URL
Filtering and Certificate Revocation. While these configuration options arent complex, its
important that you know about them and understand the effects of the various settings. After all,
thats why you have a TMG firewall anyway because its easy to create a secure configuration
for web access control.
MG Back to Basics - Part 8: SafeSearch, URL Filtering and Certificate
Revocation Options
by Deb Shinder [Published on 14 June 2011 / Last Updated on 20 May 2013]
In this article, we will take a quick look at three key features in the TMG firewall - SafeSearch,
URL Filtering and Certificate Revocation.
Introduction
This week I thought Id poke around the TMG firewall console to see if there were some
interesting options that I hadnt covered in my Back to Basics series. And lo, I did discover some
options that I havent addressed, including the Safe Search, URL Filtering and Certificate
Revocation options. So in this article, well take a look at these options and what you can do with
them.
When you open the TMG firewall console and click the Web Access Policy node in the left pane
and then click the Tasks Tab in the in tasks pane, youll see the Web Protection Tasks as
shown in Figure 1 below. The Web Protection Tasks that were most interested in today are:
Configure SafeSearch
Configure URL Filtering
Configure URL Category Overrides
Query for URL Category

Figure 1
SafeSearch
First lets click on the SafeSearch link. This brings up the General tab in the SafeSearch dialog
box, which is shown in Figure 2. Youll see that its s pretty simple dialog box. You have one
option here: Enable SafeSearch. But what does that mean? When you enable SafeSearch, the
TMG firewall will enforce strict filtering of adult content from search results delivered by
supported search engines. This makes it possible for you to automatically block adult-oriented
text, videos and images in the workplace. The supported search engines are those that are
included in the Search Engines URL Category.

Figure 2
When SafeSearch is enabled, TMG will step in every time a user does a search on a major search
engine, and modify the query string so that filtered results will be returned. The user cant
disable this in their browsers, so you maintain control over the web content that users can access,
which is increasingly important to avoid lawsuits and liability.
When you enable SafeSearch, it creates a firewall rule, as you can see in Figure 3 below. In this
example, the firewall rule is disabled because I disabled SafeSearch after initially enabling it.
The rule doesnt appear until you enable SafeSearch the first time. If you disable it later, the
TMG firewall will not remove the rule; it will just disable it. That makes it easy for you to switch
SafeSearch on and off when needed. If you enable SafeSearch again, the rule will change state
from disabled to enabled.

Figure 3
But what if there are some users in your organization who need to be exempt from the filtering?
Maybe they do research that gives them a legitimate reason to access adult content. Click the
Users tab, which is shown in Figure 4. On this tab, you can add users who will be excluded from
SafeSearch. When you click the Add button, it will bring up the Users Excluded From
SafeSearch dialog box. Note that these are user groups that you configure on the TMG firewall.
You can use Active Directory groups to populate these groups, but you do need to create the
groups first.

Figure 4
Thats about it for SafeSearch. Its very easy to configure it and works great! Id demo it for you,
but all you would see is a search results page that doesnt include any adult links.
URL Filtering Options
Next, well look at the URL Filtering options. Click on the Configure URL Filtering link in the
right pane of the TMG console. This brings up the General tab that you can see in Figure
5. Once again, there is only one option here: Enable URL Filtering. When URL Filtering is
enabled, access rules can be configured to allow or block traffic based on the URL categories
you select. Note that when this feature is enabled, information about the URL being reached is
sent to the Microsoft Reputation Services for categorization. The TMG firewall doesnt
download a database for this, it sends queries to the MRS database to determine to what category
each URL belongs. This is done over an SSL connection and Microsoft does not keep a record of
the URLs your users are accessing.

Figure 5
URL filtering gives you granular control over the types of content that users can access on the
web. There are a number of predefined category sets: Liability, Bandwidth, Business,
Communication, Entertainment, General Productivity, Information Technology, Lifestyles,
News/Reports, Purchasing, and Security. Each category set includes subcategories; for example,
those in the Liability category set include:
Alcohol
Gambling
Tobacco
Obscene/tasteless
Profanity
Violence
Weapons
Nudity
Pornography
Provocative attire
Mature content
Criminal activities
Dubious
Hacking/computer crime
Hate/discrimination
Illegal drugs
Illegal software
School cheating information
For more information about exactly what types of web sites fall under each of these
subcategories, see this link
Click on the Category Query tab. Here you can test to see what category a particular URL
belongs to. For example, in Figure 6 below you can see that I wanted to determine what category
the URL www.hotpants.com belongs to (I have no idea what kind of site this is so I recommend
that you dont go there). After entering the URL, click the Query button. In the Query Results
section you can see that this URL belongs to the Pornography category (big surprise!).

Figure 6
If you dont agree with Microsofts assessment of a particular category, you can click the Report
a URL to Microsoft Reputation Service as incorrectly categorized link. This brings up a web
page that allows you to enter the URL you want re-categorized, as seen in Figure 7 below. You
can also go there directly by visiting this link.

Figure 7
In the URL Filtering Settings dialog box, click on the URL Category Override tab, as shown in
Figure 8. Here you can add a URL to a different category than the one to which its
automatically added by Microsoft. Click the Add button and the URL Category Override
dialog box appears. Enter the URL in the Override the default URL category for this URL
pattern text box and then from the Move the URL pattern to this URL Category drop down
list, select the new category.

Figure 8
The License Details tab provides a space where you can enter your License agreement
number. You can test the TMG firewall for four months, but then youll need to enter a license
number to keep using the URL filtering feature. URL filtering is subscription-based and is part of
TMGs Web Security Service license, which also includes the Malware Inspection updates.

Figure 9
One more thing. If you create Deny rules, then you need to know about a new option available
for the rule that allows your users to temporarily override the deny rule. Double click on the rule
and click the Action tab, as shown in Figure 10. If you select Deny, you have the option to
Allow user override. When you enable the users to override, you can also set a limit on how
long that override lasts. When a user overrides the rule, the rule is temporarily disabled, and the
Web request continues in the firewall policy evaluation. If you click the Advanced button, you
can select the Display denial notification to user option and include text that the user will see
when the access to a site is denied. The other option is to redirect the user to another site.

Figure 10
URL filtering is important because, by blocking access to inappropriate web sites, you not only
reduce the risk of lawsuits and liability but you also increase security, because these types of
sites often host malware. Further, you conserve bandwidth for legitimate network usage, and you
improve productivity by denying users the opportunity to waste time on such sites. You can also
use URL filtering to block advertising, and you can use URL Filtering reports to track how the
organization uses the Web, determine which users visit which types of sites, and so forth.
Certificate Revocation
Finally, were going to move on to the Certificate Revocation options in TMG, which allow you
to control how TMG handles verification that incoming client and server certificates are not
revoked. If you click on the Web Access Policy node in the left pane of the console and click the
Tasks Tab in the Task Pane, and scroll down to the bottom of the Tasks Tab, youll see the
Configure Certificate Revocation link, as shown in Figure 11 below.

Figure 11
This brings up the Certificate Revocation dialog box thats shown in Figure 12. You have three
options here:
Verify that incoming client certificates are not revoked. This option is enabled by default. When
enabled, the TMG firewall will block access from web clients whose certificates are revoked; this
is typical for web publishing rules.
Verify that incoming server certificates are not revoked in a forward scenario. This is for
outbound access. If the destination web site or web proxy in front of the TMG firewall presents
a revoked certificate, the connection will fail. This is the default setting.
Verify that incoming server certificates are not revoked in a reverse scenario. This option,
which is disabled by default, applies to web publishing scenarios where you are using SSL to SSL
bridging. If the web server that youre publishing presents a revoked certificate, then the
connection request will fail when this option is enabled.

Figure 12
Summary
In this article, we took a quick look at three key features in the TMG firewall SafeSearch, URL
Filtering and Certificate Revocation. While these configuration options arent complex, its
important that you know about them and understand the effects of the various settings. After all,
thats why you have a TMG firewall anyway because its easy to create a secure configuration
for web access control.

Configuring ISA Server For Incoming Ping Responses

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Configuring ISA Server For Incoming Ping Responses

Diunggah oleh

Hak Cipta:

Format Tersedia

Configuring ISA Server for Incoming Ping Responses

Dieter Rauscher [MVP ISA Server]

Anda mungkin juga menyukai