Share via

Design Active Directory for DirectAccess

  • Article

Applies To: Windows 7, Windows Server 2008 R2

Important

This topic describes design considerations for DirectAccess in Windows Server 2008 R2. For the design considerations of DirectAccess in Microsoft Forefront Unified Access Gateway (UAG), see the Forefront UAG DirectAccess Design Guide (https://go.microsoft.com/fwlink/?LinkId=179988).

DirectAccess clients, DirectAccess servers, and selected servers must be members of an Active Directory Domain Services (AD DS) domain. DirectAccess also uses Active Directory security groups and Group Policy objects (GPOs) to identify sets of computers and the sets of settings that are applied to them.

The DirectAccess Setup Wizard uses security groups to identify the following:

  • The computer accounts of DirectAccess clients (required)

  • The computer accounts of application servers for selected server access (optional)

Warning

You must not use a built-in security group, such as Domain Computers or Domain Users, for the security group for DirectAccess clients.

You must create and populate these groups before running the DirectAccess Setup Wizard. For more information, see Create DirectAccess Groups in Active Directory in the DirectAccess Deployment Guide.

The DirectAccess Setup Wizard creates GPOs for the following:

  • DirectAccess clients that contains settings for Internet Protocol version 6 (IPv6) transition technologies, Name Resolution Policy Table (NRPT) rules, intranet detection settings, and Windows Firewall with Advanced Security connection security rules (required).

  • The DirectAccess server that contains settings for IPv6 transition technologies and Windows Firewall with Advanced Security connection security rules (required).

  • Selected servers that contain settings for Windows Firewall with Advanced Security connection security rules (optional).

If you remove a computer from a DirectAccess client or selected server security group, the next update of Group Policy will remove the DirectAccess settings from the computer.

Active Directory and the DirectAccess server

The DirectAccess server must be a domain member and cannot be a domain controller. Additionally, an Active Directory domain controller cannot be reachable from the Internet interface of DirectAccess server; the Internet interface cannot be attached to a network that has been assigned the domain profile of Windows Firewall. If any of these conditions exist, the DirectAccess Setup Wizard cannot be run. If a domain controller is reachable from the Internet interface of DirectAccess server, when the Network Location Awareness service assigns the Domain profile to the Internet interface, the connection security rules that allow the DirectAccess server to act as an Internet Protocol security (IPsec) tunnel endpoint are not active. As a result, DirectAccess clients on the Internet cannot establish the infrastructure and intranet tunnels with the DirectAccess server.

In some configurations, you must have an Active Directory domain controller that is on the perimeter network, and therefore reachable from the Internet interface of DirectAccess server. For example, for small offices that use a single router and a single subnet for an intranet in which there is no physical perimeter network, all of your DirectAccess server interfaces can reach the domain controller. In these configurations, you can prevent the DirectAccess server from reaching the domain controller by adding packet filters on the Internet interface of the DirectAccess server that prevent connectivity to the Internet Protocol (IP) address of the perimeter network domain controller.

Additionally, because the DirectAccess server is an IPv6 router, if you have a native IPv6 infrastructure, the Internet interface can also reach the domain controllers on the intranet. In this case, add IPv6 packet filters to the Internet interface that prevent connectivity to the intranet domain controllers.

For more information, see Configure Packet Filters to Block Access to Domain Controllers in the DirectAccess Deployment Guide.

Active Directory Sites and Services configuration

When you are using Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) and your Windows-based ISATAP hosts obtain an ISATAP-based IPv6 address, they begin to use ISATAP-encapsulated traffic to communicate if the destination is also an ISATAP host. Because ISATAP uses a single 64-bit subnet for your entire intranet, your communication goes from a segmented, multi-subnet Internet Protocol version 4 (IPv4) communication model to a flat, single-subnet communication model with IPv6. This can affect the behavior of Active Directory Domain Services (AD DS) and other applications that rely on your Active Directory Sites and Services configuration. For example, if you used the Active Directory Sites and Services snap-in to configure sites, IPv4-based subnets, and inter-site transports for forwarding of requests to servers within sites, this configuration is not used by ISATAP hosts.

To configure Active Directory sites and services for forwarding within sites for ISATAP hosts, you have to configure an IPv6 subnet object equivalent to each IPv4 subnet object, in which the IPv6 address prefix for the subnet expresses the same range of ISATAP host addresses as the IPv4 subnet.

For example, for the IPv4 subnet 192.168.99.0/24 and the 64-bit ISATAP address prefix 2002:836b:1:1::/64, the equivalent IPv6 address prefix for the IPv6 subnet object is 2002:836b:1:1:0:5efe:192.168.99.0/120. For an arbitrary IPv4 prefix length (set to 24 in the example), the corresponding IPv6 prefix length is 96 + IPv4PrefixLength.

For the IPv6 addresses of DirectAccess clients, you should add the following:

  • An IPv6 subnet for the range 2001:0:WWXX:YYZZ::/64, in which WWXX:YYZZ is the colon-hexadecimal version of the first consecutive public IPv4 address (w.x.y.z) assigned to the Internet interface of the DirectAccess server. This IPv6 prefix is for Teredo-based DirectAccess clients.

  • If you have a native IPv6 infrastructure, an IPv6 subnet for the range 48-bitIntranetPrefix:5555::/64, in which 48-bitIntranetPrefix is the 48-bit native IPv6 prefix that is being used on your intranet. This IPv6 prefix is for Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS)-based DirectAccess clients.

  • If you are using a 6to4-based IPv6 prefix on your intranet, an IPv6 subnet for the range 2002:WWXX:YYZZ:2::/64, in which WWXX:YYZZ is the colon-hexadecimal version of the first consecutive public IPv4 address (w.x.y.z) assigned to the Internet interface of the DirectAccess server. This IPv6 prefix is for IP-HTTPS-based DirectAccess clients.

  • A series of 6to4-based IPv6 prefixes that begin with 2002: and represent the regional, public IPv4 address prefixes that are administered by Internet Assigned Numbers Authority (IANA) and regional registries. The 6to4-based prefix for a public IPv4 address prefix w.x.y.z/n is 2002:WWXX:YYZZ::/[16+n], in which WWXX:YYZZ is the colon-hexadecimal version of w.x.y.z. For example, the 7.0.0.0/8 range is administered by American Registry for Internet Numbers (ARIN) for North America. The corresponding 6to4-based prefix for this public IPv6 address range is 2002:700::/24. For information about the IPv4 public address space, see IANA IPv4 Address Space Registry (https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml). These IPv6 prefixes are for 6to4-based DirectAccess clients.

DirectAccess and user profiles for remote users

Using roaming user profiles for DirectAccess clients for all of the contents of the user profile folder can result in long logon and logoff times. If you want to store user profiles on network locations for DirectAccess clients, use folder redirection for the folders of the user profile rather than roaming user profiles for the entire user profile.

For more information, see the Managing Roaming User Data Deployment Guide (https://go.microsoft.com/fwlink/?LinkId=73435).