Geek of All Trades: Step-by-Step DirectAccess Installation
Just because you’re part of a small business doesn’t mean you can’t extend your network over the Internet with DirectAccess.
Greg Shields
My laptop, sitting here in this coffee shop, is on my company domain. When I double-click the H: drive, I see the files and folders on my internal file server. If I run a gpupdate /force or wuauclt /detectnow, it applies Group Policies and detects updates from internal domain controllers and Windows Server Update Services (WSUS) servers. In short, I’m using DirectAccess and loving it.
My company is a small to midsize business (SMB), and a remarkably small SMB at that. We don’t have many servers, but those we do have are extremely important. All we’ve done to run DirectAccess is add one new server and a handful of configurations. Suddenly, I’m in the office while I’m here in this coffee shop—or anywhere else.
DirectAccess? For an SMB? Yes, indeed, and putting it together was admittedly less challenging than we thought. It wasn’t trivial, but it certainly wasn’t impossible.
Are you ready to securely extend your LAN onto the Internet? Grab a Windows Server 2008 R2 server with two NICs, two consecutive public IP addresses and this guide for a step-by-step process you can implement today that will power up your own DirectAccess always-on virtual private network (VPN).
Step 1: Build and Provision a DirectAccess Server
Start by provisioning a Windows Server 2008 R2 machine with two NICs. Make sure it’s a member of your internal Active Directory domain. Connect the two NICs, one to an external subnet and the other to your internal network. Next, you’ll be installing certificates and the DirectAccess components. Because this server will bridge the inside and outside network, double-check to ensure it has all the required updates.
You’ll also need two consecutive, static, public IP addresses. For example, these two addresses could be 98.34.120.34 and 98.34.120.35. The important thing is that they’re consecutive. Getting these addresses can be a challenge for a small IT shop. You’ll need an Internet provider who will work with you.
Be careful about which two addresses you’re given. There’s a little-known gotcha reported in the TechNet Library that outlines some special rules for what DirectAccess considers to be “consecutive.” The DirectAccess Management console alphabetically sorts the public IPv4 addresses assigned to the Internet adapter. Therefore, DirectAccess doesn’t consider the following sets of addresses as consecutive: w.x.y.9 and w.x.y.10, which are sorted as w.x.y.10, w.x.y.9; w.x.y.99 and w.x.y.100, which are sorted as w.x.y.100, w.x.y.99; w.x.y.1, w.x.y.2 and w.x.y.10, which are sorted as w.x.y.1, w.x.y.10, w.x.y.2. You’ll need to use a different set of consecutive addresses.
Configure the two external addresses on the external adapter of your DirectAccess server. Do the same for the single internal address on its internal adapter. It’s a good idea to rename the adapters to remind you which adapter corresponds to which connection. Set the internal adapter’s DNS suffix for this connection to your internal suffix.
Step 2: Create External DNS Records
DirectAccess requires external resolution for a pair of external DNS A records. Both should point to the first of your two consecutive IP addresses (not to the second, and not to both). While both will point to the same address, only one will be used for DirectAccess. The other will locate a Certificate Revocation List (CRL) that you’ll set up shortly.
For example, these are the two A records for my environment: directaccess.company.com and crl.company.com. You may have to work with your Internet provider to create these A records.
Step 3: Set up a PKI with Active Directory Certificate Services
Part of the DirectAccess security model involves mutual authentication using a Certificate Services public key infrastructure (PKI). Add the Active Directory Certificate Services (ADCS) role and Certification Authority (CA) role service to an available server, such as a DC. Set it up as an Enterprise Root CA, create a new Private Key, and accept the installation defaults to complete the installation.
Next, you’ll need to create a Web server certificate template. In Server Manager, navigate to the ADCS role and click on Certificate Templates. Right-click the Web server template and choose Duplicate Template.
Create a Windows Server 2008 Enterprise template and bring up the Properties console. Under the Request Handling tab, select Allow private key to be exported. Under the Security tab, grant the Domain Computers and Authenticated Users groups Read and Enroll permissions. Exit the Properties console and right-click the template you just created. Select Change Names to give it a friendly name.
Add that template to your CA Certificate Templates folder by right-clicking the folder and choosing New | Certificate Template to Issue. Select and issue the template you just created.
Step 4: Set up a CRL on the DirectAccess Server
The certificates a PKI uses require access to a CRL. This list identifies revoked certificates that are now invalid. You must be able to access the CRL from both the Internet and intranet, so your DirectAccess server is the perfect host.
Start by installing the IIS role with default role services. In IIS Manager, create a new Virtual Directory named CRLD that points to the path C:\inetpub\wwwroot\crld. Enable the Directory Browsing feature in Properties of this virtual directory.
Next, create a share named CRLD$ on the path C:\inetpub\wwwroot\crld. Grant the CA computer account Full Control permissions on the share.
Back in the virtual directory’s properties screen, select the Configuration Editor and navigate to system.webserver/security/request Filtering. Once there, set allow Double Escaping to True.
Next, create the path clients that will resolve to find the CRL from both internal and external networks. Back on the DC, launch the Certification Authority console and right-click to view the CA Server properties. On the Extensions tab, select the extension called CRL Distribution Point (CDP). Click Add, then enter the external address outside clients will use to access the CRL.
My address is https://crl.company.com/crld/\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl. Yours will be similar for all but your server’s Fully Qualified Domain Name (FQDN). Check all the boxes at the bottom of the console page. Click Add again to create the connection for internal clients. Enter the UNC path internal clients can use to access the CRL.
My path is \\crl.company.internal\crld$\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl. Because this internal connection is where the CRL is published, check the boxes marked Publish CRLs to this location and Publish Delta CRLs to this location.
Back in the CA console, right-click Revoked Certificates and select All Tasks | Publish. If you’ve done everything correctly, you should see two CRL files appear in the share.
Step 5: Install Certificates on the DirectAccess and Network Location Servers
Earlier you created certificate templates. Now it’s time to create the certificates themselves. Both the DirectAccess and its internal Network Location Server require Web server certificates for mutual authentication.
Open the Certificates MMC console on the DirectAccess server and navigate to the Certificates | Personal store. Right-click on Certificates and choose All Tasks | Request New Certificate. In the Certificate Enrollment console, select the certificate you created in Step 3.
A link will appear prompting you for more information required to enroll for this certificate. Click here to configure settings. Click the link and select the Subject tab in the resulting window. Add a Common name and a DNS alternative name. The latter will be your server’s external DirectAccess FQDN (for example, mine is directaccess.company.com). Click OK, then Enroll to enroll the certificate.
Your Network Location Server (NLS) is an internal server running the IIS role. The NLS requires few resources, so you can safely install it on an existing server. Repeat the previously described process to install the certificate from Step 3 on the NLS. There will be one slight difference, though. Instead of entering the external DirectAccess FQDN, you’ll need to provide an internally resolvable FQDN.
For my system, I created the name nls.company.internal, and added it to the DNS as a CNAME for the actual server name of my NLS. DirectAccess interacts with its NLS over HTTPS, so you’ll need to create an HTTPS binding to that CNAME on the IIS Default Web site.
Step 6: Ready Your Clients with Group Policy
DirectAccess clients require some firewall and certificate auto-enrollment settings that are easiest to set using Group Policy. The first setting creates ICMPv6 Inbound and Outbound rules to enable IPv6 ping support for DirectAccess.
In the Group Policy Management Editor, navigate to Computer Configuration | Policies | Windows Settings | Security Settings | Windows Firewall with Advanced Security | Windows Firewall with Advanced Security. Create a new Inbound Rule. Choose a Custom rule, for All programs, with ICMPv6 as the Protocol type and Echo request as the Specific ICMP type (you’ll find this under ICMP settings).
Map that rule to any local or remote IP addresses, and enable the connection on all three Profiles. Give your rule a name and click Finish. Repeat these steps to create a new Outbound Rule with the same settings.
You can create the second client configuration in either the same Group Policy Object (GPO) or a new object. This time, in the Group Policy Management Editor, navigate to Computer Configuration | Policies | Windows Settings | Security Settings | Public Key Policies and view properties for the Certificate Services Client – Auto-Enrollment. Set the Configuration Model to enabled, check the two checkboxes that appear, and click OK.
You’ll find your last Group Policy setting under Public Key Policies | Automatic Certificate Request Settings. Right-click and select New | Automatic Certificate Request. This will launch the Automatic Certificate Request Setup Wizard. This tells the computer the kinds of certificates it should automatically request. Select the Computer template and click through to finish the wizard.
Apply this Group Policy to your domain, so all computers will receive and apply the policy. Allow enough time for computers to apply the policy before moving on to the final two steps.
Step 7: Preparing Domain Services
There are three minor settings that prepare domain services for working with DirectAccess. For the first, you’ll need to create a global group. DirectAccess will later grant external access to the members of this global group. Add the computer accounts for any clients to which you’d like to grant access.
Your Dynamic Host Configuration Protocol (DHCP) server performs the second setting. If you haven’t implemented IPv6 in your environment, modify the DHCP server setting to disable DHCPv6 stateless mode.
The third setting modifies DNS. DirectAccess uses the Intra-Site Automatic Tunneling Address Protocol (ISATAP) for some of its communication. That protocol is normally part of a DNS server’s global block list. You’ll have to remove ISATAP from the blocked list for it to function correctly. To remove ISATAP, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters on your DNS servers and remove the ISATAP entry. Restart its services after making this change.
Step 8: Install DirectAccess
With our handful of configurations complete, we’re ready to install DirectAccess. You should do so via the Server Manager. Once installed, launch the DirectAccess console and select its Setup node. Setting up DirectAccess requires four steps:
- Specify the global group that contains the computer accounts that will be granted external access.
- Specify the Internet and internal network interfaces, as well as the CA and external server certificate. This should be easy if you’ve renamed your interfaces and certificates with useful, easy-to-remember names.
- Specify the infrastructure servers that can interact with external clients. Here you’ll provide the NLS URL, as well as the name and IPv6 information for the DNS, DC and any other servers you use to manage clients such as WSUS or System Center servers. These servers must all have IPv6 enabled.
- Finish out the configuration by identifying any other servers that external clients can access. These other servers are those you use for client applications.
The installation will complete once you’ve finished each of these four steps. As part of the installation process, DirectAccess will create two more GPOs (in addition to those you created earlier) that will require linking to the domain. These GPOs further configure the DirectAccess experience on connecting clients.
8 Steps to Everywhere Access
This isn’t trivial, for sure, but it’s not impossible, either. There are more than a handful of configurations, but the hardest part will be obtaining the two static consecutive IP addresses from your Internet provider.
The results are absolutely worth the effort. Considering today’s everywhere and always-on business requirements, DirectAccess presents an excellent solution for keeping your users connected—even for the smallest of SMB networks.
.jpg "Greg Shields")
Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Shields’ Jack-of-all-trades tips and tricks at ConcentratedTech.com.