50402A-ENU Module08

Implementing Forefront Unified Access Gateway 2010
Student Manual Module 8: DirectAccess
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. 2010 Microsoft Corporation. All rights reserved. Microsoft is either a registered trademark or trademark of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess
Table of Contents
Module 8 Overview ............................................................................................................................................... 1 Lesson 1 DirectAccess Overview ......................................................................................................................... 2 Networking and Access Landscape .................................................................................................................3 What is DirectAccess? .....................................................................................................................................4 DirectAccess Solution ......................................................................................................................................5 Benefits of DirectAccess ..................................................................................................................................7 UAG and DirectAccess Better Together........................................................................................................8 Lesson 1 Review ..............................................................................................................................................9 Lesson 2 DirectAccess Solution Components..................................................................................................... 10 Under the Hood: UAG DA Architecture .........................................................................................................11 Under the Hood: IPv6 Gateway .....................................................................................................................12 IPv6 Gateway Components ...........................................................................................................................13 Under the Hood: IPSec Tunnels .....................................................................................................................14 IPSec Tunnel Mode Configuration .................................................................................................................15 Name Resolution Policy Table (NRPT) ...........................................................................................................16 Network Location Determination..................................................................................................................18 DirectAccess Connection Process ..................................................................................................................19 How DirectAccess Works Connecting to Internal Server .............................................................23 Internet and Intranet Traffic .........................................................................................................................24 Force Tunneling...............................................................................................................................24 DirectAccess Authentication .........................................................................................................................26 Two-factor AuthN using Smart Cards ............................................................................................................27 Exempting Users from Smart Card Authentication .........................................................................28 Lesson 2 Review ............................................................................................................................................29 Lesson 3 Planning a DirectAccess Deployment .................................................................................................. 30 Designing a DirectAccess Solution.................................................................................................................31 Identifying Resources Available to DA Clients ...............................................................................................33 Infrastructure and Management Servers ........................................................................................33 Application Servers .........................................................................................................................34 Designing Internal IPv6 Deployment .............................................................................................................35 Internal IPv6 Connectivity Options ................................................................................................................36 Design Name Resolution ...............................................................................................................................38 NRPT Exemptions ............................................................................................................................38 Split-Brain DNS Namespaces .........................................................................................................................40 Local Name Resolution ..................................................................................................................................42
Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess Single-label Name Resolution........................................................................................................................44 Design Active Directory .................................................................................................................................46 DirectAccess Access Models ..........................................................................................................................47 End-to-edge Access Model ............................................................................................................................48 End-to-end Access Model..............................................................................................................................49 Authentication and Authorization .................................................................................................................51 Smart Cards for Additional Authorization .......................................................................................51 Policy Enforcement with NAP .........................................................................................................52 Additional End-to-End Peer Authentication for Specified Server Access........................................52 Placement of the DirectAccess Server...........................................................................................................54 Edge Firewall Port Requirements ..................................................................................................................55 Design of the Network Location Server.........................................................................................................56 Design Public Key Infrastructure ...................................................................................................................58 Lesson 3 Review ............................................................................................................................................60 Lesson 4 Deploying DirectAccess Using Forefront UAG ..................................................................................... 61 Infrastructure Requirements .........................................................................................................................62 DirectAccess Deployment Requirements ......................................................................................................64 DirectAccess Configuration Wizard ...............................................................................................................66 DirectAccess Setup Wizard ............................................................................................................................67 Step 1 DA Client Configuration.....................................................................................................67 Step 2 DA Server Configuration....................................................................................................69 Step 3 Infrastructure Server Configuration ..................................................................................73 Step 4 Application Server Configuration ......................................................................................76 Applying the Configurations............................................................................................................78 DirectAccess Wizard Outputs ........................................................................................................................80 Provisioning DirectAccess Clients ..................................................................................................................82 Disabling DirectAccess ...................................................................................................................................83 Lesson 4 Review ............................................................................................................................................84 Module 8 Review ................................................................................................................................................. 85
ii
Module 8 Overview
This module gives an overview of DirectAccess, a technology enabled by Microsoft Forefront Unified Access Gateway that provides seamless network access to clients of the Windows 7 operating system. Module Objectives After completing this module, you will be able to: Understand the benefits provided by DirectAccess to users and IT organizations. Describe the DirectAccess architecture and its components. Understand the requirements and design decisions involved in a DirectAccess solution using Forefront UAG. Configure DirectAccess using Forefront UAG.
Lesson 1 DirectAccess Overview

This lesson provides an overview of the Windows DirectAccess technology, and the role that Forefront UAG plays as an enabler of this technology in enterprise environments. Lesson Objectives After completing this lesson, you will be able to: Explain the value proposition of DirectAccess. Describe what Forefront UAG adds to the DirectAccess solution.
Networking and Access Landscape
A few years ago, the workspace referred to one physical location. People drove to the office in the morning, worked all day, and went home in the evening. Todays mobile workforce is a paradigm shift from the traditional office. We have a steadily growing employee base that works remotely: from home, from customer premises, from hotels and airports. With the mobile workforce, technology trends have changed too. Data actually walks out of the front door, on laptops, USB drives, mobile phones, and other devices. Ubiquitous Internet means malware and spyware threats for everyone. IT organizations are challenged to manage client devices and enforce security policies regardless of how and where employees connect to the corporate network. Another trend in recent years is outsourcing and the new era of software as a servicewhere others manage your network and your datacenter, and your data sits on the cloud. With both data and users now living outside the perimeter, traditional perimeter security is not sufficient anymore, and emerging new technologies enable us to reperimeterize the network.
What is DirectAccess?
DirectAccess is a new feature, introduced in the Windows 7 and Windows Server 2008 R2 operating systems, that gives users the experience of being seamlessly connected to their corporate network any time they have Internet access. With DirectAccess, users are able to access corporate resources (such as e-mail servers, shared folders, or intranet Web sites) following common security standards, anytime they have an Internet connection. The seamless connectivity provided by DirectAccess also enables the IT organization to manage its mobile computers outside the network perimeter. Mobile computers are able to update Group Policy settings, receive distributed software updates, and report security events anytime they have Internet connectivity, even if the user is not logged on. This flexibility allows IT professionals to manage remote computers on a regular basis, and ensures that mobile users stay up to date with security and system health policies. Communications over the Internet between the mobile computers and the corporate network resources are authenticated and encrypted using Internet Protocol security (IPSec). DirectAccess performs both computer and user authentication, and can be configured to require two-factor user authentication for corporate network access using smart cards.
DirectAccess Solution
The following are the key elements of a DirectAccess solution: DirectAccess client A domain-joined computer running Windows 7 Enterprise, Windows 7 Ultimate, or Windows Server 2008 R2 that can automatically and transparently connect to an intranet through a DirectAccess server. DirectAccess clients communicate with the corporate network using Internet Protocol version 6 (IPv6) and IPSec, encapsulated over IPv4 transition technologies (6to4, Teredo, or IP-HTTPS). The use of IPv6 allows clients to make use of the underlying IPv4 network infrastructure, and enables seamless connectivity to the corporate network. DirectAccess server A domain-joined computer running Windows Server 2008 R2 that accepts connections from DirectAccess clients and facilitates communication with intranet resources. The DirectAccess server authenticates DirectAccess clients and acts as the IPSec tunnel mode endpoint for the external traffic, while also acting as an IPv6 router forwarding the traffic between the clients and the corporate network resources. Internal resources Internal servers and clients are also joined to the IPv6 network and communicate with the DirectAccess clients through the DirectAccess server. Optionally, IPSec transport mode can be used to provide end-to-end security. For legacy applications and nonWindows servers that have no IPv6 support, Forefront UAG translates the incoming IPv6 traffic to IPv4 using Network Address Translator64 (NAT64)/DNS64. NAP servers Network Access Protection (NAP) is an optional component of the DirectAccess solution, allowing organizations to validate compliance and enforce security policy for DirectAccess clients over the Internet. Clients connect to the NAP Health Registration Authority (HRA) server using a Web service to validate policy, and if considered healthy, receive a health
certificate that is then used to authenticate the client before the DirectAccess server. Unhealthy clients do not obtain the health certificate and have restricted access to the corporate network.
There are other components of the DirectAccess solution (such as the network location server) which will be introduced later in this module.
Note:
Benefits of DirectAccess
DirectAccess provides organizations with the following benefits: Improved productivity of mobile workforce DirectAccess provides increased productivity for your mobile workforce by offering the same connectivity experience both in and outside of the office. DirectAccess is on whenever the user has an Internet connection, giving users access to intranet resources whether they are traveling, at the local coffee shop, or at home. There is no user action required to connect, and users have the same experience whether on or off premises. Improved security DirectAccess uses IPSec for authentication and encryption. Optionally, you can require smart cards for user authentication. IT administrators can also configure the DirectAccess server to restrict the servers that users and individual applications can access. DirectAccess integrates with NAP to require that DirectAccess clients must be compliant with system health requirements before allowing a connection to the DirectAccess server. Organizations are able to manage and enforce security policies on their assets beyond the network perimeter, while taking the initial steps in adopting the IPv6 protocol. Improved manageability of remote users Without DirectAccess, mobile computers can only be managed when users connect to a VPN or physically enter the office. With DirectAccess, mobile computers can be managed anytime there is Internet connectivity, even if the user is not logged on. This allows remote computers to be managed regularly and helps ensure mobile users stay up to date with security and system health policies. DirectAccess helps ensure that organizations can meet regulatory and privacy mandates for security and data protection for assets that must roam beyond the corporate network.
UAG and DirectAccess Better Together
Forefront UAG DirectAccess extends the benefits of Windows DirectAccess across your infrastructure, enhancing scalability and simplifying deployments and ongoing management. Forefront UAG enables DirectAccess by adding the following capabilities: Simplified deployment using wizards and automated deployment tools. Built-in array management and integrated load balancing for scale-out and reduced administrative overhead. Failover support for high availability using the integrated Windows Network Load Balancing (NLB) feature. NAT64/DNS64 support extends Windows DirectAccess to legacy applications and resources running on the existing IPv4 resources such as Windows 2003 and non-Windows servers. Integrated NAP support for endpoint health validation.
Forefront UAG provides a consolidated access gateway for centralized control and auditing. From the same infrastructure, Forefront UAG is able to provide SSL VPN access for downlevel (Windows Vista/Windows XP) and non-Windows clients as well as PDAs, while providing seamless connectivity to Windows 7 clients using DirectAccess.
Lesson 1 Review
Lesson 1 provided an overview of the Windows DirectAccess technology, and the role that Forefront UAG plays as an enabler of this technology in enterprise environments. You should now be able to: Explain the value proposition of DirectAccess. Describe what Forefront UAG adds to the DirectAccess solution.
Lesson 2 DirectAccess Solution Components

