Configure network services and access - Exam Ref 70-417 Upgrading Your Skills to Windows Server 2012 R2 (2014)

Exam Ref 70-417 Upgrading Your Skills to Windows Server 2012 R2 (2014)

Chapter 6. Configure network services and access

The Configure Network Services and Access domain is another with just one objective tested on the 70-417 exam: Configure DirectAccess. DirectAccess is an improved alternative to a VPN that was first introduced in Windows Server 2008 R2 and Windows 7. If you earned your Windows Sever 2008 MCSA before the release of Windows Server 2008 R2, you might have missed this major new technology completely. And if you did learn about DirectAccess in Windows Server 2008 R2, you need to know that this feature has changed significantly in Windows Server 2012 and Windows Server 2012 R2.

Objectives in this chapter:

Image Objective 6.1: Configure DirectAccess

Objective 6.1: Configure DirectAccess

DirectAccess in Windows Server 2008 R2 and Windows 7 was a very promising technology that was also difficult to configure. Beginning with Windows Server 2012 and Windows 8, the infrastructure requirements of DirectAccess have been simplified along with the configuration steps. At the same time, its feature set has expanded considerably.

For the 70-417 exam, you first need to understand basic DirectAccess concepts and components. You also need to know how the infrastructure requirements to support DirectAccess clients differ to support various features. Finally, you need to know how to configure DirectAccess.

This section covers the following topics:

Image DirectAccess infrastructure options

Image Configuring DirectAccess clients

Image Configuring DirectAccess servers

Image Configuring DirectAccess infrastructure servers

What is DirectAccess?

DirectAccess is an always-on remote access technology that is based on IPv6 communication. Through DirectAccess, a user’s computer automatically, transparently, and securely connects to a private corporate network from any location in the world as soon as the computer is connected to the Internet. When a DirectAccess connection is active, remote users connect to resources on the corporate network as if they were on the local premises.

DirectAccess overcomes the limitations of VPNs by providing the following benefits:

Image Always-on connectivity Unlike with a VPN, a DirectAccess connection is always on, even before the user logs on to his or her computer.

Image Seamless connectivity To the user, the DirectAccess connection to the corporate network is completely transparent and resembles an always-on VPN connection.

Image Bidirectional access With DirectAccess, the user’s remote computer not only has access to the corporate intranet, but the intranet can also see the user’s computer.. This means that the remote computer can be managed by using Group Policy and other management tools (such as System Center 2012 R2 Configuration Manager [“Configuration Manager” for short]) in exactly the same way that computers located on the internal network are managed.

In addition, DirectAccess includes the following security features:

Image DirectAccess uses IPsec to authenticate both the computer and user. If you want, you can require a smart card for user authentication.

Image DirectAccess also uses IPsec to provide encryption for communications across the Internet.

Understanding IPv6 and DirectAccess

A DirectAccess connection from a remote client to an internal resource includes two legs. In the first half of the connection, the DirectAccess client always uses IPv6 to initiate contact with the DirectAccess server, typically found at the edge of the private network. IPv6 transition technologies are used to assist this connection when necessary. The second half of the connection occurs between the DirectAccess server and the internal network resource. This part of the connection can proceed either over IPv4 (only if the DirectAccess server is running Windows Server 2012 or Windows Server 2012 R2 and acting as a NAT64/DNS64 device) or over IPv6.

Figure 6-1 shows the two legs of a DirectAccess connection between a remote client and an internal network resource.

Image

FIGURE 6-1 A DirectAccess connection to an internal resource

First leg: External client to private network edge

If the DirectAccess client can obtain a global IPv6 address from its environment, then the connection to the DirectAccess server proceeds over the IPv6 Internet in a straightforward manner. However, IPv6 is not widely implemented yet on public networks, so three IPv6 transition technologies are used to assist in establishing the IPv6 connection to the DirectAccess server. If all three of the following transition technologies are enabled on the client through Group Policy, they are attempted in the following order of preference:

1. 6to4 For DirectAccess clients that have a public IPv4 address, 6to4 can be used to connect to the DirectAccess server via IPv6 across the public IPv4 Internet. 6to4 achieves this by tunneling or encapsulating IPv6 data within an IPv4 header, in a technique known as IPv6-over-IPv4. 6to4 requires any intervening router or firewall to be configured so that outbound traffic for Protocol 41 is allowed. Also note that 6to4 does not work if the client is behind a network address translation (NAT) device.

2. Teredo For DirectAccess clients behind a NAT device and configured with a private IPv4 address, Teredo can be used to connect to the DirectAccess server via IPv6 across the public IPv4 Internet. Like 6to4, Teredo tunnels IPv6 traffic in IPv4. The intervening routers and firewalls must be configured to allow outbound traffic through User Datagram Protocol (UDP) port 3544.

3. IP-HTTPS For DirectAccess clients that cannot effectively establish IPv6 connectivity to the DirectAccess server through 6to4 or Teredo, IP-HTTPS is used. With IP-HTTPS, DirectAccess clients encapsulate IPv6 traffic within HTTPS traffic. Virtually all routers allow outbound HTTPS traffic, so this option is almost always possible.

