Your first decision when planning a publishing solution using Forefront TMG 2010 (TMG) or Forefront UAG 2010 (UAG) is to determine which of the two products best fits the needs of the deployment.

Both TMG and UAG can securely publish Exchange, SharePoint, Terminal Services and web-based line of business applications to the Internet. However TMG and UAG offer some features or support some scenarios that the other does not. So, the first step in choosing which product to use is deciding what features you need or think you may need.

Some deployments may actually benefit from using both TMG and UAG to satisfy specific requirements. For example, you might use UAG to provide a unified portal experience for your inbound Web-based client access, use TMG to protect Internet access for your internal users, and use Forefront TMG to provide certificate-based authentication to your mobile device-enabled workforce.

The following table compares both products at a functional level:

Feature or Capability	Forefront Threat Management Gateway 2010	Forefront Unified Access Gateway 2010
Scale Out Using Arrays Arrays enable you to apply the same configuration setting to multiple machines participating in the same array	X	X
Network load balancing of the publishing array Network Load Balancing (NLB) enables high availability and transparent failover for participants in the NLB array	X	X
Load Balancing of Back-End Servers Integrated Web Farm load balancing enables you to load balance connections to back-end web servers, removing the need for a hardware load balancer behind the web gateway	X	X
Single network interface deployment The web gateway can be deployed in a single NIC configuration, so that NICs do not span multiple networks	X
Enterprise Management (multiple nodes in one array) Enterprise Management enables the administrator to manage multiple arrays located throughout the organization from a single management interface; in addition, configuration for all arrays is stored in a centralized location which located off any of the array members	X
Integrated Windows Authentication Integrated Windows Authentication enables SPNEGO, Kerberos or NTLM authentication with the web gateway	X
Support two-factor authentication for web applications Two-factor (multi-factor) authentication enables the administrator to require users to present two or more pieces of information to access resources	X	X
Certificate Authentication with ActiveSync Certificate authentication with ActiveSync increases the overall ActiveSync security scenario by requiring the device to present a certificate before allow access to Exchange Server resources	X
Upgrade Path from ISA 2006 While it’s not possible to do an in-place upgrade from ISA to TMG (because ISA was 32bit only and TMG is 64bit only), there is a clear and easy to perform upgrade path.	X
Authorization Using Endpoint Policies Endpoint detection determines the state of the device connecting to the gateway and enforces access policy based on the results of the endpoint detection		X
SharePoint rich client support (MSOFBA) MSOFBA is a protocol that provides forms based authentication, instead of basic authentication, when you use Office client applications		X
Federation support with ADFS Use integration support for ADFS to enable federated identity scenarios		X
Endpoint Session Cleanup Endpoint session cleanup provides a mechanism to remove information obtained from the server during the course of the session; removal takes place on log off.		X
Port Scalability Port scalability enables you to publish more resources while using fewer ports on the receiving interface of the web gateway		X
Password Lockout Protection (at a node level) Password lockout protection protects the user account from being inadvertently locked out by either a friendly or malicious user; user is locked out of the gateway, but not in the Active Directory.		X
Granular access policies Granular access policies enable the administrator to control access to applications and to components of applications, based on the results of user and device assessments.		X
Support for DirectAccess DirectAccess is a new remote access technology that enables users to be always connected to the intranet and enables IT to always be connectivity to the users – all done transparently without user intervention		X
Portal functionality to publish multiple line-of-business applications Portal functionality enables users to connect to a single URL to access a portal page that contains applications and services available to the user, based on the results of user and device assessment.		X
Load balancing support for HTTP-based protocol access from the Internet Load balancing enables an array of web gateway to handle more requests more efficiently by evenly distributing connections among members of the load balanced array.	X	X
Highly Customizable Customizable according to the support guidelines and the development policies and processes for Microsoft partners		X
Built-in Wizards for Exchange Built-in wizard for publishing Exchange web services makes it simple to publish these resources using a secure default configuration	X	X
Outlook Web Access “Look and Feel” Both UAG and TMG provide a log on page experience that is similar to the one provided by Exchange Outlook Web Access (OWA).	X	X
Publish Microsoft Office Outlook Web App and the Exchange Control Panel (ECP) using forms-based authentication Forms based authentication enables users to enter credentials in an easy to use form to authenticate with the web gateway	X	X
Publish Outlook Anywhere using Basic or NTLM authentication	X	X
Publish Microsoft Exchange ActiveSync using Basic authentication	X	X
Support two-factor authentication for Exchange ActiveSync	X
Provide certificate-based authentication for Exchange ActiveSync, Outlook Web App, and ECP	X
Perform mail hygiene for Exchange with installation of the Edge Transport server role and Microsoft Forefront Protection 2010 for Exchange Server Email inspection can be performed on the web gateway to protect against spam and malware	X
Protect and filter Internet access for internal users from malware and other Web-based threats The web gateway can perform URL filtering to block undesirable web sites and scan and block malware delivered from the web	X
Provide support for scaled up Outlook Anywhere deployments by using multiple source IP addresses UAG has a Port Scalability feature that allows UAG to use multiple source IP address on its internal interface to contact the published CAS servers, allowing it to overcome the limit of 60000 ports maximum in a single IP address.		X
Check a client computer accessing Outlook Web App for presence of approved antivirus software, updates, etc. Endpoint detection can be performed to insure that the client attempting to access the OWA Exchange web service meets corporate security standards before allowing access		X
Built-in features for SharePoint publishing The web gateway has wizards and other technologies that make intelligent decisions on how to best publish SharePoint resources	X	X

