When I’m between doing things that I sort of want to do, but not enough where I want to start on them right away, I’ll do a little ego surfing. If you haven’t heard the term “ego surfing”, it’s the act of going to your favorite search engine (or multiple search engines) and searching for the results returned on your name. I do this from time to time because, well, ahhh – for the same reason anybody else does it!

Today I was doing some ego surfing for someone else. That “someone else” in this case was DirectAccess. I wanted to see what the top search engine results were for DirectAccess using a number of search engines. On more than one search engine, I found an article that left me a little perturbed. The title of the article is Microsoft DirectAccess: The ugly truth. Now, I know that headline writers write outrageous headlines because they get more attention, but I felt that I needed to write a response to show that the ugly really isn’t there and that there is beauty in its place.

Microsoft UAG DirectAccess: The Beautiful Truth

In fact, when it comes to UAG DirectAccess, much of the ugliness is swept away and what we see is a real thing of beauty. Hence the name of this article Microsoft UAG DirectAccess: The Beautiful Truth. To find this beautiful truth about UAG DirectAccess, let’s take a look as some quotes from the Network World article.

“The following list of DirectAccess requirements comes directly from Microsoft TechNet:

• One or more DirectAccess servers running Windows Server 2008 R2 with two network adapters: one connected directly to the Internet, and a second connected to the intranet.
• On the DirectAccess server, at least two consecutive, public IPv4 addresses assigned to the network adapter that's connected to the Internet.
• DirectAccess clients running Windows 7.
• At least one domain controller and DNS server running Windows Server 2008 SP2 or Windows Server 2008 R2.
• A public key infrastructure (PKI) to issue computer certificates, smart card certificates, and for NAP, health certificates.
• IPsec policies to specify protection for traffic.
• IPv6 transition technologies available for use on the DirectAccess server: ISATAP, Teredo, and 6to4.
• Optionally, a third-party NAT-PT device to provide access to IPv4-only resources for DirectAccess clients”

Let’s look at each one of these:

• One of more DA servers running Windows Server 2008 R2 with two NICs: one connected directly to the Internet and one to the intranet. That’s still true – although the external interface does NOT need to be directly connected to the Internet – putting the UAG DirectAccess server behind a front-end firewall is fully supported.
• On the DirectAccess server, at least two consecutive, public IPv4 address assigned to the NIC that’s connected to the Internet. Well, we know that the external interface does NOT need to be connected to the Internet. However, we still need two consecutive public IP addresses to support Teredo.
• DirectAccess clients running Windows 7. That is true – the only systems that can act as DirectAccess clients are Windows 7 Enterprise and Ultimate, and Windows Server 2008 R2 (yes – the Windows Server 2008 R2 operating system can act as a DirectAccess client – which sets up for some interesting scenarios)
• At least one domain controller and DNS server running Windows Server 2008 SP2 or Windows Server 2008 R2. If you have using UAG DirectAccess, you do not need a Windows Server 2008 SP2 or above domain controller or DNS server. So UAG debunks this “ugly” truth
• A Public Key Infrastructure (PKI) to issue certificates, smart card certificates, and for NAT health certificates. Yep, a PKI is required. But come on folks, everyone has at least a simple PKI in place already – too many Microsoft and non-Microsoft products and services require a PKI these days not to already have one in place. And the PKI requirements for UAG DirectAccess are very simple: use autoenrollment to deploy the computer certificates, use a web site certificate to assign to the Network Location Servers, and use a commercial certificate to assign to the IP-HTTPS listener. When it comes to certificates and PKI, DirectAccess requirements are on the “no-brainer” of the certificates food chain.
• IPsec policies to specify protection for traffic. Yes, you still need those, but when you run the UAG DirectAccess wizard, all of these policies are created for you. The amount of knowledge you need about IPsec to get a working UAG DirectAccess solution work is around, well – ZERO. The UAG DirectAccess wizard creates the IPsec policies and then if you want, will automatically deploy them to Group Policy (either a security group or OU linked GPO, it’s your choice) for you.
• IPv6 transition technologies available for use on the DirectAccess server: ISATAP, Teredo and 6to4. This is mostly true, but he left out IP-HTTPS .  Teredo, 6to4 and IP-HTTPS are used to tunnel IPv6 communications over an IPv4 Internet to connect to the UAG DirectAccess server. How much do you need to understand about these protocols? Of course, that’s up to you – but the only thing you really need to know is that if you have a firewall in front of the UAG DirectAccess Server, you should enable TCP port 443 inbound and outbound, UDP port 3544 inbound and outbound, and Protocol 41 inbound and outbound to and from the external interface of the UAG DirectAccess server. That’s it. The UAG DirectAccess wizards takes care of the rest, so don’t need to make it an avocation (or worse, a vocation) of trying to understand the intricacies of IPv6 transition technologies. The same is true of ISATAP (Intra-site Automatic Tunnel Addressing Protocol) – UAG configures itself automatically to be an ISATAP router. All you need to do is create a DNS entry and that’s pretty easy!
• Optionally, a third-party NAT-PT device to provide access to IPv4-only resources for DirectAccess clients. We can debunk this one for UAG DirectAccess with one word NAT64/DNS64 (OK, maybe not one word). With the integrated NAT64/DNS64 feature built into UAG, there is no need to bring in any third-party solutions to provide transparent access to IPv4-only resource. Another example the Beautiful Truth of UAG DirectAccess.

