Understand and Troubleshoot Remote Access in Windows ...15782B344FD85B... · Web viewDirectAccess implements IPsec Denial of Service Protection ... the deployment requires manual

Understand and Troubleshoot Remote Access in Windows Server "8" Beta

Microsoft Corporation

Published: February 2012

Abstract

This Understand and Troubleshoot Guide (UTG) enables you to learn technical concepts, functionality, and troubleshooting methods for Remote Access in Windows Server “8” Beta. This UTG provides you with:

A technical overview and functional description of this feature.

Technical concepts to help you successfully install, configure, and manage this feature.

User Interface options and settings for configuration and management.

Relevant architecture of this feature, with dependencies, and technical implementation.

Primary troubleshooting tools and methods for this feature.

Copyright informationThis document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

© 2012 Microsoft. All rights reserved.

Active Directory, Hyper-V, Microsoft, MS-DOS, Visual Basic, Visual Studio, Windows, Windows NT, Windows Server, and Windows Vista are trademarks of the Microsoft group of companies.

All other trademarks are property of their respective owners.

Table of ContentsWindows Server "8" Beta Understanding and Troubleshooting Guide: Remote Access Server Role..........1

About The Understanding and Troubleshooting Guide.......................................................................................1

Introducing the DirectAccess and RRAS Unified Server Role....................................................................................1

Technical Overview..................................................................................................................................................2

Prerequisites........................................................................................................................................................3

Functional Description.........................................................................................................................................3

Installing/Enabling the Remote Access Unified Server Role...................................................................................22

Installation Considerations................................................................................................................................22

Installation Process............................................................................................................................................24

Configuring and Managing Remote Access Server Role.........................................................................................31

Management Considerations.............................................................................................................................31

Configuration and Management UI...................................................................................................................31

DRAFT V5.0 Understand and Troubleshoot Remote Access in Windows Server "8" Beta

Windows Server "8" Beta Understanding and Troubleshooting Guide: Remote Access Server RoleAbout The Understanding and Troubleshooting Guide

Understanding and Troubleshooting Guides enable you to learn about technical concepts, functionality, and general troubleshooting methods for new Windows features and enhancements. The Understanding and Troubleshooting Guide supports you in developing understanding of key technical concepts, architecture, functionality, and troubleshooting tools and techniques. This understanding will enable more successful testing and early adoption experiences during the pre-release product evaluation phase, and will support early ramp-up of help desk and technical support roles.

Introducing the DirectAccess and RRAS Unified Server Role

Windows Server 2008 R2 introduced DirectAccess, a new remote access feature that allows connectivity to corporate network resources without the need for traditional Virtual Private Network (VPN) connections. DirectAccess provides support only for domain-joined Windows 7 Enterprise and Ultimate edition clients.

The Windows Routing and Remote Access Server (RRAS) provides traditional VPN connectivity for clients running previous Windows versions, third-party VPN clients, and non-domain members. RRAS also provides site-to-site connections between servers. RRAS in Windows Server 2008 R2 cannot coexist on the same edge server with DirectAccess, and must be deployed and managed separately from DirectAccess.

What Is the Windows Server "8" Beta Remote Access Server Role?Windows Server "8" Beta combines the DirectAccess feature and the RRAS role service into a new unified server role. This new Remote Access server role allows for centralized administration, configuration, and monitoring of both DirectAccess and VPN-based remote access services. Additionally, Windows Server "8" Beta DirectAccess provides multiple updates and improvements to address deployment blockers and provide simplified management.

Group or OrganizationMicrosoft Confidential - For Internal Use Only 1

Understanding and Troubleshooting Guide DRAFT V5.0Windows Server "8" Beta Understanding and Troubleshooting Guide: Remote Access Server Role

Purpose/BenefitsThe new unified server role for DirectAccess and RRAS provides a single point of configuration and management for remote access server deployment. Windows Server "8" Beta includes the following improvements over Windows 7 DirectAccess and RRAS.

• DirectAccess and RRAS coexistence

• Simplified DirectAccess management for small and medium organization administrators

• Removal of PKI deployment as a DirectAccess prerequisite

• Built-in NAT64 and DNS64 support for accessing IPv4-only resources

• Support for DirectAccess server behind a NAT device

• Simplified network security policy

• Load balancing support

• Support for multiple domains

• NAP integration

• Support for OTP (token based authentication)

• Automated support for force tunneling

• IP-HTTPS interoperability and performance improvements

• Manage-out support

• Multisite support

• Support for Server Core

• Windows PowerShell support

• User and server status monitoring

• Diagnostics

• Accounting and reporting

• Site-to-site IKEv2 IPsec tunnel mode VPN

Each of these improvements and sub features is described in detail in the following Technical Overview section.

Technical Overview

2 © 2012 Microsoft Corporation. All rights reserved.


PrerequisitesThis Understanding and Troubleshooting Guide assumes familiarity with previous releases of RRAS and DirectAccess, and does not provide foundation detail around their purpose and functionality. The focus of this guide is to provide information and guidance on the new features and improvements introduced in Windows Server "8" Beta.

More Information:For more information about RRAS and DirectAccess, see the TechNet Portal pages linked below:Routing and Remote Access -http://technet.microsoft.com/en-us/network/bb545655.aspxDirectAccess -http://technet.microsoft.com/en-us/network/dd420463.aspx

Functional DescriptionThe unified DirectAccess and RRAS server role in Windows Server "8" Beta introduces several functional improvements over the previous version of Windows Server. The sections below provide a functional description of each.

DirectAccess and RRAS CoexistenceBoth DirectAccess and RRAS implement security features to protect the server from hostile inbound traffic. These security feature settings conflict with each other if both services attempt to run on the same server, preventing either DirectAccess or RRAS from functioning as expected.

DirectAccess relies on Internet Protocol version six (IPv6) transition technologies to establish client connections. RRAS implements Internet Key Exchange version 2 (IKEv2) Internet Protocol security (IPsec), and configures incoming and outgoing packet filters to drop all packets using transition technologies. This results in DirectAccess traffic being blocked if RRAS is installed and VPN access is deployed with IKEv2.

DirectAccess implements IPsec Denial of Service Protection (DoSP) to protect resources on the corporate network. DoSP drops all IPv4 traffic, and all IPv6 traffic that is not protected by IPsec, except ICMPv6 packets. This results in all IPv4 packets and non-IPsec-protected IPv6 packets forwarded by RRAS being blocked if DirectAccess is installed.

Windows Server "8" Beta DirectAccess and RRAS unified server role solves these problems by modifying IKEv2 policies to allow IPv6 transition technology traffic, and by modifying IPsec DoSP to allow VPN traffic. These changes allow both DirectAccess and RRAS to coexist on the same server.


http://technet.microsoft.com/en-us/network/dd420463.aspx

http://technet.microsoft.com/en-us/network/bb545655.aspx


Simplified DirectAccess Management Windows Server "8" Beta DirectAccess includes features to facilitate deployment, particularly for small and medium size organizations. These new features include a simplified prerequisite list, removal of the need for a full PKI deployment, integrated certificate provisioning, and removal of the requirement for two consecutive public IPv4 addresses. Each of these features is discussed in more detail in the following sections.

Administrators can now deploy DirectAccess using a new Getting Started Wizard, which presents a greatly simplified configuration experience. The Getting Started Wizard masks the complexity of DirectAccess, and allows for an automated setup in a few simple steps. The administrator no longer requires an understanding of the technical details of things like IPv6 transition technologies and Network Location Server (NLS) deployment.

More Information:

Step-by-step guidance on running the Getting Started Wizard is provided in the Configuration and Management UI section of this document.Getting Started Wizard

Removal of PKI Deployment as a DirectAccess PrerequisiteOne major deployment blocker for Windows 7 DirectAccess is the requirement of a Public Key Infrastructure (PKI) for server and client certificate-based authentication. DirectAccess relies on IPsec AuthIP policies for authenticating and securing traffic from Internet-connected clients. In order to authenticate to domain resources using Kerberos, the client must first establish connectivity to DNS servers and Domain Controllers (DCs).