Thanks to Fernando Cima and Carsten Kinder for developing this table.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

What would you be willing to pay for a really cool IPv6 and DirectAccess troubleshooting cheat sheet?

$5? $10? $100? ONE HUNDRED BILLION DOLLARS?

Since these cheat sheets are priceless we’re going to give them away. Thanks to DirectAccess guru and all around good guy Pat Telford, we’re making the .vsd file for these cheat sheets available for download.

You haven’t seen these cheat sheets? Here’s what they look like:

You can download the .vsd for these sheets HERE.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management/ICG
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

If you choose to deploy ISATAP to support your DirectAccess deployment, one of the things you need to do is remove the name ISATAP from the DNS block list if you’re using a Windows DNS server running Windows Server 2003 SP2 or above. By default, these DNS servers will not resolve queries for the names WPAD and ISATAP. Even if there is a resource record for WPAD or ISATAP in DNS, the DNS server will not return a response for those names if they are on the DNS query block list.

The reason for this is that it’s possible for a rogue device to dynamically register these names in DNS. If that happens, there is the possibility that client systems will auto-configure themselves to use the rogue device as their web proxy, or configure their ISATAP adapters to use the rogue device as their ISATAP gateway. Both of these scenarios are enabled by the fact that Internet Explorer uses auto-discovery by default to configure the web proxy, and the ISATAP adapter is enabled by default if the name ISATAP can be resolved and the client can contact an ISATAP router.

If you check this link you will find a document that contains the following statement:

“By default, the DNS Server service in Windows Server 2008 and later blocks name resolution for the name ISATAP through the DNS Global Query Block List. To use ISATAP on your intranet, you must remove the ISATAP name from the list for all DNS servers running Windows Server 2008 and later. For more information, see Remove ISATAP from the DNS Global Query Block List in the DirectAccess Deployment Guide..”

The question then is “if ISATAP responses from the DNS server is considered unsecure, then isn’t deploying ISATAP on the network considered unsecure?”

The answer is “no”. The reason for this is that when you deploy ISATAP on your network and enable the DNS server to answer queries for ISATAP, you will enter a static Host (A) record for ISATAP. When you configure the static DNS resource record, it will not be overwritten by dynamic registrations by potential rogue hosts. Therefore, the security implications of removing ISATAP from the DNS block list are mitigated since no one can dynamically overwrite the static ISATAP record you created.

