Microsoft UAG DirectAccess: The Beautiful Truth

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 notneed 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): https://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: https://twitter.com/tshinder
Facebook: https://www.facebook.com/tshinder

Comments

• Anonymous
  January 01, 2003
  Hi Conrad, In most cases, the manage out limitations are more apparent than real. The vast majority of management activities are done by and agent on the client calling the management server. In this scenario, NAT64/DNS64 will work fine. If there are machines on the intranet that need to call a DirectAccess client, you can use a HOSTS file entry on those management stations. Check out my article on ISATAP and see if that helps clear things up. The article is at blogs.technet.com/.../clearing-the-air-on-isatap.aspx HTH, Tom

• Anonymous
  January 01, 2003
  Hi Xavier, You can do this by NATing from public IP address to public IP address. The NAT device would have public IP addresses and forward the connection to another pair of public IP address on the UAG DirectAccess server behind it. Not sure this is supported though - but it should work.

• Anonymous
  January 01, 2003
  Hi Xavier, I answered in the thread, but I'll answer here too. We can't support it because we never tested that scenario and there may be things that break in a production deployment. It works in test labs and small deployments - but without testing, its hard to say what would happen under "stress" - so we can't support it. Tom

• Anonymous
  May 03, 2011
  The comment has been removed

• Anonymous
  May 03, 2011
  Hello again and thanks ! I already try to know if this trick is supported : social.technet.microsoft.com/.../d29b4570-6513-4595-9458-9250af1f918b ...bot no answers ! Xavier.

• Anonymous
  May 31, 2011
  Hi Thomas I have a couple of queries. According to the microsoft whitepaper on ISATAP, creating an ISATAP router will mean that all Windows Vista/Server 2008 and above machines will automatically start communicating with each other over IPv6 ISATAP addresses, which in turn will have an impact on AD Sites and Services, in that the subnets will no longer be relevant? The fix is to add the ISATAP range prefix to AD Sites and Services, however surely a 2003 AD will not accept 64bit values? I could disable ISATAP/IPV6 on the hosts, but this would then mean I couldn't use any of these resources over direct access! Also I believe NAT64/DNS64 doesn't support connections initiated from the Intranet to machines in the Direct Access extranet and thus management applications may fail to monitor/maintain machines that are off site for extended periods of time? I would appreciate it if you could advise me on these points, as I would like to implement this solution initially as a PoC, but cannot currently enable the ISATAP router due to the above concerns. Regards, Conrad

• Anonymous
  June 01, 2011
  The comment has been removed