A Complete Guide to UAG DirectAccess (Part 4) – Infrastructure Requirements

By /

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

Introduction

This month, we’ll continue our Complete Guide to UAG DirectAccess series by going over some of the details of the infrastructure components that support the UAG DirectAccess solution. This is probably the most important part of the series, because if you don’t have these components in place, your UAG DirectAccess solution will not work, no matter how well you configured the UAG DirectAccess server itself. Pay special attention to the material in this part and it will definitely improve the chances that you’ll have a successful UAG DirectAccess deployment.

Infrastructure Components of a UAG DirectAccess Solution

While the UAG DirectAccess Wizard does a lot of the configuration for you, there are a number of infrastructure components you need to have in place before you can deploy a UAG DirectAccess solution. The UAG DirectAccess Wizard will configure many of these for you, but other components will require that you install and configure them separately. The good news is that most of these infrastructure services are ones that you’re already using and already familiar with, so that the learning curve won’t be that steep. The primary challenge that you, as a UAG DirectAccess admin, will have to deal with is the number of “moving parts” that are involved in the solution. However, once you have configured UAG DirectAccess in a lab environment, you’ll understand how all of these parts work together and it will all make sense, and might actually end up seeming quite easy to configure.

The key components of a UAG DirectAccess infrastructure include the following:

  • Active Directory Domain Services and Group Policy

  • Domain Name Services (DNS)

  • A Public Key Infrastructure (PKI) and Windows Active Directory Certificate Services

  • 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

In this and the next part of this series, we’ll discuss each of these servers and technologies and how they integrate with a UAG DirectAccess solution. This part (Part 4) will focus on the first three: Active Directory Domain Services and Group Policy, DNS and PKI/Windows Active Directory Certificate Services.

Active Directory Domain Services and Group Policy

Both the DirectAccess client and the UAG DirectAccess server should be members of a domain. The DirectAccess client computer account and user login account can be members of a different domain or forest than the UAG DirectAccess server, but in that scenario you will have to make sure there is a two-way trust between the UAG server forest and the computer/user account forest. There are no provisions for a workgroup configuration, on the client side or the server side.

The reason you need the DirectAccess client and server to be domain members is because UAG DirectAccess leverages domain Group Policy to deploy many of the configuration parameters that are involved with the DirectAccess configuration. For example, the Windows Firewall with Advanced Security is configured on both the DirectAccess clients and UAG DirectAccess server using Group Policy. Without domain membership, the Group Policy delivery mechanism across multiple computers wouldn’t be available. Of course, you could manually configure the UAG DirectAccess client and server, but this wouldn’t be very scalable.

Another reason for the computers to be domain members is the ability to map computer certificates in the NT Auth Store in Active Directory. This is required for the computer certificate authentication that is used for authenticating both the first and second tunnel IPsec DirectAccess tunnels. If the computer certificate isn’t mapped, the computer will not be able to establish these tunnels. Active Directory also allows us to leverage the ability to automatically deploy certificates via Group Policy. We’ll cover computer certificate deployment later in the discussion about PKI and Windows Active Directory Certificate Services.

Another important thing to realize regarding Active Directory is that there is no domain functional level required. You can be running your current Active Directory infrastructure in Windows Server 2003 functional level and get DirectAccess working. There is no requirement for a Windows Server 2008 or Windows Server 2008 R2 domain controller.

Domain Name Services (DNS)

DNS is part of all networks, and so this won’t represent a new technology for you. In fact, you can use any version of DNS you like in a UAG DirectAccess solution. However, the level of functionality you get depends on what your DNS servers can support. If you want full functionality, your DNS servers should support IPv6 Quad A (AAAA) records and should be able to accept dynamic registrations of these records. If you are using Windows Server 2008 or above as your corporate DNS server, it will meet these requirements.

The IPv6 dynamic registrations are used mostly in two areas:

  • IPv6 capable servers on the corporate network will be able to automatically register their ISATAP addresses with the DNS server, enabling hosts on the corpnet to use IPv6 addresses to communicate with one another.

  • UAG DirectAccess clients on the Internet will register this IPv6 address dynamically in your DNS database, so that if you want to initiate outbound connections from management stations on the corpnet, you can do this using the computer name of the DirectAccess client.

However, you can still use other DNS servers, such as non-Microsoft DNS servers or Windows Server 2003 and below. You will lose some functionality because these servers do not support dynamic registration of IPv6 records, which means that DirectAccess clients will need to use NAT64/DNS64 for all their communications with resources on the corpnet. We discussed earlier what some of the limitations are regarding NAT64/DNS64. However, if you are comfortable with these limitations, there’s no reason that you need to upgrade to Windows Server 2008 or above DNS servers.

A Public Key Infrastructure (PKI) and Windows Active Directory Certificate Services

In the past, when the subject of a PKI was brought up, many administrators would duck and run for cover. However, in the last few years there seems to be a bit less of this behavior. Most likely this is due to the fact that so many Microsoft servers and services require certificates now that most administrators have been forced to learn about PKI to get those services running.

If you don’t have any kind of PKI in place, don’t let this requirement be a roadblock for your DirectAccess deployment. The PKI requirements are relatively simple. You need certificates in three places for a UAG DirectAccess deployment:

  • All DirectAccess client computers need a computer certificate delivered by your enterprise CA. This allows for automatic mapping of computer certificates to computer accounts and significantly improves on the overall security of the solution. This is the default setting for UAG DirectAccess and we highly recommend that you use a Windows Active Directory Certificate Services Certificate Authority and Group Policy to automate deployment of computer certificates throughout the domain/forest infrastructure.

  • The Network Location Server requires a web site certificate because computers configured as DirectAccess clients try to use an SSL connection to the NLS server to determine whether the DirectAccess client is on or off the corpnet. A Windows PKI is not required, but it does simplify the task of assigning the certificates to the web sites. The CRL of the CA that issued this certificate must be available to computers that are configured as DirectAccess client when they are connected to the corpnet.

  • The UAG DirectAccess server needs a web site certificate to bind to its IP-HTTPS listener. While you do have the option of using a private PKI based on your Windows Active Directory Certificate Services CA infrastructure, we highly recommend that you use a commercial certificate to ensure high availability for the CRL listed on the certificate. If the DirectAccess client on the Internet tries to use IP-HTTPS to connect to the UAG DirectAccess server, and isn’t able to connect to the CRL listed on the certificate, the IP-HTTPS connection will fail.

You can start your private PKI with a single Windows Server 2008 or Windows Server 2008 R2 certificate server. In fact, if your only Windows Server 2008 or above server is the UAG DirectAccess server, you can use a Windows Server 2003 CA and Windows Server 2003 Active Directory to generate and deploy the certificates. As for the IP-HTTPS certificate, you can use your private PKI for proof of concept and small pilot deployments, but you’ll save yourself a lot of trouble if you use a commercial certificate for your production release of DirectAccess.

Summary

Your UAG DirectAccess deployment is dependent on having necessary infrastructure components in place and configured properly. In this, Part 4 of our series on UAG DirectAccess, we began the discussion of how to set up the infrastructure so that DirectAccess will work. Next month, in Part 5, we’ll continue that discussion with details on 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. See you then!

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