In a few years, DirectAccess will be the standard way remote users will access their network, just like Outlook Anywhere (what used to be called RPC over HTTPS) allowed email users to synchronize their Exchange email without having to VPN to their network. DirectAccess does away with VPNs by giving you access to “everything else” on your network beyond what Outlook Anywhere provides like your F> and K> drive shares, http:// SharePoint shares, accounting software, CRM software, etc. Basically “anything” you normally have access to from a VPN, you can now access “natively” from a Windows 7 client.
DirectAccess leverages IPSec policies and Certificates to “automatically” tunnel a Windows 7 client into the network. Effectively a client that has DirectAccess configured can simply turn on their laptop or desktop computer, get an Internet connection, and over encrypted IPSec establish normal network connection to company resources, but “outside” the network. AND, your internal network doesn’t have all be Windows 2008 R2, just a single server in the DMZ needs to be running Windows 2008 R2 as a “proxy” that effectively encrypts communications between the client and this one 2008 R2 server. Everything else “inside” your network can be just plain old TCP networking like Windows servers, SharePoint, Linux, etc…
So here’s the catch, the client systems need to be Windows 7 (not a biggie, a lot of orgs have already started their migration to Win7 clients). You need to enable IPv6 on the 2008 R2 proxy/gateway server and IPv6 on all Win7 clients (also not a biggie because it’s on by default since Win2008 and Vista, although you need to now understand how IPv6 works to do the proper addressing, so that’s a learning experience to figure out). You need to be running Microsoft Certification Authority (CA), which for many orgs is also not a big deal as they’ve been running Microsoft’s CA for a while, however if you haven’t setup Microsoft’s CA, you need to get familiar with Auto-enrollment of certificates to automatically push out certs using Active Directory Group Policies. If you’re already doing Auto-enrollment, you’re set! And then IPSec and split DNS, this is the technical pieces that everyone gets wrong and Microsoft’s whitepaper guide on DA is not very helpful. We took time writing this portion of the chapter of my Windows 2008 R2 Unleashed book to create a step by step guide to really get DirectAccess working.
More specifically, DirectAccess uses IPv6, IPSec, and certificates to establish secure connections from the DirectAccess clients to intranet resources via the DirectAccess server. To traverse public IPv4 networks, DirectAccess uses IPv6 transition technologies such as ISATAP, Teredo, and 6to4.
DirectAccess has some specific requirements, as follows:
► The server running Windows Server 2008 R2 needs to have two network cards: one attached to the intranet and one attached to the Internet.
► The Internet network card must have two consecutive public IPv4 addresses.
► The Intranet resources and applications must support IPv6.
► The DirectAccess clients need to be running Windows 7; older clients are not supported.
► A domain controller and DNS server that the systems are connected to need to be running Windows Server 2008 SP2 or Windows Server 2008 R2.
► A PKI needs to be available to issue certificates with a published Internet available certificate revocation list (CRL).
These requirements are somewhat stringent and might prevent many organizations from deploying DirectAccess. However, for an organization with an up-to-date infrastructure, servers, and clients, DirectAccess can be an excellent solution.
DirectAccess and IPv6
DirectAccess is designed on top of IPv6 and requires that all endpoint devices support IPv6. It is one of the first services to require this modern protocol.
DirectAccess is most likely to be deployed in an IPv4 world, given the prevalence of IPv4 on the Internet today. This creates an IPv4 gap across which IPv6 devices like DirectAccess clients need to communicate.
Most organizations will need to use IPv6 transition technologies to bridge the IPv4 gap from their IPv6 enlightened devices to communicate. This, in effect, routes the IPv6 communications through the IPv4 protocol stack. The packets traveling down the IPv6 protocol stack take a sharp turn and move across the protocol stack to the IPv4 protocol stack, allowing them to transit the IPv4 network. On the other side, the same packets come in via the IPv4 protocol stack, but are routed to the IPv6 stack.
Communications between IPv6 devices like DirectAccess clients over IPv4 networks is accomplished with IPv6 over IPv4 tunneling. In tunneling, the IPv6 packets are encapsulated in an IPv4 packet by the source device and routed through the IPv4 network. When the encapsulated packet arrives at the boundary between the IPv4 and IPv6 networks, the IPv4 encapsulation is stripped off and the IPv6 packet continues on its way. The most common tunneling protocols are ISATAP, 6to4, and Teredo.
For organizations, the IPv6 tunneling protocols are used for the following purposes:
► ISATAP—This protocol is used to automatically assign IPv6 addresses within the organization’s IPv4 intranet.
► 6to4—This protocol is used to automatically assign IPv6 addresses and route across the public IPv4 Internet.
► Teredo—This protocol is used to automatically assign IPv6 addresses and route across the public IPv4 Internet to devices behind Network Address
Translation (NAT) firewalls.
For organizations that have not deployed IPv6 natively, Microsoft Windows Server 2008 R2 and Windows 7 support ISATAP, 6to4, and Teredo transition protocols. However, even while DirectAccess clients are using IPv6 transitional technologies like Teredo or 6to4, it is ultimately communicating from IPv6 clients to IPv6 hosts.
Internally, DirectAccess can use Network Address Translation-Protocol Translation (NAT-PT) devices, which can be used to provide access to IPv4 resources. Resources that don’t support IPv6 natively can be accessed through the use of a Network Address Translation-Protocol Translation (NAT-PT) device. Microsoft Windows Server 2008 R2 does not currently include that capability, so a third-party device would be needed for this functionality.
NOTE
NAT-PT is covered in IETF RFC-2766 (https://tools.ietf.org/html/rfc2766), but was reclassified from a Proposed Standard to Historic due to issues with the standard. RFC4966 (https://tools.ietf.org/html/rfc4966) contains the details of these issues. These include difficulty with integrity mechanisms, inability to redirect protocols that lack demultiplexing capabilities, premature state timeouts, loss of information due to IPv4 and IPv6 header incompatibilities, packet fragmentation issues, and an inability to handle multicast traffic. NAT-PT devices are only recommended as a stop-gap measure due to these issues.
For organizations that have not deployed IPv6, the deployment of DirectAccess is an excellent project to test the IPv6 waters with. The infrastructure can be deployed in parallel with existing remote access solutions and without impacting the existing IPv4 addressing scheme, providing IT personnel with a chance to learn IPv6 and its integration with IPv4 in a low-impact production setting.
A Tale of Two Tunnels
The DirectAccess client establishes two tunnels, which are key to the versatility of this method of remote access. These tunnels are IPSec Encapsulating Security Payload (ESP) tunnels that are authenticated with certificates and encrypted to ensure the confidentiality. These tunnels are as follows:
► Computer tunnel—The computer tunnel is established first when the DirectAccess client starts up. This tunnel is authenticated with the computer certificate only and provides access to the intranet DNS and domain controllers. This tunnel is also used to download the computer group policy and request user authentication.
► User tunnel—This tunnel is authenticated with the computer certificate and the user credentials and provides access to the intranet resources. This tunnel is used to download user group policy as well.
Both these tunnels are established transparently to the user. The user does not have to present credentials above and beyond the normal Windows logon to establish remote access.
These tunnels allow for the transparent establishment of remote access, essentially allowing the computer to connect to the intranet even when no user is logged on. This allows the DirectAccess client to receive Group Policy remotely and be managed by the management servers in the intranet. When a user logs on, they are authenticating to the intranet and, thus, ensuring that users are subject to the latest requirements, password changes, and policies. In contrast, other VPN solutions typically have users authenticating using cached credentials against the local machine and then establishing the remote access connection.
End-to-Edge DirectAccess Model
The end-to-edge model of DirectAccess has the DirectAccess client establish an IPSec tunnel to the DirectAccess server. The DirectAccess server then forwards unprotected traffic to the intranet resources. This is the most common form of DirectAccess and closely follows a standard remote access methodology.
The end-to-edge model requires no IPSec support within the intranet, although the intranet resources still need to support IPv6.
End-to-End DirectAccess Model
The end-to-end model of DirectAccess has the DirectAccess client establish an IPSec tunnel with each application server that they connect to. This ensures that traffic is protected end to end (hence the name) by the IPSec encryption, including while traversing the intranet.
The end-to-end model requires that each application server run on Windows Server 2008 or Windows Server 2008 R2, as well as use IPv6 and IPSec. There is also some additional overhead for the IPSec connections.
The requirement that all application servers be Windows Server 2008 or higher is a difficult hurdle to overcome in today’s heterogeneous IT environments. This makes the end-to-end model of DirectAccess less common than the end-to-edge model.
Internet Versus Intranet Traffic with DirectAccess
One of the benefits of DirectAccess is the ability to separate the intranet traffic (destined for internal servers) from the Internet traffic (destined for external servers). This conserves the corporate bandwidth for access to corporate resources. By specifying the domains and subdomains for which the DirectAccess server provides access, traffic for those domains is directed through the DirectAccess connection. Other traffic is routed through the default routes and bypasses the DirectAccess connection. This is the highest performance configuration and is the default mode of operation.
However, in some cases, administrators might want to have all traffic route through the DirectAccess connection. Examples of this include organizations that want to control or monitor their client communications or prevent access to certain Internet sites. In these cases, the DirectAccess client can be configured to route all traffic through the DirectAccess connection.
DirectAccess Components
DirectAccess leverages IPv6 technology along with PKI to provide a seamless secure connection to the enterprise network. DirectAccess runs at boot and connects as soon as Internet connectivity is established. There’s no need for a user to configure a VPN client or logon. From an administrative perspective, this technology allows system administrators to manage and monitor remote systems through tools like Microsoft System Center Configuration Manager (SCCM) and Group Policy. DirectAccess finally puts remote workers on equal ground with traditional office employees.
The following list depicts the components found in a DirectAccess deployment:
► DirectAccess server—This is the server that connects to the internal network and the Internet. It has to be running Windows Server 2008 R2 with two physical interfaces: one on the public Internet and one for the internal network. The public interface must have two consecutive public IP addresses assigned.
► DirectAccess client—This is a computer running Windows 7. It must be a domain member with a certificate.
► Corporate IPv6 network—The IPv6 network to which DirectAccess clients will be connecting remotely.
► Certificate server—This server issues the certificates that support the tunnel creation, authentication, and security. This certificate server must have a published certificate revocation list (CRL) that is available internally and externally.
► Network Location Server (NLS)—This is an HTTPS site that serves as the indicator to the DirectAccess client if it is connected to the Internet or the intranet.
► Active Directory and DNS server—This server must be running Windows Server 2008 SP2 or Windows Server 2008 R2. The AD and DNS role can be separate servers, although most organizations will have these services on the same server.
Smart cards or NAP protection can also be implemented for additional security if desired. In its most simple configuration, DirectAccess requires each client to have a valid computer certificate for authentication to the internal network. This takes the place of a traditional username and password.
DirectAccess requires IPv6 on the internal enterprise network. It leverages conversion technology like Teredo, 6to4, and also the new IP-HTTPS for remote clients using IPv4 to connect to the IPv6 enterprise network. These new technologies are described in the following list:
► Teredo is the most common method for DirectAccess. It allows IPv6 traffic to pass through NAT devices that transition out to an IPv4 public network. A good example is many “hot spot” connections at coffee shops and many home networks.
► 6to4 directly translates IPv6 addresses into IPv4 addresses. If remote clients are directly connected to the Internet and have only IPv4 public IP addresses, 6to4 is the preferred method for connectivity.
► IP-HTTPS is a new protocol in Windows 7 and Windows Server 2008 R2. It tunnels IPv6 traffic over an IPv4 HTTPS tunnel between a DirectAccess client and a DirectAccess server. Although this might seem like the simplest option, it comes at a large performance cost due to network overhead and should be used only as a last resort.
The DirectAccess protocol is very robust and will transparently attempt multiple methods of access to establish a connection.
Network Location Service
The Network Location Service (NLS) is a critical component for the DirectAccess architecture. This is a website that clients attempt to connect to determine if they are currently connected to the Internet or to the intranet. It is the URL of a highly available website in the corporate intranet.
There are two behaviors that would be experienced for the DirectAccess client system. They are as follows:
► If the DirectAccess client can reach the NLS URL, it assumes that it is connected to the corporate network and no further action is necessary.
► If the DirectAccess client cannot reach the NLS URL, it assumes that it is not connected to the corporate network and then begins the DirectAccess connection process.
The NLS service is normally a highly available website, such as servers in a Network Load Balanced (NLB) cluster or a Windows cluster.
NOTE
As you can see, if the NLS website is down, this can result in the disastrous situation of all the DirectAccess clients suddenly thinking they are on the Internet, even though they are really in the intranet. They would all then begin the DirectAccess connection process. That’s why the NLS website must be highly available.
DirectAccess Connection Process
The DirectAccess client is very robust and will try a variety of methods to connect to the corporate network. The connection process is started when the DirectAccess client detects that it is connected to a network—that is, a network transition such as the connection to a LAN, wireless access point, or other connection becomes active.
The DirectAccess client goes through the following connection process when it detects that it is connected to a network:
1. The DirectAccess client attempts to connect to the NLS website. If it can reach the site, it determines that it is connected to the intranet and stops the DirectAccess process. If it cannot reach the NLS website, it determines that it is connected to the Internet and continues with the DirectAccess process.
2. The DirectAccess client establishes an IPSec tunnel to the DirectAccess server using IPv6. If there is an intervening IPv4 network, the client uses the Teredo or 6to4 protocols to tunnel IPv6 over IPv4.
3. If the DirectAccess client is unable to connect using the Teredo or 6to4 protocols, the client will attempt to connect using the IP-HTTPS protocol.
4. The DirectAccess client establishes an IPSec tunnel to the DirectAccess server using IPv6. The DirectAccess client and the DirectAccess server mutually authenticate using certificates in the process of setting up the IPSec computer tunnel.
5. The DirectAccess client contacts the domain controller and obtains the computer group policy.
NOTE
The user does not have to be logged on to the computer for this process to complete to this point in the process.
6. The DirectAccess user logs on or the logged-on credentials are used in conjunction with the certificates to establish the IPSec user tunnel. The user group policy is applied to the DirectAccess client.
7. The DirectAccess server begins forwarding traffic from the DirectAccess client to authorized intranet resources.
This entire process is transparent to the user and requires no user interaction. In the event of an interruption in network connectivity, the DirectAccess client will reestablish the connection through this process when it detects network connectivity again.
I cover the installation and configuration of DirectAccess in my book, Windows Server 2008 R2 Unleashed where we cover step by step a process to get DirectAccess working. We found that Microsoft’s DirectAccess whitepaper, if followed step by step, actually leaves an organization with Direct Access not working (works inside the corporate network, but doesn’t work when the Windows 7 client is outside the corporate network). The Microsoft whitepaper left out a handful of critical steps. We tried writing an addendum to the Microsoft whitepaper on how to “fix” the things that are wrong, unfortunately the end result is we have always had to uninstall and start from scratch to get DirectAccess working. So in my book chapter (Chapter 24), we cover all of the pieces needed to getting DirectAccess working. The Windows 7 client piece, the IPSec piece, the IPv6 piece, the Certificate Authority piece, the DNS piece, the Group Policies piece.
DirectAccess is a REALLY slick technology once you get it working. I’d recommend any hardcore techie to throw this in your lab to fiddle with, it’s a great technology to understand and ultimately implement!