Note

Since the release Windows Server 2012 and Windows 8, the performance of IP-HTTPS is close to that of Teredo because a “null encryption” option is used for HTTPS communication. However, in Windows Server 2008 R2 and Windows 7, IP-HTTPS used Secure Sockets Layer (SSL) encryption on top of the IPsec encryption that was used to secure the connection between the DirectAccess client and server. This “double encryption” significantly degraded network performance.

Second leg: Private network edge to internal resource

Between the network edge and the internal network resource, the connection can proceed over either IPv6 or IPv4. You don’t have to deploy global IPv6 on your internal network because Windows Server 2012 and Windows Server 2012 R2 can act as a NAT64/DNS64 device when deployed as a DirectAccess server at the network edge. (A NAT64/DNS64 device translates between IPv6 and IPv4.) However, an all-IPv6 connection still provides the best performance and is the preferred scenario.

Note

Windows Server 2008 R2 didn’t provide NAT64/DNS64 functionality, but you could use Microsoft Forefront Unified Access Gateway 2010 or a third-party device to provide NAT64/DNS64 translation. Otherwise, to implement DirectAccess, you had to deploy global IPv6 on your internal network or use the IPv6 transition technology ISATAP. You can still use ISATAP in Windows Server 2012 and Windows Server 2012 R2, but it is not recommended.

Understanding the DirectAccess connection process

A DirectAccess connection to a target intranet resource is initiated when the DirectAccess client connects to the DirectAccess server through IPv6. IPsec is then negotiated between the client and server. Finally, the connection is established between the DirectAccess client and the target resource.

This general process can be summarized in the following steps:

1. The DirectAccess client computer attempts to connect to an internal computer configured as the network location server. If the network location server is available, the DirectAccess client determines that it is already connected to the intranet, and the DirectAccess connection process stops. If the network location server is not available, the DirectAccess client determines that it is connected to the Internet and the DirectAccess connection process continues.

Network location server

A network location server is an intranet web server that a DirectAccess client attempts to access as a way to determine whether the client is located on the intranet or Internet. An internal address of the DirectAccess server can be configured as the network location server, but using a separate, high-availability internal web server for the network location server is preferred. If you configure a separate web server as a network location server, the web server does not have to be dedicated to this one service.

2. The DirectAccess client computer connects to the DirectAccess server by using IPv6 and IPsec. If a native IPv6 network isn’t available, the client establishes an IPv6-over-IPv4 tunnel by using 6to4, Teredo, or IP-HTTPS. The user does not have to be logged in for this step to complete.

3. As part of establishing the IPsec session, the DirectAccess client and server authenticate each other by using Kerberos or computer certificates.

4. By validating Active Directory Domain Services group memberships, the DirectAccess server verifies that the computer and user are authorized to connect using DirectAccess.

5. If Network Access Protection (NAP) is enabled and configured for health validation, the DirectAccess client obtains a health certificate from a Health Registration Authority (HRA) located on the Internet prior to connecting to the DirectAccess server. The HRA forwards the DirectAccess client’s health status information to a NAP health policy server. The NAP health policy server processes the policies defined within the Network Policy Server (NPS) and determines whether the client is compliant with system health requirements. If so, the HRA obtains a health certificate for the DirectAccess client. When the DirectAccess client connects to the DirectAccess server, it submits its health certificate for authentication.

6. The DirectAccess server begins forwarding traffic from the DirectAccess client to the intranet resources to which the user has been granted access.

Understanding DirectAccess infrastructure options

You can deploy DirectAccess in a number of network scenarios, ranging from the very simple to the very complex. A few of these options are illustrated in the examples that follow.

Simple DirectAccess infrastructure

A simple DirectAccess infrastructure includes a DirectAccess server that is running Windows Server 2012 or Windows Server 2012 R2 and is deployed at the network edge. This DirectAccess server is configured as a Kerberos proxy and NAT64/DNS64 translation device. The external interface is configured with a public IP address. (Two would be necessary to support Teredo.) The internal address is associated with the network location server.

Within the internal network is a domain controller/DNS server and at least one internal network resource such as a file server or application server. Note that this simple infra-structure supports only Windows 8 clients and later because Windows 7 clients do not support Kerberos authentication for DirectAccess.

Figure 6-2 shows a simple DirectAccess infrastructure.

Image

FIGURE 6-2 A simple DirectAccess infrastructure

Image Exam Tip

Remember that only Windows Server 2012 and later, and Windows 8 and later, support Kerberos proxy, a feature that greatly simplifies authentication for DirectAccess clients. In addition, only Windows Server 2012 and Windows Server 2012 R2 include built-in support for NAT64/DNS64 translation, which lets you use DirectAccess with your existing internal IPv4 infrastructure.

DirectAccess server behind NAT

