Although the prerequisites and associated
technologies for DirectAccess can be difficult to implement,
DirectAccess configuration is fairly straightforward through a simple
wizard. The example walks through the DirectAccess Wizard in Windows
Server 2008 R2.
The scenario accomplishes two
major goals, as follows:
1. | Allow a
workstation to seamlessly move between internal, public, and home
networks while retaining access to application servers.
|
2. | Enable IPv6 in an IPv4 network using IPv6 transition
technologies.
|
It is important to note that
the scenario does not require that you have deployed IPv6 throughout the
internal network to begin using DirectAccess. The scenario leverages
the Windows Server 2008 R2 and Windows 7 technologies that will
automatically enable and configure IPv6 using transitional technologies
like ISATAP, 6to4, and Teredo.
This scenario assumes
that Windows Server 2008 R2 Active Directory and DNS are already
deployed. The DirectAccess server must have two physical network
interfaces. The first is connected directly to the Internet, no NAT, and
must have two consecutive public IP addresses. The second interface is
connected to the internal network. This scenario also assumes you have
an internal enterprise PKI deployment with CRLs published on the
Internet.
There are five servers and a
client in the scenario shown in Figure 1. These are the systems that will be configured and tested
against during the scenario. The systems are as follows:
DC1— Domain controller, DNS, and enterprise
Certificate Authority server running Windows Server 2008 R2. The Active
Directory domain is companyabc.com. The CA must have an Internet
available certificate revocation list (CRL). The DC1 IP address is
192.168.3.200.
DA1—
DirectAccess server domain member running Windows Server 2008 R2, with
two network interface cards, and two public IP addresses (12.155.166.2
and 12.155.166.3) assigned. The internal IP address is 192.168.3.211.
This server should also have the Web Server role installed to support
IP-HTTPS.
Note
The reason for two
consecutive public IPv4 addresses on the DirectAccess server’s public
Internet interface is so that Teredo-based DirectAccess clients can
detect the type of NAT that they are located behind.
SERVER1— The application server that the DirectAccess
client is accessing. The server also hosts the NLS role, using the URL https://nls.companyabc.com. The application server has been assigned
the internal IP address 192.168.3.201.
NS1— External
DNS server hosting the external companyabc.com zone. The NS1 IP address
is 12.155.166.1.
WS3—
DirectAccess client domain member running Windows 7. This system will
travel between the internal, public, and home networks.
The scenario assumes that
split-brain DNS is being used—that is, that there is an internal
companyabc.com zone and an external companyabc.com zone. There should be
a DNS A record for da1.companyabc.com (12.155.166.2) in the external
companyabc.com zone, as well as the DNS record for the CRL for the
certificate authority (typically crl.companyabc.com).
There are three networks in the
scenario. The DirectAccess client is WS3 and will be roaming between
these networks, but must be able to access the application server no
matter which network they are in. The three networks are as follows:
Internal network— This is the corporate network and is using an IPv4
address in the 192.168.3.x range.
Public network—
This is the Internet, and the servers being configured are using the
IPv4 12.155.166.x range.
Home network—
This is a network behind a NAT firewall, and the IP address range is not
known.
The client WS3 will be
tested while connected to the internal network, the public network, and,
finally, to the home network. In all cases, the client WS3 will
seamlessly transition between the networks with no interruption in
access to internal resources.
Configuring the
Infrastructure
Next, configure the DNS
service to remove the ISATAP name from its default global block list.
This allows the DNS to service ISATAP requests.
To remove ISATAP from the DNS
global query block list, complete the following steps:
1. | On the
domain controller server, open a command prompt.
|
2. | In the Command Prompt window, enter the command dnscmd
/config /globalqueryblocklist wpad and then press Enter.
|
3. | Close the Command Prompt window.
|
The preceding command needs to
be run on each DNS server.
This scenario assumes
split-brain DNS—that is, there is a companyabc.com domain internally,
and there is a companyabc.com on the Internet with a limited set of
records.
The NLS record needs to be
created in DNS. This supports the NLS URL that DirectAccess clients use
to determine if they are in the corporate network. The website used for
the NLS needs to support HTTPS and can be any website available
internally, although it is a best practice that it be highly available.
To create an NLS DNS record, execute the following steps:
1. | On the
domain controller DC1, launch Server Manager.
|
2. | Expand Roles, DNS Server, DNS, DC1, Forward Lookup
Zones, and select the companyabc.com zone.
|
3. | Right-click company abc.com and then click New Host (A
or AAAA).
|
4. | In
the Name field, type nls. In the IP address field, type the IP
address of the NLS website, click Add Host, click OK, and then click
Done.
|
The next step is to create a
security group for DirectAccess client computers. This allows the
DirectAccess clients to be specified. The group will be named
DirectAccessClients. To create the group, execute the following steps:
1. | On the
domain controller, launch Server Manager.
|
2. | Expand Roles, Active Directory Domain Services, Active
Directory Users and Computers, expand the companyabc.com domain, and
select the Users container.
|
3. | Right-click on Users, select New, and then click Group.
|
4. | In the Group Name field, type DirectAccessClients
and click OK.
|
This group will be used
later to assign Group Policy to the DirectAccess clients.