Windows 7 DirectAccess enables this connectivity by implementing two authentication methods in the AuthIP policies. The infrastructure IPsec tunnel is established using computer certificate as the first authentication method and user NTLM as the second method. Once this tunnel is established and a DC is available, the client can obtain a Kerberos token and establish the intranet IPsec tunnel using computer certificate and user Kerberos as the first and second authentication methods.

This implementation requires that the DirectAccess server and all clients be provisioned with computer certificates for mutual authentication. Managing an internal PKI is considered difficult by many small and medium organizations. Windows Server "8" Beta DirectAccess makes PKI deployment optional to simplify configuration and management.

This functionality is achieved by implementing an HTTPS based Kerberos proxy. Client authentication requests are sent to a Kerberos proxy service running on the DirectAccess server. The Kerberos proxy then sends Kerberos requests to Domain Controllers on behalf of the client.



The new Getting Started wizard provides a seamless experience for the administrator by configuring this solution automatically. In this simplified DirectAccess deployment, user level configuration options such as force tunneling, Network Access Protection (NAP) integration, and two-factor authentication are not available. This deployment requires only one IPsec tunnel to be established, and has the following requirements.

• The DirectAccess server must have TCP port 443 open on its firewall

• The DirectAccess server must have a server authentication certificate for TLS issued by a Certificate Authority (CA) that is trusted by the DirectAccess clients. This can be a public CA and does not require an internal PKI deployment. If no certificate is available, the DirectAccess server setup process will configure the necessary IP-HTTPS and KDC proxy certificate automatically as a self-signed certificate.

CORP

INTERNET

DA-Client

IP-https

DCIPSEC tunnel

Allows IPsec/Iphttps traffic DA-SRV with Server Certificates

Traffic to Corp

Figure 1 HTTPS Based KDC Proxy and DirectAccess

NAT64 and DNS64 Support for Accessing IPv4-only ResourcesWindows DirectAccess is an IPv6-only technology from a client perspective. This means that clients can only access intranet resources accessible via IPv6 while connected remotely, and only if the client application itself supports connecting to an IPv6 resource. Intranet applications or resources are accessible directly via IPv6 if they are listening on the internal server's IPv6 interface. For remote management of DirectAccess clients initiated by intranet computers, internal application or management servers must also be fully IPv6 compliant and the server applications they run must be IPv6 compatible.

To allow access to internal IPv4-only resources, Windows Server "8" Beta DirectAccess includes native support for a protocol translation (NAT64) and name resolution (DNS64) gateway to convert the IPv6 communication from a DirectAccess client to IPv4 for the internal servers. IPv4-only intranet computers cannot initiate connections to DirectAccess clients for remote management because the translation done with NAT64 is unidirectional (for traffic initiated by the DirectAccess client).

More Information:

For more information about NAT64 and DNS64, see the following Internet Drafts:NAT64 - HYPERLINK "http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-



stateful"http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-statefulhttp://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate http://tools.ietf.org/html/draft-ietf-behave-address-formatDNS64 - http://tools.ietf.org/html/draft-ietf-behave-dns64

There are three primary instances where IPv6-only DirectAccess does not allow full access to corporate intranet resources.

• Intranet servers that are not fully IPv6 capable and support only IPv4, such as Windows Server 2003 file servers

• Environments where IPv6 has been administratively disabled on the network

• Applications running on IPv6 capable servers (such as Windows Server 2008) which are not IPv6 capable themselves (such as applications that are not able to listen and respond to traffic on the IPv6 interface)

To access these resources over DirectAccess, protocol translation must be done between the DirectAccess server and the internal IPv4-only resources, with subsequent translation back to IPv6 for responses sent to DirectAccess clients. NAT64 receives IPv6 traffic from the client and converts it into IPv4 traffic to the intranet. NAT64 is used in combination with DNS64. DNS64 intercepts DNS queries from clients, and sends responses after converting IPv4 answers into associated IPv6 mappings on the NAT64.

Note:Prior to Windows Server "8" Beta DirectAccess, the only method available to provide protocol translation for DirectAccess is through deployment of Microsoft Forefront Unified Access Gateway DirectAccess

The DirectAccess setup wizard will seamlessly configure protocol translation components as a background operation, without any need for administrative interaction. There are no configuration options exposed to the administrator. The setup wizard will automatically enable NAT64 and DNS64 if the internal interface of the DirectAccess server has an IPv4 address assigned. To support this functionality, the setup wizard will configure an IPv6 network prefix for NAT64. The wizard assigns the NAT64 prefix automatically, and applies it to all IPv4 ranges in the enterprise. When a client attempts connection to an IPv4-only resource, the DirectAccess server returns an IPv6 address for the internal resource generated from this prefix.

Figure 2 below illustrates the basic process taken when a DirectAccess client NRPT is configured to send DNS queries to the IPv6 address of the DNS64 server.


http://www.microsoft.com/Forefront/edgesecurity/iag/en/us/UAG-DirectAccess.aspx

http://www.microsoft.com/Forefront/edgesecurity/iag/en/us/UAG-DirectAccess.aspx

http://tools.ietf.org/html/draft-ietf-behave-dns64

http://tools.ietf.org/html/draft-ietf-behave-address-format

http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate


Figure 2 DNS64 and NAT64 Workflow

1. The DirectAccess client queries the DNS64 service (running on the DirectAccess server) for the IPv6 AAAA record of the internal file server. Since DirectAccess clients use IPv6 only, the client will never query for an IPv4 A record, or accept an IPv4 A record in response to an IPv6 AAAA query.

2. The DNS64 server sends both the AAAA query and an A query for the internal file server to the internal DNS server. The AAAA query is sent first, followed by the A query after a time delay configurable in seconds.

3. The internal DNS server will respond with the AAAA answer, the A answer, or both, depending on which records have been registered with DNS.

4. If the internal DNS server responds with only an IPv6 AAAA record, the DNS64 server returns this address to the client. If the internal DNS server responds with only an IPv4 A record, the address returned is mapped to an IPv6 address using the NAT64 prefix, and this IPv6 address is returned to the client as a AAAA query response.

5. The client application initiates a connection to the IPv6 address returned by the DNS64 server.

6. NAT64 receives the IPv6 packet, and if the network prefix matches the NAT64 prefix, it translates the IPv4 address and port from the IPv6 packet. The NAT64 service then crafts an IPv4 packet with the original data payload and sends it to the IPv4 address of the internal file server. NAT64 maintains a mapping of the IPv6 address and port to the IPv4 address.

7. The file server sends an IPv4 response, which is converted back to the IPv6 address and port by the NAT64 service, using the mapping created in the previous step.

8. The translated IPv6 packet is then sent back to the client.



Important:DNS64 translation support is limited to A, AAAA, and PTR record types. All other DNS record types will be passed through to DNS without any further processing or translation.

Support for DirectAccess Server behind a NAT DeviceA Windows 2008 R2 DirectAccess server requires two network interfaces with two consecutive public IPv4 addresses assigned to the external interface. This is required so that it can act as a Teredo server. In order for clients behind a NAT to determine the Teredo server and the type of NAT device, the Teredo server requires two consecutive IPv4 addresses.

This requirement presents difficulty for small and medium organizations that do not have access to consecutive, public IPv4 addresses. In the future this has the potential to become a deployment blocker as the available IPv4 address space is exhausted. Windows Server "8" Beta DirectAccess provides the ability to deploy the DirectAccess server behind a NAT device, with support for a single network interface or multiple interfaces, and removes the public IPv4 address prerequisite.

When the Remote Access Services setup Getting Started Wizard or Remote Access Setup Wizard is run, it will check the status of network interfaces on the server to determine if the DirectAccess server is located behind a NAT device. In this configuration, only IP over HTTPS (IP-HTTPS) will be deployed. The IP-HTTPS protocol is an IPv6 transition technology that allows for a secure IP tunnel to be established using a secure HTTP connection.