Beginning with Windows Server 2008 R2, all versions of DirectAccess allow you to deploy a DirectAccess server behind the network edge in a perimeter network. However, only in Windows Server 2012 and Windows Server 2012 R2 can you deploy the DirectAccess server behind a NAT device. In such a scenario, the DirectAccess server needs only a single network adapter and a single address. Connections from the DirectAccess clients through the NAT device to the DirectAccess server are established through IP-HTTPS.

Figure 6-3 illustrates a DirectAccess network topology in which a DirectAccess server is deployed behind a NAT device.

Image

FIGURE 6-3 DirectAccess server deployed behind a NAT device

Multisite/Multidomain DirectAccess infrastructure

Another infrastructure option that is new to Windows Server 2012 and Windows Server 2012 R2 is the ability for DirectAccess to be deployed across multiple sites. A multisite deployment of DirectAccess requires a public key infrastructure (PKI) and computer authentication through certificates. In addition, multidomain support is now a built-in feature of DirectAccess that requires no extra configuration.

When you configure a multisite deployment, the DirectAccess clients are provided with a list of the DirectAccess servers that act as entry points to the private network at each site. Before connecting, DirectAccess clients running Windows 8 or later then ping each of these DirectAccess servers. The Windows 8 or later client then initiates contact with the server whose latency is determined to be the shortest. (Windows 7 clients in a multisite deployment simply use a single, preconfigured DirectAccess server address.)

Figure 6-4 shows a multisite DirectAccess infrastructure.

Image

FIGURE 6-4 A multisite DirectAccess infrastructure

Note

To enable multisite capability in DirectAccess, in the Remote Access Management Console click Enable Multisite (as shown later in this chapter in Figure 6-20), or use the Windows PowerShell cmdlet Enable-DAMultiSite.

Complex DirectAccess infrastructure

Although Windows Server 2012 and Windows Server 2012 R2 greatly simplify the basic infrastructure requirements for DirectAccess, the infrastructure can become complex if you need functionality that is not included by default in a basic setup. For example, one new feature introduced in Windows Server 2012 is the ability to deploy DirectAccess servers in a Network Load Balancing (NLB) cluster. This functionality naturally adds complexity to your infrastructure but is often necessary to support many remote clients. Another requirement that adds more elements to your infrastructure is the need to support Windows 7 clients. Windows 7 clients can authenticate DirectAccess connections only with computer certificates, so your DirectAccess infrastructure would require a PKI in such a scenario. Next, DirectAccess can also be deployed with NAP, which is another factor that adds complexity but might be required by your IT policies. Additional features such as two-factor authentication with one-time passwords (OTPs) would raise the infrastructure requirements even more. Figure 6-5 illustrates a more complex DirectAccess infrastructure that supports all three IPv6 transition technologies, improves load capacity with an NLB cluster, supports Windows 7 clients with a PKI/certification authority, includes a NAP infrastructure, and has a network location server deployed apart from the DirectAccess server.

Image

FIGURE 6-5 A complex DirectAccess infrastructure

Note

To enable load balancing in DirectAccess, in the Remote Access Management Console click Enable Load Balancing (as shown later in this chapter in Figure 6-20) or use the Windows PowerShell cmdlets Set-RemoteAccessLoadBalancer and Add-RemoteAccessLoadBalancerNode.

Installing and configuring DirectAccess

Windows Server 2012 and Windows Server 2012 R2 have greatly simplified the process of installing and configuring DirectAccess. DirectAccess is now unified with traditional VPNs in a new Remote Access server role and managed with the same tool, the Remote Access Management Console. In fact, you can now configure a Windows Server to act as both a DirectAccess server and a traditional VPN server at the same time, an option that was not possible in Windows Server 2008 R2. Even more significant than unified management are the new configuration wizards first introduced in Windows Server 2012 that make the process of deploying and configuring DirectAccess and VPNs relatively easy.

Installing DirectAccess

DirectAccess now belongs to the Remote Access server role. You can install the DirectAccess component of the Remote Access role through the Add Roles and Features Wizard or by typing the following at an elevated Windows PowerShell prompt:

Install-WindowsFeature DirectAccess-VPN -IncludeManagementTools

You can then configure DirectAccess using the Remote Access Management Console, shown in Figure 6-6, or by using Windows PowerShell commands.

Image

FIGURE 6-6 The Remote Access Management Console provides a unified configuration and management tool for all remote access technologies

More Info

To review the cmdlets used to configure DirectAccess, visit http://technet.microsoft.com/en-us/library/hh918399 or type the following at a Windows PowerShell prompt when the “DirectAccess and VPN (RAS)” component of the Remote Access role is installed:

Get-Command -Module RemoteAccess *da*

Note also that installing the Remote Access role and its role management tools installs the Windows PowerShell module named DirectAccessClientComponents, which provides the additional client cmdlets listed at http://technet.microsoft.com/en-us/library/hh848426.

Configuring DirectAccess

Figure 6-6 shows the Remote Access Management Console before you take any configuration steps. The central pane shows two options for wizards: the Getting Started Wizard and the Remote Access Setup Wizard. Whichever wizard you choose to begin configuration, you are next presented with an option to configure just DirectAccess, just a VPN, or both, as shown in Figure 6-7.

Image

FIGURE 6-7 The Remote Access configuration wizards allow you to configure just DirectAccess, just a VPN, or both.

The Getting Started Wizard, which was first introduced in Windows Server 2012, is an excellent tool that helps you deploy a remote access solution quickly. However, it is not especially useful for exam preparation precisely because it hides the very configuration options you need to know and understand for the test. In addition, VPN configuration has not changed since you earned your Windows Server 2008 MCSA in any way that is significant for the 70-417 exam. For these reasons, to prepare for the Configure DirectAccess objective for the 70-417 exam, you should focus on configuration options that appear after you click Run The Remote Access Setup Wizard shown in Figure 6-6 and then click Deploy DirectAccess Only shown in Figure 6-7.

After you click Deploy DirectAccess Only, the Remote Access Management Console reappears with the center pane replaced by an image similar to the one shown in Figure 6-8. The four steps in the map are associated with four configuration wizards that you must complete in order: The first is for configuring DirectAccess clients, the second is for configuring the DirectAccess server, the third is for configuring infrastructure servers, and the fourth is for configuring the application servers (if desired). These wizards create and configure Group Policy Objects (GPOs) for DirectAccess servers and clients.

Image

FIGURE 6-8 The four DirectAccess configuration wizards

It’s unlikely you’ll be asked to identify any of these wizards by name on the 70-417 exam. However, you might be asked about any configuration option that appears in any of these four wizards. These four wizards, then, provide a useful way to organize the new configuration options that you need to learn and understand for the 70-417 exam, so we will look at them in order.

Step 1: DirectAccess Client Setup

The first page of the DirectAccess Client Setup Wizard is shown in Figure 6-9. This Deployment Scenario page allows you the option to configure DirectAccess clients either for both remote access and remote management, or for remote management only. The first, default option configures bidirectional communication for DirectAccess servers and clients. Choosing the second option, however, would allow administrators to manage remote DirectAccess clients through tools such as Configuration Manager, but it would prevent those clients from accessing the internal corporate network. Note that the option to deploy DirectAccess clients for remote management only is new to Windows Server 2012 and Windows Server 2012 R2.

Image

FIGURE 6-9 The Deployment Scenario page of the DirectAccess Client Setup Wizard

Note

To choose the deployment scenario in Windows PowerShell, use the Set-DAServer cmdlet with the -DAInstallType parameter and either the FullInstall or ManageOut value. For example, to configure the DirectAccess deployment for remote management only, type the following at an elevated Windows PowerShell prompt on the DirectAccess server:

Set-DAServer -DAInstallType ManageOut

The second page of the DirectAccess Client Setup Wizard is the Select Groups page, shown in Figure 6-10. The first function of this page is to let you specify the security groups containing the computer accounts that you want to enable for DirectAccess. This is an important step to remember: No DirectAccess client is allowed access to the internal network if you don’t assign that client the right to do so. To perform this task in Windows PowerShell, use the Add-DAClient cmdlet with the -SecurityGroupNameList parameter.

Image

FIGURE 6-10 The Select Groups page of the DirectAccess Client Setup Wizard

A second option on this page is to enable DirectAccess for mobile computers only. Interestingly, this option is selected by default if you run the Getting Started Wizard. Computers connecting remotely through DirectAccess are most likely to be mobile computers, but there are exceptions, and these exceptions could easily form the premise of an exam question. (Scenario: Some users working on domain-joined desktop computers from remote sites can’t connect through DirectAccess. Why not? The option to enable DirectAccess for mobile computers only is selected.)

Image Exam Tip

If only laptops are able to connect through DirectAccess, you can change this setting by modifying the the DirectAccess Client Settings GPO. Specifically, you need to remove the DirectAccess - Laptop Only WMI filter that is linked to this GPO in the Security Filtering settings. Note also that both creating and removing these WMI filters requires Domain Admin permissions.

The third option on this page is Use Force Tunneling. This option forces the DirectAccess client to tunnel all network traffic through the private network, regardless of where that traffic is ultimately destined. This behavior, for example, could be used to ensure that all web traffic from DirectAccess clients passes through an internal web proxy server. In Windows PowerShell, this option is configured by using the Set-DAClient cmdlet with the -ForceTunnel parameter.

Image Exam Tip

Expect to see the Use Force Tunneling option appear in an exam question about DirectAccess.

The final page in the DirectAccess Client Setup Wizard is the Network Connectivity Assistant page, shown in Figure 6-11. The Network Connectivity Assistant is client software embedded in Windows 8 and later that determines whether DirectAccess is functioning. (This feature is not the same as the network location server, which helps a client determine whether it is on the Internet or intranet.)

Image

FIGURE 6-11 The Network Connectivity Assistant page of the DirectAccess Client Setup Wizard

The first setting on this page is the host address for the Network Connectivity Assistant. DirectAccess client computers use this address to verify that the client can successfully connect to the internal network. This setting is unlikely to appear on the 70-417 exam (except maybe as an incorrect answer choice), but if you need to enter this resource manually, you should specify the address of a corporate URL or FQDN that is always available to DirectAccess clients. Your internal DNS should resolve this address to the internal address of the Remote Access server.

