DirectAccessDeploymentGuide Morimoto

DirectAccess and UAG DirectAccess

Deployment Guide

DRAFT – May 18, 2010

Written by: Tyson Kopczynski, CISSP, GSEC, GCIH, and MCTS

Reviewed by: Manish Kalra, Microsoft

Rand Morimoto, Ph.D., MVP, MCITP, CISSP

2

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

3

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-to-

point tunnel for both the mobile computer and the remote user—in this case, specifically a remote user on

Windows 7—to 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.

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:

Note

4

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.

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

today’s 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

Note

5

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:

ISATAP—Used 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 organization’s IPv4 intranet with mappings from each IPv4 address to a link-

local IPv6 address.

6to4—The 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.

Teredo—While 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.

6

DirectAccess Connections

A DirectAccess connection actually consists of two separate connections from a client computer to an

organization’s internal network. Each of these connections, are IPsec Encapsulating Security Payload

(ESP) tunnels as described in the following bullets:

Computer tunnel—The 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 tunnel—This 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 organization’s 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

client’s current network connection may block encapsulated IPv6 traffic. To work around these scenarios,

7

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 network—that 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.

The user does not have to be logged on to the computer for this process to complete to this point

in the process.

Note

8

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.

9

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.

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

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.

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 end-

to-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:

10

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 end-

to-edge access model.

The following are the limitations of the end-to-end 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.

DirectAccess Components

DirectAccess leverages IPv6 along with PKI to provide a seamless secure connection to an organization’s

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 server—This 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 client—This is a computer running Windows 7. It must be a domain member with a

client authentication certificate.

Corporate IPv6 network—The 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 server—This 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:

11

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 organization’s 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).

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. That’s why the network location server

Web site must be highly available.

Note

12

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 it’s 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 don’t 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

13

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 Internet-

facing 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 organization’s 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 traffic—UDP destination port 3544 inbound and UDP source port 3544 outbound.

6to4 traffic—Protocol 41 inbound and outbound

IP-HTTPS—Transmission Control Protocol (TCP) destination port 443, and TCP source port 443

outbound

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

Protocol 50

UDP destination port 500 inbound, and UDP source port 500 outbound

Internet Control Message Protocol for IPv6 (ICMPv6) traffic inbound and outbound

14

Intranet-facing

ISATAP—Protocol 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 server’s 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 client’s 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

from a 3rd

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 certificate’s CRL Distribution Point (CDP) field and

any referenced AIA OCSP responder URLs are highly available both from the Internet and the intranet.

15

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.

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

Note

16

/64 1

/63 2

/62 3 or 4

/61 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:

AD01—Domain 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.

DA01—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.

The reason for two consecutive public IPv4 addresses on the DirectAccess server’s public

Internet interface is so that Teredo-based DirectAccess clients can detect the type of NAT that

they are located behind.

FILE01—File server and domain member that the DirectAccess client is accessing.

WEB01—Web 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.

Note

17

NS01—This server is the external DNS server and Web server that is hosting the CRL for the URL

pki.contoso.com.

CLIENT01—DirectAccess 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 used—that 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 network—This is the corporate network and is using an IPv4 address in the 192.168.1.x

range.

Public network—This is the Internet, and the servers being configured are using the IPv4

12.155.166.x range.

Home network—This 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.

18

2. In the PowerShell console, execute the following command:

dnscmd /config /globalqueryblocklist wpad

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:


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:


Note

19

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.


15. On the Protocols and Ports page, for Protocol Type, click ICMPv6, and then click Customize.


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


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.

20

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.


12. Click OK, click Enroll, and then click Finish.

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:


2. Expand Roles\Active Directory Certificate Services and select Certificate Templates.

Note

21

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.

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.



and then click OK.







Name.

9. In Value, type da01.contoso.com, and then click Add.


11. In Value, type da01.contoso.com, and then click Add.





Note

Note

22




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:


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.

23

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 DirectAccess Client Setup.

6. Click Finish.

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

24

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.

25

FIGURE 12 DirectAccess Infrastructure Server Setup for DNS.

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.

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.

Note

Note

26

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:



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.

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

Note

27

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 A—Internal 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.



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.

28

FIGURE 14 Test B—Public Network.



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.



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 C—Home Network.


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:

29

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.


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.

30

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:


2. Expand Features\DirectAccess and select Monitoring.

31

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.

Microsoft’s 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.

32

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.

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.

Start

All Windows 7 Clients or the Environment includes Non-

Windows 7 ClientsWindows 2008 R2 DirectAccessWindows 7 Only

GetUAG DirectAccess

Non-Win7 Client

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

IPv4 Servers?

Mix of IPv4 serversand IPv6 servers

All IPv6 supported Windows 2008 or2008R2 Servers

33

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:

AD01—Domain 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.

UAG01—UAG 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.

The reason for two consecutive public IPv4 addresses on the DirectAccess server’s public

Internet interface is so that Teredo-based DirectAccess clients can detect the type of NAT that

they are located behind.

FILE01—File server and domain member that the DirectAccess client is accessing. For the purposes

of this scenario FILE01 will only support IPv4.

WEB01—Web 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.

NS01—This server is the external DNS server and Web server that is hosting the CRL for the URL

pki.contoso.com.

CLIENT01—DirectAccess client and domain member running Windows 7. This system will travel

between the internal, public, and home networks.

Note

34

FIGURE 18 DirectAccess Scenario.

The scenario assumes that split-brain DNS is being used—that 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 network—This is the corporate network and is using an IPv4 address in the 192.168.1.x

range.

Public network—This is the Internet, and the servers being configured are using the IPv4

12.155.166.x range.

Home network—This 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

35

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



2. Expand Roles\DNS Server\DNS\DC01\Forward Lookup Zones, and select the contoso.com zone.


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.


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




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

Note

36

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:



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.





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.






then click OK.

18. Click Next, Next, Next, and Next.





37



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.







31. On the Action page, click Allow the Connection, and then click Next and Next.


33. Close the Group Policy Management Editor and the Group Policy Management Console.

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


1. On WEB01 click Start, type mmc, and then press ENTER.



and then click OK.







Name.



Note

38









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:


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.

Note

39

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.

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.



and then click OK.







Name.

9. In Value, type da.contoso.com, and then click Add.


11. In Value, type da.contoso.com, and then click Add.








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.

Note

Note

40

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.


Configuration Wizard, as shown in Figure 19.

41

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.

42

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.

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.

Note

43

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.

44

FIGURE 23 DNS Suffixes.

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.

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.

Note

Note

45

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:



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.

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.


Note

46


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 A—Internal Network.



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.



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 B—Public Network.



47

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.



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 C—Home Network.


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

48

FIGURE 27 IP-HTTPS status.


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 Log—This 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 Log—With 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




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.

49

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 server’s 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

50

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:



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.

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.

Note

51

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:



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).

52

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

organization’s network.

This deployment guide provided the step-by-step implementation of both Windows Server 2008 R2

DirectAccess and UAG DirectAccess in repeatable implementation processes.

53

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.

Date post:	23-Oct-2014
Category:	Documents
Upload:	cyborgdk4
View:	211 times
Download:	3 times

DirectAccessDeploymentGuide Morimoto

Documents