Simplified Network Security PolicyWindows Server 2008 R2 DirectAccess uses two IPsec tunnels to establish connectivity to the corporate network. The DirectAccess client requires the infrastructure tunnel to access infrastructure resources such as DNS, DC, and Management servers. These infrastructure servers are all listed as endpoints in the infrastructure tunnel IPsec policy. Then the intranet tunnel provides access to all other corporate intranet resources.

The endpoints listed in the infrastructure tunnel policy require periodic updates as the infrastructure changes, such as when DNS servers or Domain Controllers are added to or removed from the production network. Clients can lose connectivity to the domain when their IPsec policies are not updated to reflect the current infrastructure server endpoints, and this loss of connectivity will prevent them from receiving group policy updates to correct the failure.

In Windows Server "8" Beta, the Simplified DirectAccess model provides a way to deploy DirectAccess over a single IPsec tunnel, which eliminates this problem (See Removal of PKI Deployment as a DirectAccess Prerequisite.) However, Simplified DirectAccess does not



support certain capabilities, which rely on certificate-based authentication. Examples are two-factor authentication with smart cards, and NAP integration. Enterprises requiring a full featured DirectAccess experience will still need to deploy the two-tunnel model.

If the two-tunnel model is required for full functionality, there is additional functionality available to enable administrators to refresh the list of servers that are made accessible via the infrastructure tunnel. New domain controllers and SCCM servers are discovered and added to the list. Servers that no longer exist are removed from the list, and entries for servers whose IP addresses have changed are updated.

This can be activated either from the Update Management Servers task in the Remote Access management console, or by calling the Update-DAMgmtServer Windows PowerShell cmdlet. In addition, the Get-DAMgmtServer Windows PowerShell cmdlet can be used to filter output by server type, enabling administrators to see all the domain controllers, SCCM servers and other management servers in the deployment.

Load Balancing SupportWindows Server 2008 R2 DirectAccess does not provide a full high availability solution, and is limited to single-server deployments. To provide limited hardware redundancy, DirectAccess can be configured inside a Hyper-V Failover cluster configured for Hyper-V Live Migration. However, only one server node may be online at any time.

DirectAccess deployments have quickly grown beyond the point where a single server can provide adequate processing power. Enterprises need the flexibility to deploy additional servers quickly and transparently to meet changing load requirements. Additionally, the Network Location Server used for inside/outside detection must be highly available to prevent major outages for DirectAccess clients connected to the intranet.

Windows Server "8" Beta DirectAccess addresses these issues through built-in support for Windows Network Load Balancing (NLB) to achieve high availability and scalability for both DirectAccess and RRAS. The NLB configuration is simple to setup and automate through the new deployment wizard interface. The setup process also provides integrated support for third party external hardware-based load balancer solutions.

Important:Windows Server "8" Beta DirectAccess provides a basic failover solution using Network Load Balancing for up to eight nodes. Although server load will be shared across all NLB nodes, existing connections will not automatically be transferred to other servers when one server becomes unavailable.

More Information:NLB Configuration is covered in the Configuring and Managing section of this



document.HYPERLINK "" \l "_NLB_Configuration"NLB Configuration

Support for Multiple DomainsThe DirectAccess setup wizard in Windows Server 2008 R2 can be used to configure DirectAccess for a single domain only. This means that remote clients from a different domain from the DirectAccess server will not be able to use DirectAccess. In addition, if application servers are in a different domain, remote clients will not be able to access them remotely via DirectAccess.

Although administrators can manually configure multiple domain support in Windows Server 2008 R2, the deployment requires manual edit of the DirectAccess policies after setup is completed. Windows Server "8" Beta DirectAccess provides integrated multiple domain support to allow remote client access to enterprise resources located in different domains.

NAP IntegrationWindows Server 2008 R2 DirectAccess supported the integration of Network Access Protection (NAP) by requiring a health certificate for the IPsec peer authentication of the intranet tunnel. A health certificate is a certificate with the System Health object identifier (OID). A NAP client can only obtain a health certificate from a Health Registration Authority (HRA) if it complies with system health requirements as configured on a NAP health policy server.

More Information:

For information about how to deploy NAP IPsec enforcement, see the IPsec Enforcement Design topic on TechNet:IPsec Enforcement Design

To integrate NAP with Windows Server 2008 R2 DirectAccess, the administrator must manually edit the Group Policy objects and policies created by the DirectAccess setup wizard after DirectAccess has been deployed. Windows Server "8" Beta DirectAccess provides the ability to configure a NAP health check directly through the setup user interface. This feature automates the policy modifications needed for NAP integration. NAP health check enforcement can be enabled from the Remote Access Setup Wizard.

Note:Although the new setup wizard simplifies NAP integration with DirectAccess, it does not automate the actual NAP deployment itself. An Administrator must configure the NAP IPsec enforcement and HRA infrastructure independently.


http://technet.microsoft.com/en-us/library/dd125391(WS.10).aspx


Support for OTP (Token Based Authentication)To increase login security, many organizations have deployed One-Time Password (OTP) two-factor authentication, and mandate its use for remote access connections. Windows Server 2008R2 DirectAccess provided support for two-factor authentication with Smart Cards, but was not capable of integrating with OTP vendor solutions, such as RSA SecurID. This prevented DirectAccess deployment in organizations that require this level of security.

Windows Server "8" Beta DirectAccess supports two-factor authentication with Smart Cards or OTP token based solutions. This feature requires a PKI deployment, so if the option is selected in the DirectAccess Setup Wizard, the “Use computer certificates” option is automatically selected and enforced.

In addition to support for standard smart card authentication, DirectAccess can use the Trusted Platform Module (TPM)-based virtual smart card capabilities available in Windows Server "8" Beta. The TPM of client computers can act as a virtual smart card for two-factor authentication, thus removing the overhead and costs incurred in smart card deployment.

Figure 3 Enable Two Factor Authentication

Automated Support for Force TunnelingBy default, DirectAccess clients are able to access the Internet, the corporate intranet, and local LAN resources simultaneously. Since only connections made to the corporate intranet are sent over the DirectAccess IPsec tunnels, this is known as a split-tunnel configuration. Split tunneling provides an optimal user experience when accessing resources on the Internet, while still providing strong security for traffic intended for the intranet.

Some administrators consider split tunneling to be a security risk. With VPN connections, the potential exists for users to bridge traffic between networks, such as a home network and the corporate network, effectively making the client operate as a router. For this reason, it is



common practice for administrators to disable split tunneling for VPN connections, forcing all network traffic to be routed through the VPN connection. This results in decreased performance when accessing Internet resources, since all traffic must traverse the VPN tunnel and then be proxied out to the Internet. It also consumes significant additional bandwidth on the corporate network.

The perceived security risk of split tunneling is not valid in a DirectAccess scenario, since the IPsec rules that enable DirectAccess require authentication by the client endpoint. If another endpoint attempts to route through the DirectAccess client, it will not be an authenticated source, and IPsec will prevent the connection. However, since some organizations have a requirement to force all traffic through the corporate proxy server so that it can be inspected, the DirectAccess Force Tunneling option provides this ability.

The Force Tunneling option was provided in Windows Server 2008 R2 DirectAccess, but required manual steps to enable it via group policy setting. Windows Server "8" Beta DirectAccess integrates the Force Tunneling option with the Setup Wizard and management UI to automate the required settings. Enabling the Force Tunneling option limits the DirectAccess client to using only the IP-HTTPS protocol for connectivity, and by default uses the DirectAccess server as the NAT64/DNS64 server to translate IPv6 resources to send to the IPv4 proxy server.

Figure 4 DirectAccess Client Force Tunneling option