This lesson describes the Forefront UAG DirectAccess architecture and its different components. Lesson Objectives After completing this lesson, you will be able to: Describe how DirectAccess uses IPv6 and IPSec to provide always on connectivity to remote clients. Explain how DirectAccess clients determine whether they are inside or outside the corporate network. Understand how DirectAccess handles DNS name resolution using the Name Resolution Policy Table (NRPT). Explain how DirectAccess enforces authentication of remote clients.
10
Under the Hood: UAG DA Architecture
Forefront UAG DirectAccess (DA) leverages native Windows Server 2008 R2 components while adding additional functionality to provide connectivity, security, and high availability for DirectAccess clients: The Windows network stack provides IPv6 connectivity, using either IPv6 or its transition technologies. Forefront UAG leverages the new Teredo server introduced in Windows Server 2008 R2, as well as the 6to4 relay, IP-HTTPS server, and Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) router (all of which are native to Windows). Forefront UAG adds support for the NAT64 and DNS64 translation technologies. The Forefront UAG NAT64 and DNS64 components sit in the network stack, and perform IPv6-to-IPv4 DNS name resolution and IPv6/IPv4 traffic translation services for traffic between DirectAccess clients and IPv4-only intranet application servers. The network stack also provides IPSec tunnel mode endpoint functionality. Forefront UAG leverages the new Dynamic Tunnel Endpoint (DTE) feature introduced in Windows Server 2008 R2, incorporating a function that rate-limits key negotiation traffic used to set up new IPSec sessions to protect against denial of service attacks (IPSec Denial of Service Protection, or DoSP). Forefront UAG incorporates custom logic in Windows Network Load Balancing (NLB) to implement support for DirectAccess load balancing and failover. NLB is able to load balance IPv6 transition technologies and renegotiate IPSec tunnel mode sessions during failover.
11
Under the Hood: IPv6 Gateway
Internet Protocol version 6 (IPv6) plays a major role in DirectAccess, providing end-to-end connectivity between the DirectAccess client machines and corporate resources. Since native IPv6 support is not yet commonly used on the Internet and in corporate networks, DirectAccess relies on IPv6/IPv4 transition technologies to enable IPv6 connectivity on top of the existing IPv4 infrastructure. On the Internet side, the following transition technologies are used by DirectAccess clients: 6to4 is used by DirectAccess clients connected directly to the Internet, using public (routable) IPv4 addresses. Teredo is used by clients connecting to the Internet through network address translation (NAT) devices. IP-HTTPS is used by clients when neither 6to4 nor Teredo connectivity is available, such as clients behind Web proxies, or in networks where 6to4 and Teredo traffic is blocked by a firewall.
Forefront UAG DirectAccess does not support native IPv6 connectivity from the client.
Note:
On the intranet side, DirectAccess supports native IPv6 connectivity, plus the ISATAP protocol that enables IPv6 to be deployed on top of an existing IPv4 network infrastructure. Forefront UAG is also able to use NAT64/DNS64 to translate incoming IPv6 traffic to IPv4, allowing clients to connect to internal systems that are IPv4-only.
12
IPv6 Gateway Components
The Forefront UAG DirectAccess server plays the role of an IPv6 router, forwarding traffic between the DirectAccess clients and the intranet servers. The following IPv6 functionality is enabled on the server: 6to4 relay routes IPv6 traffic from and to clients connecting using 6to4. Teredo server and relay provide IPv6 addressing and routing services for Teredo clients. The IP-HTTPS server acts as the endpoint for receiving Secure Hypertext Transfer Protocol (HTTPS) connections from clients that cannot use 6to4 or Teredo. The ISATAP router role can be run either on the Forefront UAG DirectAccess server or on a separate server. It provides address assignment and routing for ISATAP clients. NAT64 and DNS64 are optional services implemented by Forefront UAG that translate IPv6 traffic on the Internet side to IPv4 on the intranet. NAT64/DNS64 translation is stateful and unidirectional; only connections initiated from the IPv6 (Internet) side are supported.
13
Under the Hood: IPSec Tunnels
DirectAccess uses IPSec to authenticate both the computer and user, allowing IT to manage the computer before the user logs on. Optionally, you can require a smart card for user authentication. DirectAccess also leverages IPSec to provide encryption for communications across the Internet. You can use IPSec encryption methods such as Triple Data Encryption Standard (3DES) and the Advanced Encryption Standard (AES). Clients establish an IPSec tunnel for the IPv6 traffic to the DirectAccess server, which acts as a gateway to the intranet. The image above shows a DirectAccess client connecting to a DirectAccess server across the public IPv4 Internet. Clients can connect even if they are behind a firewall. The DirectAccess client establishes two IPSec tunnels: The infrastructure tunnel provides access to an intranet Domain Name System (DNS) server, domain controller, NAP, and other client management servers, allowing the computer to download Group Policy objects and to request authentication on the users behalf. This tunnel is authenticated using a computer certificate and NTLMv2 credentials, and is active even without a logged-on user. The intranet tunnel authenticates the user and provides access to intranet resources and application servers. For example, this tunnel would need to be established before Microsoft Outlook could download e-mail from the intranet Microsoft Exchange Server.
After the tunnels to the DirectAccess server are established, the client can send traffic to the intranet through the tunnels. The incoming IPv6 traffic is routed by the Forefront UAG DirectAccess server to the internal machines using native IPv6, ISATAP, or IPv4 after NAT64 translation.
14
IPSec Tunnel Mode Configuration
When a DirectAccess client sends data to the intranet, the traffic is encrypted over the Internet. Remote management of DirectAccess clients is also an important consideration, so there must be some way for the client computer to authenticate even before the user logs on. To solve these needs, one of the IPSec policies configured on the DirectAccess client implements a tunnel mode policy (in the end-to-edge and end-to-edge with authentication access models) or transport mode policy (in the end-to-end access model) that defines multiple rules for communication between the client and the intranet: The tunnel mode policy requires authentication with a computer certificate and encrypts traffic with IPSec and the Encapsulating Security Payload (ESP). This policy provides secure communication with Active Directory domain controllers and other intranet resources before the user has logged on. The transport mode policy requires authentication with a computer certificate and user-based Kerberos credentials. This policy provides secure communication to all intranet resources after the user has logged on. Optionally, the tunnel may be configured to require the user-based Kerberos ticket issued by a smart card-based Kerberos logon, forcing the user to authenticate using a smart card for intranet access.
Termination of IPSec tunnel mode sessions between the DirectAccess client and the intranet is performed by the IPSec Gateway component in the Forefront UAG DirectAccess server. Another component on the DirectAccess server, IPSec Denial of Service Protection (DoSP), monitors the IPSec traffic to help prevent malicious users on the Internet from launching Denial of Service (DoS) attacks against intranet resources.
15
Name Resolution Policy Table (NRPT)
To separate Internet traffic from intranet traffic for DirectAccess, Windows 7 and Windows Server 2008 R2, include the Name Resolution Policy Table (NRPT), a new feature that allows DNS servers to be defined per DNS namespace, rather than per interface. The NRPT stores a list of rules. Each rule defines a DNS namespace and configuration settings that define the DNS clients behavior for that namespace. When a DirectAccess client is on the Internet, each name query request is compared against the namespace rules stored in the NRPT. If a match is found, the request is processed according to the settings in the NRPT rule. The settings determine the DNS servers to which the request will be sent. The NRPT allows DirectAccess clients to use intranet DNS servers for name resolution (dedicated DNS servers are not required), so that your intranet namespace is not exposed to the Internet. 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. For a remote client, this will typically be the Internet DNS servers as configured through the Internet service provider. For a DirectAccess client on the intranet, this will typically be the intranet DNS servers as configured through the Dynamic Host Configuration Protocol (DHCP). Single-label names, such as http://internal, will typically have configured DNS search suffixes appended to them before they are checked against the NRPT. If no DNS search suffixes are configured and the single-label name does not match any other single-label name rules in the NRPT, the request will be sent to the DNS servers specified in the clients TCP/IP settings. Namespaces, such as .internal.contoso.com, are added to the NRPT followed by the IPv6 addresses of the DNS servers to which requests matching that namespace should be directed. If an IP address is entered for the DNS server, then all DNS requests will be sent directly to the DNS server over the DirectAccess connection.
16
There is no need to specify any additional security for this configuration. However, if a name is specified for the DNS server (such as dns.contoso.com) in the NRPT, then that name must be publicly resolvable when the client queries the DNS servers specified in its TCP/IP settings. To prevent an attacker from hijacking this external name query request and injecting a malicious reply, it is strongly recommended that you enable IPSec protection for the DNS message exchanges in this configuration.
Enabling IPSec protection for DNS queries is not available in the Forefront UAG console.
Note:
17
Network Location Determination
The network location server is a critical part of the DirectAccess deployment. If DirectAccess client computers on the intranet cannot successfully locate and access the secure Web page on the network location server, they might not be able to access intranet resources. When the DirectAccess client determines that it is inside the corporate network, the Windows Firewall adopts the Domain profile, which does not have a connection security rule requiring connections to the internal network to be sent over an IPSec tunnel through the Forefront UAG DirectAccess server. This allows the client to connect directly to other resources on the intranet. The NRPT is also disabled on clients on the intranet, and name resolution will typically rely on the DNS servers informed by the internal DHCP servers. When DirectAccess clients obtain a physical connection to the intranet or experience a network status change on the intranet (such as an address change when roaming between subnets), they attempt an HTTPS connection to a configured URL for an internal Web site. If the DirectAccess client can successfully obtain an HTTPS connection to the configured URL, including a revocation check of the Web servers certificate, it determines that it is on the intranet. Determination is performed by simply connecting to the specified URL; there is no need for the Web server to provide any particular data.
The Web site used for network location determination (known as the network location server) cannot be hosted on the Forefront UAG DirectAccess server itself.
Note:
The URL for the network location server is stored in the client registry and can be configured using a Group Policy. Only a single URL can be specified for network location determination. 18
DirectAccess Connection Process
To understand how DirectAccess enables clients on the Internet to seamlessly and securely access internal servers, here is the connection process for a sample scenario where a DirectAccess client on the Internet is connecting to the internal Server1 server: 1. The DirectAccess client computer running Windows 7 (Enterprise or Ultimate) detects that it is not connected to the intranet, and sends an IPv6 router solicitation to the Forefront UAG DirectAccess server using a transition technology (6to4, Teredo, or IP-HTTPS). 2. The DirectAccess server replies with an IPv6 router advertisement message providing the client with an IPv6 prefix or address, depending on the transition technology used. 3. The DirectAccess client computer connects to the DirectAccess server by using IPv6 and IPSec. As part of establishing the IPSec session for the infrastructure tunnel to reach the intranet DNS server, the DirectAccess client and server authenticate each other using computer certificates for authentication.
19
4. The DirectAccess client uses the NRPT to identify which DNS server to query for server1.corp.contoso.com. The NRPT contains the IPv6 address of the DNS server to be queried for the contoso.com DNS namespace. 5. The client sends a query to the internal DNS server over the IPv6 transition technology, protected by an IPSec tunnel to the Forefront UAG DirectAccess server. 6. The DirectAccess server terminates the IPSec tunnel and forwards the IPv6 DNS query to the internal DNS server.
20
7. The internal DNS server receives the query, and replies back with the IPv6 address of server1.corp.contoso.com. 8. The IPv6 response is routed through the DirectAccess server to the DirectAccess client, protected over the Internet by the infrastructure IPSec tunnel.
21
9. After receiving the IPv6 address for the internal server, the DirectAccess client establishes the second IPSec tunnel to access the resources of the intranet. The DirectAccess client and the DirectAccess server authenticate each other over AuthIP using a combination of computer and user credentials, and establish another IPSec session for the Intranet tunnel. The client uses the intranet tunnel to contact the internal server and negotiate a secure end-to-end channel using IPSec transport mode.
22
How DirectAccess Works Connecting to Internal Server
10. The DirectAccess client uses the end-to-end transport mode session to securely connect to resources on the internal server.
23
Internet and Intranet Traffic
DirectAccess can separate traffic to the intranet from Internet traffic, as shown in Figure 4, to reduce unnecessary traffic on the corporate network. Most VPNs send all trafficeven traffic that is destined for the Internetthrough the VPN, which can slow both intranet and Internet access. Because communications to the Internet do not have to travel to the corporate network and back to the Internet, DirectAccess does not slow down Internet access.
Force Tunneling
You can use Force Tunneling to flow all of your intranet and Internet traffic through the DirectAccess connection. Force Tunneling is enabled with the following Group Policy setting on the Group Policy object for your DirectAccess clients: Computer Configuration\Administrative Templates\Network\Network Connections\Route all traffic through the internal network When Force Tunneling is enabled, all traffic from the DirectAccess client must be IPv6 traffic and will be routed to the intranet over an IP-HTTPS tunnel. Clients with Force Tunneling enabled will still be able to access any resources on their local subnet, such as network printers, but any network traffic beyond the local subnet must be IPv6 traffic. To reach resources on the IPv4 Internet when Force Tunneling is enabled, use an IPv6-capable Web proxy server. Alternately, you can use a Network Address Translation/Protocol Translation (NAT-PT) device on your intranet and route the resulting IPv4 Internet traffic to your IPv4-based Web proxy servers. To reach these resources for IPv4 Internet traffic, you must configure the following additional NRPT rule in the DirectAccess Setup Wizard:
24
Name suffix set to . DNS server IPv4 or IPv6 addresses set to the IPv6-capable proxy server or NAT-PT.
Due to the infrastructure requirements and reduced performance for accessing IPv4 Internet resources, Microsoft does not recommend the use of Force Tunneling for DirectAccess.
Note:
25
DirectAccess Authentication
DirectAccess performs authentication at the edge of the network using IPSec tunnel mode. There are two IPSec tunnels in a default DirectAccess configuration: The infrastructure tunnel is established from the DirectAccess client to the DirectAccess server to support access to the IPv6 addresses of DNS servers and Active Directory Domain Services (AD DS) domain controllers. This tunnel uses computer certificate credentials for the first authentication and NTLMv2 computer credentials for the second authentication. NTLMv2 credentials are used to force the use of AuthIP, and because the DirectAccess client needs DNS and domain controller access before it can use Kerberos credentials for the second tunnel. The intranet tunnel is established from the client to the DirectAccess server to support access to the IPv6 address space of the intranet. This tunnel uses computer certificate credentials for the first authentication and user (Kerberos V5) credentials for the second authentication. Optionally, a NAP health certificate can be required for computer authentication for integration with NAP, and a smart card can be required for user authentication.
You can also configure an additional end-to-end peer authentication for application server access. In this case, an IPSec transport mode session is established between the client and the internal application using certificate or Kerberos V5 credentials for the computer authentication, and Kerberos V5 credentials for user authentication.
26
Two-factor AuthN using Smart Cards
DirectAccess supports standard user authentication using a user name and password. For greater security, you can implement two-factor authentication with smart cards. This type of configuration allows users to access Internet resources without their smart cards, but it requires a smart card before users or computers can connect to intranet resources. Users are required to insert a smart card in addition to typing their user credentials. Smart card authentication prevents an attacker who acquires a users password (but not the smart card) from connecting to the intranet. Similarly, an attacker who acquires the smart card but does not know the users password is unable to authenticate.
The DirectAccess client is able to establish the Infrastructure tunnel and connect to management servers and DCs even without the user presenting a smart card certificate. Smart card authentication is only required for the Intranet tunnel.
Note:
For smart card authorization, the authorization rules on the DirectAccess server require that the Kerberos ticket presented by the DirectAccess user specify a security identifier (SID) that indicates the user is in possession of a certificate that qualifies for the This Organization Certificate property. This identifies that the Kerberos PKINIT extension was used during the authentication, indicating that a certificate (in a smart card) was the credential used to obtain the ticket.
This approach for smart card authentication requires domain controllers running Windows Server 2003 or above.
Note:
27
When smart card authorization is enforced at the edge by using an IPSec authorization policy and a user logs in without a smart card, a message displays in the notification area similar to the above image. Users can click this message and provide their smart cards and PINs to gain access to intranet resources.
Exempting Users from Smart Card Authentication

