DirectAccess and UAG DirectAccess

Deployment Guide

DRAFT May 18, 2010

Written by: Reviewed by:

Tyson Kopczynski, CISSP, GSEC, GCIH, and MCTS Manish Kalra, Microsoft Rand Morimoto, Ph.D., MVP, MCITP, CISSP

Contents
What IS DirectAccess?............................................................................................................................... 3 Understanding DirectAccess ..................................................................................................................... 4 DirectAccess Connections ..................................................................................................................... 6 DirectAccess Access Models ................................................................................................................. 8 DirectAccess Components ................................................................................................................... 10 Planning a DirectAccess Deployment ..................................................................................................... 12 When to use DirectAccess ................................................................................................................... 12 DirectAccess Server Location .............................................................................................................. 13 Network Location Server ...................................................................................................................... 14 Certificate Revocation Checking .......................................................................................................... 14 High Availability .................................................................................................................................... 15 Completing a Basic DirectAccess Deployment ....................................................................................... 16 Making the Basic Infrastructure Changes ............................................................................................ 17 Configuring Windows Firewall for DirectAccess ................................................................................... 18 Configuring the Network Location Server ............................................................................................ 19 Certificate Auto-Enrollment .................................................................................................................. 20 Installing and Configuring DirectAccess ............................................................................................... 21 Finalizing the DirectAccess Configuration ............................................................................................ 26 Testing DirectAccess ............................................................................................................................ 26 Monitoring the DirectAccess Server ..................................................................................................... 29 What is UAG DirectAccess? .................................................................................................................... 31 Choosing DirectAccess or UAG DirectAccess ........................................................................................ 31 Completing a Basic UAG DirectAccess Deployment .............................................................................. 32 Making the Basic Infrastructure Changes ............................................................................................ 34 Configuring Windows Firewall for DirectAccess ................................................................................... 35 Configuring the Network Location Server ............................................................................................ 37 Certificate Auto-Enrollment .................................................................................................................. 38 Installing and Configuring UAG DirectAccess ...................................................................................... 39 Finalizing the DirectAccess Configuration ............................................................................................ 45 Testing DirectAccess ............................................................................................................................ 45 Monitoring the UAG DirectAccess Server ............................................................................................ 48 Configuring End-to-End Authentication ................................................................................................... 50 Summary.................................................................................................................................................. 52

What IS DirectAccess?
DirectAccess is a remote access feature that was introduced in Windows Server 2008 R2 and Windows 7 which provides seamless connectivity to internal organizational networks from remote systems without the need for traditional VPN add-on software. By deploying DirectAccess, organizations address several challenges found with most traditional VPN solutions, including the following: The need for the user to manually connect to the VPN. The delay the user experiences when connecting to the VPN while health checks are completed during the connection process. The need for the user to reconnect manually if an established VPN connection is lost. The inability to manage mobile computers unless they are connected to a VPN or physically within the internal network. The inability to granularly control which internal resources different users should have access to. The slow performance when all traffic (Intranet and Internet) is routed through the VPN connection.

As most IT organizations can attest to, these challenges add an additional amount of overhead to IT operations and cause users unneeded frustration when using traditional VPN solutions. To address these challenges, DirectAccess was designed around the primary concept that mobile computer should be always be connected to the Intranet. This means that when a mobile computer boots up a DirectAccess connection is automatically started. The connection process is transparent to the user and the user never needs to explicitly connect to DirectAccess. Therefore, health checks, software and operating system updates, and remote management can be performed without user interaction. In addition, DirectAccess hides all the connection processes from the users and can intelligently route Intranet versus Internet traffic. DirectAccess also has built-in options to control how DNS requests are handled, effectively bifurcating the Internet and Intranet traffic to avoid burdening the remote access connection and improving performance. In the end, DirectAccess achieves remote access to Intranet resources by creating an encrypted point-topoint tunnel for both the mobile computer and the remote userin this case, specifically a remote user on Windows 7to the internal enterprise network. The primary difference from traditional VPN solutions is that the connection process is transparent to the user. Once configured, the computer will automatically connect to the office from any available Internet connection. Therefore the user experience is almost identical to being in the office. In addition, through the use of the Windows Server 2008 R2 NPS server, remote-connected clients can now be securely managed similarly to internal client systems. Note Although positioned as an alternative to a VPN, the DirectAccess technology has all the elements of a VPN. It establishes a secure private tunnel through public networks using IPsec and certificates, with an end result functionally not much different from L2TP. The differences are mainly administrative rather than technical. DirectAccess uses IPv6, IPsec, and certificates to establish secure connections from the DirectAccess clients to Intranet resources via the DirectAccess server. To traverse public IPv4 networks, DirectAccess uses IPv6 transition technologies such as ISATAP, Teredo, and 6to4. Organizations that are planning to deploy DirectAccess will need to meet the following requirements: 3

The server running Windows Server 2008 R2 (Standard or Enterprise) needs to have two network cards: one attached to the Intranet and one attached to the Internet. The Internet network card must have two consecutive public IPv4 addresses. The Intranet resources and applications must support IPv6 or a third-party NAT-PT device must be deployed provide access to IPv4-only resources for DirectAccess clients. The DirectAccess clients need to be running Windows 7 (Enterprise or Ultimate); older clients are not supported. A domain controller and DNS server that the systems are connected to need to be running Windows Server 2008 SP2 or Windows Server 2008 R2. A PKI needs to be available to issue certificates with a published Internet available certificate revocation list (CRL).

These requirements are somewhat stringent and might prevent many organizations from deploying DirectAccess. However, for an organization with an up-to-date infrastructure, servers, and clients, DirectAccess can be an excellent remote access solution that is geared to answer the previously mentioned challenges with traditional VPN solutions. Note The listed requirements will vary slightly when using Forefront Unified Access Gateway (UAG). For example, a UAG server becomes the DirectAccess server and can act as the NAT64 and DNS64 device. Details about how UAG DirectAccess is deployed are discussed later in this deployment guide.

Understanding DirectAccess
DirectAccess is designed on top of IPv6 and requires that all endpoint devices support IPv6. As such, DirectAccess is one of the first remote access solutions to require end-to-end IPv6 support. However, in todays current network environments, IPv4 is still the prevalent Internet Protocol in use on the Internet today and within most internal enterprise networks. Therefore, this creates what is called an IPv4 gap (as shown in Figure 1) across which IPv6 enabled devices like DirectAccess clients need to communicate through.

FIGURE 1

The IPv4 gap between IPv6 devices.

To bridge this IPv4 gap, most organizations will need to use IPv6 transition technologies for their IPv6 enabled devices to communicate over DirectAccess. This, in effect, routes the IPv6 communications 4

through the IPv4 protocol stack, as shown in Figure 2. As visualized in the figure, the packets traveling down the IPv6 protocol stack take a sharp turn and move across the protocol stack to the IPv4 protocol stack, allowing them to transit the IPv4 network. On the other side, the same packets come in via the IPv4 protocol stack, but are routed to the IPv6 stack.

FIGURE 2

Bridging the IPv4 gap with transition technologies.

Communications between IPv6 devices like DirectAccess clients over IPv4 networks is accomplished with IPv6 over IPv4 tunneling. In tunneling, the IPv6 packets are encapsulated in an IPv4 packet by the source device and routed through the IPv4 network. When the encapsulated packet arrives at the boundary between the IPv4 and IPv6 networks, the IPv4 encapsulation is stripped off and the IPv6 packet continues on its way. The most common tunneling protocols are ISATAP, 6to4, and Teredo. Details about each of these tunneling protocols are as follows: ISATAPUsed for intra-site tunneling, ISATAP is designed to provide IPv6 connectivity between IPv6 devices within a single organization. When used, ISATAP will automatically assign IPv6 addresses within the organizations IPv4 intranet with mappings from each IPv4 address to a linklocal IPv6 address. 6to4The most popular IPv6 over IPv4 tunneling protocol, 6to4 is used for inter-site tunneling. To facilitate the IPv6 tunneling, 6to4 embeds an IPv6 packet in the payload portion of an IPv4 packet with protocol type 41. However, to use 6to4, the tunnel endpoint must have a public IPv4 address and the host is responsible for encapsulation of outgoing IPv6 packets and decapsulation of incoming 6to4 packets. TeredoWhile 6to4 is the most popular IPv6 over IPv4 tunneling protocol the public IPv4 address requirement makes it an unsuitable option for when hosts are behind a Network Address Translation (NAT) device. To solve this issue, Teredo is also an inter-site tunneling protocol where IPv6 packets are encapsulated within IPv4 UDP datagrams so that they can be routed through NAT devices and across the IPv4 internet.

For organizations that have not deployed IPv6, Microsoft Windows Server 2008 R2 and Windows 7 both natively support ISATAP, 6to4, and Teredo tunneling protocols. However, even while DirectAccess clients are using IPv6 transition technologies like Teredo or 6to4, the end-to-end communication is ultimately IPv6. Additionally, for access to internal IPv4 resources (which do not support IPv6), organizations can use Network Address Translation-Protocol Translation (NAT-PT) or NAT64/DNS64 devices. While Windows Server 2008 R2 does not currently include NAT-PT as a feature, a third-party device or Unified Access Gateway (UAG) DirectAccess can be used to implement NAT64/DNS64.

DirectAccess Connections
A DirectAccess connection actually consists of two separate connections from a client computer to an organizations internal network. Each of these connections, are IPsec Encapsulating Security Payload (ESP) tunnels as described in the following bullets: Computer tunnelThe computer tunnel is established first when the DirectAccess client starts up. This bi-directional infrastructure tunnel is authenticated with the computer certificate only and provides access to domain resources, such as domain controllers, DNS servers, and management servers. This tunnel is also used to apply the computer group policy and perform user authentication. Lastly, IT Administrators can also initiate manage out connections to the DirectAccess clients on the Internet allowing them to manage these clients in the same manner as clients on their Intranet. User tunnelThis tunnel, called the intranet tunnel, is authenticated with the computer certificate and the user credentials. By using this tunnel, a DirectAccess user is effectively on the internal network regardless of their location. Therefore, they can access internal resources in the same way any other Intranet host connects to those resources. This tunnel is also used to apply user group policy as well.

Both of these tunnels are established transparently to users and they do not have to present credentials above and beyond their normal Windows logon process to VPN into an organizations internal network. As shown in Figure 3, because these tunnels are fully independent a DirectAccess client will connect the intranet even when no user is logged on.

FIGURE 3

The two DirectAccess tunnels.

This allows the DirectAccess client to receive Group Policy remotely and be managed by the management servers in the intranet. When a user logs on, they are authenticating to the intranet and, thus, ensuring that users are subject to the latest requirements, password changes, and policies. In contrast, other VPN solutions typically have users authenticating using cached credentials against the local machine and then establishing the remote access connection.

IP-HTTPS
In some scenarios, the inter-site IPv6 transition technologies (6to4 and Teredo) may fail to allow IPv6 connectivity across the IPv4 Internet. For example, web proxy servers and firewalls on a DirectAccess clients current network connection may block encapsulated IPv6 traffic. To work around these scenarios, 6

