ISAserver.org Monthly Newsletter of January 2010 Sponsored by: Wavecrest Computing
Welcome to the ISAserver.org newsletter by Debra Littlejohn Shinder, MVP. Each month we will bring you interesting and helpful information on ISA Server. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to firstname.lastname@example.org
I have been receiving an increasing number of questions about DirectAccess lately. It makes sense, as with both Windows 7 and Windows Server 2008 R2 now available, people want to take advantage of the new features made available with the combination of these two new operating systems. And definitely one of the most exciting and the most useful features enabled by the combination of Windows 7 and Windows Server 2008 R2 - at least, in my opinion - is DirectAccess.
If you have not heard about DirectAccess, it is a new remote access solution designed to allow domain member computers to access the corpnet without having to initiate a VPN connection. I wrote a very high level overview of the feature in my article titled Death of the VPN on WindowSecurity.com, back in August when Windows 7 was still in beta. For the basics, you can check that out here.
Now let us delve a little deeper. DirectAccess works by creating a connection to the corporate network before the user even logs in. This first tunnel is an IPv6 IPsec tunnel called the "infrastructure" tunnel. The infrastructure tunnel allows the DirectAccess client access to domain controllers, DNS servers, and management servers on your network. The infrastructure tunnel also enables what is referred to as "manage out" connectivity, so that management servers can initiate connections to DirectAccess clients and, well, manage them. This provides IT the same level of command and control over DirectAccess clients that they have over a client that is directly connected to the intranet.
When the user logs on, a second IPv6 IPsec tunnel is created, and this is called the "intranet" tunnel. The intranet tunnel is used to connect to resources anywhere on the network. Note that the user does not do anything to initiate this tunnel - it is established automatically, in the background, when the user logs on. That is one of the big benefits of DirectAccess; it is much more transparent to the user. After the intranet tunnel is established, the user can access file servers, web servers, database servers, mail servers, and any other kind of server you can think of in the same way that they access them when directly connected to the corpnet over a wired or wireless connection.
So where does Forefront UAG fit into this picture? Well, there are two ways you can deploy DirectAccess:
The Windows version of DirectAccess is built right into the platform - there is nothing else to buy. You can build out your DirectAccess solution using just Windows Server 2008 R2 and Windows 7 and get it working right away. While the Windows version of DirectAccess is good to get you started, you might want to consider the UAG version of DirectAccess. The reasons for this include:
Of course, if you have a native IPv6 network already, the Windows version of DirectAccess might be the way to go. But most of us are not there yet. In reality, any enterprise level organization that is seriously considering DirectAccess today is probably going to want to use UAG as their DirectAccess server. UAG has several advantages that it brings to the DirectAccess table:
Tom has been working extensively with DirectAccess in his new job with Microsoft. He told me that there is a big misconception out there that you need a Windows Server 2008 R2 domain infrastructure and Windows Server 2008 R2 DNS servers in order to deploy DirectAccess. Well, if you have already dismissed the idea of deploying DirectAccess because of that, the good news is that you do not need Windows Server 2008 R2 domain controllers and you do not need Windows Server 2008 R2 DNS servers.
In fact, your entire infrastructure can be based on Windows 2000 Advanced Server and if you have a UAG DirectAccess server, your Windows 7 clients will be able to access all the IPv4 resources on your Windows 2000 based infrastructure. There are a couple of limitations related to the client-side applications needing to be IPv6 compliant (the server applications don?t need to be), but the point is, in order to get a UAG DirectAccess solution working, the only Windows Server 2008 R2 computer you need is the one running UAG.
So let?s get going! There is nothing stopping you from getting started on your DirectAccess journey. In the coming weeks I will be writing some articles for this site on IPv6, IPsec, and UAG DirectAccess so that your UAG DirectAccess experience will be smooth and smart. Until then, the best place for you to start learning about this great new technology is by completing the UAG DirectAccess step by step lab. You can find that here.
If you have any questions about DirectAccess, please send them my way. If I can?t answer them, I know someone who will be able to find the answers.
On another note, I am very happy to welcome Richard Hicks, who has just joined the ISAserver.org team. Richard is not just a colleague and a fellow MVP, but also a friend whose company Tom and I have enjoyed when he visited our area. Now you can look forward to reading his latest articles here on ISAserver.org. For more information about Richard, check out his profile page here. Richard is a Forefront MVP and has taken Tom?s place as the only Forefront MVP from the United States. Richard has a wealth of ISA/TMG and UAG information and hands-on experience, and we are thrilled to have his valuable presence here at ISAserver.org
Until next month
We have a great group of articles in the Learning Zone that will help you get a handle on your most difficult configuration issues. Here are just a few of the newer and more interesting articles:
This month my ?article of the month? is not an article at all. The good news is that I think it?s even better than an article! What is this thing that is better than an ?article of the month??? It?s the release of the Forefront Threat Management Gateway 2010 Best Practices Analyzer. The TMG BPA that was released last week is the first version of the BPA that you can use with the TMG firewall. Earlier versions created for use with the ISA firewall will not work with the TMG firewall. Here?s Microsoft?s description of the TMG BPA:
"The Forefront TMG BPA is a diagnostic tool that automatically performs specific tests on configuration data collected on the local Forefront TMG computer from the Forefront TMG hierarchy of administration COM objects, Windows Management Instrumentation (WMI) classes, the system registry, files on disk, and the Domain Name System (DNS) settings.
The resulting report details critical configuration issues, potential problems, and information about the local computer. By following the recommendations of the tool, administrators can achieve greater performance, scalability, reliability, and uptime."
The Forefront TMG BPA is supplied with two supplemental tools:
Sounds good to me. You can download the TMG firewall BPA here!
So you are hyped up about installing your brand new TMG firewall on some crazy fast Nehalem based hardware with 8 GB of RAM. You already know that TMG performance is going to smoke anything a ?hardware? firewall is going to give you, because of your ability to use the latest and greatest 64bit hardware and fully leverage the scalability that the 64bit architecture can provide - in contrast to the underpowered stuff you will get when you pay big bucks to Cisco or Blue Coat (I had to say that, to carry on in the Shinder tradition).
So first you install Windows Server 2008 R2 and then begin your installation of the TMG firewall. You run the prep tool and it needs to download the .NET Framework 3.5 SP1 to complete the prerequisites. But they would not download! What?s up with that?
What?s up with that is that in order to download the .NET Framework 3.5 SP1 bits, you need to make sure that you are not behind an authenticating Web proxy. What you need to do is create an Access Rule that allows the IP address of your network TMG firewall?s external interface anonymous access to the default External Network. Do this on the Web proxy in front of your network TMG firewall that you?re installing. After you get TMG installed, delete that rule, and then you can enjoy your new TMG firewall?s blazing performance and security.
Good to see that you are doing the newsletter and other stuff that Tom used to do on ISAserver.org. I am sure that you will be able to take up the challenge! With that in mind, I would like to ask you a question. I am thinking of upgrading my ISA firewall to TMG, but I am wondering about UAG. I understand that UAG actually has TMG installed on it, so I am sort of confused about what the best way to go might be. If I get UAG, will I be able to use both the UAG stuff and the TMG stuff on the same computer, so that I essentially get two products on the same box? Or is there something else going on? Right now I am using ISA to publish Exchange and SharePoint and I also use it for outbound access control, although more for logging and reporting than controlling where the users are actually going. Oh, and I am interested in Web anti-malware and URL filtering, because I?m sort of tired of paying Websense so much money.
Thanks! - Earl J.
Thanks for the kind words! My goal is to keep up the quality that Tom?s provided all these years :)
To answer your questions, let us start with the UAG/TMG issues. It is true that UAG has TMG installed on the same box. However, the purpose of the TMG, for the most part, is to provide a host based firewall to protect the UAG box itself. Of course, you can put the UAG on the edge of the network, since the TMG is designed as an edge network firewall and it would not allow attackers from the Internet to get into your corporate network. However, with that said, you should not use the TMG on the UAG box in the same way you would use a dedicated TMG box. In fact, you should never need to enter the TMG firewall console on the UAG server, since TMG configuration is done automatically in the background when you configure UAG using the UAG console.
Now let?s look at your requirements. You are publishing Web sites (Exchange and SharePoint) and you also want outbound access control. Since UAG is designed to control inbound access only, the best solution for you is to get both a UAG and a dedicated TMG firewall on your network. You can put both of these devices on the edge if you like, or you can put the UAG behind your TMG firewall. However, if you want to take advantage of the DirectAccess feature included with the UAG, you will have to assign public IP addresses to the external interface of the UAG server. This means that you will need to subnet your network if you put it behind the TMG firewall - so in most cases it is easier to put the UAG on the edge. And since TMG is also on the UAG server, you don?t have to worry about attacks from Internet intruders.
Do you have any questions or ideas for content? Email me on email@example.com.
Till next month!