To allow temporary access for users with no valid smart cards, do the following: 1. Create an Active Directory security group that will contain the user accounts of users who temporarily cannot use their smart cards. 2. For the Forefront UAG DirectAccess server Group Policy object, configure global IPSec settings for IPSec tunnel authorization, and add the Active Directory security group to the list of authorized users. 3. To grant access to users that cannot their smart cards, temporarily add the user account to the Active Directory security group. Remove the user account from the group when the smart card is usable.
28
Lesson 2 Review
Lesson 2 covered the Forefront UAG DirectAccess architecture and described its different components. You should now be able to: Describe how DirectAccess uses IPv6 and IPSec to provide always on connectivity to remote clients. Explain how DirectAccess clients determine whether they are inside or outside the corporate network. Understand how DirectAccess handles DNS name resolution using the Name Resolution Policy Table (NRPT). Explain how DirectAccess enforces authentication of remote clients.
29
Lesson 3 Planning a DirectAccess Deployment

This lesson lists the requirements for deploying a DirectAccess solution using Forefront UAG, and the considerations involved in designing the solution. Lesson Objectives After completing this lesson, you will be able to: List the steps involved in designing a DirectAccess solution. Explain the options available for deploying IPv6 to an internal network. Understand the issues involved in planning DNS name resolution for DirectAccess clients. Understand where to place the Forefront UAG DirectAccess servers and the network location servers.
30
Designing a DirectAccess Solution
DirectAccess is a flexible solution that can be deployed in many different ways to meet your requirements. Many decisions must be made in advance to ensure the DA design meets the needs of your environment. The following slides break down the steps into smaller decision points to help you understand the big picture and make an informed decision. The DirectAccess design process involves the following steps: Identify resources available to the DA clients DirectAccess enables access to management servers and domain controllers, as well as application servers. During the design, you should identify which internal servers should be reachable by DirectAccess clients using only computer authentication and which servers will also require the logged-on user to be authenticated. Design internal IPv6 connectivity DirectAccess relies on IPv6 connectivity between the DirectAccess clients and the internal resources. You should plan to enable IPv6 connectivity to the internal network. Design name resolution Identify the internal DNS namespaces and DNS servers, and define how DirectAccess clients will handle local name resolution and split-brain DNS namespaces. Note that split-brain DNS namespaces are discussed later in this lesson. Design Active Directory Assign IPv6 subnets to Active Directory sites. Choose an access model Choose between the end-to-edge and end-to-end access models, based on the organization security requirements and the existing infrastructure. Design the placement of the Forefront UAG server Understand the infrastructure prerequisites for the Forefront UAG DirectAccess servers, and select their logical and physical locations.
31
Design the network location server Plan for maintaining a highly-available internal Web site for network location determination. Design public key infrastructure DirectAccess requires valid certificates for the Forefront UAG DirectAccess server, clients, network location server, and (optionally) application servers and users. Design authentication and authorization Understand the security requirements of the organization, and plan for two-factor authentication using smart cards, end-to-end security between clients and application servers, and NAP policy validation and enforcement.
32
Identifying Resources Available to DA Clients
When designing your DirectAccess deployment, you must determine how DirectAccess clients will reach all of the desired intranet resources. The clients can use either the infrastructure or the intranet tunnels to reach the intranet servers, depending on whether user authentication is required.
Infrastructure and Management Servers

DirectAccess client computers are connected to the intranet whenever the DirectAccess client is connected to the Internet, regardless of whether the user has logged on to the computer. This means that they can be more easily managed as intranet resources and kept up to date with Group Policy changes, operating system updates, antimalware software updates, and other changes. Intranet management servers that client computers use to keep themselves up to date can be: Active Directory domain controllers (DCs) and DNS servers. Microsoft System Center Configuration Manager 2007 servers. Windows Update servers. Network Access Protection (NAP) servers. Servers for antimalware updates, such as antivirus servers.
In some cases, intranet servers or computers must initiate connections to DirectAccess clients. For example, helpdesk department computers can use remote desktop connections to connect to and troubleshoot remote DirectAccess clients. To ensure that DirectAccess clients accept incoming traffic from these types of computers, and that the traffic is protected over the Internet, you should identify
33
sets of these intranet management computers, record either their names or all of their IPv4 addresses and IPv6 addresses, and configure them to be reachable by the IPSec infrastructure tunnel.
Application Servers
Users can leverage DirectAccess to have seamless connectivity to internal resources such as Web sites, file shares, line of business (LOB) applications, and other application servers. Access to these applications will only be available to DirectAccess clients with an authenticated user logged onto the machine. Optionally, DirectAccess can enforce end-to-end authentication between the client and the application server using IPSec transport mode.
34
Designing Internal IPv6 Deployment
DirectAccess relies on Internet Protocol version 6 (IPv6) for end-to-end connectivity between the DirectAccess client and an intranet endpoint. DirectAccess clients only send IPv6 traffic across the connection to the DirectAccess server. Therefore, DirectAccess clients can only communicate using applications that support IPv6 and can only connect to intranet resources that are reachable with IPv6. IPv4-only applications on the DirectAccess client cannot be used to access intranet application servers with DirectAccess. An intranet infrastructure that supports forwarding IPv6 traffic can be achieved in the following ways: Configure your intranet infrastructure to support native IPv6 addressing and routing Computers running Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2 use IPv6 by default. Although few organizations today have a native IPv6 infrastructure, this is the preferred and recommended connectivity method. For the most seamless intranet connectivity for DirectAccess clients, organizations should deploy a native IPv6 infrastructure, typically alongside their existing IPv4 infrastructure. Deploy Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) on your intranet Without a native IPv6 infrastructure, you can use ISATAP to make intranet servers and applications reachable by tunneling IPv6 traffic over your IPv4-only intranet. Deploying ISATAP consists of setting up one or more ISATAP routers that provide address configuration and default routing for ISATAP hosts on your intranet. Computers running Windows 7 or Windows Server 2008 R2 support ISATAP host functionality and can be configured to act as ISATAP routers. Translate incoming IPv6 traffic using NAT64 The Forefront UAG DirectAccess server can use its NAT64 and DNS64 features to translate IPv6 connections initiated from the DirectAccess clients to IPv4, enabling connectivity to intranet resources that only support the IPv4 protocol.
35
Internal IPv6 Connectivity Options
To enable DirectAccess connectivity, you must ensure that the IPv6 routing infrastructure can forward packets between DirectAccess clients and intranet resources. There are three options available for enabling internal IPv6 connectivity: Native IPv6 Using IPv6 natively is the desired end state for the internal network, when no transition technologies will be required for connectivity. However, very few organizations have fully implemented IPv6 on their networks as this requires upgrading the entire network and hosting infrastructure to IPv6-compliant implementations. Organizations can, however, gradually implement pockets of IPv6 networks inside their organization, linked over the IPv4 infrastructure using tunneling. If you do have an existing native IPv6 infrastructure, the Forefront UAG DirectAccess Configuration Wizard prompts you for the 48-bit prefix of the organization, and does not configure itself as an ISATAP router. To ensure that DirectAccess clients are reachable from the intranet, you must modify your IPv6 routing so that default route traffic is forwarded to the Forefront UAG DirectAccess server. ISATAP tunneling ISATAP, defined in RFC 4214, is an IPv6 transition technology that provides IPv6 connectivity between IPv6/IPv4 hosts across an IPv4-only intranet. ISATAP can be used for Forefront UAG DirectAccess to provide IPv6 connectivity to ISATAP hosts across your intranet. When the Forefront UAG DirectAccess Configuration Wizard detects that the Forefront UAG DirectAccess server has no native or ISATAP-based IPv6 connectivity, it automatically derives a 6to4-based 49-bit prefix for the intranet, configures the Forefront UAG DirectAccess server as an ISATAP router, and moves to the next step of the Forefront UAG DirectAccess Configuration Wizard.
36
NAT64/DNS64 You can use the integrated Network Address Translator64 (NAT64) and DNS64 functionality that is provided on the Forefront UAG DirectAccess server to enable connectivity to IPv4-only resources on the internal network. NAT64 and DNS64 perform IPv6-to-IPv4 DNS name resolution and IPv6/IPv4 traffic translation services, for traffic between DirectAccess clients and IPv4-only intranet application servers. NAT64 and DNS64 are the only option available to enable connectivity between DirectAccess clients and servers running Windows Server 2003 or other legacy systems. One limitation of NAT64 is that translation is unidirectional and only available to traffic initiated from the DirectAccess client side. Use of NAT64 also places an additional load on the Forefront UAG DirectAccess server.
37
Design Name Resolution
When planning domain name resolution for DirectAccess clients, you should identify all DNS namespaces used by clients to reach internal servers and Active Directory domains. The namespaces should be listed in the name resolution policy table (NRPT), an internal table used by the DNS Client service to determine where to send DNS name queries. The NRPT consists of a set of rules associating an internal DNS namespace with one or more intranet DNS servers that will be used by the DirectAccess clients to resolve names in that namespace. The NRPT can also contain exemption rules for DNS names that should not be resolved using intranet DNS servers, with the client using instead the DNS servers provided by the external network.
The maximum number of rules in the NRPT is 1000. Note:
NRPT Exemptions
There are some names that need to be treated differently from all others with regard to name resolution; these names must not be resolved using intranet DNS servers. To ensure that these names are resolved with interface-configured DNS servers, you must add them as NRPT exemptions. If no DNS server addresses are specified in the NRPT rule, the rule is an exemption. If a DNS name matches a rule in the NRPT that does not contain addresses of DNS servers or does not match a rule in the NRPT, the DirectAccess client sends the name query to interface-configured DNS servers.
38
If any of the following servers have a name suffix that matches an NRPT rule for the intranet namespace, that server name must be an NRPT exemption: Network location servers. Internet certificate revocation list (CRL) distribution points. IP-HTTPS public URL name.
These servers must always be resolved with interface-configured DNS servers. If you have a split-brain DNS environment, you must add exemption rules for the names of resources for which you want DirectAccess clients located on the Internet to access the public (Internet) version, rather than the intranet version.
39
Split-Brain DNS Namespaces
Split-brain DNS is the use of the same DNS domain for both Internet and intranet resources. For example, the Contoso Corporation is using split-brain DNS; contoso.com is the domain name for intranet resources and Internet resources. Internet users use http://www.contoso.com to access Contosos public Web site and Contoso employees on the Contoso intranet use http://www.contoso.com to access Contosos intranet Web site. For example, Jane is a Contoso employee whose laptop is not a DirectAccess client on the intranet. When she accesses http://www.contoso.com, she sees the intranet Contoso Web site. When she takes her laptop to the local coffee shop and accesses that same URL, she sees the public Contoso Web site. When a DirectAccess client is on the Internet, the NRPT sends DNS name queries for intranet resources to intranet DNS servers. A typical NRPT for DirectAccess will have a rule for the namespace of the organization, such as contoso.com for the Contoso Corporation, with the IPv6 addresses of intranet DNS servers. Using just this rule in the NRPT, when users on DirectAccess clients on the Internet attempt to access the URL for their Web site (such as http://www.contoso.com), they will see the intranet version. Because of this rule, they will never see the public version of this URL when they are on the Internet. If you want users on DirectAccess clients to see the public version of this URL when they are on the Internet, you must add the fully qualified domain name (FQDN) of the URL as an exemption rule to the NRPT of DirectAccess clients. However, if you add this exemption rule, users on DirectAccess clients will never see the intranet version of this URL when they are on the Internet. For split-brain DNS deployments, you must list the FQDNs that are duplicated on the Internet and intranet and decide which resources the DirectAccess client should reach, the intranet version or the public (Internet) version. For each name that corresponds to a resource for which you want DirectAccess
40
clients to reach the public version, you must add the corresponding FQDN as an exemption rule to the NRPT for your DirectAccess clients.
In a split-brain DNS environment, if you want both versions of the resource to be available, configure your intranet resources with alternate names that are not duplicates of the names that are being used on the Internet and instruct your users to use the alternate name when on the Intranet. For example, configure and use the alternate name www.internal.contoso.com for the intranet name www.contoso.com.
Note:
41
Local Name Resolution
If a name cannot be resolved with DNS, the DNS Client service in Windows 7 and Windows Server 2008 R2 can use local name resolution, with the Link-Local Multicast Name Resolution (LLMNR) and NetBIOS over TCP/IP protocols, to resolve the name on the local subnet. Local name resolution is typically needed for peer-to-peer connectivity when the computer is located on private networks, such as single subnet home networks. When the DNS Client service performs local name resolution for intranet server names and the computer is connected to a shared subnet on the Internet, malicious users can capture LLMNR and NetBIOS over TCP/IP messages to determine intranet server names. In Step 3 of the Forefront UAG DirectAccess Setup Wizard, you configure the local name resolution behavior based on the types of responses received from intranet DNS servers. You have the following options: Only use local name resolution only if the name does not exist in DNS This option is the most secure because the DirectAccess client will only perform local name resolution for server names that cannot be resolved by intranet DNS servers. If the intranet DNS servers can be reached, the names of intranet servers will be resolved. If the intranet DNS servers cannot be reached or if there are other types of DNS errors, the intranet server names will not be leaked to the subnet through local name resolution. Fall back to local name resolution if the name does not exist in DNS or the DNS servers are unreachable when the client computer is on a private network This option is moderately secure because it allows the use of local name resolution on a private network when the intranet DNS servers are unreachable. This is the default option.
42
Fall back to local name resolution for any kind of DNS resolution error This is the least secure option because the names of intranet network servers can be leaked to the local subnet through local name resolution.
Choose the option that complies with your security requirements.
43
Single-label Name Resolution
Unqualified, single-label names are sometimes used for intranet servers so that you can specify a single name, such as http://paycheck. The DNS Client service combines these names with your DNS suffix search list to create a series of FQDNs to resolve with DNS. By default, your computers domain name is in the DNS suffix search list and additional DNS suffixes can be added. For example, when a user on a computer that is a member of the corp.contoso.com domain types http://paycheck in their Web browser, Windows constructs the name paycheck.corp.contoso.com as the FQDN.
You can use the Computer Configuration/Administrative Templates/Network/ DNS Client/DNS Suffix Search List Group Policy setting to add DNS suffixes to the DNS suffix search lists of domain-joined client computers.
Note:
To ensure that unqualified, single-label names resolve to the same intranet resources whether DirectAccess clients are connected to the intranet or the Internet, your DNS suffix search list should match the namespace rules in your NRPT. As a general rule, each DNS suffix for an intranet namespace should correspond to a namespace rule in your NRPT.
44

If the name of a server on the local subnet is a duplicate of a server name on the intranet, the DirectAccess client will always connect to the intranet resource. For example, if your home network server is named Server1 and there is an intranet server of the same name, you will always connect to the intranet Server1. To connect to the local subnet resource, append .local to the name of the server. For example, to connect to the local subnet server named Server1, use the name Server1.local.
Note:
45
Design Active Directory
To configure Active Directory sites and services for forwarding within sites for ISATAP hosts, for each IPv4 subnet object, you must configure an equivalent IPv6 subnet object, in which the IPv6 address prefix for the subnet expresses the same range of ISATAP host addresses as the IPv4 subnet. For example, for the IPv4 subnet 192.168.99.0/24 and the 64-bit ISATAP address prefix 2002:836b:1:8000::/64, the equivalent IPv6 address prefix for the IPv6 subnet object is 2002:836b:1:8000:0:5efe:192.168.99.0/120. For an arbitrary IPv4 prefix length (set to 24 in the example), you can determine the corresponding IPv6 prefix length from the formula: 96 + IPv4PrefixLength. You can also assign the IPv6 address ranges used by the DirectAccess clients to a specific Active Directory site, which will define which domain controllers will be preferably used by these clients for authentication and Group Policies. For the IPv6 addresses of DirectAccess clients, add the following: An IPv6 subnet for the range 2001:0:WWXX:YYZZ::/64, in which WWXX:YYZZ is the colonhexadecimal version of the selected First Internet-facing IPv4 address of the Forefront UAG DirectAccess server. This IPv6 prefix is for Teredo-based DirectAccess clients. An IPv6 subnet for the range 2002:WWXX:YYZZ:8100::/56, in which WWXX:YYZZ is the colonhexadecimal version of the selected First Internet-facing IPv4 address (w.x.y.z) of the Forefront UAG DirectAccess server. This IPv6 prefix is for IP-HTTPS-based DirectAccess clients. A series of 6to4-based IPv6 prefixes that begin with 2002: and represent the regional, public IPv4 address prefixes that are administered by Internet Assigned Numbers Authority (IANA) and regional registries. The 6to4-based prefix for a public IPv4 address prefix w.x.y.z/n is 2002:WWXX:YYZZ::/[16+n], in which WWXX:YYZZ is the colon-hexadecimal version of w.x.y.z.
46
DirectAccess Access Models
IPSec protects communications over IP networks through the use of cryptographic security services, providing a flexible framework that can be used for secure access scenarios that meet virtually any requirement. As part of your Forefront UAG DirectAccess planning, you must decide where you intend terminating IPSec encryption. The level of authentication you intend to provide to your intranet servers assists you in choosing the access model that is suited to your organization's requirements. Forefront UAG supports two different access models: End-to-edge access model The end-to-edge access model allows DirectAccess clients to connect to IPv6 reachable resources inside your intranet. Traffic is always encrypted between the DirectAccess client and the Forefront UAG DirectAccess server. The Forefront UAG DirectAccess server acts as an IPSec gateway, and terminates the IPSec tunnels for the DirectAccess client. Traffic between the Forefront UAG server and the intranet resources is neither encrypted nor authenticated. End-to-end access model The end-to-end access model extends the end-to-edge IPSec policies all the way to the specified application servers. The DirectAccess clients use an IPSec transport policy, which requires that the authentication and traffic protection of IPSec sessions is terminated at the specified application servers. In this case, the Forefront UAG DirectAccess server forwards the authenticated and traffic protected IPSec sessions to the application servers. Additionally, you can encrypt the data payload between the DirectAccess client and an application server, by changing the data protection (quick mode) settings. Intranet application servers that are not included in AD DS security groups that use the end-to-end access model are still accessible using the end-to-edge access model.
47
End-to-edge Access Model
In end-to-edge access mode, the DirectAccess client uses IPSec to create two encrypted tunnels to the Internet-facing interface of the Forefront UAG DirectAccess server. The first tunnel, known as the infrastructure tunnel, uses computer authentication and allows the DirectAccess client to access AD DS domain controllers, DNS servers, and other management servers. The second tunnel, known as the intranet tunnel, allows the DirectAccess client to access intranet resources, and uses both computer and user authentication. The following are the benefits of the end-to-edge access model: It does not require IPSec-authenticated traffic in the enterprise network. It allows access to IPv6-capable application servers and applications on the intranet, in a native IPv6 infrastructure or when using ISATAP. It allows access to non-IPv6 capable application servers and applications on the intranet, when using NAT64 and DNS64. It enables access to servers that do not support IPSec. It closely resembles current VPN architecture and is typically easier to deploy. It is configurable with the Forefront UAG DirectAccess Configuration Wizard. It can be used with smart cards for an additional level of authorization.
A limitation of the end-to-edge access model is that it fails to provide end-to-end authentication or data protection with intranet application servers.
48
End-to-end Access Model
The end-to-end access model is similar to the end-to-edge model described above, with one important addition. Communication between the DirectAccess clients and the Forefront UAG DirectAccess servers is still protected by IPSec-based tunnel policies requiring encryption and authentication, but this model adds an additional authentication mechanism. By creating an additional IPSec transport rule requiring IPSec authentication between the DirectAccess client and the application server, the clients communications will be encrypted to the Forefront UAG DirectAccess server, but authenticated all the way to the application server. This allows clients to maintain a high degree of confidence that they are communicating with the server they think they are communicating with. This model also makes it easy to create restriction policies to prevent certain users or applications from being able to access certain servers. When selecting application servers that require end-to-end encryption and authentication, it is important to note that: The selected end-to-end application servers must run Windows Server 2008 or later. The selected end-to-end application servers must be members of one or more AD DS security groups. The selected end-to-end application servers can be used with smart cards for an additional level of authorization.
49
The following are the benefits of the end-to-end access model: It provides additional end-to-end authentication, data integrity, and data confidentiality beyond that provided with traditional VPN connections. The specified end-to-end application servers are configurable with the Forefront UAG DirectAccess Configuration Wizard.
A limitation of the end-to-end access model is that application servers included in the AD DS security group must run Windows Server 2008 or later.
50
Authentication and Authorization
By default, the Forefront UAG DirectAccess Configuration Wizard configures Windows Firewall with Advanced Security connection security rules that specify the use of the some types of credentials when negotiating the IPSec security associations for the tunnels to the Forefront UAG DirectAccess server. The infrastructure tunnel uses computer certificate credentials for the first authentication, and user (NTLMv2) credentials for the second authentication. User (NTLMv2) credentials are used to force the use of Authenticated Internet Protocol (AuthIP), and because the DirectAccess client needs Domain Name System (DNS) and domain controller access before it can use Kerberos credentials for the intranet tunnel. The intranet tunnel uses computer certificate credentials for the first authentication and user (Kerberos V5) for the second authentication.
You can also specify additional authentication with specified server access, peer authentication methods for end-to-end access, and the use of smart cards for additional authorization. The following sections describe the authentication and authorization design considerations to be taken when deploying a Forefront UAG DirectAccess solution.
Smart Cards for Additional Authorization

On the Authentication Options page of the Forefront UAG DirectAccess Wizard, you can require the use of smart cards for access to the intranet. When this option is selected, the DirectAccess Setup Wizard configures the IPSec connection security rule for the intranet tunnel on the DirectAccess server to require tunnel mode authorization with smart cards. Tunnel mode authorization is a new feature of Windows Firewall with Advanced Security for Windows 7 and Windows Server 2008 R2, which allows you to specify that only authorized computers and users can establish an inbound tunnel. 51
Smart card authorization works by enabling tunnel mode authorization on the intranet tunnel connection security rule of the Forefront UAG DirectAccess server, for a specific Kerberos-based security identifier (SID) in a DirectAccess clients Kerberos token. For smart card authorization, the authorized user is a well-known SID (S-1-5-65-1) that maps to smart-card-based logons. This SID is referred to as This Organization Certificate when configured in the global IPSec tunnel mode authorization settings. When you enable smart card authorization in the Authentication Options page of the Forefront UAG DirectAccess configuration Wizard, the wizard configures the global IPSec tunnel mode authorization setting with this SID for the Forefront UAG DirectAccess server Group Policy object. To view this configuration in the Windows Firewall with Advanced Security snap-in for the Forefront UAG DirectAccess server Group Policy object, do the following: 1. Right-click Windows Firewall with Advanced Security, and then click Properties. 2. On the IP Settings tab, in IPSec tunnel authorization, click Customize. 3. Click the Users tab. You should see the NT AUTHORITY\This Organization Certificate as an authorized user.
The DirectAccess client has access to the infrastructure servers even when smart card authorization is not successful. You can consider moving antivirus and Windows Server Update Services (WSUS) servers so that they are accessed in the infrastructure tunnel. This would enable you to update DirectAccess client antivirus settings even if the smart card authorization is unsuccessful.
Note:
Policy Enforcement with NAP

To encourage computers to comply with security and health requirement policies and reduce the risk of malware spreading, non-compliant clients can be restricted from accessing intranet resources or communicating with compliant computers. By using NAP with DirectAccess, IT administrators can require DirectAccess client computers to be healthy and comply with corporate health requirement policies. For example, client computers can obtain a connection to the DirectAccess server only if they have recent security updates, antimalware definitions, and other security settings. Using NAP in conjunction with DirectAccess requires that NAP-enabled DirectAccess clients submit a health certificate for authentication when creating the initial connection with the DirectAccess server. The health certificate contains the computers identity and proof of system health compliance. As previously described, an NAP-enabled DirectAccess client obtains a health certificate by submitting its health state information to an HRA that is located on the Internet. The health certificate must be obtained prior to initiating a connection to a DirectAccess server.
Additional End-to-End Peer Authentication for Specified Server Access

In the end-to-end access model, DirectAccess clients use Internet Protocol security (IPSec) transport mode rules to protect the traffic from the DirectAccess client to intranet resource servers. If you require end-to-end authentication and encryption to specified application servers, the Forefront UAG DirectAccess Configuration Wizard configures Windows Firewall with Advanced Security connection security rules on the DirectAccess clients to use computer certificate or computer (Kerberos V5)
52
credentials for the first authentication and user (Kerberos V5) credentials for the second authentication to the selected servers.
The end-to-end access model requires application servers to be domain-joined and run Windows Server 2008 or above.
Note:
53
Placement of the DirectAccess Server
Because Forefront UAG DirectAccess servers provide intranet connectivity to DirectAccess clients on the Internet, Forefront UAG DirectAccess servers are installed in your perimeter network, typically between your Internet-facing firewall and your intranet. The above figure shows an example. The Forefront UAG DirectAccess server has the following requirements: It must be joined to an Active Directory domain, running Windows Server 2008 R2, and have at least two physical network adapters installed. It must have at least two consecutive public IPv4 addresses assigned to the interface that is connected to the perimeter network, or in the absence of an Internet firewall, it must be connected directly to the Internet. Addresses in the ranges 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are private IPv4 addresses and cannot be used.
Two consecutive public IPv4 addresses are required so that the server can act as a Teredo server, and Windows-based Teredo clients can use the Forefront UAG DirectAccess server to perform detection of the type of network address translator (NAT) that they are behind.
Note:
The edge firewall should allow incoming traffic using IPv6 transition technologies (6to4, Teredo, and IP-HTTOS) from the Internet to the DirectAccess server.
54
Edge Firewall Port Requirements
When using additional firewalls on the edge, the following exceptions should be configured on the Internet-facing firewall for Forefront UAG DirectAccess traffic: Teredo traffic User Datagram Protocol (UDP) destination port 3544 inbound, and UDP source port 3544 outbound. 6to4 traffic Protocol 41 inbound and outbound. IP-HTTPS Transmission Control Protocol (TCP) destination port 443, and TCP source port 443 outbound.
55
Design of the Network Location Server
The network location server is a critical part of a Forefront UAG DirectAccess deployment. If DirectAccess client computers on the intranet cannot successfully locate and access the secure Web page on the network location server, they might not be able to access intranet resources. When DirectAccess clients obtain a physical connection to the intranet or experience a network status change on the intranet (such as an address change when roaming between subnets), they attempt an HTTPS connection to the location in a configured URL. If they can obtain an HTTPS connection to the location in the configured URL, including a revocation check of the Web servers certificate, they determine that they are on the intranet. This will disable NRPT on the client and switch Windows Firewall to its Domain profile, with no IPSec tunnels in place. The recommended configuration for a network location server is a highly available and, depending on the number of DirectAccess clients, high-capacity intranet Web server. The Web server must be able to support HTTPS-based URLs with certificate-based authentication. Internet Information Services 7.0, included with Windows Server 2008 R2 and Windows Server 2008, can be used as a network location server. The content of the HTTPS-based URL is not important, only the DirectAccess clients ability to successfully access the page at the URL.
DirectAccess only supports a single URL for network location determination. Note:
To ensure the availability of the network location server, it is recommended that it is physically located in a site with reliable network connectivity to the entire internal network. Organizations should also
56
ensure that the SSL certificate used by the site remains valid so internal DirectAccess clients are able to validate the site identity.
To ensure that the FQDN of the network location server is reachable for a DirectAccess client with Forefront UAG DirectAccess-based rules in the NRPT, the Forefront UAG DirectAccess Configuration Wizard by default adds the FQDN of the network location server as an exemption rule to the NRPT. When the DirectAccess client attempts to resolve the FQDN of the network location server, the FQDN matches the exemption rule in the NRPT and the DirectAccess client uses interface-configured DNS servers, which are reachable to resolve the name and connect to the network location server.
Note:
57
Design Public Key Infrastructure
DirectAccess requires a public key infrastructure (PKI) in place to provide certificates for mutual IPSec computer authentication, as well as authentication of the network location server and the IP-HTTPS servers. Optionally users can be required to use smart card certificates for two-factor authentication for the IPSec intranet tunnel. The following certificates are used by DirectAccess: The DirectAccess server needs to have a machine certificate for IPSec computer authentication, and a Web SSL server certificate to authenticate its IP-HTTPS connections. The machine certificate should have the computer FQDN DNS name in its subject name, while the IP-HTTPS should have the URL used for client connections. The network location server should have a Web SSL server certificate with the URL used for client connections in its subject. Internal clients should be able to retrieve the certificate revocation information for the network location server certificate in order to validate its identity. DirectAccess clients need to have a machine certificate for IPSec computer authentication. The subject name in the certificate should contain the DNS name of the client computer as defined in Active Directory.
If DirectAccess is integrated with NAP, DirectAccess clients will also use a health certificate issued through NAP health registration authority (HRA) servers.
Note:
58
In the end-to-end access model, application servers also need to have a machine certificate for IPSec computer authentication. If smart card authentication is required, users should have a trusted smart card certificate with the user Active Directory user principal name (UPN) in the subject alternative name (SAN) attribute of the certificate.
Since all computers in a DirectAccess deployment are domain-joined, there is no need to use a public (commercial) PKI to issue the certificates. An internal PKI implemented using Windows Certificate Services can be deployed to issue all the required certificates, using the Autoenrollment feature to automatically issue and renew the computer IPSec certificates.
If youre using an internal PKI to issue the Web SSL server certificate used for the IP-HTTPS server, the PKI should have an externally accessible certificate revocation list distribution point (CDP) to allow external clients to validate the certificate. If the CDP uses a URL in an internal DNS namespace, you will need to exempt the CDP DNS name in the NRPT.
Note:
59
Lesson 3 Review
Lesson 3 covered the requirements for deploying a DirectAccess solution using Forefront UAG, and the considerations involved in designing the solution. You should now be able to: List the steps involved in designing a DirectAccess solution. Explain the options available for deploying IPv6 to an internal network. Understand the issues involved in planning DNS name resolution for DirectAccess clients. Understand where to place the Forefront UAG DirectAccess servers and the network location servers.
60
Lesson 4 Deploying DirectAccess Using Forefront UAG

This lesson covers the steps involved in configuring DirectAccess on a Forefront UAG server, and some of the post-deployment configuration steps for client configuration. Lesson Objectives After completing this lesson, you will be able to: Describe the requirements for configuring DirectAccess using Forefront UAG. Understand how to use the Forefront UAG DirectAccess Wizard. Explain the post-deployment configuration steps.
61
Infrastructure Requirements
The following lists the prerequisites for deploying Forefront UAG DirectAccess on single servers, and multiple servers that use Forefront UAG DirectAccess integrated Network Load Balancing (NLB). For Active Directory, the following requirements apply: Global or universal security groups for Forefront UAG DirectAccess clients. In an end-to-end access model deployment, global or universal security groups for application servers.
The following infrastructure servers are required: At least one domain controller running Windows Server 2003 upwards, and a DNS server that supports dynamic updates. DNS servers that do not support dynamic updates can be used, but entries need to be manually updated.
If ISATAP will be deployed internally, the ISATAP name should be unblocked in the DNS servers.
Note:
62
The following PKI requirements should be in place to support a DirectAccess deployment: Install and configure a Certification Authority (CA) for issuing client authentication certificates. Provision a machine certificate to all Forefront UAG DirectAccess clients and servers.
You may choose to provision the certificates by enabling domain certificate Autoenrollment for Forefront UAG DirectAccess clients, using their security group and Group Policy.
Note:
Provision an IP-HTTPS certificate to the Forefront UAG DirectAccess server. The certificate subject should be the public URL of the Forefront UAG DirectAccess server or array. In case of an array deployment, the certificate should be installed in all array nodes. If the IP-HTTPS is issued by an internal PKI, a certificate revocation list (CRL) distribution point (CDP) should be reachable from a publicly resolvable FQDN.
For the network location server, the following requirements apply: A Web server with high availability, and a valid SSL certificate trusted by the DirectAccess clients.
Do not configure your Forefront UAG DirectAccess server as the network location server.
Note:
63
DirectAccess Deployment Requirements
The Forefront UAG DirectAccess server has the following requirements: It must be running Windows Server 2008 R2 Standard (RTM release) or Windows Server 2008 R2 Enterprise (RTM release). It must be joined to an Active Directory domain. It must have two physical network adapters installed. The network adapters should be configured as Internal and External in the Forefront UAG Getting Started Wizard, and the external adapter should have two consecutive public IPv4 addresses. The internal adapter should have a static IPv4 address for NAT64. If your organization has an internal IPv6 deployment, ensure that you configure an internal static IPv6 address.
When configuring your TCP/IP properties on the Forefront UAG DirectAccess server, do not configure Internet DNS servers on any of the Forefront UAG DirectAccess server interfaces, as this could cause DNS64 performance degradation.
Note:
IPv6 transition technologies should not be disabled.
A Forefront UAG DirectAccess client has the following requirements: It must be running Windows 7 Enterprise or Windows 7 Ultimate. It must be joined to an Active Directory domain. The internal DNS namespaces should be configured in its DNS suffix search order.
64
In an end-to-end access model deployment, the following requirement applies to application servers: Servers should be running Windows Server 2008 or Windows Server 2008 R2 operating systems.
65
DirectAccess Configuration Wizard
The Forefront UAG DirectAccess Configuration Wizard guides you through the configuration stages of the Forefront UAG DirectAccess deployment. After completing the Forefront UAG Configuration Wizard, you have the option to apply the configuration, or to save the configuration settings to an export script. You can view or modify the export script and, when ready, run the script from a Windows PowerShell command prompt.
Running the configuration script to apply the settings requires Domain Admin privileges for the domain.
Note:
66
DirectAccess Setup Wizard

Step 1 DA Client Configuration
Forefront UAG DirectAccess use Active Directory Group Policies to create, distribute, and apply DirectAccess settings to clients. You must create or use an existing Active Directory Domain Services security group (or groups) that contain the computer accounts for the computers that you want to receive DirectAccess settings. Select a security group (or groups), and add it to the list in the Forefront UAG DirectAccess client configuration screen. The Forefront UAG DirectAccess Configuration Wizard automatically creates Group Policy objects (GPOs) with the appropriate settings, and applies them to the specified security groups.
The security group's scope must be universal or global. Universal security groups can contain computer accounts from multiple domains. For all domains that have computer accounts in the specified security groups, you must add the domain controllers to the list of management servers and domain controllers,
Note:
1. In the Forefront UAG Management console, click DirectAccess to start the Forefront UAG DirectAccess Configuration Wizard. 2. From the Forefront UAG DirectAccess Configuration Wizard, in the Clients box, click Configure. 3. Click Add, select the security group(s) containing the computer accounts you want to enable for DirectAccess configuration, click OK, and then click Finish. Clicking Remove removes the currently selected security group from the list.
67