Now that we’ve debunked many of the issues regarding DirectAccess for UAG, let’s take a look at another quote from the article:

“That is no small list of requirements. What it means is that to implement DirectAccess, I have to change, replace, or upgrade just about everything at my network edge. In addition to maintaining a public-facing firewall for Internet access, I have to add another direct-to-Internet server to act as the DirectAccess termination point. As servers are replaced and updated, I can see the enterprise eventually getting to the point where all of these things are already in place. But for most of us, this set of conditions can be a showstopper.”

Everyone already has a firewall at the edge of their networks. So, there’s nothing to add there. And, firewalls and NAT are not the same thing. All you need to do is create a small block of public addresses for the UAG DirectAccess server and route the connections through the firewall (firewalls still provide firewall protection without NAT) – so there’s nothing to add there when it comes to hardware, and subnetting is pretty easy for the network guys. Yes, it is true that you need to add the DirectAccess server as an Internet facing device – but you already have a lot of those, so what’s one more? Again, this is something most network admins do frequently and it isn’t a odd “one off” situation. There really don’t appear to be any show stoppers here – and with UAG DirectAccess, I think we end up with the “star of the show” when both users and IT tip their hats to you for giving them what they’ve actually wanted since the first PPTP VPN was deployed.

Let’s finish up with another quote that we can easily address:

“Also, because other releases of Windows server operating systems don't support dual-layer IP, DirectAccess can't natively talk to them. If your enterprise has a bank of Windows Server 2003 or older machines that won't be upgraded anytime soon, that data is in a silo that DirectAccess can't directly access.”

With UAG DirectAccess and its built-in NAT64/DNS64 service, the only Windows Server 2008 or above machine you need on your network is the UAG DirectAccess server. Your entire network can be full of Windows Server 2003, Windows 2000 Server, and Windows XP. DirectAccess clients will be able to connect to these network resources just fine. In addition, you can run your domain on Windows Server 2003 domain controllers and DNS servers. Like I said – only the UAG DA server needs to be running Windows Server 2008 R2. That means there is no silo – DirectAccess users can access whatever they need on legacy operating systems.

There you go. Microsoft UAG DirectAccess – The Beautiful Truth. I hope that you’ve had a chance to read this article before you read the ugly truth article, but if you read the ugly truth article first, at least you know what the truth is regarding UAG DirectAccess. And with these truths in mind, I hope that you’ll consider researching a possible DirectAccess deployment for your company. If you have any questions on how to do this, send me a note at the address in the sig line below.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder