Step 1: Plan the Remote Access Infrastructure

If you are using certificate-based IPsec authentication, the Remote Access server and clients are required to obtain a computer certificate. The simplest way to install the certificates it to configure group-policy based auto enrollment for computer certificates. This ensures that all domain members obtain a certificate from an enterprise CA. If you do not have an enterprise CA set up in your organization, see Active Directory Certificate Services. Note that the following is required for this certificate:

• The certificate should have client authentication extended key usage (EKU).
  
  
• Both the client and the server certificates should chain to the same root certificate. This root certificate must be selected in the DirectAccess configuration settings.
  
  

The Remote Access server acts as an IP-HTTPS listener, and you must manually install an HTTPS website certificate on the server. Note the following when planning:

• Using a public CA is recommended, so that CRLs are readily available.
  
  
• In the subject field, specify either the IPv4 address of the Internet adapter of Remote Access server, or the FQDN of the IP-HTTPS URL (the ConnectTo address). If the Remote Access server is located behind a NAT device, the public name or address of the NAT device should be specified.
  
  
• The common name of the certificate should match the name of the IP-HTTPS site.
  
  
• For the Enhanced Key Usage field, use the Server Authentication object identifier (OID).
  
  
• For the CRL Distribution Points field, specify a CRL distribution point that is accessible by DirectAccess clients that are connected to the Internet.
  
  

  Note
  This is only required for Windows 7 clients.

• The IP-HTTPS certificate must have a private key.
  
  
• The IP-HTTPS certificate must be imported directly into the personal store.
  
  
• IP-HTTPS certificates can have wildcards in the name.
  
  

When planning for the network location server website, note the following:

• In the Subject field, specify either an IP address of the intranet interface of the network location server or the FQDN of the network location URL.
  
  
• For the Enhanced Key Usage field, use the Server Authentication OID.
  
  
• For the CRL Distribution Points field, use a CRL distribution point that is accessible by DirectAccess clients that are connected to the intranet. This CRL distribution point should not be accessible from outside the internal network.
  
  

Note
Ensure that the certificates for IP-HTTPS and network location server have a Subject Name. If the certificate does not have a Subject Name but has an Alternative Name, then it will not be accepted by the Remote Access wizard.

In a Remote Access deployment, DNS is required for the following:

• DirectAccess client requests—DNS is used to resolve requests from DirectAccess client computers that are not located on the internal network. DirectAccess clients attempt to connect to the DirectAccess network location server in order to determine whether they are located on the Internet, or on the corporate network: If the connection is successful, then clients are determined to be on the intranet and DirectAccess is not used, and client requests are resolved using the DNS server configured on the network adapter of the client computer. If the connection does not succeed, clients are assumed to be on the Internet. DirectAccess clients will use the name resolution policy table (NRPT) to determine which DNS server to use when resolving name requests. You can specify that clients should use DirectAccess DNS64 to resolve names, or an alternative internal DNS server. When performing name resolution, the NRPT is used by DirectAccess clients to identify how to handle a request. Clients request an FQDN or single-label name such as http://internal. If a single-label name is requests, a DNS suffix is appended to make an FQDN. If the DNS query matches an entry in the NRPT, and DNS4 or an intranet DNS server is specified for the entry, then the query is sent for name resolution using the specified server. If a match exists but no DNS server is specified, then this indicates an exemption rule and normal name resolution is applied.
  
  Note that when a new suffix is added to the NRPT in the Remote Access Management console, the default DNS servers for the suffix can be automatically discovered by clicking the Detect button. Auto detection works as follows:
  
  
  1. If the corporate network is IPv4-based, or IPv4 and IPv6, the default address is the DNS64 address of the internal adapter on the Remote Access server.
     
     
  2. If the corporate network is IPv6-based, the default address is the IPv6 address of DNS servers in the corporate network.
     
     