When security groups are added in the Client Configuration section of the wizard, the domains of the client computers held in the security group are provisioned to receive settings from the GPO. If a client from an additional domain (not present as a client domain when the GPO was created) is added to the specified security group, it is not automatically linked to the GPO so the client will not receive GPO settings. The same is true of a client whose domain is not included in the first level of nesting of the security group.
Important:
To link additional user domains, do the following: 1. At the end of the Forefront UAG DirectAccess Configuration Wizard, click Export Script and save the script, for example script.ps1. 2. On the taskbar, click Start, click All Programs, click Accessories, click Windows PowerShell, right-click Windows PowerShell, and then click Run as administrator. 3. From the PowerShell command prompt type the command:
./script.ps1 AdditionalClientDomains "DC=corp, DC=contoso, DC=com|DC=corp2, DC=contoso, DC=com"
and then press ENTER. DC=corp, DC=contoso, DC=com represents a domain, and each domain you want to link is separated by a pipe symbol ( | ).
68
Step 2 DA Server Configuration
The second step in the DirectAccess Setup Wizard is to define the configuration settings for the Forefront UAG DirectAccess server itself. From the Forefront UAG DirectAccess Configuration Wizard, in the DirectAccess Server box, click Configure. If Forefront UAG is configured as an array, the DirectAccess Setup Wizard will display the load balancing page configuration page. Forefront UAG DirectAccess supports two methods of load balancing: Windows Network Load Balancing Integrates the NLB functionality provided by Windows Server 2008 R2 with additional functionality provided by Forefront UAG, enabling the load balancing of Forefront UAG DirectAccess servers. External Load Balancing Uses an external load balancing solution that enables the load balancing of Forefront UAG DirectAccess servers.
Select the load balancing method to use, and then click Next to proceed to the Connectivity page.
Install the Windows KB977342 hotfix on all Forefront UAG DirectAccess array members to provide ISATAP connectivity when integrated Windows Network Load Balancing is configured.
Note:
On the Connectivity page you should select IP addresses for the following: First Internet-facing IPv4 address The IPv4 address that services 6to4, Teredo server, Teredo relay, and IP-HTTPS traffic.
69
Second Internet facing IPv4 address The IP address that, together with the first Internetfacing IPv4 address, services Teredo server traffic. This address is automatically assigned and is the next consecutive IPv4 address; for example, when the first Internet-facing IPv4 address is 192.0.2.18, the second IPv4 address is 192.0.2.19.
Two consecutive public IPv4 addresses are required so that the Forefront UAG DirectAccess server can act as a Teredo server, and the Windows-based Teredo clients can use the Forefront UAG DirectAccess server to detect the type of network address translator (NAT) that they are behind.
Note:
The first and second Internet-facing IPv4 addresses are also used to generate IPv6 addresses, using the 6to4 prefix for the IPSec dynamic tunnel endpoint (DTE). Internal IPv4 address This address is used when an ISATAP router is deployed on the Forefront UAG DirectAccess server.
When there is no IPv6 infrastructure on your intranet, the Forefront UAG DirectAccess server is automatically configured as an ISATAP router. It automatically derives 6to4-based organization, IP-HTTPS, and NAT64 IPv6 prefixes, and skips the Prefix Configuration screen of the Forefront UAG DirectAccess Configuration Wizard.
Note:
Internal IPv6 address The IP address that services IPv6 internal traffic.
Your choice of internal IPv4 or IPv6 addresses depends on whether you will be running an ISATAP router on your internal network, and if so, whether the router will be hosted on the Forefront UAG server or on a separate server: If IPv6 is not deployed in your organization, and no ISATAP deployment is required, you should select an internal IPv6 address so an ISATAP router is not enabled on the Forefront UAG server. Create a fictitious internal IPv6 address and assign it to the internal network facing card. If native IPv6 is already deployed in your organization, and no ISATAP deployment is required, simply select a native IPv6 address. If ISATAP is deployed on the Forefront UAG DirectAccess server in an IPv4 only environment, select an IPv4 address. This IPv4 address will be configured as the ISATAP router for the internal network. After activating Forefront UAG, register ISATAP in a DNS server within each domain using the internal IPv4 address (for example, ISATAP.corp.contoso.com). When configured as an NLB array, add each array member's internal IPv4 DIP (in addition to the internal IPv4 VIP) to the ISATAP DNS record. An ISATAP is deployed in your organization on a separate server, and the Forefront UAG DirectAccess server connects to the internal network using Native IPv6, select a native IPv6 address.
70

It is not supported to have ISATAP is deployed in your organization on a separate server, and the Forefront UAG DirectAccess server being a client of the ISATAP router. This may cause asymmetric routing and connectivity problems, and it is recommended that customers in this configuration consider deploying native IPv6.
Important:
After defining the Internet-facing and Internal addresses, click Next to proceed to the Managing DirectAccess Services page. On this page, you can set the IPv6 prefixes for your organization, IP-HTTPS clients, and NAT64, as well as enable or disable NAT64 and DNS64 translation.
If you are using Forefront UAG for NAT64 and DNS64, ensure that you use the Forefront UAG DNS64 IP address when adding DNS suffixes to the NRPT.
Note:
On the Prefix Configuration page, type the following IPv6 prefixes: Organization IPv6 prefix The 48-bit IPv6 prefix that your internal network uses. You can configure Forefront UAG DirectAccess with single or multiple Organization IPv6 prefixes. For a single Organization IPv6 prefix, type the 48-bit IPv6 prefix that your internal network uses. For multiple Organization IPv6 prefixes: 1. Click Multiple prefixes. 2. To add an additional prefix, click Click here to add, and type the new prefix. 3. To delete one of the multiple prefixes, select the prefix record, and then press DELETE.
The IP-HTTPS (/56) and NAT64 (/96) prefixes can be subsets of any of the multiple prefixes.
Note:
IPv6 prefix for addresses assigned to remote client computers connecting using IP-HTTPS (/56 to /64) The prefix that is used by computers connecting using IP-HTTPS. You can use any prefix within the range /56 to /64, depending on the number of array members you want to configure. This prefix must be a subset of the 48-bit Organization IPv6 prefix. The IP-HTTPS prefix is also used to configure the number of array members that can be used by Forefront UAG DirectAccess. The IP-HTTPS prefix should be enough to allocate one /64 prefix for each member of the Forefront UAG in the array. For example, a /64 prefix can support only one Forefront UAG DirectAccess server in the array, a /63 a maxim two servers, a /63 a maximum of four servers, and a /62 prefix a maximum of eight servers in the array. IPv6 prefix for addresses assigned for IPv4-only internal network resources using NAT64 and DNS64 (/96) The prefix used by the NAT64 to assign IPv6 prefixes to computers that only support IPv4. You must use a 96-bit prefix which is a subset of the 48-bit Organization prefix.
After setting the IPv6 prefixes and confirming the use of NAT64 and DNS64, click Next to move to the Authentication Options page.
71
In the DirectAccess Server section of the wizard, on the Authentication Options page: 1. Select the root or intermediate certificate that verifies certificates sent by DirectAccess clients, as follows: To use a root certificate, click Browse, select the required root certificate, and click OK. To use an intermediate certificate, click Use intermediate certificate, click Browse, select the required intermediate certificate, and then click OK.
2. To select the certificate that authenticates the Forefront UAG DirectAccess server to a client connecting using IP-HTTPS, click Browse, select the required IP-HTTPS certificate, and then click OK. 3. If you need to change the IPSec cryptography settings, click Edit IPsec cryptography settings and select the relevant Integrity, Encryption and Key exchange algorithm, and then click OK. 4. Select the following authentication options, if deployed in your organization: a. Clients that log on using a PKI smart card When selected, client endpoints must use PKI smart cards. b. Computers that comply with your organization's NAP policy When selected, NAP policy is applied to client endpoints. 5. Click Finish.
72
Step 3 Infrastructure Server Configuration
In the Infrastructure Server Configuration page you are able to define the network location server, the internal DNS suffixes and local name resolution behavior on the DirectAccess client, and which management servers and DCs will be accessible through the IPSec Infrastructure tunnel.
Defining the Network Location Server

1. From the Forefront UAG DirectAccess Configuration Wizard, in the Infrastructure Servers box, click Configure. This will open the Network Location Server page. 2. Type the HTTPS URL, click Validate, and then click Next.
The HTTPS URL should be entered as an FQDN. It is recommended that the network location server function is installed on a server with high availability, and you should ensure that the network location server will not be accessible to DirectAccess clients when they are connecting from the Internet.
Note:
73
Defining the Internal DNS Suffixes

On the DNS Suffixes page, follow the instructions below to add, edit, or delete entries in the NRPT. To add entries in the NRPT: 1. Right-click an empty row, and then click New. Alternately, you can double-click an empty row. 2. In the Name Resolution servers used by DirectAccess dialog box, select DNS suffix, or Specific Server, and then type a DNS suffix, or a specific server. If you want to use the Forefront UAG DNS64 server IP address when resolving names ending with the DNS suffix, click OK.
This is the default option, and is used in most cases. Note:
If you want to create an exemption entry, click Do not use an internal DNS server for the specified server or suffix, and click OK. If you want to use another DNS server IP address when resolving names ending with the DNS suffix, click Other DNS server IPv4 or IPv6 address, click Click here to add, and type the IP address of the internal DNS server. Click Validate, to confirm that the DNS servers are running and reachable from the Forefront UAG DirectAccess server, and if the validation is successful, then click OK.
You can also manage lists of multiple DNS server IP addresses for a DNS suffix. Note:
To edit an entry in the NRPT, right-click the entry, and then click Edit. Alternately, you can double-click the existing entry. Edit the IP address, and then click OK. To delete an entry from the NRPT, right-click the entry, and then click Delete.
Configuring Local Name Resolution Behavior