IP-HTTPS Interoperability and Performance ImprovementsOn certain networks, Internet firewall settings may prevent successful client connections using the 6to4 or Teredo IPv6 transition technologies. IP-HTTPS is an IPv6 transition technology introduced in Windows 7 to ensure that DirectAccess clients can connect to the corporate network even when all other IPv6 transition technologies fail. IP-HTTPS assigns a unique, globally routable IPv6 address to an IPv4 host, encapsulates the IPv6 packets within



IPv4 for transmission over an HTTP tunnel, and routes IPv6 traffic between the host and other globally routable IPv6 nodes.

Windows Server "8" Beta DirectAccess provides several improvements to the implementation of IP-HTTPS. Changes to the technology allow IP-HTTPS clients to obtain proxy configuration information, and authenticate to an HTTP proxy if authentication is required. The Windows 7 requirement to deploy client certificates to each IP-HTTPS client has been removed.

IP-HTTPS works by creating an SSL/TLS connection between the client and server, then passing IP traffic across the connection. This data is encrypted by IPsec, which means that the data is encrypted twice, first by IPsec, and again by SSL. The result is poor performance and a negative user experience compared to the other IPv6 transition technologies 6to4 and Teredo, and limits the scalability of the DirectAccess server.

Windows Server "8" Beta DirectAccess includes several performance improvements for IP-HTTPS to increase scalability and reduce the overhead associated with this connectivity method. These optimizations include changes to batched send behavior and receive buffers, reduced lock contention, and the option to implement SSL with NULL encryption.

IP-HTTPS runs in a system context rather than a user context. This context can cause connection issues. For example, if a DirectAccess client computer is located in the network of a partner company that uses a proxy for Internet access, and WPAD auto detection is not used, the user must manually configure proxy settings in order to access the Internet. These settings are configured in Internet Explorer on a per user basis, and cannot be retrieved in an intuitive way on behalf of IP-HTTPS. In addition, if the proxy requires authentication, the client provides credentials for Internet access, but IP-HTTPS will not provide the credentials required to authenticate to DirectAccess. In Windows Server "8" Beta, a new feature solves these issues. Specifically, the user can configure IP-HTTPS to work when behind a proxy that is not configured using WPAD and IP-HTTPS will request and provide the proxy credentials needed to IP-HTTPS request authenticated, and relay it to the DirectAccess server.

When configuring IP-HTTPS in DirectAccess, you can use a certificate issued by a certification authority (CA), or you can specify that DirectAccess should automatically generate a self-signed certificate. A self-signed certificate is useful if you do not want to deploy a PKI.

Manage-out SupportDirectAccess clients establish connectivity to the corporate intranet whenever an Internet connection is available, even if there is no user logged in. This allows IT administrators to manage remote machines for patching and compliance enforcement even when they are not in the office. Some customers see this as the primary benefit to DirectAccess, and choose to keep their existing remote access solution in place for user connectivity, while using DirectAccess just for remote management.



Windows Server 2008 R2 DirectAccess does not provide an automated method to limit the deployment to manage-out only, and administrators must manually edit the policies created by the setup wizard. Windows Server "8" Beta DirectAccess provides support for a manage-out only configuration through a deployment wizard option that limits the creation of policies to only those needed for remote management of client computers. In this deployment, user level configuration options such as force tunneling, NAP integration, and two-factor authentication are not available.

Figure 5 Manage Out Only Deployment

Multisite SupportDirectAccess servers can be deployed in multiple sites to increase capacity and provide more efficient access to the nearest entry point for intranet resources. This works well if clients remain in their respective sites and do not need to travel to different sites within the enterprise. However, setting up multisite DirectAccess requires careful planning and design if clients will roam between sites, to ensure that they connect through DirectAccess servers via the most efficient route.

There are many challenges to consider in a multisite environment, such as making sure the client locates the closest IP-HTTPS server, Teredo server, DNS server, and Domain Controller. Windows Server "8" Beta DirectAccess provides a solution that allows for deployment of multiple DirectAccess entry points across geographic locations, and allows clients regardless of their physical location to access resources within corpnet in an efficient manner.

Windows Server "8" Beta Remote Access servers can be configured in a multisite deployment that allows remote users in dispersed geographical locations, or in the same geographic location for business continuity reasons, to connect to the multisite entry point closest to them. DirectAccess clients determine the nearest DirectAccess server based on the round trip time for the connection. For client computers running Windows 8 Consumer Preview, entry points can be assigned automatically, or selected manually by the client. For Windows 7 client



computers, entry points can be allocated statically. Traffic across the multisite deployment can be distributed and balanced with an external global load balancer.

More Information:

Multi-Site Configuration is covered in the Configuring and Managing section of this document.Multi-Site Configuration

Support for Server CoreServer Core is a minimal server installation option designed to reduce disk space, servicing, and management requirements, and decrease the operating system attack surface. The Server Core system does not support a Graphical User Interface, and administrators must use command line or remote management tools to accomplish all necessary configuration tasks.

A Server Core installation supports only a limited subset of the features available on a full installation of Windows Server, and currently does not include support for the DirectAccess feature or the RRAS role. A Windows Server "8" Beta Server Core installation includes support for the unified server role for both DirectAccess and RRAS.

The new Remote Access server role has complete Windows PowerShell support in Windows Server "8" Beta that may be used for installation, configuration and monitoring. The Remote Access server role can also be configured through remote server management.

Windows PowerShell SupportDirectAccess in Windows Server 2008 R2 lacks a complete scripting and command line interface for configuration options. Windows Server "8" Beta provides full Windows PowerShell support for the setup, configuration, management, monitoring and troubleshooting of the Remote Access Server Role.

More Information:

Detailed information on Windows PowerShell cmdlets for the Remote Access role is provided in the TechNet link belowWindows PowerShell TechNet Library

User and Server Status MonitoringMonitoring and diagnostics capabilities for both RRAS server and DirectAccess are limited in Windows Server 2008 R2. For DirectAccess, the monitoring capabilities only include basic status monitoring of the DirectAccess and its components. The monitoring data and statistics available are of little significance or relevance to administrators.


http://technet.microsoft.com/library/hh801904.aspx


User and server status monitoring introduced in Windows Server "8" Beta allows the administrator to understand the behavior of the DirectAccess clients and connections. The monitoring console is used to keep track of the load on the DirectAccess server, user activity, current resource usage, and operational status of the server. The administrator uses this information to identify potentially undesirable or inappropriate usage activities. Diagnostic tracing can be enabled from the monitoring console as well.

User MonitoringAdministrators of remote access solutions require the ability to monitor not only which users are connected, but also which resources they are accessing. If users complain that a particular server or file share is inaccessible while remote, the administrator currently has no way to determine if other users are successfully accessing the resource from the remote access console. Multiple tools and applications are typically needed to troubleshoot issues such as particular users consuming excessive bandwidth.

Administrators desire the following capabilities in a remote access monitoring and tracking solution:

• Ability to see all active connections

• A way to track which users are accessing which resources

• Ability to track connection statistics

• Traffic and bandwidth utilization data for each user and connection

• A centralized console to display data from all remote connectivity methods, whether via VPN or DirectAccess

The Dashboard is accessed from the new Remote Access server management console by selecting the Dashboard tab in the navigation pane. The dashboard displays overall operational status and remote client activity and status. The administrator can also view quick reports directly from the dashboard.

The Remote Access Dashboard shows a summary of remote client connectivity status for the following items. The information is generated from the relevant Performance Monitor counters and accounting data.

• Total number of active remote clients connected – includes both DirectAccess and VPN remote clients

• Total number of active DirectAccess clients connected – only the total number of clients connected using DirectAccess

• Total number of active VPN clients connected – only the total number of clients connected using VPN

• Total unique users connected – includes both DirectAccess and VPN users, based on the active connections (this counter is available only when WID accounting is enabled)



• Total number of cumulative connections – the total number of connections serviced by the Remote Access Server since the last server restart

• Maximum number of remote clients connected – the maximum concurrent remote users connected to the Remote Access Server since the last server restart

• Total data transferred – the total inbound and outbound traffic from the Remote Access Server for both DirectAccess and VPN since the last server restart

• Inbound traffic – Total bytes/traffic into the remote access server/gateway

• Outbound traffic – Total bytes/traffic out of the remote access server/gateway

In a cluster deployment, the Remote Client Activity and Status summary on the Remote Access Dashboard displays total values for all of the cluster nodes.

Administrators can see a list of all remote users currently connected, and can display a listing of all resources being accessed by clicking on a particular remote user. Administrators can display remote user statistics by selecting the Remote Client Status link in the Remote Access Management Console. The user statistics can be filtered based on criteria selections using the following fields:

Field Name Value

User Name The user name or alias of the remote user. For DirectAccess, if only 1st tunnel is present, then this field is blank (“-“)

Host Name The computer account name of the remote user. An IPv4 or IPv6 address can be specified as well.

Type Either DirectAccess or VPN. If DirectAccess is selected, then all remote users connecting using DirectAccess are listed. If VPN is selected, then all remote users connecting using VPN are listed.

ISP Address The IPv4 or IPv6 address of the remote user

IPv4 Address The inner IPv4 address of the tunnel connecting the remote user to the corporate network

IPv6 Address The inner IPv6 address of the tunnel connecting the remote user to the corporate network

Protocol/Tunnel The transitioning technology used by the remote client – Teredo, 6to4 or IP-HTTPS in case of DirectAccess users, and PPTP, L2TP, SSTP or IKEv2 in case of VPN users

Duration The duration/time since the remote client is connected

Total Bytes In Total data traffic received by the server for the session

Total Bytes Out Total data traffic flowing out of the server for the session

Connection Start Time The time stamp when the session was formed



Health Status This is relevant only for VPN. Values can be Healthy, Limited Access, Probation or Unknown based on NAP status.

Authentication Method For DirectAccess, this will be based on IPsec and can have values like Machine Kerberos and User Kerberos, Machine Certificate and UserNTLM, etc.For VPN, the values can be MSChapv2, Eap MSChapv2, EAP TLS, PEAP TLS, etc.

Server Operational StatusThis feature allows administrators to manage and monitor the status of remote access deployments from a centralized monitoring console. The feature alerts administrators whenever an issue requiring attention is detected. The interface displays detailed diagnostic information with steps to provide resolution.

The Dashboard node of the console tree shows the status of the Remote Access Server, including the status of remote access infrastructure and related components.

Figure 6 Remote Access Dashboard Server Status

The Server Operations Status node of the console tree shows the status of the Remote Access Server, including the status of remote access infrastructure and related components. By clicking on a particular component, administrators can see the state, change history, and monitoring details for that component.

If remote access servers are deployed in a cluster or multisite deployment, all servers in the cluster or multisite deployment are evaluated asynchronously, and are listed with their



overall status. Administrators can scroll through the list of servers and expand or collapse the view to display DirectAccess and VPN server components.

Figure 7 Server Operations Status

The Remote Access components with status monitors displayed in the Server Operations Status pane are listed below.

• 6to4

• DNS

• DNS64

• Domain controller

• IP-HTTPS

• IPsec

• ISATAP

• Kerberos

• Management Servers

• NAT64

• Network Adapters

• Network Location Server

• Network Security (IPsec DoSP)

• Services

• Teredo

• Load Balancing

• VPN addressing

• VPN connectivity



DiagnosticsTroubleshooting remote access connectivity failures for both RRAS and DirectAccess can be very complex due to the limited logging capabilities currently provided. Administrators typically require Network Monitor captures and RRAS tracing for troubleshooting, since Event Viewer logs are not very useful or prescriptive.

Windows Server "8" Beta provides the following diagnostic feature improvements for remote access troubleshooting.

Detailed event logging for DirectAccess

Administrators can use improved event logging to identify problems and perform capacity and performance analysis. The event logs are standardized to ensure a consistent experience with other networking components.

Tracing and Packet Capture

Integrated tracing makes it easy for administrators to gather trace logs and network packet captures with a single click. Both tracing with packet capture and log correlation are done as part of a single process when the administrator clicks the Start tracing task in the Tasks pane.

Log Correlation

This feature provides automated collection and correlation of logs for different DirectAccess components with a single click, leveraging the Unified Tracing feature of Windows. The events gathered from different components are consolidated into a single file through correlation of Activity IDs. Activity IDs are GUIDs that identify a particular task or action. When a component logs an event, it associates an Activity ID with the event. The component then passes either this ID or a transfer event mapped to the ID to the component that performs the next task in the scenario, which associates its activity ID to log events. When analyzing the resulting trace file, the relationship between the various components relevant to a scenario can be reconstructed.

Enabling/Viewing Logs

Logging can be enabled from the Tasks pane of the Remote Access Dashboard, or from the command line, which also controls logging levels, keywords and filters. The resultant Unified Tracing ETL files generated can be read and viewed using Network Monitor.

Accounting and ReportingA Windows Server "8" Beta remote access server can leverage an existing RADIUS server deployment or Windows Internal Database (WID) for accounting purposes. The NPS accounting store only contains user statistics, and server statistics and configuration changes



are not stored in the remote accounting store. Information and historical data for load and server status are available through system Performance Monitor counters, and are stored in the WID accounting store. Whenever any connection is received or disconnected on the remote access server, all the remote user statistics (including the endpoints accessed) is saved in the accounting store as one user session. This allows session details to later be accessed for reporting and auditing purposes.

The accounting and reporting functionality provided in the Remote Access Server Role includes the ability to measure specific metrics. Available metrics include the number of users connected to a particular DirectAccess server, access status, and total bytes transferred. Administrators can create custom reports to identify traffic and usage patterns, including a history of these patterns.

Accounting settings can be configured from the Reporting node of the Remote Access management console.

Figure 8 Configure Accounting

DirectAccess and RRAS reporting capabilities enable administrators to generate rich usage reports on various user and server statistics such as remote user statistics, server availability and load. The inbox accounting store is leveraged to generate the usage report. Inbox accounting to a local WID database must be enabled in order to generate usage reports. NPS/RADIUS accounting is not used for generating reports.

The usage report provides a display of usage history including which users established remote connections, what resources they accessed, the total number of unique users, and



maximum server load generated. The administrator can select a specific timeframe from which to generate the data.

Figure 9 Remote Access Reporting

Site-to-site IKEv2 IPsec tunnel mode VPNCross Premise Connectivity is a Windows Server "8" Beta feature that provides the network connectivity to enable service hosting providers to migrate their applications and infrastructure to the cloud. This feature includes a site-to site Internet Key Exchange version 2 (IKEv2) tunnel mode VPN connectivity solution and management interface. Windows Server 2008 R2 introduced IKEv2 support in RRAS for VPN connections. An IKEv2 VPN provides resilience to the VPN client when the client moves from one network to another or when it switches from a wireless to a wired connection. The use of IKEv2 and IPsec allows support for strong authentication and encryption methods. Windows Server "8" Beta RRAS provides added feature enhancements to enable IKEv2 for site-to-site VPN connections.

Installing/Enabling the Remote Access Unified Server RoleInstallation Considerations

Deployment ScenariosThe combined Remote Access server role for DirectAccess and RRAS can be deployed in three ways, depending on the intended method of remote access. Both RRAS and DirectAccess can



be deployed alone, or they can be collocated on the same Windows Server "8" Beta server. If an organization has only Windows 7 and Windows 8 Consumer Preview remote clients, they would typically deploy DirectAccess. If the organization has additional remote clients running legacy operating systems such as Windows Vista or Windows XP, or unmanaged clients, they should deploy DirectAccess and VPN. The three deployment choices are as follows.

Legacy Mode – RRAS only

Rich Experience without VPN – DirectAccess only

Rich Experience with VPN – both DirectAccess and VPN

