TMG or UAG? Which one do I need?

by Shijaz Abdulla on 30.06.2010 at 15:20

Of late, I have seen that a lot of customers and even partners are confused between the capabilities of Forefront Threat Management Gateway (TMG) and Forefront Unified Access Gateway (UAG).

The most important difference is that TMG is an “inbound AND outbound” access gateway that includes a network level firewall with stateful packet inspection & application filtering, forward and reverse web proxy, VPN server (for users and site-to-site). TMG is more focused on keeping the bad guys out and to a certain extent, allowing good guys in. On the other hand, UAG is an “inbound-only” secure remote access gateway that enables you to allow "the good guys” in more securely.

I need TMG if:

  • I need an inbound and outbound access gateway
  • I need a state-of-the-art firewall with stateful packet inspection and application filtering capabilities to protect my network
  • I need built-in IPS (Intrusion Prevention System) on that firewall
  • I need a secure forward proxy for users on my network to access the internet
  • I need to be able to do web filtering based on individual URLs or URL categories (like Politics, Sports, Pornography, etc)
  • I need to be able to monitor my user’s web activity and firewall logging.
  • I need to be able to block unproductive websites and services (like IM, P2P, video sharing, etc)
  • I need to protect my users from web-based threats (web antivirus, web antimalware, block malicious websites)
  • I need Forward HTTPS inspection to protect users against web threats that are hidden inside HTTPS
  • I need to publish (reverse proxy) services to the internet (like web servers, email servers, webmail, extranet, intranet and internet portals, etc)
  • I need SSL bridging to protect my publish servers against threats embedded inside SSL
  • I need zero day protection from vulnerabilities that do not have a patch released yet (NIS)
  • I need site-to-site VPN
  • I need a VPN server for my users in addition to all the above

I need UAG if:

  • I need an ‘inbound only’ access gateway
  • I need to enable my users to securely access internal resources remotely (while they are outside the company network)
  • I need to enable Secure VPN access for users when they are outside my network
  • I need to quickly and easily enable DirectAccess for my Windows 7 users
  • I need to ensure only healthy and secure remote machines can access information/services/applications in my network with appropriate user authentication
  • I need to be able to define which applications or services these users can access and granularly define the security policies that will govern access to these services remotely
  • I need to ensure that these users can access these applications regardless of whether they are web-based, terminal services, RemoteApp or Citrix without having to establish VPN connection.
  • I need to give my users the ability to access these applications from a mobile device, or a non-Windows client such as a Mac or a Linux machine.
  • I need to provide a web-based interface that the user can login remotely and execute these applications from this portal without connecting VPN, provided his machine is healthy.
  • I need to provide a web-based interface that the user can login remotely and establish a secure SSTP VPN session or access file servers from the portal without connecting VPN, provided his machine passes the health requirements of my organization.
  • I need to be able to easily define the security/machine health policies for machines that are attempting to access these applications.
  • I have smaller remote sites where I have small numbers of users with no site-to-site VPN and just an internet connection. I need to provide them secure access to my applications over the internet.

As you can see, each product is specialized to deliver very focused capabilities. Hence it is quite possible that some organizations need both solutions while others need only one. For many smaller organizations which need a one-product solution to protect their network and provide reasonably secure remote access, TMG would be the answer. However, for designs that focus purely on inbound access, UAG needs to be considered. If an organization has separate TMG/ISA Server arrays – one for inbound access and another for outbound access – the solution is simple – use a UAG array instead for inbound access and continue using TMG for the outbound array.

Establishing an SSTP connection using the Windows VPN client

by Shijaz Abdulla on 05.04.2010 at 20:25

I was chatting with Tom Shinder this evening when he started an interesting discussion on setting up a Windows VPN connection to use SSTP to connect to the corporate network via Forefront Unified Access Gateway (UAG). This would allow Windows 7 users to connect via SSTP without having to log in to the UAG portal.

So far, we’ve seen it only being done on the UAG Portal – where the user has to log in to the UAG portal and open the Remote Network Access application.

So I fired up my UAG lab VMs to see if this is do-able – and we were successful in getting it to work! Here’s how we did it.

 

  1. Open the user’s properties in Active Directory Users & Computers. On the Dial-in tab, choose Allow Access under Network Access Permission. Alternatively, you can configure the NPS Network policy accordingly.

    clip_image002

  2. On the Windows 7 client machine, create a new VPN connection. (Hint: Network & Sharing Centre –> Set up a new connection or network –> Connect to workplace)
  3. For the newly created connection, set the connection properties as below. The host name will be the same that’s configured on your UAG trunk.

    clip_image004

  4. On the Security tab of the VPN connection properties, set the Type of VPN as Secure Socket Tunneling Protocol (SSTP). Select the option to automatically use te Windows logon name and password.

    clip_image006

  5. You’re good to go. Make that connection! 🙂

clip_image008

clip_image010

Threat Management Gateway 2010 now available

by Shijaz Abdulla on 28.11.2009 at 18:24

TMG LogoMicrosoft Forefront Threat Management Gateway has been released to market on November 16, 2009 after completing three beta releases and receiving extensive customer feedback.

You can download the trial version of Threat Management Gateway here.

From the Forefront TMG team’s blog:

“Forefront TMG is a Secure Web Gateway (SWG) that improves security enforcement by integrating multiple detection technologies such as URL filtering, Anti Malware, and intrusion prevention into a single, easy-to-manage solution. We have seen a lot of interest in the features that comprise this solution, so here is some information on what they do and how:

  • URL Filtering: URL Filtering allows controlling end-user access to Web sites, protecting the organization by denying access to known malicious sites and to sites displaying inappropriate or nonproductive materials, based on URL categories. TMG features over 80 URL categories including security-oriented categories, productivity-oriented and liability-oriented categories. Forefront TMG uses Microsoft Reputation Services (MRS), a cloud-based categorization system hosted in Microsoft data center. To ensure the best bandwidth utilization and low latency, Forefront TMG has implemented a local URL cache. There is a lot more on URL Filtering available in an earlier URL Filtering post (on the TMG blog).
  • Anti Malware: Stopping malware on the edge significantly decreases the possibility that a virus will hit a computer with anti-virus signatures that are not up-to-date or a test computer without an anti-virus to protect it. TMG has integrated the Microsoft Anti Malware engine to provide world class scanning and blocking capability on the edge.
  • Network Inspection System (NIS): NIS is a generic application protocol decode-based traffic inspection system that uses signatures of known vulnerabilities, to detect and potentially block attacks on network resources. NIS provides comprehensive protection for Microsoft network vulnerabilities, researched and developed by the Microsoft Malware Protection Center – NIS Response Team, as well as an operational signature distribution channel which enables dynamic signature snapshot distribution. NIS closes the vulnerability window between vulnerability disclosures and patch deployment from weeks to few hours.
  • In addition, HTTPS scanning has been introduced to enable inspection of encrypted sessions, eased the deployment and management with a set of easy to use wizards and significantly improved logging and reporting to provide full visibility into how your organization is accessing the web and whether it’s compliant with your organization’s policy.
  • VPN, Firewall, Email Protection and Infrastructure.
    Significant investments have been made to ensure that we keep delivering top notch VPN and Firewall functionality. We made quality improvements in Web Caching and made sure it works well with the new Windows 7 BranchCache feature. We have added several new features, among them: Email Protection, ISP redundancy, NAP integration with VPN role, SSTP, VoIP traversal (SIP support), Enhanced NAT, SQL logging and Updated TMG Client (previously known as the Firewall Client). In addition TMG was built as a native 64bit product that supports Windows Server 2008 R2, and Windows Server 2008 SP2, allowing better scalability and increased reliability.”

My experiments with IAG 2007, Part 2

by Shijaz Abdulla on 02.09.2007 at 08:53

In my earlier post on Intelligent Application Gateway (IAG 2007), I explained how we can download a fully-functional VHD image that simulates the IAG appliance and how to get started with it.

One of the interesting features in IAG that I came across is the ability to verify how secure the endpoint is (endpoint: client computer from which the user establishes the SSL-VPN session). The administrator can define endpoint policies that define the minimum security requirements that the client computer must have, in order to be able to connect to a particular internal application or service via IAG.

For instance, users may connect from home PCs or internet kiosks to access file servers while out of office. In order to secure file servers from possible malware attacks, we can require that all client computers that request access to file servers should have anti-malware software installed, failing which connections should be disallowed.