The most testable setting on this page is the option to allow DirectAccess clients to use local name resolution. Local name resolution in this case refers to the broadcast-based protocols of NetBIOS over TCP/IP and Link-Local Multicast Name Resolution (LLMNR). When this option is enabled, DirectAccess clients are allowed to resolve single label names such as App1 using local name resolution if they can’t be resolved through DNS. Local name resolution must also be configured in the Infrastructure Server Setup Wizard.

Step 2: Remote Access Server Setup

The first page of the Remote Access Server Setup Wizard is the Network Topology page, shown in Figure 6-12. This page lets you specify where in your network you are going to deploy your DirectAccess server.

Image

FIGURE 6-12 The Network Topology page of the Remote Access Server Setup Wizard

The first option is Edge. Choosing this option requires the DirectAccess server to be configured with two network adapters, one connected directly to the Internet and one connected to the internal network. The external interface needs to be assigned two consecutive public IPv4 addresses if you need to support Teredo.

The second option is Behind An Edge Device (With Two Network Adapters). Select this option if you want to deploy the DirectAccess server in a perimeter network behind a firewall or router. In this topology, the network adapter attached to the perimeter network is assigned one or two consecutive public IPv4 addresses, and the second adapter attached to the internal network can be assigned a private address.

The third option is Behind An Edge Device (With A Single Network Adapter). Choose this option if you want to deploy your DirectAccess server behind a NAT device. In this case, your DirectAccess server is assigned a single private IP address.

Finally, the Network Topology page requires you to specify the name or IPv4 address the DirectAccess clients will use to connect to the DirectAccess server. Be sure to specify a name that can be resolved through public DNS or an IPv4 address that is reachable from the public network.

The second page of the Remote Access Server Setup Wizard is the Network Adapters page, shown in Figure 6-13. This page requires you to choose the network adapter or adapters that will be assigned to internal network and external network, as required by your specified topology.

Image

FIGURE 6-13 The Network Adapters page of the Remote Access Server Setup Wizard

This page also requires you to specify a certificate that the DirectAccess server will use to authenticate IP-HTTPS connections. If your organization has deployed a PKI, you can browse to a copy of the computer certificate for the local server. If you don’t have a PKI, you need to choose the option to use a self-signed certificate instead. Note that the availability of this latter option was first introduced in Windows Server 2012 and could easily serve as the basis for a test question.

The final page of the Remote Access Server Setup Wizard is the Authentication page, shown in Figure 6-14. This page lets you configure the following settings related to DirectAccess client authentication:

Image User Authentication By default, users authenticate only with Active Directory credentials. However, you can choose the option here to require two-factor authentication. Typically, two-factor authentication requires a user to insert a smart card in addition to typing his or her Active Directory credentials. Note that in Windows Server 2012 and Windows Server 2012 R2, however, the Trusted Platform Module (TPM) of client computers can act as a virtual smart card for two-factor authentication.

Alternatively, you can also configure two-factor authentication so that users must enter an OTP such as one provided through RSA SecurID in addition to their Active Directory credentials. OTP requires a PKI and RADIUS server, along with a number of configuration steps that you don’t need to understand for the 70-417 exam. For the 70-417 exam, you merely need to know that OTP is an alternative to smart cards for two-factor authentication in DirectAccess.

Image Use Computer Certificates If you configure DirectAccess in the GUI, client computers are authenticated through Kerberos by default. However, you can select an option to require computer authentication through the use of certificates. Computer certificate authentication is required to support two-factor authentication, a multisite deployment of DirectAccess, or Windows 7 DirectAccess clients.

Image Enable Windows 7 Client Computers To Connect Via DirectAccess By default, Windows 7 client computers cannot connect to a Windows Server 2012 or Windows Server 2012 R2 Remote Access deployment. You need to enable that functionality here.

Image Enable Corporate Compliance For DirectAccess Clients With NAP This page allows you to require a health check of client computers through NAP. To configure this setting in Windows PowerShell, use the Set-DAServer cmdlet with the -HealthCheck parameter.

Image

FIGURE 6-14 The Authentication page of the Remote Access Server Setup Wizard

More Info

The authentication settings displayed on this page can all be configured through the Set-DAServer cmdlet. For more information, use Get-Help or visit http://technet.microsoft.com/en-us/library/hh918371.

Step 3: Infrastructure Server Setup

The Infrastructure Server Setup Wizard allows you to configure settings related to the network location server, the DNS server, and management servers such as update or antivirus servers.

The first page of this wizard is the Network Location Server page, shown in Figure 6-15. As explained earlier in this chapter, DirectAccess clients use this server to determine whether they are on the company network. It’s recommended that you use an internal web server other than the DirectAccess (Remote Access) server for this purpose. (The DNS address and associated IP address in this case is naturally associated with the interface attached to the internal network.) If you do specify the DirectAccess server as the network location server, it must be authenticated by a computer certificate—a self-signed one, if necessary. To configure the network location server using Windows PowerShell, use the Set-DANetworkLocationServer cmdlet.

Image

FIGURE 6-15 The Network Location Server page of the Infrastructure Server Setup Wizard

The second page of the Infrastructure Server Setup Wizard is the DNS page shown in Figure 6-16. The main function of this page is to allow you to configure the Name Resolution Policy Table (NRPT). The entries you create here are written to the GPO used to configure DirectAccess clients.

Image

FIGURE 6-16 The DNS page of the Infrastructure Server Setup Wizard

The NRPT is a feature that allows a DNS client to assign a DNS server address to particular namespaces rather than to particular interfaces. The NRPT essentially stores a list of name resolution rules that are applied to clients through Group Policy. Each rule defines a DNS namespace (a domain name or FQDN) and DNS client behavior for that namespace. Together, these name resolution rules are called a Name Resolution Policy. When a DirectAccess client is on the Internet, each name query request is compared against the namespace rules stored in the Name Resolution Policy. If a match is found, the request is processed according to the settings in the Name Resolution Policy rule. The settings determine the DNS servers to which each request will be sent. If a name query request does not match a namespace listed in the NRPT, it is sent to the DNS servers configured in the TCP/IP settings for the specified network interface.

You might need to configure Name Resolution Policy entries if, for example, you need to enable DNS clients to resolve DNS suffixes found only within your intranet namespace. Another reason might be if you have a split public/private DNS environment based on the same domain name, and you need to ensure that DirectAccess clients don’t contact your company’s public servers (such as a web server) through the DirectAccess connection.

Image Exam Tip

You need to understand the function of a Name Resolution Policy and the NRPT for the 70-417 exam. Also know that you can view the NRPT by using the Get-DnsClientNrptPolicy cmdlet in Windows PowerShell.

The second configuration decision you need to make on the DNS page relates to the DirectAccess clients’ use of local name resolution methods such as NetBIOS and LLMNR. Unlike the setting in the DirectAccess Client Setup Wizard, which merely allows (does not block) the use of local name resolution, the setting here determines how local name resolution will be used if allowed. You have three options. The most restrictive is to use local name resolution only if the name does not exist in DNS. This option is considered the most secure because 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. The second and recommended option is to use local name resolution if the name doesn’t exist in DNS or DNS servers are unreachable when the client computer is on a private network. The final and least restrictive option is to use local name resolution for any kind of DNS resolution error. This option is considered the least secure because the names of intranet network servers can be leaked to the local subnet through local name resolution.

To configure local name resolution for clients in Windows PowerShell, use the Set-DAClientDNSConfiguration cmdlet with the -Local parameter. The three choices available in the GUI are designated by the FallbackSecure, FallbackPrivate, or FallbackUnsecure values, respectively.

More Info

For more information about the Set-DAClientDNSConfiguration cmdlet, use Get-Help or visit http://technet.microsoft.com/en-us/library/hh918389.

The third page of the Infrastructure Server Setup Wizard is the DNS Suffix Search List Page, shown in Figure 6-17.

Image

FIGURE 6-17 The DNS Suffix Search List page of the Infrastructure Server Setup Wizard

DirectAccess clients use the list you configure here to resolve single label names, such as http://finance. DNS cannot resolve single label names unless the DNS client first appends a suffix or if a GlobalNames zone is in use on the DNS servers. By default, the suffix is the domain to which the computer is joined.

Image Exam Tip

Your DNS suffix search list should normally match the namespace rules in your NRPT. This is especially important in split-brained DNS scenarios, in which both an organization’s internal private network and its publicly accessible resources use the same DNS domain name (such as contoso.com). To help DirectAccess clients resolve internal names correctly from the Internet, you can enter the full name of internal resources in the Name Suffix list (shown in Figure 6-16) and then specify for these resources a DNS server address corresponding to the IPv6 address of the internal DNS server. Likewise, you can enter the full name of external resources in the Name Suffix list and then leave the DNS server address blank. A blank entry in the DNS server address directs the client to use the DNS server currently assigned to its network connection for the suffix or FQDN specified.

The fourth and final page of the Infrastructure Server Setup Wizard is the Management page, shown in Figure 6-18.

Image

FIGURE 6-18 The Management page of the Infrastructure Server Setup Wizard

You don’t need to enter any domain controllers or Configuration Manager servers here because they are automatically detected the first time that DirectAccess is configured. Instead, use this page to configure DNS clients with the names of management servers that cannot be detected automatically, such as Windows Server Update Services (WSUS) update servers and antivirus servers. Note that if the list of available domain controllers or Configuration Manager servers is modified after you configure DirectAccess, you can simply click Update Management Servers in the Remote Access Management Console to refresh the management server list.

There is one other point to be aware of: Management servers that initiate connections to DirectAccess clients must support IPv6 either natively or through ISATAP.

Step 4: DirectAccess Application Server Setup

DirectAccess Application Server Setup is a single configuration page, as shown in Figure 6-19. You can use this page to configure encryption between the application servers you specify here and the DirectAccess server. (By default, of course, traffic is already encrypted between the DirectAccess client and server.)