Administrators can configure the Remote Access Role using either an Getting Started Wizard or Remote Access Setup Wizard, and can configure the role in either Legacy Mode (VPN only), Rich Experience (DirectAccess only), and Rich Experience (DirectAccess and VPN). The role configuration wizard provides a selection between the three deployment scenarios after the server role has been installed.

Planning and DesignThe new server role can be added to a clean install of Windows Server "8" Beta server, or it can be installed during an operating system upgrade of an existing server. If the existing server has RRAS or DirectAccess installed, the new Remote Access Server Role will automatically be installed, and will retain all remote access settings previously defined. The following table lists the supported upgrade scenarios.

Table 1: Supported Upgrades

Server Operating System RRAS installed as NPAS role service

DirectAccess installed as feature

Windows Server 2003 SP2 Supported.Upgrades to Windows Server "8" Beta DirectAccess & Routing/Remote Access Services Server role and retains RRAS configuration.

Not Applicable

Windows Server 2008 Supported.Upgrades to Windows Server "8" Beta DirectAccess & Routing/Remote Access Services Server role and retains RRAS configuration.

Not Applicable

Windows Server 2008 R2 Supported.Upgrades to Windows Server "8" Beta DirectAccess &

Supported.Installs Windows Server "8" Beta DirectAccess &



Server Operating System RRAS installed as NPAS role service

DirectAccess installed as feature

Routing/Remote Access Services Server role and retains RRAS configuration.

Routing/Remote Access Services Server role and retains DirectAccess configuration.

Administrators can also export RRAS configuration from previous Windows server versions and import the settings into the new Windows Server "8" Beta Remote Access Server Role. If RRAS configuration is exported from Windows Server 2003 SP2, Windows Server 2008, or Windows Server 2008 R2, it will be imported to the new Windows Server "8" Beta server in legacy mode.

Windows Server 2008 R2 DirectAccess does not support configuration export, so there is no method available to migrate existing DirectAccess settings aside from an in-place upgrade.

Installation ProcessThe unified Remote Access server role integrates with the Server Manager (SM) console for installation and uninstallation. The SM console eases the task of managing and securing multiple server roles through the Add Roles and Features Wizard (ARFW).

The Server Roles tab of the ARFW displays the new server role named Remote Access. This new unified role encompasses both DirectAccess which was previously a feature in Windows Server 2008 R2 and Routing and Remote Access Services which was previously a role service under the Network Policy and Access Services (NPAS) server role.

Installation UI/WizardRun the ARFW by clicking Add roles and features in the Windows Server "8" Beta Server Manager Dashboard.



Figure 10 Server Manager Dashboard

Click Next on the ARFW introduction.

Figure 11 Add Roles and Features Wizard

Click Next to select Role-based or feature-based installation.



Figure 12 Intsallation Type

Select the server on which to install the Remote Access role, and click Next.

Figure 13 Server Selection

Select Remote Access under Server Roles. The Remote Access server role provides seamless remote access to a corporate network for remote offices or mobile workers using DirectAccess and VPN/dial-up.



Figure 14 Add Roles Wizard

Select Add Features when prompted. The Add Roles wizard then presents an Introduction page to explain options for role deployment.

Figure 15 Add Roles Wizard Introduction

There are two role services installed by the Remote Access server role.



DirectAccess & VPN (RAS) – This service hosts DirectAccess, which was previously a feature in Windows Server 2008 R2, and Remote Access Services. This role service is selected by default.

Routing – This role service will host the Routing components of the legacy NPAS/RRAS server role. This is not selected by default.

Figure 16 Add Roles Wizard Select Role Services

The Remote Access Server Role is dependent on the following server features –

Web Server Role (IIS) – This feature is required to configure the Network Location Server (NLS) and default web probe.

Windows Internal Database (WID) – This feature is required by the Remote Access Server role for internal/local accounting purposes. NPS and RADIUS accounting may be used for remote accounting, but reporting can only be achieved if local accounting is present.

Group Policy Management Console feature – This feature is required by DirectAccess to create and manage the Group Policy Objects (GPOs) in Active Directory and must be installed as a required feature for the server role.

Connection Manager Administration Kit (CMAK) – This feature is required to create VPN profiles for distribution to clients. CMAK automates creation of VPN profiles for remote clients that are not joined to the domain, and clients running Windows versions prior to Windows 7, which cannot use DirectAccess. All required CMAK components are installed to enable silent profile creation for both 32-bit and 64-bit platforms.



After selecting the role services, an installation summary page is displayed for administrator confirmation.

Figure 17 Add Roles Wizard Installation Confirmation



Verifying Installation

Figure 18 Successful Installation Confirmation

Uninstalling/DisablingThe Windows Server "8" Beta Remote Access Server Role integrates with the Server Manager (SM) console for installation and uninstallation. The SM console eases the task of managing and securing multiple server roles through the Remove Roles and Features Wizard (RRFW). The uninstallation process ensures that all optional components are also removed, and removes all registry entries, configuration, and binaries that were created by the server role.

A pre-uninstall warning dialogue prompts the user with a warning dialog if there are active connections to the server.



Figure 19 Remove Roles and Features Wizard

Configuring and Managing Remote Access Server RoleManagement Considerations

Administrators can use either the Getting Started Wizard or the Remote Access Setup Wizard to configure DirectAccess and RRAS. The Getting Started Wizard simplifies deployment options by using recommended default settings. The Getting Started Wizard masks the complexity of DirectAccess, and allows for an automated setup in a few simple steps. The Remote Access Setup Wizard allows greater control of the configuration and deployment options.

Configuration and Management UIThe Remote Access Server Role provides an option to configure the role immediately after successful installation has completed by using the Getting Started Wizard. Both the Getting Started Wizard and the Remote Access Setup Wizard can be launched from the Remote Access Management Console as shown below.



Figure 20 Remote Access Management Console

Getting Started WizardThe figure below shows the Getting Started Wizard Welcome screen.

Figure 21 Getting Started Wizard



The Getting Started Wizard will first check for existence of all prerequisites to determine if all conditions have been met to deploy DirectAccess and RRAS. Before deploying remote access, the following prerequisites are checked.

The DirectAccess server must be joined to a reachable Active Directory domain

If the Windows Server "8" Beta server is not a domain member, the process to join a domain can be invoked from the Getting Started Wizard. Since this requires a server restart, setup will resume automatically once the reboot completes.

DirectAccess configuration can be completed only by a domain user who has Local Administrator rights on the DirectAccess server

The account used must also be a member of the Account Operators group, Domain Admins group, or the Enterprise Admins group in Active Directory, or must have been delegated the appropriate authority needed to create security groups in AD

IPv6 transition technologies must not be explicitly disabled on the server via Group Policy settings.

The DisabledComponents registry value is queried at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters to ensure that IPv6 and its specific components have not been disabled via the registry settings.

More Information:

For more information on how IPv6 components may be disabled via the registry, see KB article 929852:How to disable IP version 6 (IPv6) or its specific components in Windows 7, in Windows Vista, in Windows Server 2008 R2, and in Windows Server 2008

The IP Helper Service must be running on the DirectAccess server

A compatible firewall must be detected, and Windows Firewall must be responsible for processing connection security rules

Valid network interfaces must be found, must be connected to a network, and must not be disabled

A single network interface can be used only if a suitable certificate exists for use with IP-HTTPS. If an IP-HTTPS certificate is not found, the setup process will create a self-signed certificate.

Note:If a single network interface is detected on the server, then only IP-HTTPS is deployed for DirectAccess client connectivity.

The wizard will display warning or error text if DirectAccess prerequisites have not been met.

Next, the wizard prompts the administrator to select the network topology in which the DirectAccess server will be deployed. The topology selected will be dependent on the number of network interfaces on the server, and whether a NAT device is employed. The topology choices available are edge topology, back topology, and single network adapter.


http://support.microsoft.com/kb/929852

http://support.microsoft.com/kb/929852


• Edge - The server has two network interfaces, with one connected to the public network and one connected to the intranet