Microsoft has developed a new method to encapsulate the IPv6 packets in an IPv4 header. This new IPv6 transition protocol is called IP-HTTPS and is supported on Windows 7 and Windows Server 2008 R2. Using the IP-HTTPS protocol, allows hosts to establish connectivity through a web proxy or firewall by tunneling IPv6 packets inside an IPv4-based HTTPS session. While this new protocol allows for ubiquitous DirectAccess connections regardless of the current network connection there is a distinct amount of overhead associated with having an IPsec tunnel encapsulated within an HTTPS tunnel. Therefore, a DirectAccess client will only use IP-HTTPS as a last ditch method to create a DirectAccess connection.

Internet versus Intranet Traffic with DirectAccess

One of the benefits of DirectAccess is the ability to separate the intranet traffic (destined for internal servers) from the Internet traffic (destined for external servers). This conserves the corporate bandwidth for access to corporate resources. By specifying the domains and subdomains for which the DirectAccess server provides access, traffic for those domains is directed through the DirectAccess connection. Other traffic is routed through the default routes and bypasses the DirectAccess connection. This is the highest performance configuration and is the default mode of operation. However, in some cases, administrators might want to have all traffic routed through the DirectAccess connection. Examples of this include organizations that want to control or monitor their client communications or prevent access to certain Internet sites. In these cases, the DirectAccess client can be configured to route all traffic through the DirectAccess connection.

DirectAccess Connection Process

When the DirectAccess client detects that it is connected to a networkthat is, a network transition such as the connection to a LAN, wireless access point, or other connection becomes active the client will step through its connection process. Details about this process are as follows: 1. The DirectAccess client attempts to connect to the NLS website. If it can reach the site, it determines that it is connected to the intranet and stops the DirectAccess process. If it cannot reach the NLS website, it determines that it is connected to the Internet and continues with the DirectAccess process. 2. The DirectAccess client establishes an IPsec tunnel to the DirectAccess server using IPv6. If there is an intervening IPv4 network, the client uses the Teredo or 6to4 protocols to tunnel IPv6 over IPv4. 3. If the DirectAccess client is unable to connect using the Teredo or 6to4 protocols, the client will attempt to connect using the IP-HTTPS protocol. 4. The DirectAccess client establishes an IPsec tunnel to the DirectAccess server using IPv6. The DirectAccess client and the DirectAccess server mutually authenticate using certificates in the process of setting up the IPsec computer tunnel. 5. The DirectAccess client contacts the domain controller and obtains the computer group policy. Note The user does not have to be logged on to the computer for this process to complete to this point in the process. 7

6. The DirectAccess user logs on or the logged-on credentials are used in conjunction with the certificates to establish the IPsec user tunnel. The user group policy is applied to the DirectAccess client. 7. The DirectAccess server begins forwarding traffic from the DirectAccess client to authorized intranet resources. This entire process is transparent to the user and requires no user interaction. In the event of an interruption in network connectivity, the DirectAccess client will reestablish the connection through this process when it detects network connectivity again.

DirectAccess Access Models

Because DirectAccess uses IPsec to protect communications IT Administrators need to decide where to terminate the IPsec tunnel. In DirectAccess the location of the IPsec termination is called an access model. There are two access models that can be used when deploying DirectAccess.

End-to-Edge Access Model

The end-to-edge access model of DirectAccess has the DirectAccess client establish an IPsec tunnel to the DirectAccess server. The DirectAccess server then forwards unprotected traffic to the intranet resources. This is the most common form of DirectAccess and closely follows a standard remote access methodology. Figure 4 shows the end-to-edge access model. Note that there is a single protected (solid line) connection through the tunnel to the DirectAccess server, which then is forwarded to each of the application servers in three separate unprotected (dashed line) connections.

FIGURE 4

End-to-Edge Access Model

The end-to-edge access model requires no IPsec support within the intranet, although the intranet resources still need to support IPv6 unless a NAT-PT or NAT64/DNS64 solution is being used. The following are the benefits of the end-to-edge access model: It does not require IPsec-authenticated traffic on the internal network.

It allows access to all IPv6-capable application servers and applications on the intranet (non-IPv6 capable application servers and applications if NAT-PT or NAT64/DNS64 is being used) regardless if they support IPsec. It closely resembles current VPN architecture and is typically easier to deploy. It is configurable with the DirectAccess Setup Wizard or Forefront UAG DirectAccess Configuration Wizard. It can be used with smart cards for an additional level of authorization. It fails to provide end-to-end authentication or data protection with intranet resources. Additional load is placed on the DirectAccess server because it is terminating the IPsec tunnel.

The following are the limitations of the end-to-edge access model:

End-to-End Access Model

The end-to-end access model of DirectAccess requires that DirectAccess clients establish an IPsec session in transport mode with each of the specified application servers that they connect to. In others words, traffic is protected end-to-end (hence the name) by an IPsec transport policy that requires that an authenticated IPsec session be terminated at the specified application servers. Figure 5 shows the endto-end access model. Note that there is a protected (solid line) connection through the tunnel and the DirectAccess server to each of the application servers. This indicates that there are separate IPsec sessions to each server, which are protected by using IPsec not only through the Internet but also through the intranet.

FIGURE 5

End-to-End Access Model.

By default the transport policy is configured to only require authentication based on the combination of a valid domain computer (DirectAccess client) and domain user. When in this mode, the IPsec session that is created only provides authentication and data integrity. If additional encryption of the data payload is needed, in addition to the IPsec tunnel between the DirectAccess client and DirectAccess server, then the transport policy can be modified to enforce encryption. The following are the benefits of the end-to-end access model:

It provides end-to-end authentication, data integrity, and data confidentiality, beyond that found with traditional VPN connections. It is configurable with the DirectAccess Setup Wizard or Forefront UAG DirectAccess Configuration Wizard. It can be used with smart cards for an additional level of authorization. Internal servers that are not part of the end-to-end access model can still be accessed using the endto-edge access model. Each selected server must be running Windows Server 2008 or Windows Server 2008 R2. Each selected server must be part of an Active Directory security group that is used to define access.

The following are the limitations of the end-to-end access model:

DirectAccess Components
DirectAccess leverages IPv6 along with PKI to provide a seamless secure connection to an organizations internal network. Therefore, to successfully use DirectAccess, IT Administrators will need to fully understand the various components that consist of a DirectAccess deployment. Details about these components for a basic DirectAccess deployment are as follows: DirectAccess serverThis is the server that connects to the internal network and the Internet. It has to be running Windows Server 2008 R2 with two physical interfaces: one on the public Internet and one for the internal network. The public interface must have two consecutive public IP addresses assigned to it. DirectAccess clientThis is a computer running Windows 7. It must be a domain member with a client authentication certificate. Corporate IPv6 networkThe IPv6 network to which DirectAccess clients will be connecting remotely. Certificate Authority (CA)The CA is used to issue the certificates that support the tunnel creation, authentication, and security. This certificate server must have a published certificate revocation list (CRL) or be using Online Certificate Status Protocol (OCSP) that is available internally and externally. Network Location Server (NLS)This is an HTTPS site that serves as the indicator to the DirectAccess client if it is connected to the Internet or the intranet. Active Directory and DNS serverThis server must be running Windows Server 2008 SP2 or Windows Server 2008 R2. The AD and DNS role can be separate servers, although most organizations will have these services on the same server.

Figure 6 shows the logical placement of the DirectAccess components and their various connections:

10

FIGURE 6

The logical placement of DirectAccess components.

If desired, smart cards or NAP protection can also be implemented for additional security if desired. However, in its most simple configuration, DirectAccess only requires that each client have a valid machine certificate for authentication to the internal network. This takes the place of a traditional username and password. Additionally, with a basic DirectAccess deployment, IPv6 is a requirement for an organizations internal network.

Network Location Server

The network location server (NLS) is a critical component for the DirectAccess architecture. This is a website that clients attempt to connect to determine if they are currently connected to the Internet or to the intranet. It is the URL of a highly available website in the corporate intranet. There are two behaviors that would be experienced for the DirectAccess client system. They are as follows: If the DirectAccess client can reach the network location server URL, it assumes that it is connected to the corporate network and no further action is necessary. If the DirectAccess client cannot reach the network location server URL, it assumes that it is not connected to the corporate network and then begins the DirectAccess connection process.

Given criticality to a DirectAccess deployment, the network location server should be deployed as a highly available website using some form of load balancing or clustering solution (Network Load Balanced (NLB) cluster or a Windows cluster). Note If the network location server Web site is not accessible, this can result in the disastrous situation of all the DirectAccess clients suddenly thinking they are on the Internet, even though they are really in the Intranet. When this occurs, all of the DirectAccess clients will begin the DirectAccess connection process. Thats why the network location server Web site must be highly available.

11

IPv4 Support, High Availability, and Centralized Management

In certain deployment scenarios the base DirectAccess functionality that is provided in Windows Server 2008 R2 may not be enough. For example, some deployments may require IPv4 support, high availability, and better centralized management. If this is the case, then organizations should deploy DirectAccess using Microsoft Forefront Unified Access Gateway (UAG) 2010.

Planning a DirectAccess Deployment

Deploying any information system can be a very challenging task. Unfortunately, DirectAccess is no exception as there a many different technologies that need to be understood when planning a DirectAccess deployment. While Microsoft has attempted to make DirectAccess as easy as possible to deploy and use, this also happens to be its Achilles heel. It is very easy for an IT professional to install and configure DirectAccess without fully understanding all of the underlying moving pieces that support DirectAccess as a solution. Therefore, it is also very easy for a DirectAccess deployment to not be properly planned out, thus leaving the solution open to failure either through having a failed DirectAccess installation or having DirectAccess at a later date. To help ensure that your DirectAccess deployment is successful, this section describes the DirectAccess related topics that should be considered as part of your deployment plan. For each topic covered there is background information, the importance to the DirectAccess deployment, and "best practice" design advice with the goal of helping IT professionals avoid planning mistakes that can prove to be costly and difficult to correct.

When to use DirectAccess

One of the first decisions that should be made while planning a DirectAccess deployment is if DirectAccess should even be used. With VPN technologies there are number of different choices, primarily whether to use L2TP/IPsec, PPTP, or even SSL based solutions. Some solutions are better than others depending on the remote access requirements that need to be met. Therefore when deciding which solution to use, you should have a clear understanding for how the VPN technology will meet your needs, what its advantages are over other solutions, and what disadvantages it might also have. With DirectAccess, the primary selling point is its transparent always-on remote access which allows users to always appear to be on the corporate network and appear as if they are in the office. In addition, it allows administrators to manage systems as local systems through tools like Group Policy and Microsoft System Center Configuration Manager (SCCM). From a user perspective, DirectAccess is the easiest remote access solution. Once configured, they dont need to perform any action; it just works. From an administrator point of view, however, DirectAccess may seem complex to install and manage due to the IPv6 and certificate requirements. Once you have decided if DirectAccess should be used, the next decision is to determine which version of DirectAccess to deploy. DirectAccess as a feature is built into Windows Server 2008 R2 and Windows 7 and can be deployed using just these base operating systems. However, while this type of deployment will have all of the benefits of DirectAccess, it is just a base deployment of DirectAccess which lacks IPv4 support, high availability, and centralized management. If these missing elements are requirements for your DirectAccess deployment, then you should deploy UAG DirectAccess which extends the benefits of 12

DirectAccess across your infrastructure, enhancing scalability and simplifying deployments and ongoing management. For example, UAG DirectAccess adds the following benefits to a DirectAccess deployment: The ability to support IPv4 and down-level Windows servers and non-Windows servers. The ability to provide SSL VPN access for down level (Vista/XP) and non-Windows clients as well as PDAs. The ability to increase capacity and provide high availability through the use of UAG arrays. The ability to manage the DirectAccess deployment through a centralized management interface. The ability to greatly simplify the initial deployment and ongoing management through the use of wizards and automated tools.

DirectAccess Server Location

The primary purpose for a DirectAccess server is to allow DirectAccess clients on the Internet to access internal intranet based resources. Therefore, a DirectAccess server must be located on a perimeter network such that its two physical network adapters are split between Internet and intranet traffic. However, a DirectAccess server does not need to be connected directly to the Internet. If an Internetfacing firewall is already in place the DirectAccess server can be placed between the firewall and your intranet. When planning for the DireactAccess server location the following requirements should be considered: The DireactAccess server must have at least two physical network adapters installed. The DirectAccess server must be joined to an Active Directory domain running Windows Server 2008 R2. The Internet facing network adapter must have at least two consecutive public Internet Protocol version 4 (IPv4) addresses. 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.

Provided that these requirements are met the location of a DirectAccess server within the network topology can be entirely based on your organizations needs. The only other major consideration is if additional firewalls will be between the DirectAccess server, DirectAccess clients, and the internal network. If additional firewalls are in place then the following firewall rules must be applied on those firewalls to allow DirectAccess traffic: Internet-facing (UAG DirectAccess server is on the IPv4 Internet) Teredo trafficUDP destination port 3544 inbound and UDP source port 3544 outbound. 6to4 trafficProtocol 41 inbound and outbound IP-HTTPSTransmission Control Protocol (TCP) destination port 443, and TCP source port 443 outbound Protocol 50 UDP destination port 500 inbound, and UDP source port 500 outbound Internet Control Message Protocol for IPv6 (ICMPv6) traffic inbound and outbound 13

Internet-facing (UAG DirectAccess server is on the IPv6 Internet)

Intranet-facing ISATAPProtocol 41 inbound and outbound TCP/UDP for all IPv4/IPv6 traffic ICMP for all IPv4/IPv6 traffic

Network Location Server

As discussed in the previous section, the network location server is critical component within a DirectAccess deployment. When DirectAccess clients experience a change with their network status they will attempt an HTTPS connection to the location in a configured URL for the network location server. If an HTTPS connection cannot be established or if the Web servers certificate fails a revocation check, then the DirectAccess client will determine it is on the Internet and attempt to create a DirectAccess connection. Because of its criticality, the recommended location/configuration for the network location server is on a highly available and, depending on the number of DirectAccess clients, high-capacity intranet Web server. This Web server can be Windows Server 2008 R2 and Windows Server 2008 running Internet Information Services. Or, it can be a third-party Web server that supports HTTPS-based URLs with certificate-based authentication. Also, the content that is located on the network location server is not important, instead only the ability for DireactAccess clients to access the defined URL. The certificate that is used for the network location server also has the following requirements: The Subject name must be defined as the FQDN of the network location URL. The Enhanced Key Usage must Server Authentication. Revocation information must be accessible to DirectAccess clients that are connected to the intranet

Certificate Revocation Checking

Certificate revocation information for certificates that are part of a DirectAccess deployment is another DirectAccess component that needs to be highly available. This is a requirement because the DirectAccess server uses revocation information to determine if a DirectAccess clients machine certificate is valid. In addition, DirectAccess clients check revocation information for the following scenarios: To validate DirectAccess server certificate for IP-HTTPS connections. To validate the certificate for the HTTPS connection to the network location server.

Therefore, in general, to ensure DirectAccess connectivity, certificate revocation information needs to be highly available both from the Internet and the intranet. However, the decision for the location or availability of revocation information actually depends on the certificate that is being used and from what CA it was issued from. For example, if the IP-HTTPS and network location server certificate is issued rd from a 3 party publicly trusted CA then, in theory, that CA will ensure that the revocation information is highly available. However, for certificates that are issued using your organizations PKI, then you will need to ensure that the locations defined within the issued certificates CRL Distribution Point (CDP) field and any referenced AIA OCSP responder URLs are highly available both from the Internet and the intranet. 14

High Availability
To both increase availability and capacity for a UAG DirectAccess deployment you can use a UAG array. These arrays, which use the Forefront TMG standalone array infrastructure, have the following characteristics: The array consists of multiple UAG servers that are joined into an array configuration. All of the array member share the same configuration (this includes trunks, portals, portal settings, endpoint policies, published applications, authentication servers, permissions, predefined and custom files, and VPN client (SSL network tunneling) settings). However, certain server specific settings are different (like IP addresses and passwords). A separate server is not needed for array management. Instead one of the array members is configured to act as the array manager which is used to make configuration and activation changes.

To provide high availability for an array you can either use an external hardware load balancer (which supports load balancing DirectAccess) or the Windows network load balancing (NLB) functionality that is integrated into Forefront UAG. When using a hardware load balancer up to 50 servers can be deployed in the array. However, when using the integrated NLB having only up to eight array members is recommended. Note When using a hardware load balancer UAG DirectAccess cannot act as an ISATAP router. If ISATAP functionality is still needed, then the ISATAP router function will need to be moved to a separate machine. When deploying a UAG DirectAccess NLB array there are a number of items that should be planned out. For example, the static virtual IP addresses (VIPs) and dedicated IP addresses (DIPs) need to be defined: An Internet-facing static IPv4 address (DIP). An internal network facing static IPv6 address (DIP). An internal network facing static IPv4 address (DIP). Two Internet-facing consecutive public IPv4 addresses (VIPs). An internal network facing IPv6 address (VIP). An internal network facing IPv4 address (VIP).

Additionally, for load balanced IPv6 traffic, UAG NLB must examine the IPv4 tunnel for all transition technologies. However, IP-HTTPS traffic is encrypted. Therefore UAG is not able to examine the IPv4 tunnel thus preventing the IP-HTTPS traffic from technically being load balanced. To work around this issue, you must allocate a wide enough IP-HTTPS IPv6 prefix for addresses assigned to remote client computers connecting using IP-HTTPS (/56 to /64). That way, UAG can assign a different IPv6 /64 prefix to each of the nodes. This prefix must be routable to the UAG DirectAccess array, and is configured using the UAG DirectAccess Configuration Wizard. The following table lists the number of array members available for each IP-HTTPS prefix: Prefix Number of Array Members

15

/64 /63 /62 /61

1 2 3 or 4 5-8

Completing a Basic DirectAccess Deployment

Although the prerequisites and associated technologies for DirectAccess can be difficult to implement, the DirectAccess configuration itself is fairly straightforward and can be completed using a simple wizard. To illustrate how to complete a basic DirectAccess deployment this section walks through a deployment scenario using Windows Server 2008 R2. By completing this scenario the following goals will be accomplished: 1. Allow a workstation to seamlessly move between internal, public, and home networks while retaining access to application servers. 2. Enable IPv6 in an IPv4 network using IPv6 transition technologies. It is important to note that the scenario does not require that you have deployed IPv6 throughout your internal network to begin using DirectAccess. Instead, the scenario leverages Windows Server 2008 R2 and Windows 7 technologies that will automatically enable and configure IPv6 using transitional technologies like ISATAP, 6to4, and Teredo. This scenario assumes that Windows Server 2008 R2 Active Directory and DNS are already deployed. Additionally, the intended DirectAccess server must have two physical network interfaces. The first is connected directly to the Internet, no NAT, and must have two consecutive public IP addresses. The second interface is connected to the internal network. This scenario also assumes you have an internal enterprise PKI deployment with CRLs or an OCSP responder that is published on the Internet. For this scenario there are five servers and a client system as shown in Figure 7. These are the systems that will be configured and tested against during the scenario. A breakdown of the systems is as follows: AD01Domain controller, DNS, and enterprise Certificate Authority server running Windows Server 2008 R2. The Active Directory domain is contoso.com. The CA must have an Internet available certificate revocation list (CRL) or OCSP responder. DA01DirectAccess server and domain member running Windows Server 2008 R2, with two network interface cards, and two public IP addresses (12.155.166.2 and 12.155.166.3) assigned. Note The reason for two consecutive public IPv4 addresses on the DirectAccess servers public Internet interface is so that Teredo-based DirectAccess clients can detect the type of NAT that they are located behind. FILE01File server and domain member that the DirectAccess client is accessing. WEB01Web server and domain member that the DirectAccess client is accessing. This server also hosts the NLS Web site, using the URL https://nls.contoso.com.

16

NS01This server is the external DNS server and Web server that is hosting the CRL for the URL pki.contoso.com. CLIENT01DirectAccess client and domain member running Windows 7. This system will travel between the internal, public, and home networks.

FIGURE 7

DirectAccess Scenario.

The scenario assumes that split-brain DNS is being usedthat is, that there is an internal contoso.com zone and an external contoso.com zone. As such there should be a DNS A record for da01.contoso.com (12.155.166.2) in the external companyabc.com zone, as well as the DNS record for the CRL or OCSP responder for the certificate authority (typically pki.contoso.com). In addition, there are three networks in the scenario. The DirectAccess client is CLIENT01 and will be roaming between these networks and attempting to access WEB01 and FILE01. Details about the three networks are as follows: Internal networkThis is the corporate network and is using an IPv4 address in the 192.168.1.x range. Public networkThis is the Internet, and the servers being configured are using the IPv4 12.155.166.x range. Home networkThis is a network behind a NAT firewall, and the IP address range is not known.

Connectivity to WEB01 and FILE01 will be tested from the client (CLIENT01) while connected to the internal network, the public network, and, finally, to the home network. In all cases, the client should seamlessly transition between the networks with no interruption in access to internal resources.

Making the Basic Infrastructure Changes

The first task in a DirectAccess deployment is to modify the DNS service configuration and remove the ISATAP name from its default global block list. By making this change the DNS will be able to service ISATAP requests. Use the following steps to complete this task: 1. On DC01, open a PowerShell console session using the Run as Administrator option. 17

2. In the PowerShell console, execute the following command: dnscmd /config /globalqueryblocklist wpad Note The preceding command needs to be run on each DNS server on the internal network. In addition, it is important to understand that this command is only being executed because this scenario is using ISATAP for internal IPv6 support. Depending on your deployment needs, executing this command may or may not be required. The next task in the DirectAccess deployment is to create the NLS DNS record. This DNS record is used for the NLS URL that DirectAccess clients use to determine if they are in the corporate network. Use the following steps to complete this task: 1. On DC01, launch Server Manager. 2. Expand Roles\DNS Server\DNS\DC01\Forward Lookup Zones, and select the contoso.com zone. 3. Right-click contoso.com and then click New Host (A or AAAA). 4. In the Name field, type nls. In the IP address field, type the IP address of the NLS website, click Add Host, click OK, and then click Done. The last task in this section is to create a security group for DirectAccess client computers. This allows the DirectAccess clients to be defined within the DirectAccess configuration and apply specific DirectAccess Group Policy Objects. For this scenario the group will be named DirectAccessClients. Use the following steps to complete this task: 1. On DC01, launch Server Manager. 2. Expand Roles\Active Directory Domain Services\Active Directory Users and Computers\contoso.com and select the container that the new group object will be created within. 3. Right-click on the container, select New, and then click Group. 4. In the Group Name field, type DirectAccessClients. 5. Under Group scope, choose Global or Universal, under Group type, choose Security, and then click OK.

Configuring Windows Firewall for DirectAccess

The next task is to create and enable Windows Firewall rules that allow inbound and outbound ICMPv6 Echo Request messages. These rules are needed allow connectivity for Teredo-based DirectAccess clients that are behind a NAT. DirectAccess clients that are behind NATs on the Internet will attempt to use Teredo for IPv6 connectivity to the DirectAccess server. DirectAccess clients are Teredo clients to the DirectAccess server, which is acting as a Teredo server and relay. To ensure that a destination is reachable, Teredo clients send an Internet Control Message Protocol for IPv6 (ICMPv6) Echo Request message and wait for an ICMPv6 Echo Reply message. If ICMPv6 Echo Requests are not allowed, then the DirectAccess client will fall back on using IP-HTTPS to establish a DirectAccess connection. Use the following steps to create a GPO named DirectAccess ICMP which will be used to deploy the needed Windows Firewall rules: 1. On DC01, launch Server Manager. 18

2. Expand Features\Group Policy Management\Forest: companyabc.com\Domains and select contoso.com. 3. In the console tree, right-click the domain contoso.com and select Create a GPO in the Domain and Link It Here. 4. Enter the name DirectAccess ICMP and then click OK. 5. Right-click the DirectAccess ICMP Group Policy Object and select Edit. 6. In the console tree of the Group Policy Management Editor, expand Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security. 7. In the console tree, select and then right-click Inbound Rules, and then click New Rule. 8. On the Rule Type page, click Custom, and then click Next and Next. 9. On the Protocols and Ports page, for Protocol Type, select ICMPv6, and then click Customize. 10. In the Customize ICMP Settings dialog box, click Specific ICMP Types, select Echo Request, and then click OK. 11. Click Next, Next, Next, and Next. 12. On the Name page, in the Name field, type Inbound ICMPv6 Echo Requests, and then click Finish. 13. In the console tree, select and then right-click Outbound Rules, and then click New Rule. 14. On the Rule Type page, click Custom, and then click Next and Next. 15. On the Protocols and Ports page, for Protocol Type, click ICMPv6, and then click Customize. 16. In the Customize ICMP Settings dialog box, click Specific ICMP Types, select Echo Request, and then click OK. Click Next and Next. 17. On the Action page, click Allow the Connection, and then click Next and Next. 18. On the Name page, in the Name field, type Outbound ICMPv6 Echo Requests, and then click Finish. 19. Close the Group Policy Management Editor and the Group Policy Management Console.

Configuring the Network Location Server

The website used for the network location server (NLS) needs to support HTTPS and can be any website that is available internally, although it is a best practice that it be highly available. For the purpose of this scenario the server WEB01 will be used to host the NLS Web site. To complete the NLS configuration the first task is to ensure that the web server hosting the NLS Web site has a valid server authentication (SSL) certificate with customized subject and alternative name for the network location URL. Use the following steps to complete this task: 1. On WEB01 click Start, type mmc, and then press ENTER. 2. Click File, and then click Add/Remove Snap-in. 3. Click Certificates, click Add, select Computer account, click Next, select Local computer, click Finish, and then click OK. 4. In the console tree of the Certificates snap-in, expand Certificates (Local Computer)\Personal. 5. Right-click Certificates, point to All Tasks, and then click Request New Certificate. 6. Click Next twice. 19

7. On the Request Certificates page, click Web Server 2008, and then click More information is required to enroll for this certificate. 8. On the Subject tab of the Certificate Properties dialog box, in Subject name, for Type, select Common Name. 9. In Value, type nls.contoso.com, and then click Add. 10. In Alternative name, for Type, select DNS. 11. In Value, type nls.contoso.com, and then click Add. 12. Click OK, click Enroll, and then click Finish. Note Step 7 assumes that the Web Server 2008 certificate template was created beforehand. For the purpose of this scenario the Web Server 2008 template was a version 3 template that was duplicated from the version 1 Web Server template. The permissions for the Web Server 2008 certificate template were modified to allow Domain Computers to enroll for certificates based on this template and the private key can be exported. Lastly, the subject name and subject alternative name of a certificate can be specified during the request. Once the certificate has been installed the next task is to install the Web Server (IIS) role and configure the HTTPS security binding on the default Web site. Use the following steps to complete this task: 1. In the console tree of Server Manager, click Roles. In the details pane, click Add Roles, and then click Next. 2. On the Select Server Roles page, select the Web Server (IIS) check box, and then click Next three times. 3. Click Install. 4. Verify that all installations were successful, and then click Close. 5. Next, in Server Manager expand Web Server (IIS) and select Internet Information Services (IIS) Manager. 6. Next, expand WEB01\Sites, and then click Default Web site. 7. In the Actions pane, click Bindings. 8. In the Site Bindings dialog box, click Add. 9. In the Add Site Binding dialog box, in the Type list, click https. In SSL Certificate, click the certificate with the name nls.contoso.com. Click OK, and then click Close.

Certificate Auto-Enrollment
Once the network location server has been configured the next task in the DirectAccess deployment is to ensure that all domain members have a valid client authentication certificate. The steps to complete this task may vary depending on the overall certificate requirements for your environment. However, for the purposes of this scenario the following generic steps should be used: 1. On DC01, launch Server Manager. 2. Expand Roles\Active Directory Certificate Services and select Certificate Templates. 20

3. Select the Workstation Authentication certificate template. 4. Right mouse click the template and select Duplicate Template. 5. In the Duplicate Template dialog box select the Windows Server 2003 Enterprise option and click OK. 6. Next, define the name of the template as Contoso - Domain Machine Authentication. 7. Next, select the Security template and modify the Domain Computers permissions to include Autoenroll and click OK. 8. Now expand the Enterprise CA and right mouse click Certificate Templates, select New\Certificate Template to Issue. 9. In the Enable Certificate Templates dialog box choose the Contoso Domain Machine Authentication certificate template and click OK. Note The steps in this section assume that the needed GPO changes to enable auto-enrollment have already been made.

Installing and Configuring DirectAccess

The next task in the DirectAccess deployment is to complete the DirectAccess installation and configuration. To start this process you will first need to request a server authentication certificate that will be used for IP-HTTPS. Use the following steps to complete this task: 1. On DA01 click Start, type mmc, and then press ENTER. 2. Click File, and then click Add/Remove Snap-in. 3. Click Certificates, click Add, select Computer account, click Next, select Local computer, click Finish, and then click OK. 4. In the console tree of the Certificates snap-in, expand Certificates (Local Computer)\Personal. 5. Right-click Certificates, point to All Tasks, and then click Request New Certificate. 6. Click Next twice. 7. On the Request Certificates page, click Web Server 2008, and then click More information is required to enroll for this certificate. 8. On the Subject tab of the Certificate Properties dialog box, in Subject name, for Type, select Common Name. 9. In Value, type da01.contoso.com, and then click Add. 10. In Alternative name, for Type, select DNS. 11. In Value, type da01.contoso.com, and then click Add. 12. Click OK, click Enroll, and then click Finish. Note Step 7 assumes that the Web Server 2008 certificate template was created beforehand. For the purpose of this scenario the Web Server 2008 template was a version 3 template that was duplicated from the version 1 Web Server template. The permissions for the Web Server 2008 21

certificate template were modified to allow Domain Computers to enroll for certificates based on this template and the private key can be exported. Lastly, the subject name and subject alternative name of a certificate can be specified during the request. 13. In the details pane of the Certificates snap-in, verify that a new certificate with the name da01.contoso.com was enrolled with Intended Purposes of Server Authentication. 14. Right-click the certificate and select Properties. 15. In the Friendly Name field, type IP-HTTPS and click OK. Once the IP-HTTPS certificate has been installed the next task is to install the DirectAccess Management Console feature on DA01. Use the following steps to complete this task: 1. On DA01, launch Server Manager. 2. Right-click on Features and select Add Features. 3. On the Select Features page, select DirectAccess Management Console. 4. At the pop-up, click Add Required Features. This adds the Group Policy Management feature. 5. Click Next. 6. Click Install. 7. Click Close to finish. After the DireactAccess Management Console has been installed the next task is to complete the DirectAccess configuration using the DirectAccess Setup Wizard. To complete this task use the following steps: 1. On DA01, launch Server Manager. 2. Expand Features, DirectAccess, and select the Setup node. The screen will show the DirectAccess Setup Wizard, as shown in Figure 8.

FIGURE 8

DirectAccess Setup Wizard. 22

3. In Step 1 Remote Clients, click Configure. 4. On the DirectAccess Client Setup page, click the Add button. 5. In the Select Group dialog box, type DirectAccessClients and click OK. The screen will show the group, as shown in Figure 9.

FIGURE 9 6. Click Finish.

DirectAccess Client Setup.

7. In Step 2 DirectAccess Server, click Configure. 8. On the Connectivity page, for Interface Connected to the Internet, ensure that the correct interface is selected. For Interface Connected to the Internal Network, ensure that the correct interface is selected. The wizard will attempt to select the best interfaces based on the IP address ranges. In Figure 10, the public address 12.155.166.3 has been assigned to the Internet interface and the private address has been assigned to the internal interface.

FIGURE 10 DirectAccess Server Connectivity Setup. Note 23

The DirectAccess Setup Wizard has an informational note that it detected that the internal network is IPv4-based and will enable IPv6 transition technologies as part of the setup. The DirectAccess server will be configured as the ISATAP server. 9. Click Next. 10. On the Certificate Components page, for Select the Root Certificate to Which Remote Client Certificates Must Chain, click Browse. In the list of certificates, select the appropriate Root CA certificate, and then click OK. 11. For Select the Certificate That Will Be Used to Secure Remote Client Connectivity over HTTPS, click Browse. In the list of certificates, click the certificate named IP-HTTPS, and then click OK. The results are shown in Figure 11. Click Finish.

FIGURE 11 DirectAccess Server certificate components. 12. In Step 3 Infrastructure Servers, click Configure. 13. On the Location page, click Network Location Server Is Run on a Highly Available Server, type https://nls.contoso.com, click Validate, and then click Next. You should get a green check mark with a Validation Successful message. 14. On the DNS and Domain Controller page (shown in Figure 12), note the entry for the name contoso.com with the IPv6 address. This is the 6to4 IPv6 address for the DC01 domain controller. All DirectAccess client requests to the domain contoso.com will be forwarded to this domain controller. nls.consoto.com, da01.contoso.com, and pki.contoso.com are also listed with a blank DNS server which defines an NRPT exemption for these FQDNs.

24

FIGURE 12 DirectAccess Infrastructure Server Setup for DNS. Note The blank DNS for the network location server is needed so that DirectAccess clients can use the URL to determine if they are inside the corporate network or on the Internet. When inside the network, the DirectAccess clients will be able to access the site. When remote and connected via DirectAccess, the clients will be unable to reach the site due to the blank DNS entry, although they can reach all other internal resources. da01.contoso.com and pki.contoso.com have been added as NRPT exceptions because of the split-brain DNS configuration. If these exceptions were not added then clients would not be able to resolve these FQDNs when they were on an external network. 15. Click Next. 16. On the Management page, if there were internal management servers, such as Microsoft System Center Configuration Manager 2007 (SCCM) servers that needed to reach the DirectAccess clients, they would be entered in this portion of the setup. For the purposes of this scenario leave this blank and click Finish. 17. In Step 4 Application Servers, click Configure. 18. On the DirectAccess Application Server Setup page, leave Require No Additional End-to-End Authentication. Note If end-to-end protection were required, this step in the configuration wizard is where the permitted application servers would be added. For the purposes of this only the end-to-edge access model is being used, so no additional configuration is needed. 19. Click Finish. 20. Click Save, and then click Finish to launch the configuration wizard. 21. In the DirectAccess Review dialog box, click Apply.

25

During the configuration process two new Group Policy Objects are created, each named DirectAccess Policy-<GUID>. One has security filtering defined such that it applies only to the DirectAccess server by computer name (DA01$). The other has security filtering defined such that it applies only to the DirectAccess clients in the DirectAccessClients security group.

Finalizing the DirectAccess Configuration

Before testing DirectAccess functionality, CLIENT01 needs to be added to the DirectAccessClients computer group. Use the following steps to complete this task: 1. On DC01, launch Server Manager. 2. Expand Roles\Active Directory Domain Services\Active Directory Users and Computers\contoso.com and select the OU that contains the DirectAccessClients group. 3. Right-click the group DirectAccessClients and select Properties. 4. Select the Members tab, and then click the Add button. 5. In the Select Users, Contacts, Computers, or Groups dialog box, click Object Types, check Computers, and click OK. 6. Under Enter the Object Names to Select (Examples), type CLIENT01, and click OK. 7. Click OK to save. 8. Restart the CLIENT01 computer to have the changes take effect. By restarting CLIENT01 you are ensuring that the new DirectAccess group policies are applied. Additionally, you may need to also run gpupdate.exe on the DirectAccess server DA01. Once you have ensured that the DirectAccess group policies have been on all DirectAccess servers and clients you will need to restart the IP Helper service on all internal servers (this includes DC01, FILE01, WEB01, and DA01). To complete this task use the following commands: net stop iphlpsvc net start iphlpsvc By restarting the IP Helper service, the systems will be able resolve the isatap.contoso.com DNS entry created by the DirectAccess Setup Wizard and will enable their ISATAP interfaces. Once the service has been restarted the internal IPv6 network should be fully functional and all systems should be able to reach each other using the IPv6 addresses as well as the IPv4 addresses. Note The ping.exe tool can be used to verify that IPv6 is working. The -6 option forces ping to use IPv6. The -4 option forces ping to use IPv4. The command to ping a computer DC01 using IPv6 is ping dc1.companyabc.com -6. The command to ping a computer DC01 using IPv4 is ping dc1.companyabc.com -4. Each computer should be successfully pinged with both commands. This can be a very useful technique when troubleshooting DirectAccess and IPv6.

Testing DirectAccess
The last task in the DirectAccess configuration is to test the deployment and verify DirectAccess functionality. As mentioned previous the DirectAccess functionality will be verified by trying to access 26

FILE01 and WEB01 using the internal network (Test A), the public network (Test B), and finally the home network (Test C). Use the following steps to complete Test A: 1. While logged into CLIENT01 to the internal network. 2. Select Start, enter cmd, and press Enter. 3. At the command prompt, enter ipconfig and press Enter. Figure 13 shows that CLIENT01 has been assigned an IPv4 address (192.168.1.100) on the internal network and that an ISATAP address has been automatically generated in the ISATAP tunnel adapter.

FIGURE 13 Test AInternal Network. 4. Next, try to access a share on FILE01 to demonstrate access. 5. Finally, open Internet Explorer and access http://web01.contoso.com to demonstrate access. By completing Test A you should be able to demonstrate that CLIENT01 is connected to the internal network and is able to access resources and that the IPv6 transitional technologies are working internally, specifically ISATAP. For Test B, the connection to the public network, execute the following steps: 1. Connect the DirectAccess client CLIENT01 to the public network. 2. Select Start, enter cmd, and press Enter. 3. At the command prompt, enter ipconfig and press Enter. Figure 14 shows that CLIENT01 has been assigned an IPv4 address (12.155.166.20) on the public network and that a 6to4 address has been automatically generated with the 6to4 2002: prefix in the 6to4 tunnel adapter.

27

FIGURE 14 Test BPublic Network. 4. Next, try to access a share on FILE01 to demonstrate access. 5. Finally, open Internet Explorer and access http://web01.contoso.com to demonstrate access. By completing Test B you should be able to demonstrate that CLIENT01 is connected to the public network, able to access internal resources and that the IPv6 transitional technologies are working publicly, specifically 6to4. For Test C, the connection to the home network, execute the following steps: 1. Connect the DirectAccess client CLIENT01 to the home network. 2. Select Start, enter cmd, and press Enter. 3. At the command prompt, enter ipconfig and press Enter. Figure 15 shows that CLIENT01 has been assigned an IPv4 address (192.168.2.11) on the home network and that a Teredo address has been automatically generated with the Teredo 2001: prefix in the Teredo tunnel adapter.

FIGURE 15 Test CHome Network. 4. Next, try to access a share on FILE01 to demonstrate access. 5. Next, open Internet Explorer and access http://web01.contoso.com to demonstrate access. 6. To verify IP-HTTPS connectivity you will need to disable the Teredo interface by executing the following command: 28

netsh interface teredo set state disable 7. After disabling the Teredo interface execute the following command to verify the IP-HTTP connection (the output should show an active status as shown in Figure 16): netsh interface httpstunnel show interfaces

FIGURE 16

IP-HTTPS status.

8. Next, try to access a share on FILE01 to demonstrate access. 9. Lastly, open Internet Explorer and access http://web01.contoso.com to demonstrate access. By completing Test C you should be able to demonstrate that CLIENT01 is connected to the public network, able to access internal resources anetnd that the IPv6 transitional technologies are working publicly, specifically Teredo and IP-HTTPS.

Monitoring the DirectAccess Server

The DirectAccess server includes an excellent tool to monitor the activity of the DirectAccess clients. Shown in Figure 17, it provides an overall status of the DirectAccess server, status and activity of the individual DirectAccess components, and detailed statistics on the components. The figure shows that the Teredo components are active, indicating that there are DirectAccess clients using Teredo but none using IP-HTTPS.

29

FIGURE 17 DirectAccess Monitoring. The DirectAccess Monitoring tool provides information on the traffic activity, data, and control traffic counters for the following components: Teredo Relay Teredo Server 6to4 IPHTTPS ISATAP Network Security DNS Server

The status information in the tool is updated every 10 seconds and the status indicators for the components will change depending on the health and activity of the component. For example: Green indicates current activity in the component. Orange indicates the component is idle. Yellow indicates the component is experiencing issues. Red indicates that the component has failed.

To access the DirectAccess Monitoring tool use the following steps: 1. On DA01, launch Server Manager. 2. Expand Features\DirectAccess and select Monitoring. 30

3. The details window will show the component status screen. As connections are made, the status will update every 10 seconds to show the activity. 4. To see the performance metrics for any given component, click on the Details button to launch Performance Monitor with the appropriate counters. The DirectAccess Monitoring tool gives access to dozens of key performance metrics in graphical or tabular format. These metrics are invaluable for monitoring and troubleshooting the DirectAccess infrastructure.

What is UAG DirectAccess?

In a mixed platform environment where users may not all have Windows 7 remote systems such as Apple Mac or Linux systems, or in the case where an organization is upgrading from Windows XP or Windows Vista to Windows 7, the organization needs a solution that supports more than just Windows 7 systems. Microsofts ForeFront Unified Access Gateway, or UAG provides end point detection and secured (SSL) application tunneling for mixed environments. Where a complete Windows 7 environment just needs a Windows Server 2008 R2 system on the network as a gateway to allow Windows 7 DirectAccess client access to network resources, an organization can replace the Windows Server 2008 R2 server with a UAG server. The UAG server acts as both the Windows 7 DirectAccess server as well as a UAG server for non-Windows 7 systems. This dual purpose solution is called UAG DirectAccess.

Choosing DirectAccess or UAG DirectAccess

As organizations deploy DirectAccess technology on Windows 7 client systems, a common question asked for the DirectAccess server implementation is, can I just install DirectAccess, or do I need to implement UAG DirectAccess? The deciding factor is dependent on one of two things: 1) Does the organization want to implement policy-based security to only Windows 7 clients, or does the organization want to implement policy-based security to Windows 7 and non-Windows 7 clients? 2) For the policy-based security access by client systems, are the servers and applications being accessed reside only on IPv6-enabled systems such as Windows 2008 or Windows 2008 R2 servers, or are the servers and applications being accessed reside on a mix of IPv6 and IPv4 enabled systems such as Windows 2003 systems? If the organization is purely Windows 7 clients against purely IPv6 server systems, then the organization can just implement DirectAccess on a Windows Server 2008 R2 server system. However, if the organization wants to support non-Windows 7 clients such as Windows XP systems, Apple Mac systems, and/or Linux systems, then the organization needs to implement UAG DirectAccess instead of just DirectAccess. Or even if the organization is solely Windows 7 client systems, if the servers or applications being accessed are a mix of IPv6 and IPv4 systems such as Windows 2008 or 2008 R2 systems as well as Windows 2003 server systems, then the organization needs to implement UAG DirectAccess.

31

The following FlowChart shows the decision tree in determining whether the organization can implement just DirectAccess for the server component, or if the organization needs to implement UAG DirectAccess for the server component to meet the needs of the organization.

Start

All Windows 7 Clients or the Environment includes NonWindows 7 Clients

Windows 7 Only

Windows 2008 R2 DirectAccess

Non-Win7 Client

All IPv6 supported Windows 2008 or 2008R2 Servers

Get UAG DirectAccess

Mix of IPv4 servers and IPv6 servers

IPv6 (Windows 2008 / 2008 R2) only Servers, or Mix of IPv6 and IPv4 Servers?

Completing a Basic UAG DirectAccess Deployment

In the previous section you learned how to install and configure a basic DirectAccess deployment. In this section, the same scenario will be completed, however this time the deployment will be down with UAG DirectAccess to support for internal IPv4 hosts. By completing this scenario the following goals will be accomplished: 1. Allow a workstation to seamlessly move between internal, public, and home networks while retaining access to application servers. 2. Enable IPv6 in an IPv4 network using IPv6 transition technologies. 3. Enable IPv4 support using NAT64/DNS64.

32