However, if you decide that you don’t want to use ISATAP, or at least don’t want to use DNS to inform ISATAP hosts of the ISATAP router, then you should put ISATAP back into the DNS block list and remove the ISATAP resource record from your DNS server.

You can find out more about the DNS query block list HERE.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management/ICG
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

The question on how to handle DirectAccess clients and Internet security for those clients is always a popular topic. As I’ve mentioned many times in this blog, the overall threat and management profile of the DirectAccess client should be little different than a client that is on the intranet.

However, there is one major difference between the intranet client and the DirectAccess client – and that’s an Internet gateway that protects the client from Internet threats with URL filtering and web antimalware.

With this in mind, the following question is topical and I’ll use it to drive the discussion.

====================================================================

“UAG providing direct access over HTTPS to a large set of demo computers in retail stores. They are a wireless ISP so all the computers in the offices are connected directly to the Internet, rather than a corporate network.  We are using DA to manage group policy on the demo boxes to ensure they are tightly locked down.

We have a need to also provide some sort of content filtering/web site blocking on these boxes.  One thought is to leverage UAG to act as a filtering proxy server for these boxes.  The customer is concerned about using UAG “normally” because traffic would then flow across the DA/HTTPs link which would be the slowest option and may impact the performance of these demo boxes.  Thus they would like to configure their UAG box to act as a proxy server out on the Internet with some authentication for clients to connect.

So my questions to the group are:

• Is this totally crazy?
• Can this be done in a supported way?
• Is there a better way for them to do this”

====================================================================

First we have to get clear on the scenario. It sounds like these machines are configured as DirectAccess clients and are configured to use IP-HTTPS to connect to the UAG DirectAccess servers. It’s not clear why this is being used instead of 6to4 – maybe there is a device in the path between these DirectAccess clients that blocks IPv4 Protocol 41. What it appears they want to do is provide some gateway based security for these clients. The proposed idea is to use the UAG DirectAccess server as an outbound proxy for the DirectAccess clients. There are two problems with this possible solution:

• It’s not supported
• It won’t work

Given those two facts, we need to think of some other way to enable Internet gateway security for these clients. This is what I’d propose:

• Enable force tunneling on the clients – this will force all traffic, including Internet bound traffic, through the DirectAccess tunnels
• Consider configuring the browsers on the DirectAccess clients to use a web proxy. You can configure the proxy address in the UAG DirectAccess wizard
• Consider configuring the DirectAccess clients to “bounce” off the UAG DirectAccess server to reach the Internet
• If the second option is chosen, then configure the UAG DirectAccess servers with a gateway address that will force the outbound connections through a URL filtering and antivirus gateway

The figure below shows what the request path would look like when you configure the DirectAccess clients to use a Web proxy. Note in this scenario that you can have the outbound connection use a different gateway to the Internet than the one used by the DirectAccess server itself.

The figure below shows what it looks like when you configure the DirectAccess clients to “bounce off” the UAG DirectAccess server. The difference in this case is that the web filtering gateway is most likely going to be in a DMZ. You will need to be careful here, because the DirectAccess server can only have a single default gateway, which means that the web filtering gateway is going to need to be in the DirectAccess request/response path between the DirectAccess client and server. In the figure below, you can see that the outbound connections are leaving through the same firewall that they DirectAccess tunnel connections came in through.

If you want to see how this configuration works in a test lab, then check the Force Tunneling Test Lab Guide. You can find a complete list of Test Lab guides at http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management/ICG
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Ben Ari posted an answer to the Forwarding on the 6to4 Interface cannot be enabled error that you might see when you try to activate the DirectAccess configuration on the UAG DirectAccess server.

When you activate the configuration, it will look something like this:

Check Ben’s blog post at http://blogs.technet.com/b/ben/archive/2011/01/27/forwarding-on-the-6to4-network-interface-cannot-be-enabled.aspx for the reason and a fix.

Thanks Ben!

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management/ICG
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder