10 things you should know about DirectAccess

DirectAccess is promising to take remote access to a new level. Here's a look at what it offers and how it works.

DirectAccess is promising to take remote access to a new level. Here's a look at what it offers and how it works.

DirectAccess is a new remote access technology that's available with the combination of Windows Server 2008 R2 and Windows 7 Enterprise or Ultimate editions. DirectAccess promises to revolutionize the entire remote access experience so that employees can be productive from anywhere at any time, without the constraints of traditional remote access technologies, such as network-level VPNs, SSL VPN gateways, and reverse proxies. It provides a seamless experience for users and advanced management capabilities for IT. DirectAccess enables access from anywhere, even when the DirectAccess client system is behind a restrictive firewall.

1: You can extend your corporate network to any Internet-connected client

The goal of DirectAccess is to extend your corporate network's reach to any DirectAccess client computer that's connected to the Internet. A DirectAccess computer is a domain member, a managed computer that is subject to the same change management and control mechanisms as computers that never leave the physical boundaries of the corporate network. In addition to extending IT's control over all managed computers, regardless of location, DirectAccess provides a seamless network access experience for users. They don't have to remember one name for when they are on the corpnet and another name when they're off the corpnet; that's because they're always on the corpnet.

When a DirectAccess client computer starts, it establishes the "infrastructure" tunnel. This tunnel allows the DirectAccess client computer to connect to management and domain resources, such as domain controllers, DNS servers, and management servers. This tunnel is also bidirectional, so IT can initiate "manage out" connections to the DirectAccess clients on the Internet, in the same way they can when connecting to hosts on the intranet.

After the user logs on, a second tunnel, called the "intranet tunnel," enables users to connect to corporate resources in the same way an intranet host connects to those resources. They can use FQDNs or single label names to connect to file servers, Web servers, database servers, mail servers, or any other kind of server, and they never need to reconfigure their applications when they're off the network. The DirectAccess user is always on the corporate network, regardless of location.

2: You'll need to meet these DirectAccess requirements

You must meet several requirements before starting a DirectAccess deployment. For starters, you need:

At least one domain controller running Windows Server 2003 or above.

An internal PKI to assign machine certificates to DirectAccess clients and the DirectAccess server.

A private or public PKI to assign Web site certificates to the IP-HTTPS listener and the Network Location Server (discussed later).

And you'll need to meet these additional requirements:

The DirectAccess server must be Windows Server 2008 R2 Standard or Enterprise or higher.

IPv6 must be enabled, and IPv6 transition technologies must also not be disabled.

DirectAccess clients must run Windows 7 Enterprise or Ultimate edition.

DirectAccess clients must be members of an Active Directory domain.

A highly available Network Location Server (Web server) must be on the corpnet.

If there are firewalls in front of or behind the DirectAccess server, packet filters must be enabled to allow the required traffic.

The DirectAccess server must have two network interface adapters.

3: IPv6 is the cornerstone of DirectAccess communications

The DirectAccess client always uses IPv6 to communicate with the DirectAccess server. The DirectAccess server will then forward these connections to IPv6-enabled hosts on the corpnet. The corpnet can use native IPv6 infrastructure (where the routers, switches, operating systems, and applications are all IPv6 capable) or it can use IPv6 transition technologies to connect to IPv6 resources on the corpnet.

The DirectAccess server can use ISATAP (Intra-site Automatic Tunnel Addressing Protocol) to tunnel IPv6 packets inside IPv4 headers, which can then take advantage of your IPv4 routing infrastructure to move IPv6 packets throughout your network. DirectAccess clients connected to the IPv4 Internet can use a number of IPv6 transition technologies to connect to the DirectAccess server, including 6to4, Teredo, and IP-HTTPS.

4: IPSec secures communications from end to edge and end to end

Since corpnet communications between the DirectAccess client and server are moving over a public Internet, it's important that the communications be secured from interception and tampering. DirectAccess uses IPsec to secure the communications between the DirectAccess client and server. IPsec tunnel mode is used to establish both the infrastructure and intranet tunnels. In addition, you can configure DirectAccess to require end-to-end encryption between the DirectAccess client and destination server on the corpnet to use IPsec transport mode, so that the connection is encrypted from the client to its destination. DirectAccess also takes advantage of the new AuthIP feature that was initially introduced with Vista and Windows Server 2008, so that connections can be authenticated via user or computer credentials instead of just computer certificates.

5: Client applications must be IPv6 aware

While the goal is to provide a computing experience that is the same as the corpnet-connected client, there is one major difference between the corpnet client and the DirectAccess client: The DirectAccess client must use and always uses IPv6 to connect to the DirectAccess server. That means that the client application on the DirectAccess client must be IPv6 aware. If the client application is not IPv6 aware (for example, the current OCS client), the connection will fail. This is true even if you use an IPv6 to IPv4 translator, which enables DirectAccess clients to connect to IPv4 servers on the corpnet.

6: Active Directory and Group Policy make it work

A number of configuration changes are made to the DirectAccess server and DirectAccess client to make the solution work. To make these changes in the most efficient manner, the DirectAccess solution takes advantage of Active Directory and Active Directory Group Policy objects. The GPO is assigned to the DirectAccess server and DirectAccess clients. In addition, Active Directory is required for authentication. The infrastructure tunnel uses NTLMv2 authentication for the computer account connecting to the DirectAccess server, and that computer account must be part of an Active Directory domain. The intranet tunnel uses Kerberos authentication for the logged-on user to create the second tunnel.