• Infrastructure servers—
  
  
  1. Network location server—DirectAccess clients attempt to reach the network location server to determine if they are on the internal network. Clients on the internal network must be able to resolve the name of the network location server, but must be prevented from resolving the name when they are located on the Internet. To ensure this occurs, by default, the FQDN of the network location server is added as an exemption rule to the NRPT. In addition, when you configure Remote Access, the following rules are created automatically:
     
     
     1. A DNS suffix rule for root domain or the domain name of the Remote Access server, and the IPv6 addresses corresponding to the intranet DNS servers configured on the Remote Access server. For example, if the Remote Access server is a member of the corp.contoso.com domain, a rule is created for the corp.contoso.com DNS suffix.
        
        
     2. An exemption rule for the FQDN of the network location server. For example, if the network location server URL is https://nls.corp.contoso.com, an exemption rule is created for the FQDN nls.corp.contoso.com.
        
        
     IP-HTTPS server—The Remote Access server acts as an IP-HTTPS listener and uses its server certificate to authenticate to IP-HTTPS clients. The IP-HTTPS name must be resolvable by DirectAccess clients using public DNS servers.
     
     Connectivity verifiers—Remote Access creates a default web probe that is used by DirectAccess client computers use to verify connectivity to the internal network. To ensure the probe works as expected the following names must be registered manually in DNS:
     
     
     1. directaccess-webprobehost—should resolve to the internal IPv4 address of the Remote Access server, or to the IPv6 address in an IPv6-only environment.
        
        
     2. directaccess-corpconnectivityhost—should resolve to localhost (loopback) address. A and AAAA record should be created, A record with value 127.0.0.1 and AAAA record with value constructed out of NAT64 prefix with the last 32 bits as 127.0.0.1. The NAT64 prefix can be retrieved by running the cmdlet get-netnattransitionconfiguration.
        
        

        Note
        This is valid only in IPv4-only environments. In an IPv4+IPv6, or IPv6-only environment, only a AAAA record should be created with the loopback IP address ::1.

     You can create additional connectivity verifiers using other web addresses over HTTP or PING. For each connectivity verifier, a DNS entry must exist.
     
     

• For DirectAccess clients, you must use either a DNS server running Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or any DNS server that supports IPv6.
  
  
• You should use a DNS server that supports dynamic updates. You can use DNS servers that do not support dynamic updates, but entries must be manually updated.
  
  
• The FQDN for your Internet-accessible CRL distribution points must be resolvable using Internet DNS servers. For example, if URL http://crl.contoso.com/crld/corp-DC1-CA.crl is in the CRL Distribution Points field of the IP-HTTPS certificate of the Remote Access server, you must ensure that the FQDN crld.contoso.com is resolvable using Internet DNS servers.
  
  

When planning for local name resolution, consider the following issues:

• NRPT—You may need to create additional NRPT rules in the following cases:
  
  
  • You need to add more DNS suffixes for your intranet namespace.
    
    
  • If the FQDN of your CRL distribution points are based on your intranet namespace, you must add exemption rules for the FQDNs of the CRL distribution points.
    
    
  • If you have a split-brain DNS environment, you must add exemption rules for the names of resources for which you want DirectAccess clients located on the Internet to access the Internet version, rather than the intranet version.
    
    
  • If you are redirecting traffic to an external website through your intranet web proxy servers, the external website is available only from the intranet, and uses the addresses of your web proxy servers to permit the inbound requests. In this case, add an exemption rule for the FQDN of the external website, and specify that the rule uses your intranet web proxy server rather than the IPv6 addresses of intranet DNS servers.
    
    For example, when testing an external website named test.contoso.com. This name is not resolvable via Internet DNS servers, but the Contoso web proxy server knows how to resolve the name and to direct requests for the website to the external web server. To prevent users who are not on the Contoso intranet from accessing the site, the external website allows requests only from the IPv4 Internet address of the Contoso web proxy. Thus, intranet users can access the website because they are using the Contoso web proxy but DirectAccess users cannot because they are not using the Contoso web proxy. By configuring an NRPT exemption rule for test.contoso.com that uses the Contoso web proxy, webpage requests for test.contoso.com are routed to the intranet web proxy server over the IPv4 Internet.
    
    
• Single label names—Single label names, such as http://paycheck, are sometimes used for intranet servers. If a single label name is requested, and a DNS suffix search list is configured, the DNS suffixes in the list will be appended to the single label name. For example, when a user on a computer that is a member of the corp.contoso.com domain types http://paycheck in the web browser, the FQDN constructed as the name is paycheck.corp.contoso.com. By default the appended suffix is based on the primary DNS suffix of the client computer.
  
  

  Note

  Note that in a disjoint name space scenario (where one or more domain computers has a DNS suffix that does not match the Active Directory domain to which the computers belong), you should ensure that the search list is customized to include all the required suffixes. The Remote Access wizard, by default, will configure the Active Directory DNS name as the primary DNS suffix on the client. Make sure to add the DNS suffix used by clients for name resolution.

  
  
  If multiple domains and WINS are deployed in your organization and you are connecting remotely, single-names can be resolved by:
  
  
  • Deploying a WINS forward lookup zone in the DNS—When trying to resolve computername.dns.zone1.corp.contoso.com, the request is directed to the WINS server that is only using computername. The client thinks it is issuing a regular DNS A RR request but it is actually a NetBIOS request. For more information see Managing a Forward Lookup Zone.
    
    
  • Adding a DNS suffix, for example dns.zone1.corp.contoso.com, to the default domain policy GPO.
    
    
