DirectAccessDeploymentGuide Morimoto

DirectAccess and UAG DirectAccessDeployment Guide DRAFT – May 18, 2010 Written by: Reviewed by: Tyson Kopczynski, CISSP, GSEC, GCIH, and MCTS Manish Kalra, Microsoft Rand Morimoto, Ph.D., MVP, MCITP, CISSP Contents What IS DirectAccess?............................................................................................................................... 3 Understanding DirectAccess ..................................................................................................................... 4 DirectAccess Connections ..................................................................................................................... 6 DirectAccess Access Models ................................................................................................................. 8 DirectAccess Components ................................................................................................................... 10 Planning a DirectAccess Deployment ..................................................................................................... 12 When to use DirectAccess ................................................................................................................... 12 DirectAccess Server Location .............................................................................................................. 13 Network Location Server ...................................................................................................................... 14 Certificate Revocation Checking .......................................................................................................... 14 High Availability .................................................................................................................................... 15 Completing a Basic DirectAccess Deployment ....................................................................................... 16 Making the Basic Infrastructure Changes ............................................................................................ 17 Configuring Windows Firewall for DirectAccess ................................................................................... 18 Configuring the Network Location Server ............................................................................................ 19 Certificate Auto-Enrollment .................................................................................................................. 20 Installing and Configuring DirectAccess ............................................................................................... 21 Finalizing the DirectAccess Configuration ............................................................................................ 26 Testing DirectAccess ............................................................................................................................ 26 Monitoring the DirectAccess Server ..................................................................................................... 29 What is UAG DirectAccess? .................................................................................................................... 31 Choosing DirectAccess or UAG DirectAccess ........................................................................................ 31 Completing a Basic UAG DirectAccess Deployment .............................................................................. 32 Making the Basic Infrastructure Changes ............................................................................................ 34 Configuring Windows Firewall for DirectAccess ................................................................................... 35 Configuring the Network Location Server ............................................................................................ 37 Certificate Auto-Enrollment .................................................................................................................. 38 Installing and Configuring UAG DirectAccess ...................................................................................... 39 Finalizing the DirectAccess Configuration ............................................................................................ 45 Testing DirectAccess ............................................................................................................................ 45 Monitoring the UAG DirectAccess Server ............................................................................................ 48 Configuring End-to-End Authentication ................................................................................................... 50 Summary.................................................................................................................................................. 52 2 What IS DirectAccess? DirectAccess is a remote access feature that was introduced in Windows Server 2008 R2 and Windows 7 which provides seamless connectivity to internal organizational networks from remote systems without the need for traditional VPN add-on software. By deploying DirectAccess, organizations address several challenges found with most traditional VPN solutions, including the following:       The need for the user to manually connect to the VPN. The delay the user experiences when connecting to the VPN while health checks are completed during the connection process. The need for the user to reconnect manually if an established VPN connection is lost. The inability to manage mobile computers unless they are connected to a VPN or physically within the internal network. The inability to granularly control which internal resources different users should have access to. The slow performance when all traffic (Intranet and Internet) is routed through the VPN connection. As most IT organizations can attest to, these challenges add an additional amount of overhead to IT operations and cause users unneeded frustration when using traditional VPN solutions. To address these challenges, DirectAccess was designed around the primary concept that mobile computer should be always be connected to the Intranet. This means that when a mobile computer boots up a DirectAccess connection is automatically started. The connection process is transparent to the user and the user never needs to explicitly connect to DirectAccess. Therefore, health checks, software and operating system updates, and remote management can be performed without user interaction. In addition, DirectAccess hides all the connection processes from the users and can intelligently route Intranet versus Internet traffic. DirectAccess also has built-in options to control how DNS requests are handled, effectively bifurcating the Internet and Intranet traffic to avoid burdening the remote access connection and improving performance. In the end, DirectAccess achieves remote access to Intranet resources by creating an encrypted point-topoint tunnel for both the mobile computer and the remote 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. Note Although positioned as an alternative to a VPN, the DirectAccess technology has all the elements of a VPN. It establishes a secure private tunnel through public networks using IPsec and certificates, with an end result functionally not much different from L2TP. The differences are mainly administrative rather than technical. DirectAccess uses IPv6, IPsec, and certificates to establish secure connections from the DirectAccess clients to Intranet resources via the DirectAccess server. To traverse public IPv4 networks, DirectAccess uses IPv6 transition technologies such as ISATAP, Teredo, and 6to4. Organizations that are planning to deploy DirectAccess will need to meet the following requirements: 3       The server running Windows Server 2008 R2 (Standard or Enterprise) needs to have two network cards: one attached to the Intranet and one attached to the Internet. The Internet network card must have two consecutive public IPv4 addresses. The Intranet resources and applications must support IPv6 or a third-party NAT-PT device must be deployed provide access to IPv4-only resources for DirectAccess clients. The DirectAccess clients need to be running Windows 7 (Enterprise or Ultimate); older clients are not supported. A domain controller and DNS server that the systems are connected to need to be running Windows Server 2008 SP2 or Windows Server 2008 R2. A PKI needs to be available to issue certificates with a published Internet available certificate revocation list (CRL). These requirements are somewhat stringent and might prevent many organizations from deploying DirectAccess. However, for an organization with an up-to-date infrastructure, servers, and clients, DirectAccess can be an excellent remote access solution that is geared to answer the previously mentioned challenges with traditional VPN solutions. Note The listed requirements will vary slightly when using Forefront Unified Access Gateway (UAG). For example, a UAG server becomes the DirectAccess server and can act as the NAT64 and DNS64 device. Details about how UAG DirectAccess is deployed are discussed later in this deployment guide. Understanding DirectAccess DirectAccess is designed on top of IPv6 and requires that all endpoint devices support IPv6. As such, DirectAccess is one of the first remote access solutions to require end-to-end IPv6 support. However, in 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 4 through the IPv4 protocol stack, as shown in Figure 2. As visualized in the figure, the packets traveling down the IPv6 protocol stack take a sharp turn and move across the protocol stack to the IPv4 protocol stack, allowing them to transit the IPv4 network. On the other side, the same packets come in via the IPv4 protocol stack, but are routed to the IPv6 stack. FIGURE 2 Bridging the IPv4 gap with transition technologies. Communications between IPv6 devices like DirectAccess clients over IPv4 networks is accomplished with IPv6 over IPv4 tunneling. In tunneling, the IPv6 packets are encapsulated in an IPv4 packet by the source device and routed through the IPv4 network. When the encapsulated packet arrives at the boundary between the IPv4 and IPv6 networks, the IPv4 encapsulation is stripped off and the IPv6 packet continues on its way. The most common tunneling protocols are ISATAP, 6to4, and Teredo. Details about each of these tunneling protocols are as follows:  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 linklocal 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. 5 To work around these scenarios. such as domain controllers. This tunnel is also used to apply user group policy as well.‖ is authenticated with the computer certificate and the user credentials. When a user logs on. called the ―intranet tunnel. IP-HTTPS In some scenarios.  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. ensuring that users are subject to the latest requirements. 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. a DirectAccess user is effectively on the internal network regardless of their location. Each of these connections. This bi-directional ―infrastructure‖ tunnel is authenticated with the computer certificate only and provides access to domain resources.DirectAccess Connections A DirectAccess connection actually consists of two separate connections from a client computer to an organization’s internal network. password changes. As shown in Figure 3. Therefore. they can access internal resources in the same way any other Intranet host connects to those resources. thus. and policies. because these tunnels are fully independent a DirectAccess client will connect the intranet even when no user is logged on. DNS servers. By using this tunnel. 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. User tunnel—This tunnel. In contrast. For example. 6 . web proxy servers and firewalls on a DirectAccess client’s current network connection may block encapsulated IPv6 traffic. other VPN solutions typically have users authenticating using cached credentials against the local machine and then establishing the remote access connection. they are authenticating to the intranet and. the inter-site IPv6 transition technologies (6to4 and Teredo) may fail to allow IPv6 connectivity across the IPv4 Internet. FIGURE 3 The two DirectAccess tunnels. and management servers. Lastly. This tunnel is also used to apply the computer group policy and perform user authentication. This allows the DirectAccess client to receive Group Policy remotely and be managed by the management servers in the intranet. 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. the DirectAccess client can be configured to route all traffic through the DirectAccess connection. However. The DirectAccess client contacts the domain controller and obtains the computer group policy. If there is an intervening IPv4 network. administrators might want to have all traffic routed through the DirectAccess connection. Details about this process are as follows: 1. Using the IP-HTTPS protocol. or other connection becomes active the client will step through its connection process. it determines that it is connected to the intranet and stops the DirectAccess process. If it cannot reach the NLS website. 2. 3. Examples of this include organizations that want to control or monitor their client communications or prevent access to certain Internet sites. allows hosts to establish connectivity through a web proxy or firewall by tunneling IPv6 packets inside an IPv4-based HTTPS session. traffic for those domains is directed through the DirectAccess connection. it determines that it is connected to the Internet and continues with the DirectAccess process. The DirectAccess client attempts to connect to the NLS website. This conserves the corporate bandwidth for access to corporate resources. 4. a network transition such as the connection to a LAN. 5. DirectAccess Connection Process When the DirectAccess client detects that it is connected to a network—that is. Other traffic is routed through the default routes and bypasses the DirectAccess connection. The DirectAccess client establishes an IPsec tunnel to the DirectAccess server using IPv6. wireless access point. If the DirectAccess client is unable to connect using the Teredo or 6to4 protocols. Therefore. 7 . In these cases. 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).Microsoft has developed a new method to encapsulate the IPv6 packets in an IPv4 header. in some cases. the client uses the Teredo or 6to4 protocols to tunnel IPv6 over IPv4. This is the highest performance configuration and is the default mode of operation. The DirectAccess client establishes an IPsec tunnel to the DirectAccess server using IPv6. a DirectAccess client will only use IP-HTTPS as a ―last ditch‖ method to create a DirectAccess connection. By specifying the domains and subdomains for which the DirectAccess server provides access. The DirectAccess client and the DirectAccess server mutually authenticate using certificates in the process of setting up the IPsec computer tunnel. If it can reach the site. This new IPv6 transition protocol is called IP-HTTPS and is supported on Windows 7 and Windows Server 2008 R2. Note The user does not have to be logged on to the computer for this process to complete to this point in the process. the client will attempt to connect using the IP-HTTPS protocol. The DirectAccess server then forwards unprotected traffic to the intranet resources.6. 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. 7. 8 . 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. The user group policy is applied to the DirectAccess client. 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 begins forwarding traffic from the DirectAccess client to authorized intranet resources. which then is forwarded to each of the application servers in three separate unprotected (dashed line) connections. DirectAccess Access Models Because DirectAccess uses IPsec to protect communications IT Administrators need to decide where to terminate the IPsec tunnel. The DirectAccess user logs on or the logged-on credentials are used in conjunction with the certificates to establish the IPsec user tunnel. the DirectAccess client will reestablish the connection through this process when it detects network connectivity again. There are two access models that can be used when deploying DirectAccess. In the event of an interruption in network connectivity. This is the most common form of DirectAccess and closely follows a standard remote access methodology. The following are the benefits of the end-to-edge access model:  It does not require IPsec-authenticated traffic on the internal network. In DirectAccess the location of the IPsec termination is called an access model. This entire process is transparent to the user and requires no user interaction. When in this mode. In others words. 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. in addition to the IPsec tunnel between the DirectAccess client and DirectAccess server. It closely resembles current VPN architecture and is typically easier to deploy. then the transport policy can be modified to enforce encryption. FIGURE 5 End-to-End Access Model. It can be used with smart cards for an additional level of authorization. It fails to provide end-to-end authentication or data protection with intranet resources. Additional load is placed on the DirectAccess server because it is terminating the IPsec tunnel. which are protected by using IPsec not only through the Internet but also through the intranet. 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. Note that there is a protected (solid line) connection through the tunnel and the DirectAccess server to each of the application servers. The following are the benefits of the end-to-end access model: 9 . It is configurable with the DirectAccess Setup Wizard or Forefront UAG DirectAccess Configuration Wizard. Figure 5 shows the endto-end access model. If additional encryption of the data payload is needed.      The following are the limitations of the end-to-edge access model: End-to-End Access Model The end-to-end access model of DirectAccess requires that DirectAccess clients establish an IPsec session in transport mode with each of the specified application servers that they connect to. This indicates that there are separate IPsec sessions to each server. the IPsec session that is created only provides authentication and data integrity. 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. DirectAccess client—This is a computer running Windows 7. The AD and DNS role can be separate servers. 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. Active Directory and DNS server—This server must be running Windows Server 2008 SP2 or Windows Server 2008 R2. authentication. It can be used with smart cards for an additional level of authorization. It must be a domain member with a client authentication certificate. beyond that found with traditional VPN connections. It is configurable with the DirectAccess Setup Wizard or Forefront UAG DirectAccess Configuration Wizard. to successfully use DirectAccess. Certificate Authority (CA)—The CA is used to issue the certificates that support the tunnel creation. data integrity. 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.    It provides end-to-end authentication. The public interface must have two consecutive public IP addresses assigned to it. Therefore. and security. although most organizations will have these services on the same server. IT Administrators will need to fully understand the various components that consist of a DirectAccess deployment. The following are the limitations of the end-to-end access model:   DirectAccess Components DirectAccess leverages IPv6 along with PKI to provide a seamless secure connection to an organization’s internal network. Each selected server must be part of an Active Directory security group that is used to define access. 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.      Figure 6 shows the logical placement of the DirectAccess components and their various connections: 10 . Internal servers that are not part of the end-to-end access model can still be accessed using the endto-edge access model. and data confidentiality. Corporate IPv6 network—The IPv6 network to which DirectAccess clients will be connecting remotely. Each selected server must be running Windows Server 2008 or Windows Server 2008 R2. However. There are two behaviors that would be experienced for the DirectAccess client system. 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. 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). Given criticality to a DirectAccess deployment. it assumes that it is connected to the corporate network and no further action is necessary. When this occurs. DirectAccess only requires that each client have a valid machine certificate for authentication to the internal network. 11 . If the DirectAccess client cannot reach the network location server URL. all of the DirectAccess clients will begin the DirectAccess connection process. Additionally. If desired. smart cards or NAP protection can also be implemented for additional security if desired. That’s why the network location server Web site must be highly available. it assumes that it is not connected to the corporate network and then begins the DirectAccess connection process. This takes the place of a traditional username and password. with a basic DirectAccess deployment. It is the URL of a highly available website in the corporate intranet. in its most simple configuration. Note If the network location server Web site is not accessible. This is a website that clients attempt to connect to determine if they are currently connected to the Internet or to the intranet. this can result in the disastrous situation of all the DirectAccess clients suddenly thinking they are on the Internet. They are as follows:   If the DirectAccess client can reach the network location server URL.FIGURE 6 The logical placement of DirectAccess components. even though they are really in the Intranet. some deployments may require IPv4 support. or even SSL based solutions. Planning a DirectAccess Deployment Deploying any information system can be a very challenging task. the next decision is to determine which version of DirectAccess to deploy. this section describes the DirectAccess related topics that should be considered as part of your deployment plan. the importance to the DirectAccess deployment. you should have a clear understanding for how the VPN technology will meet your needs. high availability. With DirectAccess. Once configured. If these missing elements are requirements for your DirectAccess deployment. while this type of deployment will have all of the benefits of DirectAccess. PPTP. DirectAccess as a feature is built into Windows Server 2008 R2 and Windows 7 and can be deployed using just these base operating systems. what it’s advantages are over other solutions. Therefore when deciding which solution to use. Unfortunately. However. From an administrator point of view. For each topic covered there is background information. it is also very easy for a DirectAccess deployment to not be properly planned out. Some solutions are better than others depending on the remote access requirements that need to be met. If this is the case. and what disadvantages it might also have. From a user perspective. thus leaving the solution open to failure either through having a failed DirectAccess installation or having DirectAccess at a later date. and Centralized Management In certain deployment scenarios the base DirectAccess functionality that is provided in Windows Server 2008 R2 may not be enough. DirectAccess is the easiest remote access solution. 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. While Microsoft has attempted to make DirectAccess as easy as possible to deploy and use. Therefore. then you should deploy UAG DirectAccess which extends the benefits of 12 . Once you have decided if DirectAccess should be used. For example. DirectAccess may seem complex to install and manage due to the IPv6 and certificate requirements. DirectAccess is no exception as there a many different technologies that need to be understood when planning a DirectAccess deployment. it is just a base deployment of DirectAccess which lacks IPv4 support. it just works. With VPN technologies there are number of different choices. primarily whether to use L2TP/IPsec. 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. and better centralized management. it allows administrators to manage systems as local systems through tools like Group Policy and Microsoft System Center Configuration Manager (SCCM). To help ensure that your DirectAccess deployment is successful. they don’t need to perform any action. and centralized management. however.IPv4 Support. 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. High Availability. high availability. then organizations should deploy DirectAccess using Microsoft Forefront Unified Access Gateway (UAG) 2010. this also happens to be its Achilles heel. In addition. 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. Addresses in the ranges 10. UAG DirectAccess adds the following benefits to a DirectAccess deployment:      The ability to support IPv4 and down-level Windows servers and non-Windows servers.DirectAccess across your infrastructure.0/8.0/12. The ability to provide SSL VPN access for down level (Vista/XP) and non-Windows clients as well as PDAs. 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. DirectAccess clients. If an Internetfacing firewall is already in place the DirectAccess server can be placed between the firewall and your intranet.168. However. and UDP source port 500 outbound Internet Control Message Protocol for IPv6 (ICMPv6) traffic inbound and outbound 13 Internet-facing (UAG DirectAccess server is on the IPv6 Internet)    . DirectAccess Server Location The primary purpose for a DirectAccess server is to allow DirectAccess clients on the Internet to access internal intranet based resources. The only other major consideration is if additional firewalls will be between the DirectAccess server. The Internet facing network adapter must have at least two consecutive public Internet Protocol version 4 (IPv4) addresses. 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 ability to greatly simplify the initial deployment and ongoing management through the use of wizards and automated tools. 6to4 traffic—Protocol 41 inbound and outbound IP-HTTPS—Transmission Control Protocol (TCP) destination port 443. For example. and 192.0. enhancing scalability and simplifying deployments and ongoing management.0/16 are private IPv4 addresses and cannot be used. The ability to increase capacity and provide high availability through the use of UAG arrays. a DirectAccess server does not need to be connected directly to the Internet. and TCP source port 443 outbound Protocol 50 UDP destination port 500 inbound.0. a DirectAccess server must be located on a perimeter network such that its two physical network adapters are split between Internet and intranet traffic.0.16. and the internal network. Therefore.0. The ability to manage the DirectAccess deployment through a centralized management interface. 172. 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. certificate revocation information needs to be highly available both from the Internet and the intranet.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. if the IP-HTTPS and network location server certificate is issued rd from a 3 party publicly trusted CA then. To validate the certificate for the HTTPS connection to the network location server. in theory. 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. then the DirectAccess client will determine it is on the Internet and attempt to create a DirectAccess connection. to ensure DirectAccess connectivity. the content that is located on the network location server is not important. 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. Or. in general. Therefore. If an HTTPS connection cannot be established or if the Web server’s certificate fails a revocation check. instead only the ability for DireactAccess clients to access the defined URL. for certificates that are issued using your organizations PKI. high-capacity intranet Web server. 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. This is a requirement because the DirectAccess server uses revocation information to determine if a DirectAccess client’s machine certificate is valid. For example. 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. 14 . Because of its criticality. The Enhanced Key Usage must Server Authentication. However. In addition. the recommended location/configuration for the network location server is on a highly available and. it can be a third-party Web server that supports HTTPS-based URLs with certificate-based authentication. This Web server can be Windows Server 2008 R2 and Windows Server 2008 running Internet Information Services. 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. However. that CA will ensure that the revocation information is highly available. depending on the number of DirectAccess clients. DirectAccess clients check revocation information for the following scenarios:   To validate DirectAccess server certificate for IP-HTTPS connections. Also. endpoint policies. An internal network facing IPv4 address (VIP). To work around this issue. However. When deploying a UAG DirectAccess NLB array there are a number of items that should be planned out. and is configured using the UAG DirectAccess Configuration Wizard. UAG can assign a different IPv6 /64 prefix to each of the nodes.High Availability To both increase availability and capacity for a UAG DirectAccess deployment you can use a UAG array. When using a hardware load balancer up to 50 servers can be deployed in the array. However. For example. That way. The following table lists the number of array members available for each IP-HTTPS prefix: Prefix Number of Array Members 15 . permissions. Therefore UAG is not able to examine the IPv4 tunnel thus preventing the IP-HTTPS traffic from technically being load balanced. Note When using a hardware load balancer UAG DirectAccess cannot act as an ISATAP router. when using the integrated NLB having only up to eight array members is recommended. portals. UAG NLB must examine the IPv4 tunnel for all transition technologies. This prefix must be routable to the UAG DirectAccess array. published applications. If ISATAP functionality is still needed. which use the Forefront TMG standalone array infrastructure. Additionally. predefined and custom files. 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. the static virtual IP addresses (VIPs) and dedicated IP addresses (DIPs) need to be defined:       An Internet-facing static IPv4 address (DIP). All of the array member share the same configuration (this includes trunks. and VPN client (SSL network tunneling) settings). portal settings. have the following characteristics:   The array consists of multiple UAG servers that are joined into an array configuration. A separate server is not needed for array management. then the ISATAP router function will need to be moved to a separate machine. An internal network facing IPv6 address (VIP). certain server specific settings are different (like IP addresses and passwords). These arrays. authentication servers. An internal network facing static IPv6 address (DIP). IP-HTTPS traffic is encrypted. you must allocate a wide enough IP-HTTPS IPv6 prefix for addresses assigned to remote client computers connecting using IP-HTTPS (/56 to /64). for load balanced IPv6 traffic. Two Internet-facing consecutive public IPv4 addresses (VIPs). An internal network facing static IPv4 address (DIP). However. Instead. using the URL https://nls. no NAT. The first is connected directly to the Internet.2 and 12.com. 6to4. The CA must have an Internet available certificate revocation list (CRL) or OCSP responder.155.com. For this scenario there are five servers and a client system as shown in Figure 7. By completing this scenario the following goals will be accomplished: 1. WEB01—Web server and domain member that the DirectAccess client is accessing.155. public. This scenario also assumes you have an internal enterprise PKI deployment with CRLs or an OCSP responder that is published on the Internet. the DirectAccess configuration itself is fairly straightforward and can be completed using a simple wizard. and must have two consecutive public IP addresses. Additionally. DA01—DirectAccess server and domain member running Windows Server 2008 R2. with two network interface cards. Note 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. and enterprise Certificate Authority server running Windows Server 2008 R2. These are the systems that will be configured and tested against during the scenario. and home networks while retaining access to application servers. The Active Directory domain is contoso.   FILE01—File server and domain member that the DirectAccess client is accessing. and Teredo. A breakdown of the systems is as follows:  AD01—Domain controller.3) assigned. Enable IPv6 in an IPv4 network using IPv6 transition technologies. This scenario assumes that Windows Server 2008 R2 Active Directory and DNS are already deployed.  16 . Allow a workstation to seamlessly move between internal. It is important to note that the scenario does not require that you have deployed IPv6 throughout your internal network to begin using DirectAccess. The second interface is connected to the internal network.contoso.166. To illustrate how to complete a basic DirectAccess deployment this section walks through a deployment scenario using Windows Server 2008 R2. This server also hosts the NLS Web site./64 /63 /62 /61 1 2 3 or 4 5-8 Completing a Basic DirectAccess Deployment Although the prerequisites and associated technologies for DirectAccess can be difficult to implement. DNS. 2. the scenario leverages Windows Server 2008 R2 and Windows 7 technologies that will automatically enable and configure IPv6 using transitional technologies like ISATAP. and two public IP addresses (12. the intended DirectAccess server must have two physical network interfaces.166. 1. FIGURE 7 DirectAccess Scenario. and home networks.com (12. The DirectAccess client is CLIENT01 and will be roaming between these networks and attempting to access WEB01 and FILE01. CLIENT01—DirectAccess client and domain member running Windows 7. The scenario assumes that split-brain DNS is being used—that is. Details about the three networks are as follows:    Internal network—This is the corporate network and is using an IPv4 address in the 192. there are three networks in the scenario. Public network—This is the Internet. 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. Use the following steps to complete this task: 1. As such there should be a DNS A record for da01.com). the public network. This system will travel between the internal. as well as the DNS record for the CRL or OCSP responder for the certificate authority (typically pki. By making this change the DNS will be able to service ISATAP requests. and the IP address range is not known.166.  NS01—This server is the external DNS server and Web server that is hosting the CRL for the URL pki. open a PowerShell console session using the ―Run as Administrator‖ option. Home network—This is a network behind a NAT firewall. the client should seamlessly transition between the networks with no interruption in access to internal resources. In all cases.166. that there is an internal contoso.contoso. and the servers being configured are using the IPv4 12.com zone.x range.contoso.2) in the external companyabc. On DC01. public. In addition.com zone and an external contoso. 17 . to the home network. finally.contoso.x range.com zone.168. and.155. Connectivity to WEB01 and FILE01 will be tested from the client (CLIENT01) while connected to the internal network.com.155. In the IP address field. launch Server Manager. This allows the DirectAccess clients to be defined within the DirectAccess configuration and apply specific DirectAccess Group Policy Objects. These rules are needed allow connectivity for Teredo-based DirectAccess clients that are behind a NAT. then the DirectAccess client will fall back on using IP-HTTPS to establish a DirectAccess connection. and then click Group. Right-click contoso. The last task in this section is to create a security group for DirectAccess client computers. Expand Roles\DNS Server\DNS\DC01\Forward Lookup Zones. type nls. which is acting as a Teredo server and relay. Use the following steps to complete this task: 1. and select the contoso. To ensure that a destination is reachable. 3. Depending on your deployment needs. In the Name field. Use the following steps to complete this task: 1. Under Group scope. launch Server Manager. 5. For this scenario the group will be named DirectAccessClients. and then click OK. 2. and then click Done. 2. Teredo clients send an Internet Control Message Protocol for IPv6 (ICMPv6) Echo Request message and wait for an ICMPv6 Echo Reply message. The next task in the DirectAccess deployment is to create the NLS DNS record. click Add Host. select New. This DNS record is used for the NLS URL that DirectAccess clients use to determine if they are in the corporate network. launch Server Manager. If ICMPv6 Echo Requests are not allowed. it is important to understand that this command is only being executed because this scenario is using ISATAP for internal IPv6 support. choose Security.com and then click New Host (A or AAAA). executing this command may or may not be required. On DC01. 4. choose Global or Universal. On DC01.com zone. On DC01. type the IP address of the NLS website.2. 4.com and select the container that the new group object will be created within. type DirectAccessClients. 3. 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. Right-click on the container. Expand Roles\Active Directory Domain Services\Active Directory Users and Computers\contoso. In the PowerShell console. click OK. execute the following command: dnscmd /config /globalqueryblocklist wpad Note The preceding command needs to be run on each DNS server on the internal network. In the Group Name field. under Group type. DirectAccess clients are Teredo clients to the DirectAccess server. Use the following steps to create a GPO named ―DirectAccess ICMP‖ which will be used to deploy the needed Windows Firewall rules: 1. 18 . DirectAccess clients that are behind NATs on the Internet will attempt to use Teredo for IPv6 connectivity to the DirectAccess server. In addition. In the console tree. in the Name field. 12. for Protocol Type. and then click New Rule. select Computer account. type Outbound ICMPv6 Echo Requests. and then click OK. click ICMPv6. select Local computer. In the Customize ICMP Settings dialog box. and then click Next and Next. In the console tree. 17. 6. expand Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security. 4. and then click Request New Certificate. Click Next. right-click the domain contoso. 9. select and then right-click Inbound Rules. and then click Finish. 5.2. point to All Tasks. click Specific ICMP Types. and then click New Rule. and then click Next and Next. and then click OK. select Echo Request. On the Action page. In the console tree of the Group Policy Management Editor. Click File. 2. 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. type Inbound ICMPv6 Echo Requests. and then click Finish. Next. Enter the name DirectAccess ICMP and then click OK. Click Certificates. In the console tree of the Certificates snap-in. 15. 4. In the Customize ICMP Settings dialog box. On the Name page.com\Domains and select contoso. 3. click Add. and then click Customize. and Next. Close the Group Policy Management Editor and the Group Policy Management Console. On the Protocols and Ports page. 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. In the console tree. 19 . and then click Customize. Right-click the DirectAccess ICMP Group Policy Object and select Edit. expand Certificates (Local Computer)\Personal. On WEB01 click Start. Use the following steps to complete this task: 1. Next. Click Next twice. 5. Click Next and Next. 16. although it is a best practice that it be highly available. and then click Add/Remove Snap-in. 6. 7. click Next. select ICMPv6. select and then right-click Outbound Rules.com. click Custom. Right-click Certificates. 11. On the Rule Type page. and then click Next and Next. for Protocol Type. type mmc. 14. click Custom. For the purpose of this scenario the server WEB01 will be used to host the NLS Web site.com and select Create a GPO in the Domain and Link It Here. On the Name page. and then click OK. Expand Features\Group Policy Management\Forest: companyabc. 3. 18. 10. 13. select Echo Request. and then press ENTER. click Allow the Connection. 19. 8. On the Protocols and Ports page. click Finish. On the Rule Type page. in the Name field. click Specific ICMP Types. Expand Roles\Active Directory Certificate Services and select Certificate Templates. In Value. in the Type list. click Roles. 9. in Subject name. Lastly. and then click More information is required to enroll for this certificate. 10. On the Subject tab of the Certificate Properties dialog box. click Add Roles. 9. In the Site Bindings dialog box.contoso. and then click Close. 6. In the Actions pane. On the Select Server Roles page. In the Add Site Binding dialog box. 2. and then click Finish. In Alternative name. click Enroll. select DNS. 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. 4. 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. click Add. However. in Server Manager expand Web Server (IIS) and select Internet Information Services (IIS) Manager. 12. and then click Add. In Value. click Web Server 2008. Click OK. click https. 3.contoso. The steps to complete this task may vary depending on the overall certificate requirements for your environment. 20 . In SSL Certificate. and then click Next three times. 11. Note Step 7 assumes that the Web Server 2008 certificate template was created beforehand. 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. and then click Add. 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.7. In the console tree of Server Manager. select the Web Server (IIS) check box. Use the following steps to complete this task: 1. and then click Next. select Common Name. 5.com. for Type. for the purposes of this scenario the following generic steps should be used: 1. expand WEB01\Sites. and then click Default Web site. the subject name and subject alternative name of a certificate can be specified during the request. Next. and then click Close.contoso. click Bindings. On the Request Certificates page. In the details pane. type nls. click the certificate with the name nls. for Type. type nls. 8. 7. Click Install. 2. Next. Verify that all installations were successful. 8. Click OK.com.com. launch Server Manager. On DC01. 4. for Type. select Local computer. In Alternative name. Note Step 7 assumes that the Web Server 2008 certificate template was created beforehand. type da01. 4. define the name of the template as Contoso . select DNS.com. 6. The permissions for the Web Server 2008 21 . In Value. Now expand the Enterprise CA and right mouse click Certificate Templates.Domain Machine Authentication. In the Duplicate Template dialog box select the Windows Server 2003 Enterprise option and click OK. and then click Request New Certificate. and then click Add. On DA01 click Start. 5. 7. Click OK. type da01. Click Next twice. Use the following steps to complete this task: 1. 9. In the Enable Certificate Templates dialog box choose the Contoso – Domain Machine Authentication certificate template and click OK. On the Subject tab of the Certificate Properties dialog box. click Next. point to All Tasks. 8. 9. 10. 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. To start this process you will first need to request a server authentication certificate that will be used for IP-HTTPS. select Computer account. click Enroll. 6. in Subject name. select New\Certificate Template to Issue. Note The steps in this section assume that the needed GPO changes to enable auto-enrollment have already been made. 7. 12. 8. and then click Finish. and then press ENTER. Click Certificates. Right-click Certificates. select Common Name. In Value. Next.3. type mmc. In the console tree of the Certificates snap-in. for Type.contoso. click Web Server 2008. 3. Right mouse click the template and select Duplicate Template. and then click More information is required to enroll for this certificate. On the Request Certificates page.com. 2. Next. 11. click Add. Select the Workstation Authentication certificate template. 5. and then click OK. Installing and Configuring DirectAccess The next task in the DirectAccess deployment is to complete the DirectAccess installation and configuration.contoso. and then click Add. and then click Add/Remove Snap-in. Click File. select the Security template and modify the Domain Computers permissions to include Autoenroll and click OK. expand Certificates (Local Computer)\Personal. click Finish. certificate template were modified to allow Domain Computers to enroll for certificates based on this template and the private key can be exported.contoso. 2. 5. FIGURE 8 DirectAccess Setup Wizard. select DirectAccess Management Console. On DA01. Lastly. launch Server Manager.com was enrolled with Intended Purposes of Server Authentication. Click Close to finish. click Add Required Features. This adds the Group Policy Management feature. The screen will show the DirectAccess Setup Wizard. launch Server Manager. type IP-HTTPS and click OK. 3. the subject name and subject alternative name of a certificate can be specified during the request. In the Friendly Name field. Expand Features. At the pop-up. as shown in Figure 8. 13. On the Select Features page. 7. 6. On DA01. and select the Setup node. 4. 14. To complete this task use the following steps: 1. Right-click on Features and select Add Features. Once the IP-HTTPS certificate has been installed the next task is to install the DirectAccess Management Console feature on DA01. Click Next. In the details pane of the Certificates snap-in. verify that a new certificate with the name da01. DirectAccess. 2. Click Install. 15. Use the following steps to complete this task: 1. After the DireactAccess Management Console has been installed the next task is to complete the DirectAccess configuration using the DirectAccess Setup Wizard. 22 . Right-click the certificate and select Properties. On the Connectivity page. 7. ensure that the correct interface is selected. FIGURE 10 DirectAccess Server Connectivity Setup. the public address 12.3. ensure that the correct interface is selected. Click Finish.155. type DirectAccessClients and click OK. click Configure. In Figure 10. as shown in Figure 9. 4. 5. In Step 2 DirectAccess Server. The screen will show the group. In Step 1 Remote Clients. for Interface Connected to the Internet. Note 23 .3 has been assigned to the Internet interface and the private address has been assigned to the internal interface. In the Select Group dialog box.166. click Configure. FIGURE 9 6. For Interface Connected to the Internal Network. On the DirectAccess Client Setup page. The wizard will attempt to select the best interfaces based on the IP address ranges. DirectAccess Client Setup. click the Add button. 8. click Configure. This is the 6to4 IPv6 address for the DC01 domain controller. for Select the Root Certificate to Which Remote Client Certificates Must Chain.contoso. click Browse. click Validate.com.com are also listed with a blank DNS server which defines an NRPT exemption for these FQDNs. click Network Location Server Is Run on a Highly Available Server. FIGURE 11 DirectAccess Server certificate components. note the entry for the name contoso. 14. type https://nls. On the Location page. In Step 3 Infrastructure Servers. The DirectAccess server will be configured as the ISATAP server. click Browse.com. Click Next.consoto. and then click OK. In the list of certificates. 9. Click Finish.com. click the certificate named IP-HTTPS. For Select the Certificate That Will Be Used to Secure Remote Client Connectivity over HTTPS. The results are shown in Figure 11. and then click OK. da01. 13. You should get a green check mark with a Validation Successful message.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.com will be forwarded to this domain controller. 10. nls.com with the IPv6 address. On the DNS and Domain Controller page (shown in Figure 12). and then click Next.contoso. All DirectAccess client requests to the domain contoso. On the Certificate Components page. select the appropriate Root CA certificate. In the list of certificates. 24 .contoso. 12. and pki. 11. 15. 16. 19. Click Finish. Note The blank DNS for the network location server is needed so that DirectAccess clients can use the URL to determine if they are inside the corporate network or on the Internet. 21. In Step 4 Application Servers. leave Require No Additional End-to-End Authentication.contoso. and then click Finish to launch the configuration wizard. 18. On the Management page. such as Microsoft System Center Configuration Manager 2007 (SCCM) servers that needed to reach the DirectAccess clients. so no additional configuration is needed. If these exceptions were not added then clients would not be able to resolve these FQDNs when they were on an external network. When remote and connected via DirectAccess. 17. On the DirectAccess Application Server Setup page. click Apply. Click Next. For the purposes of this only the end-to-edge access model is being used. although they can reach all other internal resources. this step in the configuration wizard is where the permitted application servers would be added. click Configure. Note If end-to-end protection were required.com have been added as NRPT exceptions because of the split-brain DNS configuration. 25 . the DirectAccess clients will be able to access the site. they would be entered in this portion of the setup. da01.com and pki. In the DirectAccess Review dialog box. Click Save. For the purposes of this scenario leave this blank and click Finish. if there were internal management servers.FIGURE 12 DirectAccess Infrastructure Server Setup for DNS. the clients will be unable to reach the site due to the blank DNS entry. When inside the network. 20.contoso. This can be a very useful technique when troubleshooting DirectAccess and IPv6.com and select the OU that contains the DirectAccessClients group. and click OK. Expand Roles\Active Directory Domain Services\Active Directory Users and Computers\contoso.com -4. Contacts. The -6 option forces ping to use IPv6. FILE01. As mentioned previous the DirectAccess functionality will be verified by trying to access 26 . In the Select Users. 6.com DNS entry created by the DirectAccess Setup Wizard and will enable their ISATAP interfaces. or Groups dialog box.exe on the DirectAccess server DA01. WEB01.com -6. you may need to also run gpupdate. 2. By restarting CLIENT01 you are ensuring that the new DirectAccess group policies are applied. The -4 option forces ping to use IPv4. 4. Restart the CLIENT01 computer to have the changes take effect. 8. 3. 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. Additionally. Right-click the group DirectAccessClients and select Properties. each named DirectAccess Policy-<GUID>. 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. and click OK. Each computer should be successfully pinged with both commands. Computers. To complete this task use the following commands: net stop iphlpsvc net start iphlpsvc By restarting the IP Helper service. One has security filtering defined such that it applies only to the DirectAccess server by computer name (DA01$). Click OK to save. 5. type CLIENT01. Note The ping. the systems will be able resolve the isatap. The command to ping a computer DC01 using IPv6 is ping dc1. 7.exe tool can be used to verify that IPv6 is working. The other has security filtering defined such that it applies only to the DirectAccess clients in the DirectAccessClients security group. and then click the Add button. Use the following steps to complete this task: 1.contoso. On DC01. CLIENT01 needs to be added to the DirectAccessClients computer group. The command to ping a computer DC01 using IPv4 is ping dc1. Select the Members tab. click Object Types.During the configuration process two new Group Policy Objects are created. Under Enter the Object Names to Select (Examples). and DA01).companyabc. Testing DirectAccess The last task in the DirectAccess configuration is to test the deployment and verify DirectAccess functionality. check Computers. Finalizing the DirectAccess Configuration Before testing DirectAccess functionality. launch Server Manager.companyabc. Finally. specifically ISATAP.1.155. try to access a share on FILE01 to demonstrate access. For Test B.FILE01 and WEB01 using the internal network (Test A). Next. 27 . and press Enter.com to demonstrate access. Connect the DirectAccess client CLIENT01 to the public network. 2.contoso. and press Enter. Figure 14 shows that CLIENT01 has been assigned an IPv4 address (12.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. 5. enter cmd. 4. 2. 3. At the command prompt.100) on the internal network and that an ISATAP address has been automatically generated in the ISATAP tunnel adapter.168. Select Start. the connection to the public network. the public network (Test B). 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. Figure 13 shows that CLIENT01 has been assigned an IPv4 address (192. enter ipconfig and press Enter. Use the following steps to complete Test A: 1. Select Start. At the command prompt. enter cmd. and finally the home network (Test C). open Internet Explorer and access http://web01. 3. FIGURE 13 Test A—Internal Network. execute the following steps: 1. While logged into CLIENT01 to the internal network. enter ipconfig and press Enter. contoso. and press Enter. Next. enter ipconfig and press Enter. For Test C. Figure 15 shows that CLIENT01 has been assigned an IPv4 address (192.contoso. 2. execute the following steps: 1. 5. 5. able to access internal resources and that the IPv6 transitional technologies are working publicly. enter cmd.2. Next. Select Start. At the command prompt. To verify IP-HTTPS connectivity you will need to disable the Teredo interface by executing the following command: 28 .168. 4.com to demonstrate access. FIGURE 15 Test C—Home Network. Finally.FIGURE 14 Test B—Public Network.com to demonstrate access. 4. the connection to the home network. By completing Test B you should be able to demonstrate that CLIENT01 is connected to the public network. try to access a share on FILE01 to demonstrate access. Connect the DirectAccess client CLIENT01 to the home network. open Internet Explorer and access http://web01. open Internet Explorer and access http://web01. 3.11) on the home network and that a Teredo address has been automatically generated with the Teredo 2001: prefix in the Teredo tunnel adapter. try to access a share on FILE01 to demonstrate access. specifically 6to4. Next. 6. try to access a share on FILE01 to demonstrate access.contoso. By completing Test C you should be able to demonstrate that CLIENT01 is connected to the public network. specifically Teredo and IP-HTTPS. Monitoring the DirectAccess Server The DirectAccess server includes an excellent tool to monitor the activity of the DirectAccess clients. status and activity of the individual DirectAccess components. Next. and detailed statistics on the components. 8. Shown in Figure 17. it provides an overall status of the DirectAccess server. indicating that there are DirectAccess clients using Teredo but none using IP-HTTPS. 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. 29 . open Internet Explorer and access http://web01.netsh interface teredo set state disable 7.com to demonstrate access. 9. Lastly. able to access internal resources anetnd that the IPv6 transitional technologies are working publicly. The figure shows that the Teredo components are active. 30 . Red indicates that the component has failed. The DirectAccess Monitoring tool provides information on the traffic activity. To access the DirectAccess Monitoring tool use the following steps: 1. 2.FIGURE 17 DirectAccess Monitoring. Expand Features\DirectAccess and select Monitoring. data. launch Server Manager. 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. Orange indicates the component is idle. On DA01. For example:     Green indicates current activity in the component. Yellow indicates the component is experiencing issues. the organization needs a solution that supports more than just Windows 7 systems. These metrics are invaluable for monitoring and troubleshooting the DirectAccess infrastructure. or in the case where an organization is upgrading from Windows XP or Windows Vista to Windows 7. 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. As connections are made. To see the performance metrics for any given component. This dual purpose solution is called UAG DirectAccess. ―can I just install DirectAccess. The details window will show the component status screen. a common question asked for the DirectAccess server implementation is. 31 . 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. then the organization needs to implement UAG DirectAccess. an organization can replace the Windows Server 2008 R2 server with a UAG server. if the organization wants to support non-Windows 7 clients such as Windows XP systems. 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.3. click on the Details button to launch Performance Monitor with the appropriate counters. the status will update every 10 seconds to show the activity. 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. 4. The DirectAccess Monitoring tool gives access to dozens of key performance metrics in graphical or tabular format. are the servers and applications being accessed reside only on IPv6-enabled systems such as Windows 2008 or Windows 2008 R2 servers. Or even if the organization is solely Windows 7 client systems. Choosing DirectAccess or UAG DirectAccess As organizations deploy DirectAccess technology on Windows 7 client systems. then the organization can just implement DirectAccess on a Windows Server 2008 R2 server system. Microsoft’s ForeFront Unified Access Gateway. and/or Linux systems. However. 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. then the organization needs to implement UAG DirectAccess instead of just DirectAccess. Apple Mac systems. or UAG provides end point detection and secured (SSL) application tunneling for mixed environments. 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. The UAG server acts as both the Windows 7 DirectAccess server as well as a UAG server for non-Windows 7 systems. By completing this scenario the following goals will be accomplished: 1. 3. Enable IPv4 support using NAT64/DNS64. Allow a workstation to seamlessly move between internal. or if the organization needs to implement UAG DirectAccess for the server component to meet the needs of the organization. 32 . public.The following FlowChart shows the decision tree in determining whether the organization can implement just DirectAccess for the server component. and home networks while retaining access to application servers. Enable IPv6 in an IPv4 network using IPv6 transition technologies. the same scenario will be completed. or Mix of IPv6 and IPv4 Servers? Completing a Basic UAG DirectAccess Deployment In the previous section you learned how to install and configure a basic DirectAccess deployment. 2. Start All Windows 7 Clients or the Environment includes NonWindows 7 Clients Windows 7 Only Windows 2008 R2 DirectAccess Non-Win7 Client All IPv6 supported Windows 2008 or 2008R2 Servers Get UAG DirectAccess Mix of IPv4 servers and IPv6 servers IPv6 (Windows 2008 / 2008 R2) only Servers. however this time the deployment will be down with UAG DirectAccess to support for internal IPv4 hosts. In this section. UAG01—UAG DirectAccess server and domain member running Windows Server 2008 R2. and must have two consecutive public IP addresses. with two network interface cards. This scenario assumes that Windows Server 2008 R2 Active Directory and DNS are already deployed.    33 . UAG01 will also be the NAT64/DNS64 server and needs to have at least 4GB of memory. Additionally. This scenario also assumes you have an internal enterprise PKI deployment with CRLs or an OCSP responder that is published on the Internet.166. The second interface is connected to the internal network.3) assigned.com. The CA must have an Internet available certificate revocation list (CRL) or OCSP responder. These are the systems that will be configured and tested against during the scenario. and two public IP addresses (12. Note 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. Within there are five servers and a client system in the scenario shown in Figure 18. For the purposes of this scenario FILE01 will only support IPv4.155.It is important to note that the scenario does not require that you have deployed IPv6 throughout your internal network to begin using DirectAccess. The Active Directory domain is contoso. WEB01—Web server and domain member that the DirectAccess client is accessing. CLIENT01—DirectAccess client and domain member running Windows 7. and home networks.155. no NAT. The systems are as follows:  AD01—Domain controller. 6to4.contoso. and enterprise Certificate Authority server running Windows Server 2008 R2. This system will travel between the internal.   FILE01—File server and domain member that the DirectAccess client is accessing. The first is connected directly to the Internet.com. This server also hosts the NLS Web site. public. For the purposes of this scenario WEB01 will only support IPV4.contoso. using the URL https://nls. NS01—This server is the external DNS server and Web server that is hosting the CRL for the URL pki. the intended UAG DirectAccess server must have two physical network interfaces. Instead. DNS. and Teredo. the scenario leverages Windows Server 2008 R2 and Windows 7 technologies that will automatically enable and configure IPv6 using transitional technologies like ISATAP.166.2 and 12.com. By making this change the DNS will be able to service ISATAP requests.1.155.168. Connectivity to WEB01 and FILE01 will be tested from the client (CLIENT01) while connected to the internal network. In the PowerShell console. Home network—This is a network behind a NAT firewall. On DC01. there are three networks in the scenario. As such there should be a DNS A record for da01. execute the following command: dnscmd /config /globalqueryblocklist wpad 34 . finally.166. as well as the DNS record for the CRL or OCSP responder for the certificate authority (typically pki.x range.x range.com zone.contoso.com (12.166. open a PowerShell console session using the ―Run as Administrator‖ option. and. The DirectAccess client is CLIENT01 and will be roaming between these networks and attempting to access WEB01 and FILE01.com). The scenario assumes that split-brain DNS is being used—that is. and the IP address range is not known. and the servers being configured are using the IPv4 12.FIGURE 18 DirectAccess Scenario.com zone. to the home network. Details about the three networks are as follows:    Internal network—This is the corporate network and is using an IPv4 address in the 192. that there is an internal contoso. Use the following steps to complete this task: 1. 2.155. Public network—This is the Internet. the client should seamlessly transition between the networks with no interruption in access to internal resources.contoso. In all cases. In addition.com zone and an external contoso. the public network. 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.2) in the external companyabc. Note The preceding command needs to be run on each DNS server on the internal network. and select the contoso. choose Global or Universal. Use the following steps to complete this task: 1. Right-click contoso. 5. 4. To ensure that a destination is reachable. Depending on your deployment needs. To deploy ISATAP using UAG DirectAccess. 3. click OK. In the Group Name field. Expand Roles\Active Directory Domain Services\Active Directory Users and Computers\contoso. Expand Roles\DNS Server\DNS\DC01\Forward Lookup Zones. click OK. 3. type DirectAccessClients. launch Server Manager. DirectAccess clients that are behind NATs on the Internet will attempt to use Teredo for IPv6 connectivity to the DirectAccess server. and then click OK. In the IP address field. click Add Host. it is important to understand that this command is only being executed because this scenario is using ISATAP for internal IPv6 support. type the IPv4 address of the NLS website. Right-click on the container. launch Server Manager. the UAG DirectAccess server will be able to act as an ISATAP router for the organization.com and then click New Host (A or AAAA). This allows the DirectAccess clients to be defined within the DirectAccess configuration and apply specific DirectAccess Group Policy Objects.com and select the container that the new group object will be created within. under Group type. type the IPv4 address of the internal interface of the UAG DirectAccess server. type ISATAP. executing this command may or may not be required. Under Group scope. 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. Use the following steps to complete this task: 1. DirectAccess clients are Teredo clients to the DirectAccess server. Teredo clients send an Internet Control Message Protocol for IPv6 (ICMPv6) Echo Request 35 . the DNS record is used for the NLS URL that DirectAccess clients use to determine if they are in the corporate network. These rules are needed allow connectivity for Teredo-based DirectAccess clients that are behind a NAT. 5. and then click Group. The last task in this section is to create a security group for DirectAccess client computers. 2. which is acting as a Teredo server and relay. type nls. In the Name field. On DC01. 6.com and then click New Host (A or AAAA). 2. In the Name field.com zone. By adding the ISATAP DNS records. For this scenario the group will be named DirectAccessClients. 4. choose Security. In the IP address field. all IPv6 capable hosts must be able to resolve the name ISATAP to the internal interface of the UAG DirectAccess server. select New. Lastly. and then click Done. and then click Done. click Add Host. and provide prefix and routing information for ISATAP hosts on the corporate network. The next task in the UAG DirectAccess deployment is to create the NLS and ISATAP DNS records. In addition. Right-click contoso. On DC01. 9. select Echo Request. 6. and Next. Additionally. Expand Features\Group Policy Management\Forest: companyabc. 7. type Inbound ICMPv4 Echo Requests. 21. On the Profile page. and then click Finish. and then click New Rule. 13. type Inbound ICMPv6 Echo Requests. in the Name field. 2. select and then right-click Outbound Rules. select and then right-click Inbound Rules. and then click OK. On the Name page. Click Next. 3. for Protocol Type. On the Protocols and Ports page. Click Next. 22. 17.com. Use the following steps to create a GPO named ―DirectAccess ICMP‖ which will be used to deploy the needed Windows Firewall rules: 1. and then click New Rule. and then click Finish. In the console tree. and then click New Rule. 12. 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.com and select Create a GPO in the Domain and Link It Here. Teredo based DirectAccess client. and then click Customize. limit the scope rule so that is only applies to the Domain profile and then click Next. If ICMPv6 Echo Requests are not allowed. In the Customize ICMP Settings dialog box. click Custom. for Protocol Type. 14. On DC01. and then click Customize. and then click Next and Next. Like IPv6 hosts. select Echo Request. 18. select and then right-click Inbound Rules. and then click Customize.com\Domains and select contoso. 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. select ICMPv4. In the console tree. 5. 4. On the Protocols and Ports page. launch Server Manager.message and wait for an ICMPv6 Echo Reply message. 11. for Protocol Type. and then click Next and Next. and Next. On the Rule Type page. click Specific ICMP Types. Right-click the DirectAccess ICMP Group Policy Object and select Edit. In the console tree. 19. 36 . Next. 8. expand Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security. click ICMPv4. On the Name page. click Specific ICMP Types. click Custom. click Custom. 15. Next. in the Name field. 10. In the console tree. On the Rule Type page. Next. On the Protocols and Ports page. 16. Enter the name DirectAccess ICMP and then click OK. In the console tree of the Group Policy Management Editor. On the Rule Type page. 20. right-click the domain contoso. and then click OK. and then click Next and Next. then the DirectAccess client will fall back on using IP-HTTPS to establish a DirectAccess connection. In the Customize ICMP Settings dialog box. select ICMPv6. click Allow the Connection. type Outbound ICMPv4 Echo Requests. select Computer account. 37 . click Specific ICMP Types. select Echo Request. for Type. Click File. In Alternative name. and then click Add. type Outbound ICMPv6 Echo Requests. 26. In the Customize ICMP Settings dialog box. click ICMPv6. for Protocol Type. and then click Finish. Click Certificates. For the purpose of this scenario the server WEB01 will be used to host the NLS Web site. in the Name field. click Specific ICMP Types. On the Name page. select Common Name. 5. click Allow the Connection. and then click Next and Next. and then click Add/Remove Snap-in. In the Customize ICMP Settings dialog box. Close the Group Policy Management Editor and the Group Policy Management Console.com. On the Request Certificates page. On the Action page. On the Profile page. and then click OK. 28. click Web Server 2008. and then click Customize. Use the following steps to complete this task: 1. click Add. 33. and then click Finish. Right-click Certificates. and then click Request New Certificate. On the Rule Type page. and then click New Rule. In the console tree of the Certificates snap-in. point to All Tasks.23. In the console tree. On the Subject tab of the Certificate Properties dialog box. expand Certificates (Local Computer)\Personal. On WEB01 click Start. select Local computer. On the Action page. 30. for Type. 4. 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. click Next. 7. Click Next and Next. 10. click Custom. On the Name page. 6. 9. In Value. type nls. in the Name field. 24. and then click OK. 29. and then click Next and Next. click Finish. although it is a best practice that it be highly available. 27. 8. 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. On the Protocols and Ports page. and then click More information is required to enroll for this certificate.contoso. Click Next twice. select and then right-click Outbound Rules. Note The ICMPv4 rules were limited to the Domain profile because the IPv4 based echo request rules only need to apply to hosts that are located on the internal network. limit the scope rule so that is only applies to the Domain profile and then click Next. 31. 32. and then press ENTER. 3. 2. Click Next and Next. type mmc. select DNS. select Echo Request. and then click Next 25. and then click OK. in Subject name. click Add Roles. 12. In the Actions pane. 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. Click Install. In Value.contoso. Next. 4. In SSL Certificate. 9. type nls. and then click Close. 2. select the Web Server (IIS) check box.11. However. Next. the subject name and subject alternative name of a certificate can be specified during the request. for the purposes of this scenario the following generic steps should be used: 1. 8. 4. 7. Right mouse click the template and select Duplicate Template. and then click Next three times. Verify that all installations were successful.com. in Server Manager expand Web Server (IIS) and select Internet Information Services (IIS) Manager. Next. In the details pane. select the Security template and modify the Domain Computers permissions to include Autoenroll and click OK. 3. Select the Workstation Authentication certificate template. and then click Close. Click OK. click the certificate with the name nls. and then click Add. In the Add Site Binding dialog box. and then click Finish. in the Type list. 5.contoso. and then click Default Web site. On the Select Server Roles page. 3. In the Duplicate Template dialog box select the Windows Server 2003 Enterprise option and click OK. Expand Roles\Active Directory Certificate Services and select Certificate Templates. In the Site Bindings dialog box.Domain Machine Authentication. Note Step 7 assumes that the Web Server 2008 certificate template was created beforehand. click Add. 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. click Roles. In the console tree of Server Manager. 6. On DC01. 5. Use the following steps to complete this task: 1. The steps to complete this task may vary depending on the overall certificate requirements for your environment. 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. define the name of the template as Contoso .com. 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. click Bindings. launch Server Manager. Next. Click OK. 6. Lastly. 2. click Enroll. 7. 38 . click https. and then click Next. expand WEB01\Sites. Note Step 7 assumes that the Web Server 2008 certificate template was created beforehand. 15. click Enroll. To start this process you will first need to request a server authentication certificate that will be used for IP-HTTPS. 12. click Add. 9. Note The steps in this section assume that the needed GPO changes to enable auto-enrollment have already been made. type da. and then click Add. select New\Certificate Template to Issue. Use the following steps to complete this task: 1.contoso. 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. 9. Right-click the certificate and select Properties. Click OK. 8. 11. and then click OK. select Local computer.8. type da. click Web Server 2008. Installing and Configuring UAG DirectAccess The next task in the UAG DirectAccess deployment is to complete the UAG DirectAccess installation and configuration. In the Friendly Name field. 39 . Right-click Certificates. the subject name and subject alternative name of a certificate can be specified during the request. and then press ENTER. select Computer account. Lastly. and then click Finish. 5. 10. In Alternative name. click Next. 13. On the Subject tab of the Certificate Properties dialog box. 4. for Type. On UAG01 click Start. 14. In the Enable Certificate Templates dialog box choose the Contoso – Domain Machine Authentication certificate template and click OK. In the details pane of the Certificates snap-in. and then click Add/Remove Snap-in. 7. 2.com. 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. for Type. verify that a new certificate with the name da. In the console tree of the Certificates snap-in.contoso. 6. type IP-HTTPS and click OK. and then click More information is required to enroll for this certificate. Click Next twice. Click File.com was enrolled with Intended Purposes of Server Authentication. select Common Name. select DNS. On the Request Certificates page. in Subject name. and then click Request New Certificate. point to All Tasks. Now expand the Enterprise CA and right mouse click Certificate Templates.com. expand Certificates (Local Computer)\Personal. Click Certificates. In Value. type mmc.contoso. and then click Add. In Value. click Finish. 3. click Next. choose the desire update option and then click OK. before beginning the Forefront UAG installation. In the Getting Started Wizard dialog box. 10. This will start the Getting Started Wizard. On DA01. choose the Single server option. click Next and then click Finish. The screen will show the DirectAccess Configuration Wizard. 2. In the Getting Started Wizard dialog box. click Next. Now in the Getting Started Wizard dialog box. 11. 3. 3. In the Network Configuration Wizard dialog box. 8. In the UAG Management Console select the DirectAccess node. 40 . click Configure Network Settings. execute the Forefront UAG Setup Wizard (setup. provide a strong password to protect the configuration backup file. 5. Use the following steps to complete this task: 1. When prompted restart UAG01 to complete the installation. 4. On the Welcome page of Setup. click Start\All Programs\Microsoft Forefront UAG\Forefront UAG Management. In the Activate Configuration dialog box. and then click Next. 12. DirectAccess. In the Microsoft Update dialog box. click Install Forefront UAG to begin Forefront UAG Setup.hta) from the installation media or an ISO file. After UAG has been installed the next task is to complete the UAG Getting Started Wizard. In the Server Management Wizard dialog box. click Next. 2. define which network adapter is the internal adapter and which network adapter is the external adapter. and when prompted click Yes to activate the UAG configuration. if required. To complete this task use the following steps: 1. and select the Setup node. To complete this task use the following steps: 1. make any needed changes. On the Define Internal Network IP Address Range page. Expand Features. Next. as shown in Figure 19. When running Setup. and then click Activate.Once the IP-HTTPS certificate has been installed the next task is to install Forefront Unified Access Gateway (UAG). Do not install Forefront UAG from a network share. 13. 6. you can customize the installation folder location. On the Define Network Adapters page. click Next and then click Finish. 2. click Close. Once the configuration has been activated click Finish. In the Getting Started Wizard dialog box. click Join Microsoft Update. On the Select Configuration page. 4. click Define Server Topology. 7. On UAG01 ensure that the Network List Service (Netprofm) and the Network Location Awareness (NlaSvc) services are running. 9. Once the Getting Started Wizard has been completed the next task is to complete the DirectAccess configuration using the UAG DirectAccess Configuration Wizard. type DirectAccessClients and click OK. click Edit. 41 .FIGURE 19 UAG DirectAccess Configuration Wizard. In the Clients box. On the UAG DirectAccess Client Configuration page. click the Add button. 6. Click Finish. 4. FIGURE 20 DirectAccess Client Configuration. In the Select Group dialog box. The screen will show the group. as shown in Figure 20. 5. 3. For Select the certificate that authenticates the UAG DirectAccess server to a client connecting using IP-HTTPS. As such the DirectAccess Configuration Wizard will automatically derive the 6to4-based organization. and skip the Prefix Configuration screen of the UAG DirectAccess Configuration Wizard. Click Finish. click Edit.7. 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. In the list of certificates. and click Next. IP-HTTPS. The results are shown in Figure 22. Note If IPv6 has not been deployed within the internal network then the UAG DirectAccess server is automatically configured as an ISATAP router. Teredo relay. 12. In the DirectAccess Server box. 10. For the purposes of this scenario the UAG DirectAccess Server will be acting as a NAT64/DNS64 device. and then click OK. On the Authentication Options page. select the appropriate Root CA certificate. 42 . and IP-HTTPS traffic. Teredo server. click Browse. select the first IPV4 address that will be used to service 6to4. Once the first IPv4 address is selected the Second Internet-facing IPv4 address is automatically defined. Click Next. click the certificate named IP-HTTPS. ensure that Enable UAG DirectAccess NAT64 and Enable DireactAccess DNS64 are selected. and then click OK. and NAT64 IPv6 prefixes. 8. 11. select the Use root certificate option. On the Managing DirectAccess Services page. 9. In the list of certificates. click Browse. On the Connectivity page. for the First Internet-facing IPv4 address. On the DNS Suffixes page (shown in Figure 23).owned by the NAT64 device (the UAG DirectAccess server). On the Network Location Server page. You should get a green check mark with a Validation Successful message. the UAG DirectAccess server will ―multiplex‖ DirectAccess client DNS requests for IPv6 records into two DNS requests. and pki. 15. it is returned back to the client.com.com. If an IPV6 DNS record exists. When this occurs. If there is no IPv6 records.consoto.com.contoso.contoso.FIGURE 22 DirectAccess Authentication Options.contoso. Lastly. nls. note the entry for the name *. 14.com are also defined as NRPT exemptions. and then click Next.contoso. click Validate. 13. In the Infrastructure Servers box. This means that the UAG DNS64 server IP address will be used to resolve names ending with the specified DNS suffix for DirectAccess clients. type nls. da. click Edit.com is defined as [DNS64]. then then IPv4 records are translated into ―fake‖ IPv6 records . 43 . one for IPv4 records and one for IPv6 records which is then forwarded to an internal DNS server. 19. Click Next. click Generate Polices to launch the UAG DirectAccess Configuration Review dialog box. Note If end-to-end protection were required. da.com and pki. For the purposes of this scenario no changes are needed 18. 44 . this step in the configuration wizard is where the permitted application servers would be added. In the UAG DirectAccess Configuration Review dialog box. 20. Note The NRPT exemption for the network location server is needed so that DirectAccess clients can use the URL to determine if they are inside the corporate network or on the Internet. When remote and connected via DirectAccess. they would be entered in this portion of the setup. In the UAG Management Console. This will launch the DirectAccess Policy Configuration dialog box.FIGURE 23 DNS Suffixes.contoso. Once the DirectAccess Policy application has been completed. The other has security filtering defined such that it applies only to the DirectAccess clients in the DirectAccessClients security group. the DirectAccess clients will be able to access the site. click the Activate configuration icon. and then on the Activate Configuration dialog box. click Edit. each named UAG DirectAccess: Client{<GUID>} or DirectAccess: Server{<GUID>}. the clients will be unable to reach the site due to the blank DNS entry. On the Management Servers and DCs page. configuration. 23. and then click Finish. and application. Click Finish. Use this dialog box to monitor the status of the DirectAccess Policy creation. 17. click Activate to activate the configuration. click Apply Now. 21. Click Finish. ensure that the Require end-to-edge authentication and encryption option is selected. such as Microsoft System Center Configuration Manager 2007 (SCCM) servers that needed to reach the DirectAccess clients.contoso. click OK and then click Close. Now. 24. On the Application Server Configuration page. The Server GPO has security filtering defined such that it applies only to the DirectAccess server by computer name (UAG01$). In the Application Servers box. When inside the network.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. 25. if there were internal management servers. During the configuration process two new Group Policy Objects are created. 22. 16. although they can reach all other internal resources. For the purposes of this only the end-to-edge access model is being used. so no additional configuration is needed. 3. and click OK. the public network (Test B). and click OK. 45 . As mentioned previous the DirectAccess functionality will be verified by trying to access FILE01 and WEB01 using the internal network (Test A). Note The ping. 5. the systems will be able resolve the isatap. 7.Finalizing the DirectAccess Configuration Before testing DirectAccess functionality.com DNS entry created by the DirectAccess Setup Wizard and will enable their ISATAP interfaces. 4. The command to ping a computer DC01 using IPv6 is ping dc1. enter cmd.com -4.companyabc. 2. Use the following steps to complete Test A: 1. 2.contoso.companyabc. click Object Types. type CLIENT01. Under Enter the Object Names to Select (Examples).exe tool can be used to verify that IPv6 is working. CLIENT01 needs to be added to the DirectAccessClients computer group. 6. To complete this task use the following commands: net stop iphlpsvc net start iphlpsvc By restarting the IP Helper service. This can be a very useful technique when troubleshooting DirectAccess and IPv6. Right-click the group DirectAccessClients and select Properties. Use the following steps to complete this task: 1. The command to ping a computer DC01 using IPv4 is ping dc1. and then click the Add button. While logged into CLIENT01 to the internal network.com and select the OU that contains the DirectAccessClients group. launch Server Manager. Each computer should be successfully pinged with both commands. Select the Members tab. and press Enter.com -6. check Computers. In the Select Users. Additionally. 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. 8. 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). Computers. By restarting CLIENT01 you are ensuring that the new DirectAccess group policies are applied. On DC01. Click OK to save. The -6 option forces ping to use IPv6. or Groups dialog box. Restart the CLIENT01 computer to have the changes take effect. and finally the home network (Test C). The -4 option forces ping to use IPv4. Testing DirectAccess The last task in the UAG DirectAccess configuration is to test the deployment and verify DirectAccess functionality. you may need to also run gpupdate.exe on the DirectAccess server DA01. Contacts. Expand Roles\Active Directory Domain Services\Active Directory Users and Computers\contoso. Select Start. 168. 4. enter cmd. At the command prompt. For Test B. try to access a share on FILE01 to demonstrate access. Finally. Figure 24 shows that CLIENT01 has been assigned an IPv4 address (192. the connection to the public network. execute the following steps: 1. 2. 46 .contoso. Next. At the command prompt. enter ipconfig and press Enter.100) on the internal network and that an ISATAP address has been automatically generated in the ISATAP tunnel adapter. 3. enter ipconfig and press Enter. open Internet Explorer and access http://web01. specifically ISATAP. open Internet Explorer and access http://web01.155. Connect the DirectAccess client CLIENT01 to the public network.166. Select Start. FIGURE 25 Test B—Public Network.com to demonstrate access. try to access a share on FILE01 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. 5.com to demonstrate access. Next. 4. Finally.3. Figure 25 shows that CLIENT01 has been assigned an IPv4 address (12. FIGURE 24 Test A—Internal Network.1.contoso. 5.20) on the public network and that a 6to4 address has been automatically generated with the 6to4 2002: prefix in the 6to4 tunnel adapter. and press Enter. After disabling the Teredo interface execute the following command to verify the IP-HTTP connection (the output should show an active status as shown in Figure 27): netsh interface httpstunnel show interfaces 47 . Next. Next. 2.168.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 shows that CLIENT01 has been assigned an IPv4 address (192. open Internet Explorer and access http://web01. try to access a share on FILE01 to demonstrate access. 5. At the command prompt.2. 3. For Test C. able to access internal resources and that the IPv6 transitional technologies are working publicly. Connect the DirectAccess client CLIENT01 to the home network. 6. Select Start. the connection to the home network. FIGURE 26 Test C—Home Network. 4. enter ipconfig and press Enter.com to demonstrate access. 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. and press Enter.contoso. specifically 6to4. execute the following steps: 1. enter cmd.By completing Test B you should be able to demonstrate that CLIENT01 is connected to the public network. Next. In the Computer Configuration node. try to access a share on FILE01 to demonstrate access. 48 . By completing Test C you should be able to demonstrate that CLIENT01 is connected to the public network.contoso.com. 9. By using this cmdlet. 2. 4. Monitoring the UAG DirectAccess Server Unlike the base DirectAccess server. Instead. able to access internal resources anetnd that the IPv6 transitional technologies are working publicly. a UAG DirectAccess server does not have a built-in GUI monitoring tool. you will be limited to viewing events on only one array member from a single PowerShell console session. 8. and then click Edit. Lastly. On DC01. However.com\Domains and select contoso.com to demonstrate access. Right mouse click the UAG DirectAccess: DAServer Group Policy object. and on the UAG DirectAccess array members. open Internet Explorer and access http://web01. If the UAG DirectAccess server is part of an array. Aggregated Log—With this mode you are able to view an aggregated set of security events from all of the array members. 3. 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. Expand Features\Group Policy Management\Forest: companyabc. Use the following steps to complete this task: 1. before you can use this mode you must first enable event forwarding on the collector server (the server to which events are forwarded).  Before you can start using the Get-DirectAccessUsers cmdlet you must first enable IPsec logging. and then click Logon/Logoff. launch Server Manager. 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. specifically Teredo and IP-HTTPS.FIGURE 27 IP-HTTPS status. expand Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies. and then click OK. and then click OK. if you have System Center Operations Manager (SCOM) you could use the Unified Access Gateway (UAG) management pack. As you can image. DirectAccess connection information will start being logged to a UAG DirectAccess server’s security event log. Once IPsec logging has been enabled. 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. In the right pane.5. Use the following steps to view this information using the Get-DirectAccessUsers cmdlet: 1. Double-click Audit IPsec Main Mode. To some extent. while the connection data that is provided by the Get-DirectAccessUsers cmdlet is useful. open a PowerShell console session using the ―Run as Administrator‖ option. select Success and Failure. there are some DirectAccess related performance counters. This monitoring includes information that comprises the health state of the DirectAccess components: 6to4 49 . With the Unified Access Gateway (UAG) management pack you will get DirectAccess monitoring. However. Instead. 6. double-click Audit IPsec Extended Mode. There is a lot more monitoring data that an IT Administrator would want to ensure the health of their UAG DirectAccess deployment. Next. On UAG01. execute the following command to add the UAGDAUserMonitoring snap-in into your PowerShell console session: Add-PSSnapin UAGDAUserMonitoring 3. 2. that data can be retrieved from various sources on a UAG DirectAccess server. select Configure the following audit events. select Success and Failure. select Configure the following audit events. For example. pulling the data together and making sense of it may be a bit tricky. ISATAP router. the IPsec policies that protect DirectAccess traffic are extended all the way to the specified application servers. 4. In the UAG Management Console select the DirectAccess node. In the Application Servers box. and Teredo server. In addition. 50 . When using this type of access model. In the Application Server Configuration dialog box. DirectAccess. click Edit. Expand Features. 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. and then click Finish. FIGURE 29 Application Server Configuration. To configure a UAG DirectAccess server to use the end-to-end access model. and Teredo packet receive rate. Note To enable data payload encryption for the IPsec session click the Edit IPSec cryptography settings option. 2. IP-HTTPS gateway. In the Select Group dialog box. Teredo relay. Network security. Lastly. number of Main Mode Security Associations. edit the Quick Mode encryption settings as shown in Figure 30. 3. and select the Setup node. DNS64. 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. Then in the IPSec Advanced Settings dialog box. Configuring End-to-End Authentication As discussed earlier in this document you can configure DirectAccess to use an end-to-end access model. use the following steps: 1. The results of adding a group are shown in Figure 29. 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. The screen will show the DirectAccess Configuration Wizard. click OK.router. 5. select the Require end-to-end authentication and encryption to specified application servers option and then click Add. click Edit. 51 . Expand Features. This will launch the DirectAccess Policy Configuration dialog box. Now. and then click Finish. Once the DirectAccess Policy application has been completed. and select the Setup node. 4. 7. the newly created GPO must be applied to the specified application server(s). The screen will show the DirectAccess Configuration Wizard. you must use the following steps: 1. If at a later date you add application servers to the security group you used or you change an application servers IP address.FIGURE 30 Enabling End-to-End encryption. 3. To correct this issue. In the UAG Management Console select the DirectAccess node. Next. or click Export Script. connect the DirectAccess client to an external network. However. 5. or for a testing scenario you may want to force GPO application by using gpupdate. Next. click OK and then click Close. then that application server will be inaccessible to the DirectAccess client in both clear and encrypted modes. configuration. In the Application Servers box. You can either allow the application of GPO to occur naturally. 4. before DirectAccess clients must start using the end-to-end protection. and application. Now. While logged into a DirectAccess client on the internal network. Lastly. try to access the protected application server(s). click Generate Policies. DirectAccess. Next. During the configuration process a new Group Policy Object is created named UAG DirectAccess: AppServer{<GUID>}. 3. 6. click Generate Polices to launch the UAG DirectAccess Configuration Review dialog box. click Apply Now. 2. use the following steps to test the end-to-end protection for the application servers that were specified: 1. 2. try to access the protected application server(s). This issue occurs because the added application servers or modify IP address information is not automatically updated in the DirectAccess client application server list. This GPO has security filtering defined such that it applies only to the security groups that you specified require end-to-end protection.exe. 8. Verify that a DirectAccess connection is made to the internal network. click Apply Now. Use this dialog box to monitor the status of the DirectAccess Policy creation. In the UAG DirectAccess Configuration Review dialog box. and then click Quick Mode. open the Windows Firewall Advanced Security mmc snap-in. This deployment guide provided the step-by-step implementation of both Windows Server 2008 R2 DirectAccess and UAG DirectAccess in repeatable implementation processes. Expand Monitoring\Security Associations. As shown in Figure 31 use the Quick Mode information to verify that an IPsec session exists for the application server(s). DirectAccess provides remote network access from Windows 7 clients to Windows 2008 and Windows 2008 R2 application servers. Summary DirectAccess can be implemented as a feature in Windows Server 2008 R2 or integrated with Forefront Unified Access Gateway (UAG). If the connection to the application server(s) succeeded and while still connected. By adding in Forefront UAG.6. FIGURE 31 Verifying end-to-end protection. 52 . 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. 7. As a Windows Server 2008 R2 solution. or other intellectual property. product. in this document. without the express written permission of Microsoft Corporation. or event is intended or should be inferred. organizations. Windows Server.This document is provided for informational purposes only and Microsoft makes no warranties. copyrights. or otherwise). patent applications. photocopying. Unless otherwise noted. or for any purpose. places. copyrights. domain name. Without limiting the rights under copyright. All other trademarks are property of their respective owners. logos. All rights reserved. No association with any real company. Complying with all applicable copyright laws is the responsibility of the user. Windows. no part of this document may be reproduced. person. people. 53 . Except as expressly provided in any written license agreement from Microsoft. including URL and other Internet Web site references. recording. products. Information in this document. e-mail address. either express or implied. organization. e-mail addresses. or other intellectual property rights covering subject matter in this document. is subject to change without notice. the furnishing of this document does not give you any license to these patents. Active Directory. Microsoft may have patents. and events depicted in examples herein are fictitious. Windows Media. place. stored in or introduced into a retrieval system. domain names. the companies. © 2010 Microsoft Corporation. mechanical. The entire risk of the use or the results from the use of this document remains with the user. or transmitted in any form or by any means (electronic. trademarks. Microsoft. trademarks. logo. and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.