Although Active Directory and GPOs are required, the DirectAccess server does not need to be a member of the resource domain. As long as there is a two-way trust between the DirectAccess server domain and the resource domains/forests, the solution will work.

DirectAccess is designed to work automatically and in the background. The user should never have to do anything to "turn on" the DirectAccess connection. All the user needs to do is turn on the computer. In fact, the user doesn't even need to log on! Before the user logs on, the infrastructure tunnel is automatically established, and the DirectAccess client's agents can connect to their management servers to obtain updates, desired configuration information, security configuration settings, and anything else that IT needs to do to make sure that the DirectAccess client remains in compliance with network configuration and security policies.

To make this process transparent, there must be a mechanism where the DirectAccess client components know when to turn themselves off and on. This is where the Network Location Server comes in. The Network Location Server (NLS) is a Web server that allows incoming SSL connections. You can allow anonymous or integrated authentication to the NLS server. When the DirectAccess client connects to the NLS, it knows it's on the corpnet, and it turns off the DirectAccess client components. If the DirectAccess client can't contact the NLS server, it knows that it's off the corpnet, and it automatically turns on the DirectAccess client components to establish the IPsec tunnels to the DirectAccess server over the Internet. The DirectAccess client does do a check on the Certificate Revocation List for the NLS Web server certificate, so the CRL must be available. Otherwise, the connection to the NLS SSL Web site will fail, and the intranet detection process will fail.

8: Certificates, certificates, certificates!

Certificates are used in a number of places in the DirectAccess client/server solution. Places where you'll see certificates include:

DirectAccess client computers. Each DirectAccess client needs a computer certificate to establish the IPsec connections to the DirectAccess server. These are used to create the IPsec connections and are also used by IP-HTTPS, where the DirectAccess server will perform a certificate validation of the computer certificate before allowing the IP-HTTPS connection over the Internet. Computer certificates are best assigned using Microsoft Certificate Server and Group Policy based computer certificate auto-enrollment.

The IP-HTTPS listener on the DirectAccess Server. IP-HTTPS is an IPv6 transition technology used to tunnel IPv6 packets over the IPv4 Internet. This protocol was designed by Microsoft to enable the DirectAccess client to connect to the DirectAccess server, even if the DirectAccess client is located behind a firewall that allows only outbound HTTP/HTTPS connections or it's behind a Web proxy server. The IP-HTTPS listener requires a Web site certificate, and the DirectAccess client must be able to contact the server hosting the CRL for the certificate. If the CRL check fails, the IP-HTTPS connection will fail. Commercial certificates are best for the IP-HTTPS listener, since their CRLs are globally available.

DirectAccess servers. The DirectAccess server hosts the IP-HTTPS Web site certificate, but it also requires a computer certificate to establish the IPsec connections with the DirectAccess clients.

9: Name Resolution Policy Table provides policy-based DNS queries

The DirectAccess client uses the Name Resolution Policy Table (NRPT) to determine which DNS server to use to resolve names. When the DirectAccess client is on the corpnet, the NRPT is turned off. When the DirectAccess client detects that it is on the Internet, the DirectAccess client turns on the NRPT and checks its entries to see which DNS server it should use to connect to a resource. You put your internal domain names and possible servers on the NRPT and configure it to use an internal DNS server to resolve names.

When the DirectAccess client on the Internet needs to connect to a resource using a FQDN, it checks the NRPT. If the name is on it, the query is sent to an intranet DNS server. If the name is not on the NRPT, the DirectAccess client sends the query to the DNS server configured on its NIC, which is an Internet DNS server. The name of the NLS server is also placed on the NRPT, but it's included as an exemption -- meaning that the DirectAccess client should never use an intranet server to resolve the name of the NLS server. So the DirectAccess client on the Internet will never be able to resolve the name of the NLS server and thus will know that it is on the Internet and will turn on its DirectAccess client components. Even more important, when it connects to the corpnet over the DirectAccess connection, it doesn't think that it's connected to the corpnet by resolving the name of the NLS server.

10: DirectAccess enables "manage out" capabilities

As already mentioned, IT can take advantage of the "manage out" capabilities enabled by the infrastructure tunnel to connect to DirectAccess clients on the Internet. However, you will need to configure Firewall Rules in the Windows Firewall with Advanced Security (WFAS) to allow these connections for Teredo clients. When you create these rules, make sure that they have Edge Traversal turned on for the Firewall Rule. DirectAccess clients are Teredo clients when they are located behind a NAT device to connect to the Internet and the DirectAccess server, and the NAT device allows UDP port 3544 outbound.

Check out 10 Things... the newsletter

Get the key facts on a wide range of technologies, techniques, strategies, and skills with the help of the concise need-to-know lists featured in TechRepublic's 10 Things newsletter, delivered every Friday. Automatically sign up today.

About Deb Shinder

Debra Littlejohn Shinder, MCSE, MVP is a technology consultant, trainer, and writer who has authored a number of books on computer operating systems, networking, and security. Deb is a tech editor, developmental editor, and contributor to over 20 add...

Full Bio

Debra Littlejohn Shinder, MCSE, MVP is a technology consultant, trainer, and writer who has authored a number of books on computer operating systems, networking, and security. Deb is a tech editor, developmental editor, and contributor to over 20 additional books on subjects such as the Windows 2000 and Windows 2003 MCSE exams, CompTIA Security+ exam, and TruSecure's ICSA certification.

This article is an excellent summary of what DirectAccess offers, I'm still struggling to set up such a server on our domain. In the actual help literature it suggests that the DirectAccess server isn't the same as the domain controller. Is this an absolute, and how about if you decided to use a VM for the DirectAccess server?