1. Still on the DNS Suffixes page, select a local name resolution option from the following: Only use local name resolution if the name does not exist in DNS (most restrictive) This is the most secure option, because the DirectAccess client will only send DNS queries to Internet-facing DNS servers for server names that cannot be resolved. Fall back to local name resolution if the name does not exist in DNS or the DNS servers are unreachable when the client computer is on a private network (recommended) This option is recommended because it allows the resolution of names on a separate internal network.
74
Fall back to local name resolution for any kind of DNS resolution error (least secure) This is the least secure option, because the names of internal network servers that the DirectAccess client is attempting to resolve can be sent out to Internet-facing DNS servers. This could result in an eavesdropper between the DirectAccess client and the Internet-facing DNS server determining the names of internal network servers.
2. Click Next.
Defining Management Servers and DCs

1. In the Infrastructure Servers section of the wizard, on the Management Servers and DCs page, you can add, or delete a management server or domain controller. a. To add a management server subgroup, in the left pane, right-click on Management, click Add Group to 'Management', type a new management group name, and then click OK. b. To add a new domain, in the left pane, right-click Domains, click Add Domain to 'Domains', type a new domain name, and then click OK.
All domain controllers in a domain are automatically discovered and selected when you add a new domain to the Domains management group. Click the Refresh icon to update the domain controller list. If a domain controller does not appear in the domain controller list, create a subgroup called Custom Domain Controllers, and add the domain controller to that group. To include or exclude a domain controller, in the left pane, click on the relevant domain in the Domains management group, and in the right pane, select or clear the relevant domain controller check box.
Note:
c. To add a management server, in the left pane, right-click a management server subgroup, click Add Server, type a server name, IP address or IPv6 prefix, and click OK. You can add multiple management servers by then clicking on Add Multiple Servers. d. To delete a management subgroup, domain, or a management server, right-click the item you want to delete, and click Remove. 2. Click Finish after you add all management servers.
75
Step 4 Application Server Configuration
Forefront UAG DirectAccess uses the following access models: End-to-edge Allows DirectAccess clients to connect to all resources inside the intranet. It does this by using IPSec-based tunnel policies that require authentication and encryption until the Forefront UAG DirectAccess server. The IPSec sessions terminate by default at the Forefront UAG DirectAccess server, which also functions as the IPSec Gateway. End-to-end Extends the endto-edge IPSec policies all the way to the specified application servers. The DirectAccess clients use an IPSec transport policy that requires that the authentication and traffic protection of IPSec sessions is terminated at the specified application servers. In this case, the Forefront UAG DirectAccess server forwards the authenticated and traffic protected IPSec sessions to the application servers. Additionally, you can encrypt the data payload between the DirectAccess client and an application server by changing the data protection (quick mode) settings.
To enable end-to-end authentication and encryption for specified servers, on the Application Server Configuration page: 1. Select the Require end-to-end authentication and encryption to specified application servers option. 2. If you need to change the IPSec cryptography settings, click Edit IPsec cryptography settings, select the relevant Protocol, Integrity and Encryption, and then click OK. 3. Click Add, select the security group(s) containing application servers that you want to enable for end-to-end authentication and encryption, click OK, and then click Finish. Clicking Remove removes the currently selected security group from the list. 76
Note:
Application servers added to the application server security group must be running Windows 2008 or above.
It is important to note that applications servers that are added to security groups after the GPO has been generated are not automatically updated in the DirectAccess client application server list. This means that any new application server added to the security group, or any application server that has its IP address changed after the GPO has been generated, is inaccessible to the DirectAccess client in both clear and encrypted modes. To resolve this, after adding a new application server to the specified security group, or after changing the IP address of an application server, do the following: 1. From the Forefront UAG DirectAccess Configuration Wizard, in the Application Servers box, click Edit, and then click Finish. 2. Click Generate Policies and click Apply Now.
77
Applying the Configurations
After you have completed the Forefront UAG DirectAccess Configuration Wizard, from the main Forefront UAG DirectAccess Configuration screen, click Generate Policies. The Forefront UAG DirectAccess Configuration Review appears. Select one of the following options: Apply Now Places the configuration settings into the Group Policy objects (GPOs). To apply the GPO on the Forefront UAG DirectAccess server, from the Windows command prompt run the command: gpupdate /force.
This can only be performed by a domain administrator. If clients from other domains are included in the client computer security groups, the domain administrator must also have link permissions to the additional domains.
Note:
Print Review Creates a reader friendly summary of the proposed configuration settings.
In the Forefront UAG Management console, click the Activate configuration icon, and then on the Activate Configuration dialog box, click Activate to activate the configuration. You also have the option to export a DirectAccess PowerShell configuration script that can be saved, forwarded and then applied by a domain administrator. To export the configuration settings, click Export Script. To run a script, the domain administrator must ensure that the computer can run unsigned scripts, as follows:
78
1. On the taskbar, click Start, click All Programs, click Accessories, click Windows PowerShell, right-click Windows PowerShell, and then click Run as administrator. 2. From the PowerShell command prompt, type setexecutionpolicy unrestricted, and press ENTER twice. 3. From the PowerShell command prompt, run the script containing the Forefront UAG DirectAccess Configuration. Note that providing customized values for script parameters is not supported for this release. 4. When the script has finished running, from the Windows command prompt, run the command: gpupdate /force.
79
DirectAccess Wizard Outputs
The DirectAccess configuration script performs the following actions: Configures the IPv6 transition technologies on the Forefront UAG DirectAccess servers. Creates the following Group Policies on the Active Directory domain: o UAG DirectAccess: DaServer {GUID} GPO settings are applied to the UAG DA servers themselves. o UAG DirectAccess: Client {GUID} GPO settings are applied to the DA clients. DA clients are assigned to the security groups defined in the first step of the DirectAccess Configuration Wizard. o UAG DirectAccess: AppServer {GUID} GPO settings are applied to machines that included in the application servers groups.
The export script must be run by the domain administrator of the domain where the Forefront UAG DirectAccess server is deployed. The script creates the GPOs on the domain where the Forefront UAG DirectAccess server is deployed, and tries to link the GPO to any additional domains that DirectAccess clients specified in the Client security group belong to. When the domain administrator does not have link permissions to the additional domains, when run, the script displays a message including the domain names where the script failed to link to, and continues running.
80
The domain administrators of the domains where the script failed to link to the GPO should do as follows: 1. Click Start, click Administrative Tools, and then click Group Policy Management. 2. In the console tree, open the relevant forest, and right-click the domain where the script failed to link to. 3. Click Link an Existing GPO, and in Look in this domain, select the domain where Forefront UAG DirectAccess is deployed. This is where the GPOs reside. 4. In Group Policy objects, select all of the Forefront UAG DirectAccess GPOs, and click OK.
81
Provisioning DirectAccess Clients
For the initial provisioning, DirectAccess clients will need to apply the UAG DirectAccess: Client {GUID} Group Policy. This will require clients to have connectivity to their Active Directory domain controllers, either through physical access to the corporate network or through a virtual private network protocol such as SSTP.
New DirectAccess clients cannot be bootstrapped remotely over DirectAccess itself.
Note:
You can run the gpupdate /force command with administrative privileges on the client to force the Group Policies to be applied. You may need to restart the computer to make effective the settings defined in the Group Policy.
82
Disabling DirectAccess
If you want to prevent DirectAccess clients from accessing the organization using the Forefront UAG DirectAccess server, you can disable Forefront UAG DirectAccess. The following procedures describe how to disable and enable Forefront UAG DirectAccess: 1. In the Forefront UAG management console, click DirectAccess to start the Forefront UAG DirectAccess Configuration Wizard. 2. From the opening Forefront UAG DirectAccess Configuration Wizard page, click Disable. 3. In the Forefront UAG management console, click the Activate configuration icon, then on the Activate Configuration dialog box, click Activate. 4. If you want to remove Forefront UAG DirectAccess, you must also do the following: a. On the taskbar, click Start, click Administrative Tools, and then click Group Policy Management. b. From the Group Policy Management console, open Forest\Domains\domain\Group Policy Objects. c. Right-click each of the following objects, and click DELETE: UAG DirectAccess: AppServer{f7b77f47-7c33-4d8c-bb9a-a913c5675d8d} UAG DirectAccess: DaServer{ab991ef0-6fa9-4bd9-bc42-3c397e8ad300}
UAG DirectAccess: Client{3491980e-ef3c-4ed3-b176-a4420a810f12} d. Refresh Group Policies on your DA clients.
83
Lesson 4 Review
Lesson 4 covered the steps involved in configuring DirectAccess on a Forefront UAG server, and some of the post-deployment configuration steps for client configuration. You should now be able to: Describe the requirements for configuring DirectAccess using Forefront UAG. Understand how to use the Forefront UAG DirectAccess Wizard. Explain the post-deployment configuration steps.
84
Module 8 Review
This module provided an overview of DirectAccess, a technology enabled by Forefront UAG that provides seamless network access to Windows 7 clients. You should now be able to: Understand the benefits provided by DirectAccess to users and IT organizations. Describe the DirectAccess architecture and its components. Understand the requirements and design decisions involved in a DirectAccess solution using Forefront UAG. Configure DirectAccess using Forefront UAG.
85

50402A-ENU Module08

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

50402A-ENU Module08

Uploaded by

Copyright:

Available Formats

Implementing Forefront Unified Access Gateway 2010

Student Manual Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Lesson 1 DirectAccess Overview

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Networking and Access Landscape

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

UAG and DirectAccess Better Together

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Lesson 2 DirectAccess Solution Components

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Under the Hood: UAG DA Architecture

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Under the Hood: IPv6 Gateway

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

IPv6 Gateway Components

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Under the Hood: IPSec Tunnels

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

IPSec Tunnel Mode Configuration

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Name Resolution Policy Table (NRPT)

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Network Location Determination

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

DirectAccess Connection Process

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

How DirectAccess Works Connecting to Internal Server

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Internet and Intranet Traffic

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Two-factor AuthN using Smart Cards

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Exempting Users from Smart Card Authentication

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Lesson 3 Planning a DirectAccess Deployment

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Designing a DirectAccess Solution

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Identifying Resources Available to DA Clients

Infrastructure and Management Servers

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Designing Internal IPv6 Deployment

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess

Internal IPv6 Connectivity Options

Implementing Forefront Unified Access Gateway 2010 Module 8: DirectAccess