Image

FIGURE 6-19 The DirectAccess Application Server Setup page

To configure the list of application servers using Windows PowerShell, use the Add-DAAppServer cmdlet.

Step 5: Advanced configuration options

After you complete DirectAccess Application Server Setup, the Remote Access Management Console appears, as shown in Figure 6-20. At this point, you can start new wizards to configure advanced options such as a multisite deployment or load balancing by clicking the related options in the Tasks pane.

Image

FIGURE 6-20 Configuring advanced DirectAccess options

Verifying the configuration

After you have completed your configuration, you can use the Operations Status item in the left pane of the Remote Access Management Console to verify that DirectAccess is ready to use. Remote clients can begin to connect to the network through DirectAccess after the operations status off all components is shown to be working, as shown in Figure 6-21. This process can take several minutes or more after you complete the final configuration wizard.

Image

FIGURE 6-21 Using the Operations Status item

After the server components are working, you can verify DirectAccess functionality from the client end. First, you can use the Get-DAConnectionStatus cmdlet to determine whether DirectAccess can properly determine the location of the client. Figure 6-22 shows a Windows PowerShell console session from a portable client that is initially plugged in to a corporate network. The first time the cmdlet is run, the client is shown to be connected locally. When the laptop is disconnected and an Internet broadband connection is enabled, the cmdlet is run again. This time, the client is determined to be connected remotely, and connectivity to the intranet is established through DirectAccess. Another way to verify DirectAccess functionality on the client end is to look at the connection status in the Networks bar. Figure 6-23 shows how a DirectAccess connection appears when it is available.

Image

FIGURE 6-22 DirectAccess automatically determines when a client is connected locally or remotely

Image

FIGURE 6-23 A DirectAccess connection as it appears in the Networks bar in Windows 8

Notice that the icon representing a DirectAccess connection in Figure 6-23 resembles a server. Contrast this DirectAccess icon with the VPN icon shown in Figure 6-24. These icons were first introduced in Windows Server 2012 and Windows 8. You need to be able to recognize both the DirectAccess and VPN icons for the 70-417 exam.

Image

FIGURE 6-24 A VPN connection as it appears in the Networks bar in Windows 8

Image Exam Tip

You should read the descriptions of the eight Group Policy settings available in the DirectAccess Client Experience Settings container within a GPO. You can find these settings in Computer Configuration\Policies\Administrative Templates\Network\DirectAccess Client Experience Settings. These settings allow you to tweak DirectAccess client behavior. For example, the Friendly Name setting allows you to specify a name other than Workplace Connection for the DirectAccess network connection. Another setting—Prefer Local Names Allowed—allows users to disconnect from NRPT rules and use normal, local DNS to resolve names and connect to local resources.

Objective summary

Image DirectAccess is a bidirectional, always-on alternative to a VPN that clients can use to connect to corporate resources while they are connected to the Internet. DirectAccess first appeared as a feature in Windows Server 2008 R2 and Windows 7, but since the release of Windows Server 2012 and Windows 8, DirectAccess deployment has been greatly simplified.

Image Windows Server 2012 and Windows 8 removed the requirement that DirectAccess clients authenticate themselves through computer certificates. Instead, Kerberos now is used as the default option.

Image Windows Server 2012 introduced several new infrastructure and topology options for DirectAccess, including support for multiple domains, support for multiple sites, deploying the DirectAccess server behind a NAT device, and load balancing through an NLB cluster.

Image In Windows Server 2012, DirectAccess and VPNs were unified in a new server role named Remote Access. To add the DirectAccess component of the Remote Access role, type the following at an elevated Windows PowerShell prompt:

Install-WindowsFeature DirectAccess-VPN -IncludeManagementTools

Image You can configure DirectAccess by completing four wizards corresponding to DirectAccess clients, the DirectAccess server, infrastructure servers, and application servers. These wizards include a number of features and options that can plausibly appear in test questions on the 70-417 exam. For this reason, it is recommended that you learn about all of the options in these wizards to prepare for the exam.

Objective review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of the chapter.

1. Which of the following is required to establish a DirectAccess connection between a Windows 8.1 client and a DirectAccess server running Windows Server 2012 R2?

A. A computer certificate on the client.

B. A user certificate on the client.

C. An IPv6 address on the client.

D. An IPv4 address on the client.

2. You are an administrator for a company with a network that includes 300 computers running Windows 8.1 and 20 servers running Windows Server 2012 R2. The network consists of a single domain named Contoso.com.

Your manager has asked you to begin testing DirectAccess with a group of 20 trial users in your organization. You deploy a single DirectAccess server on the company network edge and choose to implement computer authentication through Kerberos. You later ask the trial users to attempt to connect to the corporate network from outside the company premises. All users attempt to connect on domain-joined computers running Windows 8.1. Although most users are able to connect remotely to the corporate network, certain users working on desktop computers or virtual machines report that they cannot establish a connection. You would like to enable these users to connect to the corporate network through DirectAccess.

Which of the following Windows PowerShell commands is most likely to help you meet your goal?