• Split-brain DNS—Split-brain DNS is the use of the same DNS domain for both Internet and intranet name resolution.
  
  For split-brain DNS deployments, you must list the FQDNs that are duplicated on the Internet and intranet, and decide which resources the DirectAccess client should reach, the intranet or the Internet version. For each name that corresponds to a resource for which you want DirectAccess clients to reach the Internet version, you must add the corresponding FQDN as an exemption rule to the NRPT for your DirectAccess clients. In a split-brain DNS environment, if you want both versions of the resource to be available, configure your intranet resources with alternate names, that are not duplicates of the names used on the Internet, and instruct your users to use the alternate name when on the Intranet. For example, configure the alternate name www.internal.contoso.com for the internal name www.contoso.com. In a non-split-brain DNS environment, the Internet namespace is different from the intranet namespace. For example, the Contoso Corporation uses contoso.com on the Internet and corp.contoso.com on the intranet. Because all intranet resources use the corp.contoso.com DNS suffix, the NRPT rule for corp.contoso.com routes all DNS name queries for intranet resources to intranet DNS servers. DNS name queries for names with the contoso.com suffix do not match the corp.contoso.com intranet namespace rule in the NRPT, and are sent to Internet DNS servers. With a non-split-brain DNS deployment, because there is no duplication of FQDNs for intranet and Internet resources, there is no additional configuration needed for the NRPT. DirectAccess clients can access both Internet and intranet resources for their organization.
  
  
• Local name resolution behavior for DirectAccess clients—If a name cannot be resolved with DNS, the DNS Client service in Windows Server 2012, Windows 8, Windows Server 2008 R2, and Windows 7 can use local name resolution, with the Link-Local Multicast Name Resolution (LLMNR) and NetBIOS over TCP/IP protocols, to resolve the name on the local subnet. Local name resolution is typically needed for peer-to-peer connectivity when the computer is located on private networks, such as single subnet home networks. When the DNS Client service performs local name resolution for intranet server names and the computer is connected to a shared subnet on the Internet, malicious users can capture LLMNR and NetBIOS over TCP/IP messages to determine intranet server names. On the DNS page of the Infrastructure Server Setup wizard, you configure the local name resolution behavior based on the types of responses received from intranet DNS servers. The following options are available:
  
  
  • Use local name resolution if the name does not exist in DNS—This option is the most secure because the DirectAccess client performs local name resolution only for server names that cannot be resolved by intranet DNS servers. If the intranet DNS servers can be reached, the names of intranet servers are resolved. If the intranet DNS servers cannot be reached, or if there are other types of DNS errors, the intranet server names are not leaked to the subnet through local name resolution.
    
    
  • Use local name resolution if the name does not exist in DNS or DNS servers are unreachable when the client computer is on a private network (recommended)—This option is recommended because it allows the use of local name resolution on a private network only when the intranet DNS servers are unreachable.
    
    
  • Use local name resolution for any kind of DNS resolution error (least secure)—This is the least secure option because the names of intranet network servers can be leaked to the local subnet through local name resolution.
    
    

The network location server is a website used to detect whether DirectAccess clients are located in the corporate network. Clients in the corporate network do not use DirectAccess to reach internal resources, but instead connect directly.

The network location server website can be hosted on the Remote Access server or on another server in your organization. If you host the network location server on the Remote Access server, the website is created automatically when you deploy Remote Access. If you host the network location server on another server running a Windows operating system in your organization, you must make sure that Internet Information Services (IIS) is installed on that server, and that the website is created. Remote Access does not configure settings on the remote network location server.

Make sure that the network location server website meets the following requirements:

• It is a website with an HTTPS server certificate.
  
  
• DirectAccess client computers must trust the CA that issued the server certificate to the network location server website.
  
  
• DirectAccess client computers on the internal network must be able to resolve the name of the network location server site.
  
  
• The network location server site must be highly available to computers on the internal network.
  
  
• The network location server must not be accessible to DirectAccess client computers on the Internet.
  
  
• The server certificate must be checked against a Certificate Revocation List (CRL).
  
  

Remote Access in Windows Server® 2012 allows you to choose between using certificates for IPsec computer authentication or using a built in Kerberos proxy that authenticates using user names and passwords.