• Behind an edge device (with two network adapters) - The server has two network interfaces, with one connected to the intranet. The DirectAccess server is behind a NAT device.

• Behind an edge device (single network adapter) - The DirectAccess server has one network interface connected to the intranet, and the server is behind a NAT device.

The wizard prompts the administrator to enter the public DNS name or IP address to which the remote clients will connect. In a typical DirectAccess deployment with two network interfaces on the server, one with a public address and firewall profile and a second connected to the internal network with a domain firewall profile assigned, the administrator should add the external DNS name or external IP address of the DirectAccess server. If the DirectAccess server is behind a NAT device, the administrator should add the external DNS name or public IP address of the NAT device. The name or address entered here must match the subject name of the IP-HTTPS certificate.

Figure 22 Network Topology Selection

DirectAccess IPv6 Transition TechnologiesThe Getting Started Wizard will categorize the server network interfaces automatically based the Windows Firewall profile assigned to each interface. If the wizard finds two interfaces, one with a public or private profile and one with a domain profile, it will categorize the public or private interface as the Internet interface and the domain one as the intranet interface.



If more than one interface has a domain or public/private profile assigned, the administrator can change the auto-populated value assigned to the interfaces in the Getting Started Wizard, through the Review page.

IPv6 transition technologies will be enabled using the following logic:

• If the DirectAccess server has a public interface with two consecutive public IP addresses, 6to4 will be enabled by the Getting Started Wizard. If the Remote Access Setup wizard is used, Teredo will also be enabled. If a certificate suitable for use with IP-HTTPS is found, IP-HTTPS will be enabled. If no suitable certificate is found, the wizard will automatically provision a self-signed certificate and enable IP-HTTPS.

• If the DirectAccess server is behind an edge device with two network interfaces, only IP-HTTPS will be enabled. If a certificate suitable for use with IP-HTTPS is found, IP-HTTPS will be enabled with this certificate. If no suitable certificate is found, the wizard will automatically provision a self-signed certificate and enable IP-HTTPS.

• If the DirectAccess server has a public interface with one public IP addresses, 6to4 will be enabled. If a suitable IP-HTTPS certificate is found, IP-HTTPS will also be enabled. If no suitable certificate is found, the wizard will automatically provision a self-signed certificate and enable IP-HTTPS.

• If all the interfaces have the domain profile assigned, or if the server is behind an edge device with two interfaces, only IP-HTTPS will be enabled.

RRAS ConfigurationIf the administrator has selected the VPN deployment option, the Getting Started Wizard will use recommended default settings when configuring RRAS. The following default settings are configured.

1. Internet Interface – DirectAccess configuration automatically detects the public and private interfaces on the server, and VPN setup will configure the Internet interface detected as public by the DirectAccess configuration.

2. Static Packet Filters – RRAS setup for VPN normally creates static packet filters to allow only VPN traffic to gain access to the server through the Internet interface. Since DirectAccess will also use the same Internet interface for IPsec traffic, static filters are disabled by the Getting Started Wizard.

3. Internal Interface – RRAS setup will use the same interface determined previously by DirectAccess setup as the intranet-connected interface. If there is only one interface on the server, setup will use this for both Internet and Internal interfaces.

4. IP Address Assignment – The VPN server can be configured to assign IP addresses by either DHCP or from a static pool of IP addresses. The Getting Started Wizard will assume DHCP IP addressing by default. If DHCP is not deployed on the network or the



administrator does not want to use DHCP IP addressing, this setting can be changed later from the Review page of the Getting Started Wizard.

5. Connection Authentication – VPN connection requests can be authenticated locally, or forwarded to a Remote Authentication Dial-In User Service (RADIUS) server for authentication. Since DirectAccess and RRAS are not part of the Network Policy and Access Services (NPAS) server role, NPS is not installed by default. The Getting Started Wizard will default to using local authentication rather than RADIUS.

6. VPN Profile – Remote clients running legacy versions of Windows can use a VPN profile to connect to the RRAS server. Administrators can export the VPN profile, which will automatically create a CMAK package for VPN client. The profile is created without any user intervention by running the CMAK wizard as a background operation.

The final wizard step is to select Finish to apply the configuration. Optionally, select the link to review the configuration using the Configuration Review Page.

Figure 23 Final Configuration Step

If the administrator chooses to review the configuration prior to applying it, changes can be made from the following dialog.



Figure 24 DirectAccess Configuration Review

Remote Access Setup WizardThe Remote Access Setup Wizard allows for greater control of customized DirectAccess and Remote Access configuration options and settings. Launch the wizard via the Run the Remote Access Setup Wizard link in the Remote Access Management Console (RAMC).



Figure 25 Remote Access Setup Wizard

The Remote Access Setup Wizard first checks installation prerequisites and displays warning text if any conditions are not met. The RAMC then displays a console interface for configuring a four step process of setting DirectAccess options.

Step 1 - Remote Clients

Step 2 - Remote Access Server

Step 3 - Infrastructure Servers

Step 4 - Application Servers



Figure 26 Remote Access Setup Wizard Four Step Configuration

Click Configure under each step sequentially to provide the necessary configuration options.

Step 1 - Remote ClientsThe first option presented is whether to allow full DirectAccess connectivity for clients or to deploy DirectAccess in a manage-out scenario only.

Figure 27 Client Deployment Scenario

More Information:

For more information about the DirectAccess manage-out scenario, see the relevant section of this document.Manage-out Support



Next, select one or more security groups of client computers to enable for DirectAccess. Specify whether to deploy settings to laptop and notebook computers only and whether force tunneling is required. If the administrator chooses to deploy DirectAccess settings to only laptop and notebook computers, the wizard will add a WMI filter to the associated DirectAccess Client Settings group policy object to limit the GPO application to only mobile computers.

Figure 28 Client Deployment Options

More Information:

For more information about the DirectAccess force tunneling option, see the relevant section of this document.Automated Support for Force Tunneling

Finally, provide options for the Network Connectivity Assistant (NCA). NCA runs on DirectAccess client computers to provide connectivity information, diagnostics, and remediation support. The following options are available:

• Corporate resources can be specified to validate connectivity to the internal network. Each string can be one of the following types:

o An IPv6 address or DNS name to ping

o A Uniform Resource Locator (URL) to query with an HTTP request.

NCA periodically checks its ability to access the specified resources, and it uses the results of those tests to determine and report the connectivity status of DirectAccess.

• A helpdesk email address can be specified to be used when the user selects the option to transmit log files to the DirectAccess administrator. When the user clicks Email Logs, the default e-mail client opens a new message with the specified address in the To: field of the message, and attaches the generated log files as a .html file. The user can review the e-mail



and add additional information before clicking Send. Where no email address is specified, NCA will not provide the ability to collect logs.

• The DirectAccess connection name allows the administrator to customize the friendly name of the DirectAccess connection.

• The option Allow DirectAccess clients to use local name resolution allows users to bypass the NRPT when they are outside the corporate network, and effectively disable DirectAccess temporarily.

Figure 29 NCA Options

Step 2 - DirectAccess ServerStep 2 of the DirectAccess deployment Remote Access Setup Wizard prompts the administrator to select the network topology in which the DirectAccess server will be deployed. The topology selected will be dependent on the number of network interfaces on the server, and whether a NAT device is employed. The topology choices available are edge topology, back topology, and single network adapter.

• Edge - The server has two network interfaces, with one connected to the public network and one connected to the intranet

• Behind an edge device (with two network adapters) - The server has two network interfaces, with one connected to the intranet. The DirectAccess server is behind a NAT device.

• Behind an edge device (single network adapter) - The DirectAccess server has one network interface connected to the intranet, and the server is behind a NAT device.

The wizard prompts the administrator to enter the public DNS name or IP address to which the remote clients will connect. In a typical DirectAccess deployment with two network interfaces on the server, one with a public address and firewall profile and a second



