A Complete Guide to UAG DirectAccess (Part 5) – Infrastructure Requirements (Cont.)

By /

If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our WindowsNetworking.com Real Time Article Update newsletter.

If you would like to read the other parts in this article series please go to:

Introduction

Last month, in Part 4 of this series, we began the discussion on how to set up your network infrastructure to support the deployment of UAG DirectAccess. This time, we continue that discussion by providing details on the requirements for the following components:

  • Network Location Servers

  • Certificate Revocation List (CRL) servers

  • Windows Firewall with Advanced Security and Network Firewalls

  • Remote Access VPN servers

  • NAP and Smart Card Infrastructure

Network Location Servers

DirectAccess clients use Network Location Servers (NLS) to determine whether they’re on or off the corporate network. When you run the UAG DirectAccess Wizard, it will ask you to provide the name of the NLS. The NLS is a generic SSL web site that you can install on any Web server;  you do not have to use an IIS web server. The only requirement is that the DirectAccess client on the intranet needs to connect to the NLS web site and receive a HTTP 200 response back. When that HTTP 200 response is received, the DirectAccess client computer will turn off the Name Resolution Policy Table (NRPT) and use the DNS server assigned to its NIC to resolve names on the corpnet.

It’s important for the NLS to be highly available. If a DirectAccess client is on the corpnet, but can’t connect to the NLS, then it will believe that it is on the Internet and will leave the NRPT enabled. This can present a big problem, because the DirectAccess client will try to use the DirectAccess server’s IPv6 address to resolve host names. This may or may not be possible, depending on the configuration of your network. It also depends on whether or not Network Location Awareness (NLA) is able to determine whether the DirectAccess client is on the corpnet. If NLA isn’t able to determine that the DirectAccess client is on the corpnet, and the NRPT remains enabled, and if there is a path between the corpnet located DirectAccess client and the external interface of the UAG DirectAccess server, it’s possible that the DirectAccess client located on the corpnet will be able to connect to corpnet resources by looping back into the network through the UAG DirectAccess server. As you can imagine, if you have a large number of internally located clients doing this, it has the potential for severely bogging down your Internet link.

For this reason, make sure your NLS sites are highly available. You might even want to consider placing extra NLS sites at branch offices, so that in the event of a site to site VPN or WAN link failure, the DirectAccess clients will still be able to connect to the NLS and turn off the NRPT. Of course, if there is a site to site VPN or WAN link failure, it might be a good idea to leave the branch office clients DirectAccess enabled, since that might be their only way to reach corpnet resources.

Certificate Revocation List (CRL) servers

Web servers that host the Certificate Revocation list for the certificates used by the NLS and the IP-HTTPS listener also need to be made highly available. If the DirectAccess client situated on the corpnet is not able to connect to the CRL location specified on the NLS certificate, the connection attempt will fail and the DirectAccess client will think that it’s on the corpnet and will not turn off its NRPT. If the DirectAccess client on the Internet tries to connect to the IP-HTTPS listener on the external interface of the UAG DirectAccess server, and it is not able to connect to the CRL location specified on the IP-HTTPS certificate, then the IP-HTTPS connection will fail.

The easiest solution for the IP-HTTPS certificate is to use a commercial CA. The commercial entity will already have a robust infrastructure in place to ensure that the CRL is highly available. You could use a similar strategy with your NLS certificates, but since they are internal servers, you’ll be more likely to use your private PKI. In that case, you need to make sure your internal CRL infrastructure is also highly available. You can use any number of methods to do this, such as using NLB or an external load balancer. However, note that it’s not a good idea to use DNS round robin because the DNS client does not traverse the entire list if it is able to resolve the name;  it just connects to the first server on the list and does not move to the next entry if the connection attempt fails.

Windows Firewall with Advanced Security and Network Firewalls

UAG DirectAccess makes liberal use of Windows Firewall with Advanced Security. The Windows Firewall must be enabled on both the UAG DirectAccess server and DirectAccess clients in order for DirectAccess to work. The reason for this is that there are firewall rules and connection security rules configured on the UAG DirectAccess server and DirectAccess clients that enable the entire DirectAccess connectivity and authentication model.

The connection security rules are used to create the DirectAccess IPsec tunnels between the DirectAccess client and UAG DirectAccess server. The rules also include the source and destination IP addresses that are allowed, and the type of authentication and encryption that is applied to the tunnels. In addition, there are a number of firewall rules that are used to control and direct the type of traffic that is allowed over these tunnels, and to specify which traffic is exempted from IPsec negotiations.

If the Windows Firewall is disabled on either the DirectAccess client or the UAG DirectAccess server, DirectAccess will stop working. This is sometime problematic when administrators, in an attempt to troubleshoot a network problem, turn off the Windows Firewall with Advanced Security on the DirectAccess client or UAG DirectAccess server. This troubleshooting approach will not work since it completely breaks the DirectAccess IPsec tunnel establishment.