A. Set-DAClient -OnlyRemoteComputers “Enabled”

B. Set-DAClient -OnlyRemoteComputers “Disabled”

C. Set-DAClient -ForceTunnel “Enabled”

D. Set-DAClient -ForceTunnel “Disabled”

3. You are an administrator for a company named Contoso.com with a network that includes 500 computers running Windows 8.1 and 30 servers running Windows Server 2012 R2. The network consists of a single domain named Contoso.com.

Many Contoso employees work on the road and only rarely visit the company premises. They currently connect to the company network by means of a VPN. You want to deploy DirectAccess so that you can apply software patches through System Center Configuration Manager. You don’t want to enable computers to access resources on the company network through the DirectAccess connection.

Which of the following Windows PowerShell commands will help you meet your goal?

A. Set-DAServer -DAInstallType ManageOut

B. Set-DAServer -DAInstallType FullInstall

C. Set-DAServer -HealthCheck “Enabled”

D. Set-DAServer -HealthCheck “Disabled”

Image Thought experiment: Configuring DirectAccess at Fabrikam

You work as a network administrator for Fabrikam.com, which is based in New York and has a branch office in London. The Fabrikam.com network includes three Active Directory domains. The Fabrikam.com domain includes resources in both the New York office and the London office. The Na.fabrikam.com domain includes resources that are mostly situated in the New York office, and Eu.fabrikam.com includes resources that are mostly situated in the London office. The domain name Fabrikam.com is also used for the company’s public website.

The servers on the network are running a combination of Windows Server 2008 R2 and Windows Server 2012 R2. The clients are running a combination of Windows 7 and Windows 8.1.

You are working with the rest of the IT department in planning for a DirectAccess deployment. Currently, users connect to the network remotely through a VPN. The VPN servers in both offices are running Windows Server 2008 R2.

You can find the answers to these questions in the “Answers” section.

1. The New York and London offices each include two resources within the Fabrikam.com domain, resources that some remote users might need to access through a DirectAccess connection. You want to ensure that DirectAccess clients connecting to resources within the Fabrikam.com domain perform DNS lookup of these resources by contacting internal DNS servers. You also want to make sure that DirectAccess clients connect to public DNS servers when attempting to connect to public website at www.fabrikam.com. What can you do to ensure that DirectAccess clients always contact the proper DNS servers when attempting to access resources with a domain suffix of fabrikam.com?

2. You want remote users to be able to automatically connect through a DirectAccess connection to the nearest entry point to the company network, whether it is in London or New York. How can you achieve this, and what requirements must first be met?

3. You want to ensure that when remote users from the New York office are connected through a DirectAccess connection and enter an address such as http://app1, that the address for app1.na.contoso.com is first queried for in DNS, followed by app1.eu.contoso.com. How can you achieve this?

4. Certain users connect to confidential resources when working remotely. For these users you want to configure two-factor authentication. However, you want to avoid the expense and administrative complexity of traditional smart cards. Which two alternative features can you consider in your environment to provide two-factor authentication?

Answers

This section contains the answers to the Objective Review and the Thought Experiment.

Objective 6.1: Review

1. Correct answer: C

A. Incorrect: In Windows Server 2012 R2 and Windows 8.1, Kerberos can be used in place of a computer certificate.

B. Incorrect: A user certificate is not required to establish a DirectAccess connection.

C. Correct: DirectAccess connections are based on IPv6 communication. If the DirectAccess client cannot obtain a global IPv6 address from its environment, the client must obtain one with the aid of an IPv6 transition technology.

D. Incorrect: IPv4 communication is not required for DirectAccess.

2. Correct answer: B

A. Incorrect: If only desktop computers and virtual machines are having trouble connecting through DirectAccess, this setting is most likely already enabled.

B. Correct: This command would disable the setting that limits DirectAccess connectivity to mobile computers only.

C. Incorrect: This setting would force all traffic from the client to pass through the DirectAccess connection. It would not help desktop and virtual computers establish a DirectAccess connection.

D. Incorrect: This setting would remove the requirement that clients force all traffic to pass through the DirectAccess connection. It would not help desktop and virtual computers establish a DirectAccess connection.

3. Correct answer: A

A. Correct: This command would deploy DirectAccess for remote management only.

B. Incorrect: This command would deploy full DirectAccess for client access and remote management.

C. Incorrect: This command would require NAP health checks on DirectAccess clients. It would not configure DirectAccess clients for management only.

D. Incorrect: This command would disable NAP health checks on DirectAccess clients. It would not configure DirectAccess clients for management only.

Thought experiment

1. You can configure the NPRT so that the four internal Fabrikam.com resources are associated with internal DNS servers.

2. You can enable a multisite deployment. You first need to make sure that the DirectAccess servers are running Windows Server 2012 or later, that the clients are running Windows 8 or later, and that your company has deployed a PKI.

3. Configure a DNS suffix search list in the Infrastructure Server Setup for the DirectAccess deployment for the Na.fabrikam.com domain.

4. You can consider virtual smart cards or OTPs.