It is important to note that the scenario does not require that you have deployed IPv6 throughout your internal network to begin using DirectAccess. Instead, the scenario leverages Windows Server 2008 R2 and Windows 7 technologies that will automatically enable and configure IPv6 using transitional technologies like ISATAP, 6to4, and Teredo. This scenario assumes that Windows Server 2008 R2 Active Directory and DNS are already deployed. Additionally, the intended UAG DirectAccess server must have two physical network interfaces. The first is connected directly to the Internet, no NAT, and must have two consecutive public IP addresses. The second interface is connected to the internal network. This scenario also assumes you have an internal enterprise PKI deployment with CRLs or an OCSP responder that is published on the Internet. Within there are five servers and a client system in the scenario shown in Figure 18. These are the systems that will be configured and tested against during the scenario. The systems are as follows: AD01Domain controller, DNS, and enterprise Certificate Authority server running Windows Server 2008 R2. The Active Directory domain is contoso.com. The CA must have an Internet available certificate revocation list (CRL) or OCSP responder. UAG01UAG DirectAccess server and domain member running Windows Server 2008 R2, with two network interface cards, and two public IP addresses (12.155.166.2 and 12.155.166.3) assigned. UAG01 will also be the NAT64/DNS64 server and needs to have at least 4GB of memory. Note The reason for two consecutive public IPv4 addresses on the DirectAccess servers public Internet interface is so that Teredo-based DirectAccess clients can detect the type of NAT that they are located behind. FILE01File server and domain member that the DirectAccess client is accessing. For the purposes of this scenario FILE01 will only support IPv4. WEB01Web server and domain member that the DirectAccess client is accessing. This server also hosts the NLS Web site, using the URL https://nls.contoso.com. For the purposes of this scenario WEB01 will only support IPV4. NS01This server is the external DNS server and Web server that is hosting the CRL for the URL pki.contoso.com. CLIENT01DirectAccess client and domain member running Windows 7. This system will travel between the internal, public, and home networks.

33

FIGURE 18 DirectAccess Scenario. The scenario assumes that split-brain DNS is being usedthat is, that there is an internal contoso.com zone and an external contoso.com zone. As such there should be a DNS A record for da01.contoso.com (12.155.166.2) in the external companyabc.com zone, as well as the DNS record for the CRL or OCSP responder for the certificate authority (typically pki.contoso.com). In addition, there are three networks in the scenario. The DirectAccess client is CLIENT01 and will be roaming between these networks and attempting to access WEB01 and FILE01. Details about the three networks are as follows: Internal networkThis is the corporate network and is using an IPv4 address in the 192.168.1.x range. Public networkThis is the Internet, and the servers being configured are using the IPv4 12.155.166.x range. Home networkThis is a network behind a NAT firewall, and the IP address range is not known.

Connectivity to WEB01 and FILE01 will be tested from the client (CLIENT01) while connected to the internal network, the public network, and, finally, to the home network. In all cases, the client should seamlessly transition between the networks with no interruption in access to internal resources.

Making the Basic Infrastructure Changes

The first task in the UAG DirectAccess deployment is to modify the DNS service configuration and remove the ISATAP name from its default global block list. By making this change the DNS will be able to service ISATAP requests. Use the following steps to complete this task: 1. On DC01, open a PowerShell console session using the Run as Administrator option. 2. In the PowerShell console, execute the following command: dnscmd /config /globalqueryblocklist wpad 34

Note The preceding command needs to be run on each DNS server on the internal network. In addition, it is important to understand that this command is only being executed because this scenario is using ISATAP for internal IPv6 support. Depending on your deployment needs, executing this command may or may not be required. The next task in the UAG DirectAccess deployment is to create the NLS and ISATAP DNS records. To deploy ISATAP using UAG DirectAccess, all IPv6 capable hosts must be able to resolve the name ISATAP to the internal interface of the UAG DirectAccess server. By adding the ISATAP DNS records, the UAG DirectAccess server will be able to act as an ISATAP router for the organization, and provide prefix and routing information for ISATAP hosts on the corporate network. Lastly, the DNS record is used for the NLS URL that DirectAccess clients use to determine if they are in the corporate network. Use the following steps to complete this task: 1. On DC01, launch Server Manager. 2. Expand Roles\DNS Server\DNS\DC01\Forward Lookup Zones, and select the contoso.com zone. 3. Right-click contoso.com and then click New Host (A or AAAA). 4. In the Name field, type nls. In the IP address field, type the IPv4 address of the NLS website, click Add Host, click OK, and then click Done. 5. Right-click contoso.com and then click New Host (A or AAAA). 6. In the Name field, type ISATAP. In the IP address field, type the IPv4 address of the internal interface of the UAG DirectAccess server, click Add Host, click OK, and then click Done. The last task in this section is to create a security group for DirectAccess client computers. This allows the DirectAccess clients to be defined within the DirectAccess configuration and apply specific DirectAccess Group Policy Objects. For this scenario the group will be named DirectAccessClients. Use the following steps to complete this task: 1. On DC01, launch Server Manager. 2. Expand Roles\Active Directory Domain Services\Active Directory Users and Computers\contoso.com and select the container that the new group object will be created within. 3. Right-click on the container, select New, and then click Group. 4. In the Group Name field, type DirectAccessClients. 5. Under Group scope, choose Global or Universal, under Group type, choose Security, and then click OK.

Configuring Windows Firewall for DirectAccess

The next task is to create and enable Windows Firewall rules that allow inbound and outbound ICMPv6 Echo Request messages. These rules are needed allow connectivity for Teredo-based DirectAccess clients that are behind a NAT. DirectAccess clients that are behind NATs on the Internet will attempt to use Teredo for IPv6 connectivity to the DirectAccess server. DirectAccess clients are Teredo clients to the DirectAccess server, which is acting as a Teredo server and relay. To ensure that a destination is reachable, Teredo clients send an Internet Control Message Protocol for IPv6 (ICMPv6) Echo Request 35

message and wait for an ICMPv6 Echo Reply message. If ICMPv6 Echo Requests are not allowed, then the DirectAccess client will fall back on using IP-HTTPS to establish a DirectAccess connection. Additionally, because this scenario has hosts that only support IPv4 and NAT64 is being deployed to support those hosts then IPv4 (ICMPv4) Echo Request Windows Firewall rules will need to also be created. Like IPv6 hosts, internal hosts that are not IPv6-capable but are available using NAT64 must receive and respond to the Teredo discovery traffic (an ICMPv6 Echo Request that is translated to an ICMPv4 Echo Request) sent by a remote, Teredo based DirectAccess client. Use the following steps to create a GPO named DirectAccess ICMP which will be used to deploy the needed Windows Firewall rules: 1. On DC01, launch Server Manager. 2. Expand Features\Group Policy Management\Forest: companyabc.com\Domains and select contoso.com. 3. In the console tree, right-click the domain contoso.com and select Create a GPO in the Domain and Link It Here. 4. Enter the name DirectAccess ICMP and then click OK. 5. Right-click the DirectAccess ICMP Group Policy Object and select Edit. 6. In the console tree of the Group Policy Management Editor, expand Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security. 7. In the console tree, select and then right-click Inbound Rules, and then click New Rule. 8. On the Rule Type page, click Custom, and then click Next and Next. 9. On the Protocols and Ports page, for Protocol Type, select ICMPv4, and then click Customize. 10. In the Customize ICMP Settings dialog box, click Specific ICMP Types, select Echo Request, and then click OK. 11. Click Next, Next, and Next. 12. On the Profile page, limit the scope rule so that is only applies to the Domain profile and then click Next. 13. On the Name page, in the Name field, type Inbound ICMPv4 Echo Requests, and then click Finish. 14. In the console tree, select and then right-click Inbound Rules, and then click New Rule. 15. On the Rule Type page, click Custom, and then click Next and Next. 16. On the Protocols and Ports page, for Protocol Type, select ICMPv6, and then click Customize. 17. In the Customize ICMP Settings dialog box, click Specific ICMP Types, select Echo Request, and then click OK. 18. Click Next, Next, Next, and Next. 19. On the Name page, in the Name field, type Inbound ICMPv6 Echo Requests, and then click Finish. 20. In the console tree, select and then right-click Outbound Rules, and then click New Rule. 21. On the Rule Type page, click Custom, and then click Next and Next. 22. On the Protocols and Ports page, for Protocol Type, click ICMPv4, and then click Customize.

36

23. In the Customize ICMP Settings dialog box, click Specific ICMP Types, select Echo Request, and then click OK. Click Next and Next. 24. On the Action page, click Allow the Connection, and then click Next 25. On the Profile page, limit the scope rule so that is only applies to the Domain profile and then click Next. 26. On the Name page, in the Name field, type Outbound ICMPv4 Echo Requests, and then click Finish. 27. In the console tree, select and then right-click Outbound Rules, and then click New Rule. 28. On the Rule Type page, click Custom, and then click Next and Next. 29. On the Protocols and Ports page, for Protocol Type, click ICMPv6, and then click Customize. 30. In the Customize ICMP Settings dialog box, click Specific ICMP Types, select Echo Request, and then click OK. Click Next and Next. 31. On the Action page, click Allow the Connection, and then click Next and Next. 32. On the Name page, in the Name field, type Outbound ICMPv6 Echo Requests, and then click Finish. 33. Close the Group Policy Management Editor and the Group Policy Management Console. Note The ICMPv4 rules were limited to the Domain profile because the IPv4 based echo request rules only need to apply to hosts that are located on the internal network.

Configuring the Network Location Server

The website used for the network location server (NLS) needs to support HTTPS and can be any website that is available internally, although it is a best practice that it be highly available. For the purpose of this scenario the server WEB01 will be used to host the NLS Web site. To complete the NLS configuration the first task is to ensure that the web server hosting the NLS Web site has a valid server authentication (SSL) certificate with customized subject and alternative name for the network location URL. Use the following steps to complete this task: 1. On WEB01 click Start, type mmc, and then press ENTER. 2. Click File, and then click Add/Remove Snap-in. 3. Click Certificates, click Add, select Computer account, click Next, select Local computer, click Finish, and then click OK. 4. In the console tree of the Certificates snap-in, expand Certificates (Local Computer)\Personal. 5. Right-click Certificates, point to All Tasks, and then click Request New Certificate. 6. Click Next twice. 7. On the Request Certificates page, click Web Server 2008, and then click More information is required to enroll for this certificate. 8. On the Subject tab of the Certificate Properties dialog box, in Subject name, for Type, select Common Name. 9. In Value, type nls.contoso.com, and then click Add. 10. In Alternative name, for Type, select DNS. 37

11. In Value, type nls.contoso.com, and then click Add. 12. Click OK, click Enroll, and then click Finish. Note Step 7 assumes that the Web Server 2008 certificate template was created beforehand. For the purpose of this scenario the Web Server 2008 template was a version 3 template that was duplicated from the version 1 Web Server template. The permissions for the Web Server 2008 certificate template were modified to allow Domain Computers to enroll for certificates based on this template and the private key can be exported. Lastly, the subject name and subject alternative name of a certificate can be specified during the request. Once the certificate has been installed the next task is to install the Web Server (IIS) role and configure the HTTPS security binding on the default Web site. Use the following steps to complete this task: 1. In the console tree of Server Manager, click Roles. In the details pane, click Add Roles, and then click Next. 2. On the Select Server Roles page, select the Web Server (IIS) check box, and then click Next three times. 3. Click Install. 4. Verify that all installations were successful, and then click Close. 5. Next, in Server Manager expand Web Server (IIS) and select Internet Information Services (IIS) Manager. 6. Next, expand WEB01\Sites, and then click Default Web site. 7. In the Actions pane, click Bindings. 8. In the Site Bindings dialog box, click Add. 9. In the Add Site Binding dialog box, in the Type list, click https. In SSL Certificate, click the certificate with the name nls.contoso.com. Click OK, and then click Close.