The use of network firewalls is up to you and your corporate policy. The UAG DirectAccess server is designed to be an edge device, which means it can be safely placed on the edge of the corporate network without another firewall in front of it (I say “another” firewall because there is already a TMG firewall on the UAG server). However, because the UAG DirectAccess server is a domain member, and many organizations, for one reason or another, require a firewall to be in front of a domain member (regardless of the fact that there is already a firewall on the UAG DirectAccess server), you will need to consider the configuration on the network firewall in front of the UAG DirectAccess server.

The network firewall in front of the UAG DirectAccess server should be configured to:

  • Allow IP protocol 41 inbound and outbound to and from the UAG DirectAccess server’s external IP addresses

  • Allow UDP port 3544 inbound and outbound to and from the UAG DirectAccess server’s external IP addresses

  • Allow TCP port 443 inbound and outbound to and from the UAG DirectAccess server’s external IP addresses

As for back-end firewalls, there is no need for them. The TMG firewall is on the UAG DirectAccess server and therefore acts as both a front-end and back-end firewall for the UAG DirectAccess server. However, if your policy states that there must be a back-end firewall behind the UAG DirectAccess server, then you should configure your back-end firewall to allow all IPv4 traffic to and from the internal interface of the UAG DirectAccess server. In addition, you need to allow IP protocol 41 to and from the internal interface of the UAG DirectAccess server to support ISATAP communications on your network.

Remote Access VPN Servers

DirectAccess will be able to meet almost all the needs of your remote users. However, as pointed out in other sections of this article, there can be certain limitations introduced to the UAG DirectAccess solution, depending on the deployment details. For example, we’ve seen that there are certain limitations imposed when you have an IPv4 only network. In addition, there are some client applications that are not IPv6 aware, so even though NAT64/DNS64 could solve the connectivity issue to the IPv4 only server, the problem remains that the client side of the client/server application needs to be IPv6 aware.

For those circumstances in which the UAG DirectAccess solution will not work for a specific application, you will need to provide for methods that allow your users to use those applications. The best solution depends on the nature of the client/server application. For example, the OCS client will not work with the NAT64/DNS64 solution because the protocol it uses imbeds an IPv4 address that the NAT64/DNS64 protocol translator can’t handle. Therefore, you will need to provide an alternate method for users to access the OCS server from the Communicator client. One way you can do this is to use an Internet accessible OCS proxy and configure the NRPT so that the Internet accessible OCS proxy is not reachable through the UAG DirectAccess tunnel.

However, not all applications make it possible to set up an Internet accessible proxy. In that case, you should consider making VPN access available to these users. Remote access VPN client connectivity is also useful for non-DirectAccess capable clients, such as Windows XP and Vista machines. If you already have a VPN solution in place, you can certainly use that one. However, if you want to consolidate your VPN access solution, you might want to consider co-locating your remote access VPN client connectivity solution with the UAG DirectAccess solution.

This is actually consistent with the preferred method for deploying UAG DirectAccess arrays. UAG provides three key enabling scenarios:

  • Reverse web proxy and web portal access

  • DirectAccess

  • Remote access client VPN

If you choose to use all the functionality included with UAG, you should consider separating out the reverse web proxy and web portal access array from the DirectAccess and remote access VPN client array. You can co-locate the UAG DirectAccess server and the UAG SSTP server on the same machine. The SSTP server will support Vista SP1 above clients. However, SSTP is not supported by Windows XP, so if you want to provide remote access for the Windows XP clients, you might consider requiring them to use the reverse web proxy or portal applications. Given the higher threat that Windows XP presents to networks today, even when they are comprehensively managed, enforcing a least privilege stance on the Windows XP clients by forcing them to use the web proxy or portal experience might be the best decision overall.

Summary

In this, part 5 of our Complete Guide to UAG DirectAccess, we went over the remaining key infrastructure services that are required to be in place before you deploy your UAG DirectAccess servers and arrays. These infrastructure services are required for security, name resolution, and to provide the DirectAccess clients information about their current location. If all these infrastructure components are not in place, the UAG DirectAccess deployment will not work, or it will function in an inconsistent and unreliable way. Next month we’ll continue our series by going over some security considerations for UAG DirectAccess. See you then! –Deb.

If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our WindowsNetworking.com Real Time Article Update newsletter.

If you would like to read the other parts in this article series please go to:

About The Author

Debra Littlejohn Shinder is a technology and security analyst and author specializing in identity, security and cybercrime, utilizing her past experience as a police officer and police academy/criminal justice instructor. She has written numerous books and articles for web and print publications and has been awarded the Microsoft MVP designation for fourteen years in a row.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top