connected to the internal network with a domain firewall profile assigned, the administrator should add the external DNS name or external IP address of the DirectAccess server. If the DirectAccess server is behind a NAT device, the administrator should add the external DNS name or public IP address of the NAT device. The name or address entered here must match the subject name of the IP-HTTPS certificate.

Figure 30 Topology Selection

Click Next to access the network adapters configuration screen. The wizard automatically populates the Internet and internal interface connections based on the firewall profiles assigned to each interface. Select the certificate to be used for IP-HTTPS connections. If the wizard does not find an appropriate certificate, it will create a self-signed certificate. If a self-signed certificate is used, the wizard will add the DirectAccess server self-signed certificate to the trusted root store on DirectAccess client computers as part of the client-specific GPO.



Figure 31 Network Adapters

On the prefix configuration screen, confirm the prefixes to be used for internal and external connectivity.

Figure 32 Prefix Configuration

On the authentication settings screen, specify whether to configure DirectAccess in a single IPsec tunnel deployment with IP-HHTPS and Kerberos proxy, or a two-tunnel deployment with client certificates. Specify username and password-based authentication only for single IPsec tunnel connectivity, or specify a root certificate authority to which remote client certificates must chain to configure a two-tunnel deployment. To enable support for two-factor authentication, health check enforcement with NAP, or to enable connectivity by Windows 7 clients, certificate-based computer authentication is required.



Figure 33 Authentication Settings

Step 3 - Infrastructure ServersThe infrastructure server setup step configures the Name Resolution Policy (NRPT) client GPO settings for DirectAccess. First, specify whether the Network Location Server (NLS) is run on the DirectAccess server itself, or on another highly available server.

Figure 34 NLS Setting

Next, enter the DNS suffixes and IP addresses of the internal DNS servers. Remote clients will use this list in the NRPT to determine which queries should be directed to internal DNS



servers. Set the desired behavior of clients for fall back to local name resolution in the event of failure to resolve names using the internal DNS servers.

Figure 35 NRPT Settings

On the final infrastructure server setup screen, provide a list of management servers by IP address, IPv6 prefix, or host name.

Figure 36 Management Servers

Step 4 - Application ServersStep 4 of the Remote Access Setup Wizard is to identify application servers that will be restricted using IPsec. This feature provides a simple way to integrate the Server and Domain Isolation (SDI) solution into a DirectAccess deployment.



Figure 37 SDI Settings

After configuring the options in each of the four steps, click Finish in the Remote Access Management Console. Review the configuration summary page, and click Apply.

Figure 38 DirectAccess Settings Review

The wizard displays a progress dialog to show status of the deployment. After the applying the remote access settings, the wizard displays a confirmation dialog.



Figure 39 Remote Access Wizard Progress Dialog

NLB ConfigurationPrerequisites

To accommodate multiple DirectAccess servers in a load balancing cluster, the length of the RRAS prefix and the prefix used to assign IPv6 addresses to DirectAccess clients connecting over IP-HTTPS should be 59 bits. Prior to enabling load balancing for DirectAccess, modify the prefix configuration assigned in Step 2 of the Remote Access Setup Wizard if necessary.

Figure 40 IPv6 prefix assigned to client computers



Windows Server "8" Beta Remote Access provides support for external hardware load balancers as well as Windows Network Load Balancing (NLB). To use Windows NLB, you must first install the Network Load Balancing feature on each DirectAccess server node.

Figure 41 Add Network Load Balancing Feature

Enable Load Balancing for Remote AccessHigh Availability configuration is enabled through the Configuration node of the Remote Access Management Console.



Figure 42 Create High Availability Setup

The setup provides support for an external load balancer, or configuring NLB on the DirectAccess and RRAS servers.



Figure 43 Select Load Balancing Method

If the administrator selects the option to use Windows NLB, the IP addresses assigned to the server interfaces are converted to virtual IP (VIP) addresses. The administrator is then prompted to specify corresponding dedicated IP (DIP) addresses and subnet masks for each interface.

Figure 44 External Dedicated IP Addresses



Figure 45 Internal Dedicated IP Addresses

Review the configuration settings on the Summary page, and then click Commit.

Figure 46 Load Balancing Configuration Summary



Add or Remove Servers from the NLB ArrayAfter successfully applying the load balancing settings, you can add a server to the load-balancing array by selecting the Add or Remove Servers task.

Figure 47 Add or Remove Load Balanced Cluster Servers

In the Add or Remove Servers dialog, click Add Server.



Figure 48 Add or Remove Servers

Type the name of the server to add to the load balanced cluster, and then click Next.

Figure 49 Add Server Wizard Select Server

Specify internal and external network adapters, and select the certificate used to authenticate IP-HTTPS connections.



Figure 50 Add Server Wizard Network Interfaces

Review the configuration settings on the Summary page, and then click Add.

Figure 51 Add Server Wizard Summary



Figure 52 Add Server Wizard Completion

The Add or Remove Servers wizard is now populated with the list of array members. Click Commit to apply the changes.

Figure 53 NLB Add or Remove Servers Wizard

Multi-Site ConfigurationWindows Server "8" Beta DirectAccess provides a solution that allows for deployment of multiple DirectAccess entry points across geographic locations, and allows clients regardless of their physical location to access resources within the corporate network in an efficient



manner. A multi-site DirectAccess deployment automatically connects clients to the DirectAccess server entry point closest to them, and supports failover from one entry point to another. Additionally, Windows 8 Consumer Preview client users can manually specify an entry point, overriding the automatic entry point that is assigned.

To access the Multi-Site wizard, in the Remote Access Management Console, under Tasks, click Enable Multi-Site.

Figure 54 Enable Multi-Site Wizard

First, specify a name to identify the multi-site deployment and the first entry point. This is typically the name of a geographic location.



Figure 55 Multi-Site Name

Specify whether users can manually override automatically assigned entry points based on location.

Figure 56 Manual Site Selection

You can optionally configure an external global load balancing solution to direct clients to the nearest entry point.



Figure 57 Global Load Balancing Settings

On the Client Support page, specify whether Windows 7 client computers will access this entry point. Automatic routing or manual selection of an entry point is not available for Windows 7 clients. Add a security group which contains the Windows 7 accounts that will access this entry point.

Figure 58 Client Support



If Windows 7 clients will access this entry point, select the name of the GPO which will be used to apply DirectAccess settings to these clients.

Figure 59 Client GPO Settings

Review the configuration settings on the Summary page, and then click Commit.

Figure 60 Multi-Site Summary



Figure 61 Multi-Site Completion

Add Entry Points to the Multi-Site ConfigurationAfter DirectAccess Multi-Site has been configured, you can add additional entry points. In the Remote Access Management Console, under Tasks, Multisite Deployment, click Add an Entry Point.

Figure 62 Entry Point Name



Select the Remote Access network topology deployed at the additional site.

Figure 63 Network Topology

Next, type the public name to which the DirectAccess clients will connect.

Figure 64 Network Name or IP Address



On the Network Adapters page, the wizard will discover and attempt to populate the external and internal adapters, and the certificate to be used for authentication of IP-HTTPS connections.

Figure 65 Network Interfaces

The wizard will automatically detect an existing IPv6 network, and will populate the Prefix Configuration page with the appropriate prefix to assign to DirectAccess client computers.

Figure 66 Prefix Configuration



On the Client Support page, specify whether Windows 7 clients will access this entry point, and add a security group to which Windows 7 GPO settings will be applied.

Figure 67 Client Support

If Windows 7 clients will access this entry point, select the name of the GPO which will be used to apply DirectAccess settings to these clients.

Figure 68 Client GPO Settings



On the Server GPO Settings page, specify a name for the server GPO.

Figure 69 Server GPO Settings

On the Summary page, click Commit.

Figure 70 Add Entry Point Summary



After the entry point configuration completes successfully, click Close.

Figure 71 Add Entry Point Completion


Documents

Understand and Troubleshoot Remote Access in Windows ...15782B344FD85B... · Web viewDirectAccess implements IPsec Denial of Service Protection ... the deployment requires manual