Certificate Auto-Enrollment
Once the network location server has been configured the next task in the UAG DirectAccess deployment is to ensure that all domain members have a valid client authentication certificate. The steps to complete this task may vary depending on the overall certificate requirements for your environment. However, for the purposes of this scenario the following generic steps should be used: 1. On DC01, launch Server Manager. 2. Expand Roles\Active Directory Certificate Services and select Certificate Templates. 3. Select the Workstation Authentication certificate template. 4. Right mouse click the template and select Duplicate Template. 5. In the Duplicate Template dialog box select the Windows Server 2003 Enterprise option and click OK. 6. Next, define the name of the template as Contoso - Domain Machine Authentication. 7. Next, select the Security template and modify the Domain Computers permissions to include Autoenroll and click OK. 38

8. Now expand the Enterprise CA and right mouse click Certificate Templates, select New\Certificate Template to Issue. 9. In the Enable Certificate Templates dialog box choose the Contoso Domain Machine Authentication certificate template and click OK. Note The steps in this section assume that the needed GPO changes to enable auto-enrollment have already been made.

Installing and Configuring UAG DirectAccess

The next task in the UAG DirectAccess deployment is to complete the UAG DirectAccess installation and configuration. To start this process you will first need to request a server authentication certificate that will be used for IP-HTTPS. Use the following steps to complete this task: 1. On UAG01 click Start, type mmc, and then press ENTER. 2. Click File, and then click Add/Remove Snap-in. 3. Click Certificates, click Add, select Computer account, click Next, select Local computer, click Finish, and then click OK. 4. In the console tree of the Certificates snap-in, expand Certificates (Local Computer)\Personal. 5. Right-click Certificates, point to All Tasks, and then click Request New Certificate. 6. Click Next twice. 7. On the Request Certificates page, click Web Server 2008, and then click More information is required to enroll for this certificate. 8. On the Subject tab of the Certificate Properties dialog box, in Subject name, for Type, select Common Name. 9. In Value, type da.contoso.com, and then click Add. 10. In Alternative name, for Type, select DNS. 11. In Value, type da.contoso.com, and then click Add. 12. Click OK, click Enroll, and then click Finish. Note Step 7 assumes that the Web Server 2008 certificate template was created beforehand. For the purpose of this scenario the Web Server 2008 template was a version 3 template that was duplicated from the version 1 Web Server template. The permissions for the Web Server 2008 certificate template were modified to allow Domain Computers to enroll for certificates based on this template and the private key can be exported. Lastly, the subject name and subject alternative name of a certificate can be specified during the request. 13. In the details pane of the Certificates snap-in, verify that a new certificate with the name da.contoso.com was enrolled with Intended Purposes of Server Authentication. 14. Right-click the certificate and select Properties. 15. In the Friendly Name field, type IP-HTTPS and click OK. 39

Once the IP-HTTPS certificate has been installed the next task is to install Forefront Unified Access Gateway (UAG). Use the following steps to complete this task: 1. On UAG01 ensure that the Network List Service (Netprofm) and the Network Location Awareness (NlaSvc) services are running, before beginning the Forefront UAG installation. 2. Next, execute the Forefront UAG Setup Wizard (setup.hta) from the installation media or an ISO file. Do not install Forefront UAG from a network share. 3. On the Welcome page of Setup, click Install Forefront UAG to begin Forefront UAG Setup. When running Setup, you can customize the installation folder location, if required. 4. When prompted restart UAG01 to complete the installation. After UAG has been installed the next task is to complete the UAG Getting Started Wizard. To complete this task use the following steps: 1. On DA01, click Start\All Programs\Microsoft Forefront UAG\Forefront UAG Management. This will start the Getting Started Wizard. 2. In the Getting Started Wizard dialog box, click Configure Network Settings. 3. In the Network Configuration Wizard dialog box, click Next. 4. On the Define Network Adapters page, define which network adapter is the internal adapter and which network adapter is the external adapter, and then click Next. 5. On the Define Internal Network IP Address Range page, make any needed changes, click Next and then click Finish. 6. Now in the Getting Started Wizard dialog box, click Define Server Topology. 7. In the Server Management Wizard dialog box, click Next. 8. On the Select Configuration page, choose the Single server option, click Next and then click Finish. 9. In the Getting Started Wizard dialog box, click Join Microsoft Update. 10. In the Microsoft Update dialog box, choose the desire update option and then click OK. 11. In the Getting Started Wizard dialog box, click Close, and when prompted click Yes to activate the UAG configuration. 12. In the Activate Configuration dialog box, provide a strong password to protect the configuration backup file, click Next, and then click Activate. 13. Once the configuration has been activated click Finish. Once the Getting Started Wizard has been completed the next task is to complete the DirectAccess configuration using the UAG DirectAccess Configuration Wizard. To complete this task use the following steps: 1. In the UAG Management Console select the DirectAccess node. 2. Expand Features, DirectAccess, and select the Setup node. The screen will show the DirectAccess Configuration Wizard, as shown in Figure 19.

40

FIGURE 19 UAG DirectAccess Configuration Wizard. 3. In the Clients box, click Edit. 4. On the UAG DirectAccess Client Configuration page, click the Add button. 5. In the Select Group dialog box, type DirectAccessClients and click OK. The screen will show the group, as shown in Figure 20.

FIGURE 20 DirectAccess Client Configuration. 6. Click Finish. 41

7. In the DirectAccess Server box, click Edit. 8. On the Connectivity page, for the First Internet-facing IPv4 address, select the first IPV4 address that will be used to service 6to4, Teredo server, Teredo relay, and IP-HTTPS traffic. Once the first IPv4 address is selected the Second Internet-facing IPv4 address is automatically defined. For the Internal IPv4 address used when ISATAP is deployed on the UAG DirectAccess server select the IPv4 address that will be used by the ISATAP router on the UAG DirectAccess server as shown in Figure 21.

FIGURE 21 UAG DirectAccess Connectivity settings. Note If IPv6 has not been deployed within the internal network then the UAG DirectAccess server is automatically configured as an ISATAP router. As such the DirectAccess Configuration Wizard will automatically derive the 6to4-based organization, IP-HTTPS, and NAT64 IPv6 prefixes, and skip the Prefix Configuration screen of the UAG DirectAccess Configuration Wizard. 9. Click Next. 10. On the Managing DirectAccess Services page, ensure that Enable UAG DirectAccess NAT64 and Enable DireactAccess DNS64 are selected, and click Next. For the purposes of this scenario the UAG DirectAccess Server will be acting as a NAT64/DNS64 device. 11. On the Authentication Options page, select the Use root certificate option, click Browse. In the list of certificates, select the appropriate Root CA certificate, and then click OK. 12. For Select the certificate that authenticates the UAG DirectAccess server to a client connecting using IP-HTTPS, click Browse. In the list of certificates, click the certificate named IP-HTTPS, and then click OK. The results are shown in Figure 22. Click Finish.

42

FIGURE 22 DirectAccess Authentication Options. 13. In the Infrastructure Servers box, click Edit. 14. On the Network Location Server page, type nls.contoso.com, click Validate, and then click Next. You should get a green check mark with a Validation Successful message. 15. On the DNS Suffixes page (shown in Figure 23), note the entry for the name *.contoso.com is defined as [DNS64]. This means that the UAG DNS64 server IP address will be used to resolve names ending with the specified DNS suffix for DirectAccess clients. When this occurs, the UAG DirectAccess server will multiplex DirectAccess client DNS requests for IPv6 records into two DNS requests, one for IPv4 records and one for IPv6 records which is then forwarded to an internal DNS server. If an IPV6 DNS record exists, it is returned back to the client. If there is no IPv6 records, then then IPv4 records are translated into fake IPv6 records - owned by the NAT64 device (the UAG DirectAccess server). Lastly, nls.consoto.com, da.contoso.com, and pki.contoso.com are also defined as NRPT exemptions.

43

FIGURE 23 DNS Suffixes. Note The NRPT exemption for the network location server is needed so that DirectAccess clients can use the URL to determine if they are inside the corporate network or on the Internet. When inside the network, the DirectAccess clients will be able to access the site. When remote and connected via DirectAccess, the clients will be unable to reach the site due to the blank DNS entry, although they can reach all other internal resources. da.contoso.com and pki.contoso.com have been added as NRPT exceptions because of the split-brain DNS configuration. If these exceptions were not added then clients would not be able to resolve these FQDNs when they were on an external network. 16. Click Next. 17. On the Management Servers and DCs page, if there were internal management servers, such as Microsoft System Center Configuration Manager 2007 (SCCM) servers that needed to reach the DirectAccess clients, they would be entered in this portion of the setup. For the purposes of this scenario no changes are needed 18. Click Finish. 19. In the Application Servers box, click Edit. 20. On the Application Server Configuration page, ensure that the Require end-to-edge authentication and encryption option is selected, and then click Finish. Note If end-to-end protection were required, this step in the configuration wizard is where the permitted application servers would be added. For the purposes of this only the end-to-edge access model is being used, so no additional configuration is needed. 21. Click Finish. 22. Now, click Generate Polices to launch the UAG DirectAccess Configuration Review dialog box. 23. In the UAG DirectAccess Configuration Review dialog box, click Apply Now. This will launch the DirectAccess Policy Configuration dialog box. Use this dialog box to monitor the status of the DirectAccess Policy creation, configuration, and application. 24. Once the DirectAccess Policy application has been completed, click OK and then click Close. 25. In the UAG Management Console, click the Activate configuration icon, and then on the Activate Configuration dialog box, click Activate to activate the configuration. During the configuration process two new Group Policy Objects are created, each named UAG DirectAccess: Client{<GUID>} or DirectAccess: Server{<GUID>}. The Server GPO has security filtering defined such that it applies only to the DirectAccess server by computer name (UAG01$). The other has security filtering defined such that it applies only to the DirectAccess clients in the DirectAccessClients security group.

44

Finalizing the DirectAccess Configuration