Lets take a closer look:
In the IAG console, under the portal for HTTPS connections, I open the properties page for File Access and specify an Endpoint Policy that requires that Windows Defender be installed on any endpoint that requires access to file servers.

On an external client machine that does not have Windows Defender installed, I try to access the IAG portal. I note that even before showing me the login form, the portal quickly gathers and sends information to IAG to verify compliance with endpoint policy.
Now I login to the IAG Portal:

And – as expected – I find that File Access is disabled!

If I click Details, I am informed why my endpoint is not allowed to connect to this service.

This is indeed a very nice feature. Reminds me of quarantined VPN clients in ISA Server.

If you have read my earlier post on extending access to file servers from OWA, you will note that this amount flexibility of endpoint security compliance check is not available while allowing direct file access through OWA. In OWA, you can only set separate policies for ‘Public’ and ‘Private’ computers, as selected by the user on the login form. And of course, this can be over-ridden by the user when he/she logs in, so it really isn’t much of an enforcement.

Publishing internal file servers through OWA

by Shijaz Abdulla on 24.08.2007 at 13:46

Outlook Web Access (OWA) on Exchange Server 2007 now supports direct file access, which means users can connect to internal file servers over the web using the standard OWA interface.

Readers of my earlier posting on Intelligent Application Gateway 2007 will agree that, if SSL is configured on Outlook Web Access (OWA) with internal file server access enabled, and it is published using ISA Server 2006, this gives you the equivalent of a browser-based SSL-VPN connection to the file server! Think about it.

This is good news for organizations who want to publish their file servers securely for home users but cannot afford a secure VPN solution.

Similarly, users can access internal Sharepoint sites from OWA if this is enabled on Exchange Server 2007. Certainly good news for organizations that tried to publish both OWA and SharePoint server over SSL on the same ISA Server installation — and then daunted away because it meant replacing the SSL certificate a wildcard certificate (which offers weaker encryption than a normal SSL certificate).

For step-by-step instructions on how to configure direct file access, see my article Configuring direct file server access from Outlook Web Access in Exchange Server 2007

My experiments with IAG 2007

by Shijaz Abdulla on 28.07.2007 at 14:06

Intelligent Application Gateway 2007 (IAG) is Microsoft’s new addition to the ForeFront Edge Security family. IAG provides web-based SSL-VPN connections for secure access to applications from outside the organization’s network perimeter. IAG 2007 was previously known as Whale SSL VPN before Microsoft acquired Whale Communications.

I had always wanted to get my hands on an IAG appliance, but appliances are costly, and the only way to work on one was to get my company to buy one of those babies. However, I was excited when I saw that the IAG VHD is available for download! It’s a scenario-based demo, which involves a virtual machine image (VHD) running DC/Exchange 2007/SPS 2007 and another virtual machine running the IAG appliance itself. Also, there were two client machine VHDs – one ‘managed’ and the other an ‘unmanaged’ client.

I downloaded the whole demo lab, and put it together on my 64-bit Virtual Server 2005 R2. I got a preview of the IAG features, but found that the Network Connector feature (the one that lets a remote client connect to the corporate network – ‘VPN-style’) wasn’t working. Upon closer examination, I found that the “Whale Network Connector Server” service was not running on the IAG virtual machine. When I tried to manually start the “Whale Network Connector Server” service, i got the message that the service stopped after starting. My repeated attempts to start the service were in vain.

So I opened the IAG Configuration console, and navigated to Admin > Network Connector Server option. IAG appliance has two physical network cards – one sticking in to the internal network and the other sticking in to the external network. There is a third network interface named Whale Network Connector (a virtual NIC), which appears to be “unplugged”. I made sure that the correct network interface card was selected (it should be the NIC thats on the internal network), and then de-activated Network Connector by de-selecting the “Activate Network Connector” checkbox. Then, I applied my changes by clicking File > Activate.

Once again, I navigated to Admin > Network Connector Server. This time I selected the “Activate Network Connector” and click OK. Once again I applied my changes by clicking Activate. In a few moments, the “Whale Network Connector Server” services started and a third network interface (Whale Network Connector) started showing status as “Active”.


In short, I just de-activated and re-activated the Network Connector Server after making sure that the correct internal NIC is configured on it. So if you’ve downloaded the IAG demo lab, hope this helps you!