When you choose Active Directory credentials for authentication, DirectAccess uses one security tunnel that uses Computer Kerberos for the first authentication method, and User Kerberos for second authentication method. When using this mode for authentication, DirectAccess uses a single security tunnel that provides access to the DNS server, the domain controller, and to any other server on the internal network

When you choose to use two factor authentication or Network Access Protection, DirectAccess uses two security tunnels. The Remote Access Setup wizard configures Windows Firewall with Advanced Security connection security rules that specify the use of the following types of credentials when negotiating the IPsec security associations for the tunnels to the Remote Access server:

• The infrastructure tunnel uses Computer certificate credentials for the first authentication and User (NTLMv2) for the second authentication. User (NTLMv2) credentials force the use of Authenticated Internet Protocol (AuthIP) and provide access to a DNS server and domain controller before the DirectAccess client can use Kerberos credentials for the intranet tunnel.
  
  
• The intranet tunnel uses Computer certificate credentials for the first authentication and User (Kerberos V5) for the second authentication.
  
  

The management servers list should include domain controllers from all domain containing security groups that include DirectAccess client computers. It should contain all domains that contain user accounts that might use computers configured as DirectAccess clients. This ensures that users who are not located in the same domain as the client computer they are using are authenticated with a domain controller in the user domain. This will be done automatically if domains are in the same forest. Note that if there are computers in the security group used for client computers or application servers that are in different forests, the domain controllers of those forests are not detected automatically. forests are also not detected automatically. You can run the task Update Management Servers in the Remote Access Management UI to detect these domain controllers. You can run the task Update Management Servers in the Remote Access Management to detect these domain controllers.

Where possible, common domain name suffixes should be added to the NRPT during Remote Access deployment. For example, if you have two domains, domain1.corp.contoso.com and domain2.corp.contoso.com, instead of adding two entries into the NRPT, you can add a common DNS suffix entry, where the domain name suffix is corp.contoso.com. Note that this happens automatically for domains in the same root. Domains that are not in the same root must be added manually.

Note the following when using automatically-created GPOs:

Automatically created GPOS are applied according to the location and link target parameter, as follows:

• For the DirectAccess server GPO, both the location and link parameters point to the domain containing the Remote Access server.
  
  
• When client and application server GPOs are created, the location is set to a single domain in which the GPO will be created. The GPO name is looked up in each domain, and filled with DirectAccess settings if it exists. The link target is set to the root of the domain in which the GPO was created. A GPO is created for each domain that contains client computers or application servers, and the GPO is linked to the root of its respective domain.
  
  

When using automatically created GPOs, to apply DirectAccess settings, the Remote Access server administrator requires the following permissions:

• GPO create permissions for each domain.
  
  
• Link permissions for all the selected client domain roots.
  
  
• Link permissions for the server GPO domain roots.
  
  
• Create, edit, delete, and modify security permissions are required for the GPOs.
  
  
• It is recommended that the Remote Access administrator has GPO read permissions for each required domain. This enables Remote Access to verify that GPOs with duplicate names do not exist when creating GPOs.
  
  

Note that if the correct permissions for linking GPOs do not exist, a warning is issued. The Remote Access operation will continue but linking will not occur. If this warning is issued links will not be created automatically, even after the permissions added later. Instead the administrator will need to create the links manually.

Note the following when using manually-created GPOs:

• The GPOs should exist before running the Remote Access Setup wizard.
  
  
• When using manually-created GPOs, to apply DirectAccess settings the Remote Access server administrator requires full GPO permissions (Edit, Delete, Modify security) on the manually-created GPOs.
  
  
• When using manually created GPOs a search is made for a link to the GPO in the entire domain. If the GPO is not linked in the domain then a link is automatically created in the domain root. If the required permissions to create the link are not available a warning is issued.
  
  

Note that if the correct permissions for linking GPOs do not exist, a warning is issued. The Remote Access operation will continue but linking will not occur. If this warning is issued links will not be created automatically, even after the permissions are added later. Instead the administrator will need to create the links manually.

If a Remote Access server, client, or application server GPO has been deleted by accident and there is no backup available, you must remove the configuration settings and re-configure again. If a backup is available, you can restore the GPO from the backup.

Remote Access Management will display the following error message: GPO <GPO name> cannot be found. To remove the configuration settings, take the following steps:

1. Run the PowerShell cmdlet Uninstall-remoteaccess.
   
   
2. Re-open Remote Access Management.
   
   
3. You will see an error message that the GPO is not found. Click Remove configuration settings. After completion, the server will be restored to an un-configured state.