Before testing DirectAccess functionality, CLIENT01 needs to be added to the DirectAccessClients computer group. Use the following steps to complete this task: 1. On DC01, launch Server Manager. 2. Expand Roles\Active Directory Domain Services\Active Directory Users and Computers\contoso.com and select the OU that contains the DirectAccessClients group. 3. Right-click the group DirectAccessClients and select Properties. 4. Select the Members tab, and then click the Add button. 5. In the Select Users, Contacts, Computers, or Groups dialog box, click Object Types, check Computers, and click OK. 6. Under Enter the Object Names to Select (Examples), type CLIENT01, and click OK. 7. Click OK to save. 8. Restart the CLIENT01 computer to have the changes take effect. By restarting CLIENT01 you are ensuring that the new DirectAccess group policies are applied. Additionally, you may need to also run gpupdate.exe on the DirectAccess server DA01. Once you have ensured that the DirectAccess group policies have been on all DirectAccess servers and clients you will need to restart the IP Helper service on all internal servers that will be using ISATAP (this includes DC01 and UAG01). To complete this task use the following commands: net stop iphlpsvc net start iphlpsvc By restarting the IP Helper service, the systems will be able resolve the isatap.contoso.com DNS entry created by the DirectAccess Setup Wizard and will enable their ISATAP interfaces. Once the service has been restarted the internal IPv6 network should be fully functional and all systems should be able to reach each other using the IPv6 addresses as well as the IPv4 addresses. Note The ping.exe tool can be used to verify that IPv6 is working. The -6 option forces ping to use IPv6. The -4 option forces ping to use IPv4. The command to ping a computer DC01 using IPv6 is ping dc1.companyabc.com -6. The command to ping a computer DC01 using IPv4 is ping dc1.companyabc.com -4. Each computer should be successfully pinged with both commands. This can be a very useful technique when troubleshooting DirectAccess and IPv6.

Testing DirectAccess
The last task in the UAG DirectAccess configuration is to test the deployment and verify DirectAccess functionality. As mentioned previous the DirectAccess functionality will be verified by trying to access FILE01 and WEB01 using the internal network (Test A), the public network (Test B), and finally the home network (Test C). Use the following steps to complete Test A: 1. While logged into CLIENT01 to the internal network. 2. Select Start, enter cmd, and press Enter. 45

3. At the command prompt, enter ipconfig and press Enter. Figure 24 shows that CLIENT01 has been assigned an IPv4 address (192.168.1.100) on the internal network and that an ISATAP address has been automatically generated in the ISATAP tunnel adapter.

FIGURE 24 Test AInternal Network. 4. Next, try to access a share on FILE01 to demonstrate access. 5. Finally, open Internet Explorer and access http://web01.contoso.com to demonstrate access. By completing Test A you should be able to demonstrate that CLIENT01 is connected to the internal network and is able to access resources and that the IPv6 transitional technologies are working internally, specifically ISATAP. For Test B, the connection to the public network, execute the following steps: 1. Connect the DirectAccess client CLIENT01 to the public network. 2. Select Start, enter cmd, and press Enter. 3. At the command prompt, enter ipconfig and press Enter. Figure 25 shows that CLIENT01 has been assigned an IPv4 address (12.155.166.20) on the public network and that a 6to4 address has been automatically generated with the 6to4 2002: prefix in the 6to4 tunnel adapter.

FIGURE 25 Test BPublic Network. 4. Next, try to access a share on FILE01 to demonstrate access. 5. Finally, open Internet Explorer and access http://web01.contoso.com to demonstrate access. 46

By completing Test B you should be able to demonstrate that CLIENT01 is connected to the public network, able to access internal resources and that the IPv6 transitional technologies are working publicly, specifically 6to4. For Test C, the connection to the home network, execute the following steps: 1. Connect the DirectAccess client CLIENT01 to the home network. 2. Select Start, enter cmd, and press Enter. 3. At the command prompt, enter ipconfig and press Enter. Figure 26 shows that CLIENT01 has been assigned an IPv4 address (192.168.2.11) on the home network and that a Teredo address has been automatically generated with the Teredo 2001: prefix in the Teredo tunnel adapter.

FIGURE 26 Test CHome Network. 4. Next, try to access a share on FILE01 to demonstrate access. 5. Next, open Internet Explorer and access http://web01.contoso.com to demonstrate access. 6. To verify IP-HTTPS connectivity you will need to disable the Teredo interface by executing the following command: netsh interface teredo set state disable 7. After disabling the Teredo interface execute the following command to verify the IP-HTTP connection (the output should show an active status as shown in Figure 27): netsh interface httpstunnel show interfaces

47

FIGURE 27 IP-HTTPS status. 8. Next, try to access a share on FILE01 to demonstrate access. 9. Lastly, open Internet Explorer and access http://web01.contoso.com to demonstrate access. By completing Test C you should be able to demonstrate that CLIENT01 is connected to the public network, able to access internal resources anetnd that the IPv6 transitional technologies are working publicly, specifically Teredo and IP-HTTPS.

Monitoring the UAG DirectAccess Server

Unlike the base DirectAccess server, a UAG DirectAccess server does not have a built-in GUI monitoring tool. Instead, you can monitor DirectAccess clients and users by using a PowerShell monitoring cmdlet (Get-DirectAccessUsers) that provides information about current and historical client and user logons. By using this cmdlet, you can read DirectAccess client and user related events using one of the following modes: Local Security Event LogThis mode should be used for a standalone UAG DirectAccess server. If the UAG DirectAccess server is part of an array, you will be limited to viewing events on only one array member from a single PowerShell console session. Aggregated LogWith this mode you are able to view an aggregated set of security events from all of the array members. However, before you can use this mode you must first enable event forwarding on the collector server (the server to which events are forwarded), and on the UAG DirectAccess array members.

Before you can start using the Get-DirectAccessUsers cmdlet you must first enable IPsec logging. Use the following steps to complete this task: 1. On DC01, launch Server Manager. 2. Expand Features\Group Policy Management\Forest: companyabc.com\Domains and select contoso.com. 3. Right mouse click the UAG DirectAccess: DAServer Group Policy object, and then click Edit. 4. In the Computer Configuration node, expand Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies, and then click Logon/Logoff.

48

5. In the right pane, double-click Audit IPsec Extended Mode, select Configure the following audit events, select Success and Failure, and then click OK. 6. Double-click Audit IPsec Main Mode, select Configure the following audit events, select Success and Failure, and then click OK. Once IPsec logging has been enabled, DirectAccess connection information will start being logged to a UAG DirectAccess servers security event log. Use the following steps to view this information using the Get-DirectAccessUsers cmdlet: 1. On UAG01, open a PowerShell console session using the Run as Administrator option. 2. Next, execute the following command to add the UAGDAUserMonitoring snap-in into your PowerShell console session: Add-PSSnapin UAGDAUserMonitoring 3. Now execute the following command to view DirectAccess connection information as shown in Figure 28: Get-DirectAccessUsers -logname Security -OutputVerbosity Rawdata

FIGURE 27

Get-DirectAccessUsers cmdlet.

As you can image, while the connection data that is provided by the Get-DirectAccessUsers cmdlet is useful. There is a lot more monitoring data that an IT Administrator would want to ensure the health of their UAG DirectAccess deployment. To some extent, that data can be retrieved from various sources on a UAG DirectAccess server. For example, there are some DirectAccess related performance counters. However, pulling the data together and making sense of it may be a bit tricky. Instead, if you have System Center Operations Manager (SCOM) you could use the Unified Access Gateway (UAG) management pack. With the Unified Access Gateway (UAG) management pack you will get DirectAccess monitoring. This monitoring includes information that comprises the health state of the DirectAccess components: 6to4 49

router, DNS64, IP-HTTPS gateway, ISATAP router, Network security, Teredo relay, and Teredo server. In addition, you will also get by performance threshold monitoring to help determine the health state of various components based on the last sampled value (or average of several values. Lastly, you will also get the ability to measure three user activity quantities that indicate successful connections of clients to the DirectAccess server: number of sticky connections, number of Main Mode Security Associations, and Teredo packet receive rate.

Configuring End-to-End Authentication

As discussed earlier in this document you can configure DirectAccess to use an end-to-end access model. When using this type of access model, the IPsec policies that protect DirectAccess traffic are extended all the way to the specified application servers. To configure a UAG DirectAccess server to use the end-to-end access model, use the following steps: 1. In the UAG Management Console select the DirectAccess node. 2. Expand Features, DirectAccess, and select the Setup node. The screen will show the DirectAccess Configuration Wizard. 3. In the Application Servers box, click Edit. 4. In the Application Server Configuration dialog box, select the Require end-to-end authentication and encryption to specified application servers option and then click Add. 5. In the Select Group dialog box, select the security group(s) containing the application servers running Windows Server 2008 or later that you want to enable for end-to-end protection, click OK, and then click Finish. The results of adding a group are shown in Figure 29.

FIGURE 29

Application Server Configuration.

Note To enable data payload encryption for the IPsec session click the Edit IPSec cryptography settings option. Then in the IPSec Advanced Settings dialog box, edit the Quick Mode encryption settings as shown in Figure 30. 50

FIGURE 30

Enabling End-to-End encryption.

6. Now, click Generate Polices to launch the UAG DirectAccess Configuration Review dialog box. 7. In the UAG DirectAccess Configuration Review dialog box, click Apply Now. This will launch the DirectAccess Policy Configuration dialog box. Use this dialog box to monitor the status of the DirectAccess Policy creation, configuration, and application. 8. Once the DirectAccess Policy application has been completed, click OK and then click Close. During the configuration process a new Group Policy Object is created named UAG DirectAccess: AppServer{<GUID>}. This GPO has security filtering defined such that it applies only to the security groups that you specified require end-to-end protection. However, before DirectAccess clients must start using the end-to-end protection, the newly created GPO must be applied to the specified application server(s). You can either allow the application of GPO to occur naturally, or for a testing scenario you may want to force GPO application by using gpupdate.exe. If at a later date you add application servers to the security group you used or you change an application servers IP address, then that application server will be inaccessible to the DirectAccess client in both clear and encrypted modes. This issue occurs because the added application servers or modify IP address information is not automatically updated in the DirectAccess client application server list. To correct this issue, you must use the following steps: 1. In the UAG Management Console select the DirectAccess node. 2. Expand Features, DirectAccess, and select the Setup node. The screen will show the DirectAccess Configuration Wizard. 3. In the Application Servers box, click Edit, and then click Finish. 4. Next, click Generate Policies, click Apply Now, or click Export Script. Lastly, use the following steps to test the end-to-end protection for the application servers that were specified: 1. While logged into a DirectAccess client on the internal network. 2. Next, try to access the protected application server(s). 3. Next, connect the DirectAccess client to an external network. 4. Verify that a DirectAccess connection is made to the internal network. 5. Now, try to access the protected application server(s). 51

6. If the connection to the application server(s) succeeded and while still connected, open the Windows Firewall Advanced Security mmc snap-in. 7. Expand Monitoring\Security Associations, and then click Quick Mode. As shown in Figure 31 use the Quick Mode information to verify that an IPsec session exists for the application server(s).

FIGURE 31

Verifying end-to-end protection.

Summary
DirectAccess can be implemented as a feature in Windows Server 2008 R2 or integrated with Forefront Unified Access Gateway (UAG). As a Windows Server 2008 R2 solution, DirectAccess provides remote network access from Windows 7 clients to Windows 2008 and Windows 2008 R2 application servers. By adding in Forefront UAG, the DirectAccess solution provides remote network access to non-Windows 7 clients such as Windows XP systems as well as access to older non-IPv6 application servers in the organizations network. This deployment guide provided the step-by-step implementation of both Windows Server 2008 R2 DirectAccess and UAG DirectAccess in repeatable implementation processes.

52

This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results from the use of this document remains with the user. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. 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, Active Directory, Windows, Windows Media, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are property of their respective owners.

53