Hey folks – since the TLGs are typically put up only in the download center, it makes discoverability of some of the cool content inside of them hard when it comes to search engines. Therefore, I’m going to post the full text of the TLGs on the Edge Man blog. However, I recommend that you download the Word .doc version of the TLGs when you actually put together your Test Lab using the Test Lab Guides.
For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess Remote Management check out:
http://go.microsoft.com/fwlink/?LinkId=205210
==================================================
Introduction
Forefront Unified Access Gateway (UAG SP1 RC) provides users with the experience of being seamlessly connected to their intranet any time they have Internet access. When DirectAccess is enabled, requests for intranet resources (such as e-mail servers, shared folders, or intranet Web sites) are securely directed to the intranet, without the need for users to connect to a VPN. DirectAccess enables increased productivity for a mobile workforce by offering the same connectivity experience both inside and outside of the office. Forefront UAG SP1 RC DirectAccess extends the benefits of Windows DirectAccess across your infrastructure by enhancing availability and scalability, as well as simplifying deployments and ongoing management. For more information, see Overview of Forefront UAG DirectAccess.
This Test Lab Guide provides step-by-step instructions for configuring Forefront UAG SP1 RC DirectAccess Remote Management in a test lab so that you can see how it works. You will set up and deploy Forefront UAG SP1 RC DirectAccess using 5 server computers, two client computers, Windows Server 2008 R2 Enterprise Edition, Windows Server 2003 Enterprise Edition SP2, and Windows 7 Ultimate Edition. The Test Lab simulates intranet, Internet, and a home networks, and demonstrates Forefront UAG SP1 RC DirectAccess in different Internet connection scenarios.
Important:
These instructions are designed for configuring a test lab using the minimum number of computers. Individual computers are needed to separate the services provided on the network, and to show clearly the required functionality. This configuration is not designed to reflect best practices, nor does it reflect a required or recommended configuration for a production network. The configuration, including IP addresses and all other configuration parameters, is designed to work only on a separate test lab network. For more information on planning and deploying DirectAccess with Forefront UAG SP1 RC, please see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide
This Test Lab Guides builds on the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess. You will need to complete all the steps in that guide before you can complete the steps in this Test Lab Guide.
In this test lab scenario, Forefront UAG SP1 RC DirectAccess is deployed with:
The test lab consists of three subnets that simulate the following:
Computers on each subnet connect using either a physical or virtual hub or switch, as shown in the following figure.
The following components are required for configuring Forefront UAG SP1 RC DirectAccess in the test lab:
The following steps describe how to configure the server and client computers, in a test lab. Following these configurations you can verify DirectAccess connectivity from the Internet and Homenet subnets. In addition, you will see how you can manage DirectAccess clients from management computers on the intranet. This Test Lab Guide also highlights a new feature included in UAG SP1 RC, which allows you to limit DirectAccess client connectivity to the intranet tunnel only, which enables continuous management of DirectAccess clients without allowing users to access resources on the intranet.
Note:
You must be logged on as a member of the Domain Admins group or as a member of the Administrators group on each computer to complete the tasks described in this guide. If you cannot complete a task while you are logged on with an account that is a member of the Administrators group, try performing the task while you are logged on with an account that is a member of the Domain Admins group.
You will perform the following steps to demonstrate UAG SP1 RC DirectAccess remote management in this Test Lab Guide:
· Step 1: Complete the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess – This Test Lab Guide builds on the configuration created after completing the steps in Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.
· Step 2: Configure Remote Management – In this step you will create the DirectAccess client OU, create and configure a DirectAccess client GPO and refresh the remote access client configuration and enabling remote desktop connectivity to DirectAccess clients.
· Step 3: Test Remote Management of DirectAccess Clients – After the new firewall settings are deployed to the DirectAccess client, management servers on the corporate network can initiate connections to the DirectAccess client. In this step you validate the settings and establish connections from DC1 to CLIENT1, when CLIENT1 is acting as a DirectAccess client behind NAT1.
· Step 4: Limit DirectAccess Client to Only the Management Tunnel. In this step you will configure UAG1 to limit DirectAccess client connectivity to only the infrastructure tunnel.
· Step 5: Snapshot the Configuration. After completing the Test Lab, take a snapshot of the working UAG SP1 RC DirectAccess NLB array so that you can return to it later to test additional scenarios.
The first step is to complete all the steps in the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess. After completing the steps in that Test Lab Guide you will have the core infrastructure required to complete this Test Lab Guide on how to configure UAG SP1 RC DirectAccess remote management. If you have already completed the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess Test Lab Guide and saved the configuration in either a virtual machine snapshot or disk image for a physical deployment, you can restore that configuration and begin with the next step.
DirectAccess uses two IPsec tunnels between DirectAccess client and server to enable communications to the corporate network. The first IPsec tunnel is the “infrastructure” tunnel. This tunnel is established after the DirectAccess client computer starts, but before the user logs on. Authentication is required for this tunnel, and both a computer certificate and the computer account in Active Directory are used to authenticate the first IPsec tunnel connection. The second tunnel (the intranet tunnel) is established after the user logs on and allows the user to access network resources. Authentication for this tunnel uses computer certificate and user (Kerberos) authentication in Active Directory.
The infrastructure tunnel provides bidirectional access to and from servers included in the management servers collection, as defined in the DirectAccess configuration wizard. These servers can connect to DirectAccess clients over the infrastructure tunnel, so that connectivity is enabled whenever the DirectAccess client computer is turned on, regardless of whether the user is logged on. The infrastructure tunnel enables remote management scenarios where administrators can apply patches, make configuration changes, and employ their full suite of configuration and management tools not only to computers on the corporate network, but to any DirectAccess client on the Internet.
You will perform the following procedures to enable several remote management scenarios:
A. Create the DirectAccess Client Organizational Unit and Place CLIENT1 in the New OU. New firewall rules are required to enable some aspects of remote management of DirectAccess clients. Firewall rules can be configured on each client individually, but it is more efficient to use Group Policy to distribute the new firewall rules to all DirectAccess clients. Changes could be made to the DirectAccess Client GPO created by the UAG SP1 RC DirectAccess wizard, but these settings are overwritten each time the wizard is run. Therefore, you will create new GPO to support these custom settings. The new GPO is then linked to an OU that is populated with the DirectAccess client computer accounts.
B. Create and Configure the DirectAccess GPO and Link it to the DirectAccess Client OU. The DirectAccess GPO is linked to the DirectAccess client OU. In this step you create and populate the DirectAccess client OU.
C. Refresh the DirectAccess Client Configuration and Enable Remote Desktop Connections to CLIENT1. The DirectAccess clients need to refresh this Group Policy configuration to receive the new GPO settings. In this step the DirectAccess client refreshes it Group Policy configuration to receive the new firewall settings.
Remote management scenarios for DirectAccess clients can happen in two ways. In the first scenario, the DirectAccess client contains one or more management agents that initiate connections to management servers on the corporate network over either the infrastructure or intranet tunnel. If the user is not logged on, the management agents can initiate connections to management servers over the infrastructure tunnel. If the user is logged on, either the infrastructure or intranet tunnel can be used by the DirectAccess client to connect to the intranet. No special firewall rules are required for the DirectAccess client to initiate connections to management servers.
In the second scenario, management servers initiate connections to the DirectAccess client. Special Windows Firewall with Advanced Security firewall rules are required to enable management servers to initiate connections to Active Directory clients when the DirectAccess client is located behind a NAT device. These firewall rules must be configured for each desired protocol used to initiate the connection to the DirectAccess client, and then each of these rules must enable Edge Traversal.
The special firewall rules can be configured on each DirectAccess client individually. However, this manual approach does not scale. A better solution is to use Active Directory Group Policy to configure and distribute the new firewall rules for the desired protocols with Edge Traversal enabled.
While it is possible to configure these rules using the GPO created by the UAG SP1 RC DirectAccess wizard, these GPO settings are overwritten each time the wizard is run and the new GPO settings deployed. A viable alternative is to create a new GPO and a new Organizational Unit for the DirectAccess clients. The new DirectAccess client GPO can be linked to the new OU to apply the firewall rules required for management servers to initiate connections to the DirectAccess clients.
Note: DirectAccess clients using the 6to4 IPv6 transition technology to connect to the DirectAccess server do not require special firewall rules with Edge Traversal. However, since you cannot predict when any specific DirectAccess client will use any specific IPv6 transition technology at any specific point in time, you should always enable Edge Traversal on your firewall rules.
To apply the GPO settings to the DirectAccess clients, we create an Organizational Unit that will contain the DirectAccess clients. The DirectAccess GPO is linked to the new OU. The first step is to create the DirectAccess OU and place the CLIENT1 into this OU.
The following steps are carried out on DC1.
DirectAccess clients that connect to the DirectAccess server using Teredo or IP-HTTPS need special Firewall Rules to support “manage out” connections. These firewall rules are created for each protocol needed to connect from the intranet to the DirectAccess client. By default, there are no Firewall Rules that allow outbound management from management servers on the intranet, so you must create rules to allow the required protocols. The best way to deploy these Firewall Rules is by configuring them in Group Policy so that the settings are automatically deployed. In this example we will create rules that allow management computers on the corpnet to connect to DirectAccess clients on the Internet using Ping, File Services and Remote Desktop Protocol. Perform the following steps on DC1.
CLIENT1 needs to receive the firewall rules configured in Group Policy. That can be done by initiating a Group Policy refresh while CLIENT1 is running as a DirectAccess client on the Internet. In addition, CLIENT1 needs to be configured to allow Remote Desktop connections before it can accept RDC connections from a management server on the corpnet. Perform the following steps on CLIENT1.
The DirectAccess client is now ready for remote management using the protocols configured in the Firewall Rules that allow for Edge Traversal. Perform the following procedures on DC1. The procedures are performed on DC1 because DC1 is the only computer that is on the management servers list and therefore the only one that can connect to CLIENT1 over the infrastructure tunnel. In addition, CLIENT1 will be restarted, but you will not log on, so that DC1 will be forced to use the infrastructure tunnel to connect to CLIENT1. The intranet tunnel is only available after the user logs on to the DirectAccess client computer.
While seamless access to the intranet for DirectAccess clients is a compelling use case for DirectAccess users, many IT organizations find the remote management capabilities even more useful. There may be some organizations that prefer that only the infrastructure tunnel be available so that DirectAccess client are always managed, but that users cannot access resources on the intranet. UAG SP1 RC includes a new feature that allows you to configure DirectAccess clients so that they only have access to the intranet tunnel.
In this step we will demonstrate how to configure DirectAccess clients so that they have access only to the intranet tunnel so that they can be always managed:
1. *At UAG1, click Start and then click All Programs. Click Microsoft Forefront UAG and then click Forefront UAG Management. In the User Account Control dialog box, click Yes.
2. In the Microsoft Forefront Unified Access Gateway Management console, click DirectAccess in the left pane of the console.
3. In the right pane of the console, in the Step 1 Clients and GPOs section, click Edit.
4. This starts the Clients and GPOs Configuration wizard. On the Deployment Model page, select the Enable remote management of DirectAccess client only option. Confirm that there is a checkmark in the Allow only services running under the client computer account to access infrastructure servers used for remote management checkbox. This option allows system services running in the context of the local computer account to connect to infrastructure servers through the infrastructure tunnel, but does not allow processes running in the context of the logged on user account to reach infrastructure servers. In addition, because the intranet tunnel cannot be established, the user cannot reach any other server on the intranet. Click Next.
5. On the Client Domains page, click Next.
6. On the Policy Management page, click Next.
7. On the Client Groups page, click Finish.
8. In the right pane of the Microsoft Forefront Unified Access Gateway Management console, click the Apply Policy button.
9. On the Forefront UAG DirectAccess Configuration Review page, click Apply Now. Click OK in the DirectAccess Policy Configuration dialog box after you see it report Script run completed with no errors or warning.
10. On the Forefront UAG DirectAccess Configuration Review page, click Close.
11. Open and elevated command prompt. In the command prompt window, enter gpupdate /force and press ENTER. Close the command prompt window when the command completes.
12. *Go to CLIENT1. Log on as CORP\User1. Open an elevated command prompt. In the command prompt window, enter gpupdate /force and press ENTER. Notice that the gpupdate fails, as this command is run under the user context.
13. In the command prompt window, enter net view \\dc1 and press ENTER. You will see that you get a System Error 53 occurred. The network path was not found. Again, the connection attempt fails because the command is sent in the context of the current user.
14. In the command prompt window, enter ping dc1 and press ENTER. You will see four responses from DC1’s ISATAP assigned IPv6 address. This indicates that DNS queries are working correctly over the infrastructure tunnel. DNS queries are sent by the DNS client service in the context of the local computer account, so CLIENT1 was able to resolve the name of DC1. The ping request was send in the context of the local user account. This request was successful because ICMPv6 communications are not sent over the IPsec tunnel, therefore there is no authentication failure.
15. *Return to DC1. Open and elevated command prompt. In the command prompt window enter net view \\client1 and press ENTER. Notice that you can still access CLIENT1 because DC1 connects to CLIENT1 through the infrastructure tunnel.
16. On DC1, open Event Viewer from the Administrative Tools menu. Review the entries related to CLIENT1 starting up and receiving Group Policy settings and machine authentication. This further demonstrates that CLIENT1 was able to communicate with DC1 during the startup process because of the access provided over the infrastructure tunnel.
This completes the UAG SP1 UAG SP1 RC DirectAccess remote management test lab. To save this configuration so that you can quickly return to a working UAG SP1 RC DirectAccess remote management configuration from which you can test other DirectAccess modular TLGs, TLG extensions, or for your own experimentation and learning, do the following:
1. On all physical computers or virtual machines in the test lab, close all windows and then perform a graceful shutdown.
2. If your lab is based on virtual machines, save a snapshot of each virtual machine and name the snapshots UAG SP1RC DirectAccess Remote Management. If your lab uses physical computers, create disk images to save the DirectAccess test lab configuration
For procedures to configure the Base Configuration test lab on which this document is based, see the Test Lab Guide: Base Configuration.
For procedures required to build this Test Lab Guide, see Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.
For the design and configuration of your pilot or production deployment of DirectAccess, see the Forefront UAG SP1 RC DirectAccess design guide and the Forefront UAG SP1 RC DirectAccess deployment guide.
For information about troubleshooting DirectAccess, see the DirectAccess Troubleshooting Guide.
For information on how to troubleshoot UAG DirectAccess in a Test Lab, see Test Lab Guide: Troubleshoot UAG DirectAccess.
For a comprehensive list of UAG DirectAccess Test Lab Guides, see Test Lab Guides.
For more information about DirectAccess, see the DirectAccess Getting Started Web page and the DirectAccess TechNet Web page.
===================================
HTH,
Tom
Tom Shinder tomsh@microsoft.com Knowledge Engineer, Microsoft DAIP iX/SCD iX UAG Direct Access/Anywhere Access Group (AAG) The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
So you liked what you saw after going through the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess Test Lab Guide. In that guide you saw how to set up a working DirectAccess configuration with UAG SP1 RC and were able to check out the new Web Monitor view of DirectAccess client connections.
So what’s next? How about some UAG SP1 RC DirectAccess Remote Management?
You got it!
The new Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess Remote Management shows you how to configure UAG DirectAccess clients so that you can manage them from management stations on your intranet. The “always connected” nature of DirectAccess makes it the ideal “always managed” solution – and you can extend that by configuring custom firewall rules to gain even greater control and increased visibility of all your managed assets, regardless if those assets are on the intranet or anywhere on the Internet.
This Test Lab Guide covers several remote management scenarios, including a scenario enabled by a new feature in UAG SP1 RC that allows you to configure DirectAccess clients for remote management only. This was something that our UAG DirectAccess customers asked for, so we made it happen!
This new feature allows IT to always have access to DirectAccess clients – but doesn’t allow users to access the intranet through a DirectAccess connection. One example of why you might do this is when you want to have command and control over all your managed assets, but don’t want the users to have open network access to the intranet over the Internet – providing for a “manage only” DirectAccess deployment.
As always, if you have questions, suggestions or comments about this or any other UAG DirectAccess related Test Lab Guide, let me know! Just write to the email address in my sig line and I’ll get back to you.
Test Lab Guides make it easy to test new products and technologies in a pre-tested, well defined Test Lab. Our new Test Lab Guide system is designed so that you don’t have to reinvent the wheel each time you put together a Test Lab each time you want to test out something new. Test Lab Guides are modular, which means you reuse your Test Labs over time to test new technologies and new scenarios. In the course of a year, TLGs should end up saving your potentially hundreds of hours in test time.
In addition, Test Lab Guides “take the covers off” so that you understand what’s happening on the front-end and back-end – something you don’t get with “hands-on labs” where the front-end and back-end are preconfigured and “magically” work. Unfortunately, you can’t take that magic home with you when you actually want to put together a test lab of you own.
If you haven’t checked out how Test Lab Guides work and the philosophy behind them, then check out my blog post on the TLG concept over at http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
I’m glad you asked! All Test Lab Guides start with the “Base Configuration” which you can find at http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ab6c61af-9c34-4692-815c-4396b482d31b&displayLang=en
The Base Configuration Test Lab Guide sets up the contoso.com forest. For all Test Lab Guide modules that test a product or technology, or a collection of products or technologies in a single forest environment, you’ll always start with the Base Configuration. But what if you want to test a product or technology or a collection of products or technologies that includes two forests over the Internet, such as scenarios where two different organizations want to collaborate?
You could use the Base Configuration to build out the contoso.com forest, and the cobble together a test lab configuration for the partner network, but that wouldn’t be very reusable or very scalable. What would be better is if you had a standard and tested configuration for the partner network – where you can then build scenarios on top of that.
Sounds good, right? I thought so! That’s where the Fabrikam Test Lab guide comes in. In the Fabrikam Test Lab Guide, we define the configuration of the partner network for you, and it plugs right into the Base Configuration Test Lab Guide that defines the contoso.com test lab. After you finish the Fabrikam Test Lab Guide, you’ll have a second forest, the fabrikam.com forest, which is separated from the contoso.com forest by a simulated Internet.
I see the Fabrikam TLG being used primarily in the two following scenarios:
As with all Test Lab Guides – I’m here to help. If you need help in creating your own Test Lab Guides, let me know. I think once you get into the groove with writing your own Test Lab Guide extensions and posting them to the wiki, you’ll find them a lot of fun! I know I do. If you have questions or run into issues with this TLG or with TLGs you want to write, let me know. Just write to the email address in my sig line.
Tom Shinder tomsh@microsoft.com Microsoft DAIP iX/SCD iX UAG Direct Access/Anywhere Access Group (AAG) The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
Hey folks – since the TLGs are typically put up only on the download center, it makes discoverability of some of the cool content inside of them hard when it comes to search engines. Therefore, I’m going to post the full text of the TLGs on the Edge Man blog. However, I recommend that you download the Word .doc version of the TLGs when you actually put together your Test Lab using the Test Lab Guides.
For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess check out:
http://go.microsoft.com/fwlink/?LinkId=204993
Forefront Unified Access Gateway (UAG) 2010 SP1 RC provides users with the experience of being seamlessly connected to their intranet any time they have Internet access. When DirectAccess is enabled, requests for intranet resources (such as e-mail servers, shared folders, or intranet Web sites) are securely directed to the intranet, without the need for users to connect to a VPN. DirectAccess enables increased productivity for a mobile workforce by offering the same connectivity experience both inside and outside of the office. Forefront UAG 2010 SP1 RC DirectAccess extends the benefits of Windows DirectAccess across your infrastructure by enhancing availability and scalability, as well as simplifying deployments and ongoing management. For more information, see Overview of Forefront UAG DirectAccess.
IT professionals can benefit from UAG 2010 SP1 RC DirectAccess in many ways:
· Improved Manageability of Remote Users. Without DirectAccess, IT professionals can only manage mobile computers when users connect to a VPN or physically enter the office. With DirectAccess, IT professionals can manage mobile computers by updating Group Policy settings and distributing software updates any time the mobile computer has Internet connectivity, even if the user is not logged on. This flexibility allows IT professionals to manage remote computers on a regular basis and ensures that mobile users stay up-to-date with security and system health policies.
· Secure and Flexible Network Infrastructure. Taking advantage of technologies such as Internet Protocol version 6 (IPv6) and Internet Protocol security (IPsec), DirectAccess provides secure and flexible network infrastructure for enterprises. Below is a list of DirectAccess security and performance capabilities:
o Authentication. DirectAccess authenticates the computer, enabling the computer to connect to the intranet before the user logs on. DirectAccess can also authenticate the user and supports two-factor authentication using smart cards and one-time passwords, such as RSA SecurID.
o Encryption. DirectAccess uses IPsec to provide encryption for communications across the Internet.
o Access to IPv4-only intranet resources. UAG DirectAccess extends the value of Windows DirectAccess with NAT64/DNS64, an IPv6/IPv4 protocol transition technology that enables DirectAccess client connectivity to IPv4-only resources on the intranet.
· High availability and array configuration. UAG DirectAccess extends the value of Windows DirectAccess by adding integrated support for Network Load Balancing and array configuration, which work together to enable a highly available DirectAccess deployment.
· IT Simplification and Cost Reduction. By default, DirectAccess separates intranet from Internet traffic, which reduces unnecessary traffic on the intranet by sending only traffic destined for the intranet through the DirectAccess server. Optionally, IT can configure DirectAccess clients to send all traffic through the DirectAccess server.
The following figure shows a DirectAccess client on the Internet.
This paper contains instructions for configuring and demonstrating UAG2010 SP1 RC DirectAccess using five server computers and two client computers. The starting point for this guide is a Test Lab based on the “Steps for Configuring the Corpnet Subnet “ and “Steps for Configuring the Internet Subnet“ sections of the Test Lab Guide: Base Configuration. The resulting UAG 2010 SP1 RC DirectAccess test lab simulates an intranet, the Internet, and a home network and demonstrates DirectAccess functionality in different Internet connection scenarios.
These instructions are designed for configuring a Test Lab using the minimum number of computers. Individual computers are needed to separate the services provided on the network, and to show clearly the required functionality. This configuration is not designed to reflect best practices, nor does it reflect a required or recommended configuration for a production network. The configuration, including IP address assignment and all other configuration parameters, is designed to work only on a separate Test Lab network. For more information on planning and deploying DirectAccess with Forefront UAG for your production network, please see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide
In this test lab scenario, Forefront UAG DirectAccess is deployed with:
CLIENT1 initially connects to the Corpnet subnet and joins the intranet domain. After UAG1 is configured as a Forefront UAG DirectAccess server, and CLIENT1 is updated with the DirectAccess client Group Policy settings, CLIENT1 later connects to the Internet subnet and the Homenet subnet, and tests DirectAccess connectivity to intranet resources on the Corpnet subnet.
The following components are required for configuring Forefront UAG DirectAccess in the test lab:
The following steps describe how to configure the server and client computers, and configure the Forefront UAG DirectAccess server, in a test lab. Following these configurations you can verify DirectAccess connectivity from the Internet and Homenet subnets.
· Step 1: Complete the Base Configuration. The Base Configuration is the core of all Test Lab Guide scenarios. The first step is to complete the Base Configuration.
· Step 2: Configure DC1 - DC1 is a Windows Server 2008 R2 computer that is the domain controller, Certificate server, DNS server, File Server and DHCP server for the corp.contoso.com domain.
· Step 3: Configure APP1- APP1 is a Windows Server 2008 R2 computer that acts in the role of the Network Location Server on the network.
· Step 4: Install and Configure APP3 - APP3 is a Windows Server 2003 Enterprise Edition computer that acts as an IPv4 only host and is used to demonstrate DirectAccess connectivity to IPv4 only resources using the UAG DNS64 and NAT64 features. APP3 hosts both HTTP and SMB resources that the DirectAccess client computer will be able to access from other the simulated Internet.
· Step 5: Configure UAG1 – UAG1 acts as UAG SP1 RC DirectAccess.
· Step 6: Configure CLIENT1 – CLIENT1 is a DirectAccess client that is used to test DirectAccess connectivity in several Internet network access scenarios.
· Step 7: Install and Configure NAT1 – NAT1 acts as a simulated NAT router that enables CLIENT1 access to the UAG DirectAccess server over the simulated Internet.
· Step 8: Test DirectAccess Connectivity from the Internet – CLIENT1 is connected to the simulated Internet subnet to demonstrate DirectAccess connectivity using the 6to4 IPv6 transition technology.
· Step 9: Test DirectAccess Connectivity from Behind a NAT Device – CLIENT1 is connected to the simulated private address network to demonstrate DirectAccess connectivity using the Teredo and IP-HTTPS IPv6 transition technologies.
· Step 10: View DirectAccess Connections in the UAG SP1 RC DirectAccess Monitor. UAG SP1 RC includes a new DirectAccess Web Monitor. In this step you will view information about the UAG SP1 RC DirectAccess server and DirectAccess client connections in the new DirectAccess Monitor application.
· Step 11: Test Connectivity When Returning to the Corpnet – CLIENT1 is connected again to the Corpnet subnet to demonstrate how DirectAccess components are automatically disabled to connect to local resources.
· Step 12: Snapshot the Configuration – At the completion of the lab, snapshot the configuration so that you can later return to a working UAG DirectAccess Test Lab.
Note
You will notice that there are several steps that begin with an asterisk (*). The * indicates that the step requires that you move to a computer or virtual machine that is different from the computer or virtual machine you were at when you completed the previous step.
This Test Lab Guide uses the Base Configuration network as a starting place. Please complete all the steps in Test Lab Guide: Base Configuration before proceeding with the remainder of the steps in this guide. If you have already completed all the steps in the Base Configuration Test Lab Guide and saved a disk image or a virtual machine snapshot of the Base Configuration, then you can restore the Base Configuration and proceed to the next step.
DC1 acts as a domain controller, Certificate server, DNS server, File Server and DHCP server for the corp.contoso.com domain. The following steps build on the Base Configuration to prepare DC1 to carry out these roles to support a working DirectAccess solution:
A. Create a Reverse Lookup Zone on the DNS Server on DC1. A reverse lookup zone for network ID 10.0.0.0/24 is required to create a pointer record for DC1. The pointer record allows reverse name resolution for DC1, and prevents name resolution errors during DNS related configuration steps. The reverse lookup zone is not required for a functional DirectAccess solution.
B. Enter a Pointer Record for DC1. A pointer record for DC1 will allow services to perform reverse name resolution for DC1. This is when performing DNS related operations. It is not required for a functional DirectAccess solution.
C. Enable ISATAP Name Resolution in DNS on DC1. By default, the Windows Server 2008 R2 DNS server will not answer queries for the ISATAP and WPAD host names. The DNS server is configured so that it will answer queries for ISATAP.
D. Create DNS Records for NLS and ISATAP on DC1. The DirectAccess client uses a Network Location Server (NLS) to determine if the computer is on or off the corporate network. If on the corporate network, the DirectAccess client can connect to the Network Location Server using an HTTPS connection. A DNS record is required to resolve the name of the NLS. In addition, a DNS record for ISATAP is required so that ISATAP capable hosts on the network can obtain IPv6 addressing and routing information from the ISATAP router configured on UAG1.
E. Create a Security Group for DirectAccess Clients on DC1. When DirectAccess is configured on the UAG DirectAccess server, it automatically creates Group Policy Objects and GPO settings that are applied to DirectAccess clients and servers. The DirectAccess client GPO uses security group filtering to assign the GPO settings to a designated DirectAccess security group. This group is populated with DirectAccess client computer accounts. This is a required component of a DirectAccess solution.
F. Create and Deploy a Certificate Template for the IP-HTTPS Listener Certificate and the Network Location Server Certificate. A Web site certificate is required for the Network Location Server so that computers can use HTTPS to connect to it when they are on the corporate network. The UAG DirectAccess server uses a Web site certificate on its IP-HTTPS listener so that it can accept incoming connections from DirectAccess clients that are behind network devices that limit outbound connections to only HTTP/HTTPS. A Web site certificate template is created and used for certificate requests to the Microsoft Certificate Server installed on DC1. A Web site certificate bound to the UAG DirectAccess server’s IP-HTTPS is a required component of a working DirectAccess solution.
G. Create ICMPv4 and ICMPv6 Echo Request Firewall Rules in Domain Group Policy on DC1. ICMP v4 and v6 echo requests inbound and outbound are required for Teredo support. Firewall Rules are configured using the Windows Firewall with Advanced Security GPO snap-in to distribute the configuration.
H. Create a Shared Folder on the C:\ Drive on DC1. A shared folder is created on the C:\drive of DC1 to test SMB connectivity for DirectAccess clients to a resources on the CORP domain.
A reverse lookup zone on DC1 for network ID 10.0.0.0/24 is required to create a pointer record for DC1. The pointer record will allow reverse name resolution for DC1, which will prevent name resolution errors during several DNS related configuration steps. The reverse lookup zone is not required for a functional DirectAccess solution and is used as a convenience in this lab.
A pointer record for DC1 will allow services to perform reverse name resolution for the DC1 computer. This will be useful when performing several DNS related operations. It is not required for a functional DirectAccess solution and is configured as a convenience for this lab.
By default, the Windows Server 2008 R2 DNS server will not answer queries for ISATAP and WPAD host names. These names are included in the DNS server’s Global Query Block List. The following procedures configure the DNS server so that it will answer queries for ISATAP by removing ISATAP from the Global Query Block List.
For more information on configuring the global query block list, please see http://download.microsoft.com/download/5/3/c/53cdc0bf-6609-4841-a7b9-cae98cc2e4a3/DNS_Server_Global_%20Query_Block%20List.doc
DirectAccess clients use a Network Location Server to determine if the computer is on or off the intranet. If the DirectAccess client can connect to the Network Location Server using HTTPS, it determines that it is on the corporate network and the Name Resolution Policy Table (NRPT) is disabled. If the DirectAccess client cannot connect to the Network Location Server when on the intranet, the Name Resolution Policy Table remains enabled which can cause name resolution and connectivity problems when the DirectAccess client is situated on the intranet. A DNS record is required for the DirectAccess client to resolve the name of the Network Location Server.
In addition, all IPv6 capable hosts on the corpnet need to resolve the name ISATAP to the internal IP address of the UAG DirectAccess server, so a DNS record is required for ISATAP. The UAG DirectAccess server will act as an ISATAP router for the organization and provides prefix and routing information for ISATAP hosts on the corporate network.
When you run the UAG DirectAccess wizard on the UAG1 computer, the wizard will create Group Policy Objects and deploy them in Active Directory. One GPO is created for the UAG DirectAccess server, and another is created for DirectAccess clients. Security Group filtering is used to apply the DirectAccess GPO settings to the DirectAccess Clients security Group. To obtain the settings required to be a DirectAccess client, the computer must be a member of this security group. Do not use any of the built-in security groups as your DirectAccess client security Group. Use the following procedure to create the DirectAccess security group. This group is required for a working DirectAccess solution.
A Web site certificate is required for the Network Location Server so that computers can use HTTPS to connect to it when the DirectAccess client is on the intranet. In addition, the UAG DirectAccess server uses a web site certificate on its IP-HTTPS listener so that it can accept incoming connections from DirectAccess clients that are behind network devices that limit outbound connections to only HTTP/HTTPS. The following procedures describe how to create a web site certificate template to use for requests to the Microsoft Certificate Server installed on DC1. A web site certificate bound to the UAG DirectAccess server’s IP-HTTPS listener and a web site certificate bound to the Network Location Server Web site are both required for a working DirectAccess solution.
Support for incoming and outgoing ICMPv4 and v6 is required for Teredo clients. DirectAccess clients will use Teredo as their IPv6 transition technology to connect to the UAG DirectAccess server over the IPv4 Internet when they are assigned a private (RFC 1918) IP address and are located behind a NAT device or firewall that allows outbound UDP port 3544. In addition, enabling ping facilitates connectivity testing between participants in the DirectAccess solution.
DirectAccess clients should be able to connect to SMB resources on the intranet when the DirectAccess client is connected to the simulated Internet, or connecting from behind a NAT device over the Internet. A network share is created on DC1 to test DirectAccess client connectivity to SMB resources over the infrastructure tunnel.
APP1 is a Windows Server 2008 R2 Enterprise Edition computer that acts in the role of the Network Location Server for the intranet. We have chosen to not to install the Network Location Server on the domain controller, even though that would have reduced the number of machines required for the lab network. The reason for this is that NLS on the DC can be a problematic if the DC is IPv6 based and can cause potential problems with network location detection. For this reason we have chosen to install the NLS on APP1.
You will perform the following operations to configure APP1:
A. Obtain an NLS Certificate for SSL Connections to the Network Location Server on APP1. APP1 acts as the Network Location Server. To enable this role, APP1 needs a web site certificate so that the DirectAccess clients are able to establish an SSL connection to a Web site on APP1. DirectAccess clients access this site by connecting to Network Location Server name, which is nls.corp.contoso.com in this lab.
B. Configure the HTTPS Security Binding on the NLS Web Site on APP1. The web site certificate needs to be bound to a web site on APP1 so that it can respond to SSL connection requests from the DirectAccess clients on the intranet.
The Network Location Server requires a Web site certificate to enable SSL session establishment with the DirectAccess client. The subject name on this certificate must match the name that the DirectAccess client uses to connect to the Network Location Server. On this Test Lab network, the DirectAccess client tries to connect to connect to the NLS at nls.corp.contoso.com. This name is used later in the DirectAccess configuration wizard on the UAG server.
After the web server role is installed, the web site certificate must be bound to the Network Location Server web site. This is required for the web server to establish an SSL connection with the computer configured as a DirectAccess client, and is a required component of a DirectAccess solution.
APP3 is a Windows Server 2003 SP2 Enterprise Edition computer that acts as an IPv4 only host and is used to demonstrate DirectAccess connectivity to IPv4 only resources using the UAG DNS64 and NAT64 features. APP3 hosts both HTTP and SMB resources that the DirectAccess client computer will be able to access from other the simulated Internet. The UAG NAT64/DNS64 feature set enables organizations to deploy DirectAccess without requiring them to upgrade network resources to native IPv6 or even IPv6 capable.
For more information on NAT64/DNS64 please see Deep Dive Into DirectAccess – NAT64 and DNS64 in Action
The following operations are performed to configure APP3:
A. Install the operating system on APP3 and Disable the Firewall The first step is to install Windows Server 2003 Enterprise Edition SP2 on APP3. This is not a requirement. You could use another IPv4 only operating system, such as Windows 2000 Server or even Windows XP. The goal is to provide an IPv4 resource for the DirectAccess clients to connect to from over the Internet.
B. Install Web services on APP3 Install IIS Web services on APP3 so that HTTP connectivity over the DirectAccess connection to an IPv4 only host is demonstrated.
C. Create a shared folder on APP3 Create a shared folder on APP3 to demonstrate SMB connectivity over the DirectAccess connection.
The first step is to install Windows Server 2003 Enterprise Edition SP2 on APP3. This is not a requirement. You could use another IPv4 only operating system, such as Windows 2000 Server or even Windows XP. The goal is to provide an IPv4 resource for the DirectAccess clients to connect to from over the Internet.
Note: If you install Windows Server 2003 RTM, there is no Windows Firewall and you will not need to disable the firewall.
Install IIS Web services on APP3 so that HTTP connectivity can be demonstrated over the DirectAccess connection.
Create a shared folder on APP3 to demonstrate the ability to connect to an SMB resource on a IPv4 only computer on the DirectAccess connection over the Internet.
UAG1 acts as the UAG DirectAccess server for the network. UAG1 will be connected to both the simulated Internet and the intranet and will need one network interface connected to each of these networks. The UAG DirectAccess server provides the following network services:
· ISATAP router An ISATAP router is an IPv6 router that advertises subnet prefixes to ISATAP hosts and forwards IPv6 traffic between ISATAP hosts and hosts on other IPv4 subnets. The ISATAP router provides ISATAP clients the information they need to properly configure their ISATAP adapters. For more information about ISATAP, please see http://technet.microsoft.com/en-us/magazine/2008.03.cableguy.aspx
· Teredo server A Teredo server is an IPv6/IPv4 node that is connected to both the IPv4 Internet and the IPv6 intranet, supports a Teredo tunneling interface over which packets are received. The general role of the Teredo server is to assist in the address configuration of Teredo clients and to facilitate the initial communication between Teredo clients and other Teredo clients or between Teredo clients and IPv6 hosts. The Teredo server listens on UDP port 3544 for Teredo traffic. DirectAccess clients located behind NAT devices and firewalls use Teredo to connect to the UAG DirectAccess server. For more information on Teredo, please see http://technet.microsoft.com/en-us/library/bb457011.aspx
· IPsec gateway The Full Intranet access model (which is used in this lab document) allows DirectAccess clients to connect to all resources inside the intranet. It does this by using IPsec-based tunnel policies that require authentication and encryption and IPsec sessions terminate at the IPsec Gateway. The IPsec Gateway is a function that is hosted on the UAG DirectAccess server.
· IP-HTTPS server IP-HTTPS is a new protocol for Windows 7 and Windows Server 2008 R2 that allows DirectAccess clients behind a Web proxy server or firewall to establish connectivity by tunneling IPv6 packets inside an IPv4-based HTTPS session. HTTPS is used instead of HTTP so that Web proxy servers will not attempt to examine the data stream and terminate the connection. The UAG DirectAccess server uses an IP-HTTPS listener to accept incoming IP-HTTPS connections. Note that IP-HTTPS does not work behind authenticating web proxies (when authentication is required) or from behind web proxies that perform outbound SSL inspection (such as the TMG 2010 firewall when outbound SSL inspection is enabled).
· NAT64/DNS64 IPv6/IPv4 protocol translator The UAG DirectAccess server includes NAT64 and DNS64, which enables DirectAccess clients on the Internet to connect to IPv4 resources on the intranet. DirectAccess clients always use IPv6 to communicate with intranet servers. When a DirectAccess client needs to connect to IPv4 resources on the intranet, it issues a DNS query for the FQDN of the resource. DNS64 intercepts the request, sends the query to the intranet DNS server, and obtains the IPv4 address of the resource. DNS64 then dynamically generates an IPv6 address for the client to connect to; in addition, DNS64 informs NAT64 of the IPv4/IPv6 mapping. The client issues a request for the dynamically generated IPv6 address, which is intercepted by NAT64, and then NAT64 forwards the request to the IPv4 address of the intranet resource. NAT64 also returns the response based on entries in its state table. For more information about DNS64 and NAT64, please see http://blogs.technet.com/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx
· 6to4 relay router A 6to4 relay router can accept traffic from DirectAccess clients using the 6to4 IPv6 transition technology and forward the traffic over an IPv4 intranet. The UAG DirectAccess server acts as the 6to4 relay router and provides addressing information to the DirectAccess clients. DirectAccess clients use this information to configure their 6to4 tunnel adapters to forward IPv6 messages over the IPv4 Internet to the UAG DirectAccess servers. For more information on 6to4 please see http://technet.microsoft.com/en-us/library/cc756770(WS.10).aspx
The following procedures are performed on the UAG1 computer or virtual machine:
A. Rename UAG1 Change the computer name assigned during setup of the Base Configuration to UAG1.
B. Obtain a Certificate for the IP-HTTPS Listener on UAG1 The UAG DirectAccess server uses an IP-HTTPS listener to accept incoming IP-HTTPS connections from DirectAccess clients on the Internet. The IP-HTTPS Listener requires a web site certificate to support the SSL connection between itself and the DirectAccess client.
C. Install Forefront UAG on UAG1 Install the Forefront Unified Access Gateway software on UAG1.
D. Run the UAG Getting Started Wizard on UAG1 The UAG Getting Started Wizard walks you through the process of initial configuration of the UAG server.
E. Run the UAG DirectAccess Configuration Wizard on UAG1 DirectAccess is not enabled by default. You must run the UAG DirectAccess wizard to enable DirectAccess features and capabilities on UAG1.
F. Confirm Group Policy Settings on UAG1 The UAG DirectAccess wizard configures GPOs and settings that are automatically deployed to the Active Directory. One GPO is assigned to the UAG DirectAccess server, and one is deployed to machines that belong to the DirectAccess Clients security group. The step confirms that the Group Policy settings were deployed to the UAG DirectAccess server.
G. Confirm IPv6 Settings on UAG1 For the DirectAccess solution to function, the IPv6 settings on must be correct. This step confirms these setting on UAG1.
H. Update IPv6 Settings on DC1 DC1 is capable of being an ISATAP host. However, this functionality might not be immediately available. This step expedites DC1 setting itself up as an ISATAP host by updating its IPv6 configuration.
I. Update IPv6 Settings on APP1 APP1 is capable of being an ISATAP host. However, this functionality might not be immediately available. This step expedites APP1 setting itself up as an ISATAP host by updating its IPv6 configuration.
J. Confirm IPv6 Address Registrations in DNS IPv6 capable hosts can communicate with one another over IPv6 using their ISATAP adapters. However, they must be able to resolve the destination host to an IPv6 address to use this capability. This step confirms that the IPv6 ISATAP addressees are registered in DNS.
K. Confirm IPv6 Connectivity between DC1/APP1/UAG1 After activity the IPv6 settings on DC1, APP1 and UAG1, test IPv6 connectivity by using the ping utility.
Change the computer name of EDGE1 to UAG1.
The UAG DirectAccess server uses an IP-HTTPS listener to accept incoming IP-HTTPS connections from DirectAccess clients on the Internet. The IP-HTTPS Listener requires a web site certificate to support the SSL connection between itself and the DirectAccess client. The common name on this certificate must be the name the external DirectAccess client uses to connect to the IP-HTTPS Listener, and must be resolvable using an Internet based DNS server to the first of the two consecutive IP addresses bound to the external interface of the UAG DirectAccess server. Perform the following steps to obtain the IP-HTTPS certificate. In addition, you will request a new computer certificate for UAG1 that supports the machine’s new computer name.
In order to connect to the IP-HTTPS listener on UAG1, the DirectAccess client needs to be able to resolve the subject name listed on the IP-HTTPS certificate. In this step you will configure INET1 with a Host (A) DNS record with the name uag1.contoso.com that resolves to 131.107.0.1.
Install the Forefront Unified Access Gateway software on UAG1.
The UAG Getting Started Wizard walks you through the process of initial configuration of the UAG server. This will set up the basic information required to configure the networking settings on the server, define the server topology (standalone or array) and whether or not to join Microsoft update for updating the server.
DirectAccess is not enabled by default. To enable DirectAccess features and capabilities on UAG1, you need to run the DirectAccess Configuration wizard. After running the DirectAccess Configuration Wizard, two new Group Policy objects are created – one is linked to the computer account for the UAG DirectAccess server, and the second is linked to the DirectAccess clients security group (DA_Clients) you configured earlier. In addition, the IPv6 components, including support for IPv6 transition technologies and IPv6/IPv4 protocol transition technologies are enabled on the UAG DirectAccess server.
The UAG DirectAccess wizard configures GPOs and settings that are automatically deployed to the Active Directory. One GPO is assigned to the UAG DirectAccess server, and one is deployed to machines that belong to the DirectAccess Clients security group. The following steps confirm that the Group Policy settings were deployed to the UAG DirectAccess server.
For the DirectAccess solution to function, the IPv6 settings on must be correct. The following steps confirm these setting on UAG1.
DC1 is capable of being an ISATAP host. However, this functionality might not be immediately available. You can expedite DC1 setting itself up as an ISATAP host by updating its IPv6 configuration.
APP1 is capable of being an ISATAP host. However, this functionality might not be immediately available. You can expedite DC1 setting itself up as an ISATAP host by updating its IPv6 configuration.
IPv6 capable hosts can communicate with one another over an IPv4 network with IPv6 using their ISATAP adapters. However, they must be able to resolve the destination host to an IPv6 address to use this capability. The following steps confirm that the IPv6 ISATAP addressees are registered in DNS.
Note that the ISATAP addresses listed in the DNS resource records do not use the dotted decimal format for the last 32 bits of the IPv6 address that you see when using ipconfig to view IP addressing information on the hosts. However, these addresses represent the same information; the only difference is that the last 32 bits are represented in HEX instead of dotted decimal format.
After activating the IPv6 settings on DC1, APP1 and UAG1, test IPv6 connectivity by using the ping utility
CLIENT1 is a computer or virtual machine running Windows 7 Ultimate Edition that is used demonstrate how DirectAccess works in a number of scenarios. CLIENT1 is first connected to the corpnet subnet to receive the DirectAccess Group Policy settings. CLIENT1 is later moved to the simulated Internet to test DirectAccess connectivity over 6to4 and CLIENT1 is moved behind a NAT device to test both Teredo and IP-HTTPS DirectAccess connectivity.
NOTE: CLIENT1 is a Windows 7 computer and after installation the default power plan is applied. CLIENT1 may go to sleep before you reach the end of the lab configuration. To prevent this from happening, select the High Performance power plan in the Control Panel.
The following operations configure CLIENT1:
A. Add CLIENT1 to the DA_Clients Active Directory Security Group The DirectAccess client settings are assigned only to members of the security group designated for DirectAccess clients. Place CLIENT1 in the DA_Clients security group so that the Group Policy settings are assigned to CLIENT1.
B. Test IPv6 Configuration, Confirm Group Policy Settings and Machine Certificate on CLIENT1 Before moving CLIENT1 out of the corpnet and onto the simulated Internet and behind a NAT device, check the IPv6 configuration on CLIENT1, confirm that DirectAccess client Group Policy Settings are enabled on CLIENT1, and that CLIENT1 has the computer certificate required to establish the IPsec connections to the UAG DirectAccess server.
C. Test Connectivity to a Network Share and Network Location Server The final check on CLIENT1 before moving it outside the corpnet is to confirm connectivity to a network share on the corpnet and to the Network Location Server. Connectivity to the Network Location Server is required so that the DirectAccess client can determine if it is on-network or off-network.
The DirectAccess client settings are assigned only to members of the security group designated for DirectAccess clients. You will place CLIENT1 in the DA_Clients security group so that the Group Policy settings are assigned to CLIENT1.
Before moving CLIENT1 out of the corpnet subnet and onto the simulated Internet and behind a NAT device on the Internet, check the IPv6 configuration on CLIENT1, confirm that DirectAccess client Group Policy Settings are enabled on CLIENT1, and that CLIENT1 has the computer certificate required to establish the IPsec connections to the UAG DirectAccess server.
The final check on CLIENT1 before moving it outside the corpnet subnet is to confirm connectivity to a network share on the corpnet subnet and to the Network Location Server. Connectivity to the Network Location Server is required so that the DirectAccess client can determine if it is on or off the corporate network.
NAT1 is a Windows 7 computer configured as a NAT device that separates a private network from the Internet. The built-in Internet Connection Service (ICS) is used to provide the NAT server functionality. ICS includes DHCP server-like functionality and automatically assigns IP addressing information to clients located behind the NAT1 ICS NAT device. NAT1 has two network interfaces – one connected to the simulated Internet and one connected to a Homenet subnet.
NOTE: NAT1 is a Windows 7 computer and after installation the default power plan is applied. NAT1 may go to sleep before you reach the end of the lab configuration. You can prevent this from happening by selecting the High Performance power plan in the Control Panel.
Perform the following operations to configure NAT1 as a NAT device:
A. Install the operating system on NAT1 The first step is to install the Windows 7 operating system.
B. Rename the interfaces on NAT1 Rename the network interfaces in the Network Connections window to make them easier to identify. Note that this is not required, but makes applying the correct settings on the appropriate interface easier.
C. Disable 6to4 functionality on NAT1 Disable 6to4 functionality on NAT 1. The reason for this is that if you don’t disable 6to4 on NAT1, it will act as a 6to4 router and issue a 6to4 address to CLIENT1 when it is connect to the Homenet subnet. This will prevent CLIENT1 from acting as a Teredo or IP-HTTPS DirectAccess client.
D. Configure ICS on the External Interface of NAT1 Internet Connection Services enable NAT1 to act as a NAT device and DHCP server for clients located behind NAT1. This enables CLIENT1 to automatically obtain IP addressing information and connect to the simulated Internet when connected to the Homenet subnet behind NAT1.
The first step is to install the Windows 7 operating system.
In this step you rename the network interfaces in the Network Connections window to make them easier to identify. Note that this is not required, but makes applying the correct settings on the appropriate interface easier.
In the lab environment we use a Windows 7 computer to simulate a NAT device located in a remote location. One issue with Windows 7 when configured as an Internet Connection Service server is that it can act as a 6to4 router. When this is the case, it might assign the CLIENT1 computer behind the NAT1 ICS computer a 6to4 address and prevent it from acting as a Teredo and IP-HTTPS client. In order to demonstrate both Teredo and IP-HTTPS functionality, 6to4 functionality on the NAT1 is disabled.
Internet Connection Services enable NAT1 to act as a NAT device and DHCP server for clients located behind NAT1. This enables CLIENT1 to automatically obtain IP addressing information and connect to the simulated Internet when connected to the Homenet subnet behind NAT1.
CLIENT1 is now ready for DirectAccess testing. In the first set of tests, you connect CLIENT1 to the simulated Internet. When connected to the simulated Internet, CLIENT1 is assigned a public IPv4 address. When a DirectAccess client is assigned a public IPv4 address, it will try to establish a connection to the DirectAccess server using an IPv6 6to4 connection over its 6to4 tunnel adapter. After connecting to the simulated Internet and establishing the DirectAccess connection, you perform a number of tests to confirm IPv6 connectivity and connectivity to corpnet assets from over the simulated Internet.
When a DirectAccess client is connected to the Internet from behind a NAT device or a Web proxy server, the DirectAccess client uses either Teredo or IP-HTTPS to connect to the DirectAccess server. If the NAT device enables outbound UDP port 3544 to the DirectAccess server’s public IP address, then Teredo is used. If Teredo access is not available, the DirectAccess client falls back to IP-HTTPS over outbound TCP port 443, which enables access through firewalls or Web proxy servers over the traditional SSL port. Teredo is the preferred access method, because of its superior performance over IP-HTTPS. In addition, if the web proxy requires authentication, the IP-HTTPS connection will fail. IP-HTTPS connections also fail if the web proxy performs outbound SSL inspection, due to the fact that the HTTPS session is terminated at the web proxy instead of the UAG DirectAccess server. In this section you will perform the same tests performed when connecting using a 6to4 connection in the previous section.
The following procedures are performed on CLIENT1:
A. Test Teredo Connectivity. The first set of tests are performed when the DirectAccess client is configured to use Teredo. This is the automatic setting when the NAT device allows outbound access to UDP port 3544
B. Test IP-HTTPS Connectivity. The second set of tests are performed when the DirectAccess client is configured to use IP-HTTPS. In order to demonstrate IP-HTTPS connectivity, Teredo is disabled on CLIENT1.
The DirectAccess client can use either Teredo or IP-HTTPS when connecting to the DirectAccess server from behind a NAT device. You will first examine the settings and test connectivity using Teredo.
When the DirectAccess client is unable to establish a Teredo connection with the DirectAccess server (typically when a firewall or router has blocked outbound UDP port 3544), the DirectAccess client configures itself to use IP-HTTPS to tunnel IPv6 messages over the IPv4 Internet. In the following exercises you confirm that the host is configured as an IP-HTTPS host and check connectivity.
1. Open an elevated command prompt. In the command prompt window, enter netsh interface teredo set state disabled and press ENTER. This disables Teredo on CLIENT1 and enables CLIENT1 to configure itself to use IP-HTTPS.
2. Open an elevated command prompt. In the command prompt window, enter ipconfig /all and press ENTER. An Ok response appears when the command completes.
3. Examine the output of the ipconfig command. This computer is now connected to the Internet from behind a NAT device and is assigned a private IPv4 address. Teredo is disabled and the DirectAccess client falls back to IP-HTTPS. When you look at the output of the ipconfig command, you see a section for Tunnel adapter iphttpsinterface with an IP address that starts with 2002:836b:2:8100 consistent with this being an IP-HTTPS address. You will not see a default gateway listed for the IP-HTTPS tunnel adapter.
4. In the command prompt window, enter ipconfig /flushdns and press ENTER. This will flush name resolution entries that may still exist in the client DNS cache from when CLIENT1 was connected to the corpnet.
5. In the command prompt window, enter ping dc1 and press ENTER. You should see replies from the ISATAP address assigned to DC1, which in this case is 2002:836b:2:8000:0:5efe:10.0.0.1
6. In the command prompt window, enter ping app1 and press ENTER. You should see replies from the ISATAP address assigned to APP1, which in this case is 2002:836b:2:8000:0:5efe:10.0.0.3
7. In the command prompt window, enter ping uag1 and press ENTER. You should see replies from the ISATAP address assigned to UAG1, which in this case is 2002:836b:2:8000:0:5efe:10.0.0.2
8. In the command prompt window, enter ping app3 and press ENTER. You should see replies from the NAT64 address assigned by UAG1 to APP3, which in this case is 2002:836b:2:8001::a00:4
9. In the command prompt window, enter netsh namespace show effectivepolicy and press ENTER. The output shows the current settings for the Name Resolution Policy Table (NRPT). These settings indicate that all connections to .corp.contoso.com should be resolved by the DirectAccess DNS Server, which is the UAG DirectAccess server, with the IPv6 address of 2002:836b:3::836b:3. Also, note the NRPT entry indicating that there is an exemption for the name nls.corp.contoso.com; names on the exemption list are not answered by the DirectAccess DNS server. You can ping the DirectAccess DNS server IP address to confirm connectivity to the DirectAccess server; for example, you can ping 2002:836b:3::836b:3 in this example.
10. In the Internet Explorer address bar, enter http://app1.corp.contoso.com and press ENTER. You will see the default IIS site on APP1.
11. In the Internet Explorer address bar, enter http://app3.corp.contoso.com and press ENTER. You will see the default web site on APP3.
12. Click Start and in the Search box, enter \\App3\Files and press ENTER. Double click on the New Text Document file. This demonstrates that you were able to connect to an IPv4 only server using SMB to obtain a resource on an IPv4 only host.
13. Click Start and in the Search box, enter Firewall and press ENTER.
14. In the Windows Firewall with Advanced Security console, notice that only the Private profile is active. The Windows Firewall must be enabled for DirectAccess to work correctly. If for some reason the Windows Firewall were disabled, DirectAccess connectivity would fail.
15. Expand the Monitoring node in the left pane of the console and click the Connection Security Rules node. You should see the active connection security rules: UAG DirectAccess Client – Client Access Enabling Tunnel – All, UAG DirectAccess Client – Clients Corp Tunnel and UAG DirectAccess Client – Exempt NLA. Scroll the middle pane to the right to expose the 1st Authentication Methods and 2nd Authentication Methods columns. Notice that the first rule uses NTLMv2 to establish the infrastructure tunnel and the second rule uses Kerberos V5 to establish the intranet tunnel.
16. In the left pane of the console, expand the Security Associations node and click the Main Mode node. Notice the infrastructure tunnel security associations using NTLMv2 and the intranet tunnel security association using Kerberos V5. When you right click the Kerberos security association, you will see authentication for CORP\User1. This indicates that the client was able to authenticate with the CORP domain using Kerberos to establish the second (intranet) tunnel.
17. Close the System Control Panel window and the Windows Firewall with Advanced Security console. Close all other open windows before moving to the next step.
A new feature included in UAG 2010 Service Pack 1 DirectAccess is the new DirectAccess Monitor feature that is included in the UAG Web Monitor applications. You can use the DirectAccess Monitor to obtain information about current and historical connections to the UAG DirectAccess server.
Perform the following steps to view the DirectAccess client connections in the UAG 2010 Service Pack 1 DirectAccess Monitor:
Many of your users will move between remote locations and the corpnet, so it’s important that when they return to the corpnet that they are able to access resources without having to make any configuration changes. UAG DirectAccess makes this possible because when the DirectAccess client returns to the corpnet, it is able to make a connection to the Network Location Server. Once the HTTPS connection is successfully established to the Network Location Server, the DirectAccess client disables it DirectAccess client configuration and uses a direct connection to the corpnet.
This completes the DirectAccess test lab. To save this configuration so that you can quickly return to a working DirectAccess configuration from which you can test other DirectAccess modular TLGs, TLG extensions, or for your own experimentation and learning, do the following:
For the design and configuration of your pilot or production deployment of DirectAccess, see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide.
For information about troubleshooting DirectAccess in a Test Lab, see the Test Lab Guide: Troubleshoot UAG DirectAccess.
For a comprehensive list of UAG DirectAccess Test Lab Guides, see the TechNet wiki Test Lab Guide clearinghouse at Test Lab Guides.
Great news! Last week we released the Release Candidate of UAG Service Pack 1. If you haven’t heard about this, then check out the UAG Team Blog post on this subject at http://blogs.technet.com/b/edgeaccessblog/archive/2010/10/21/announcing-forefront-uag-2010-service-pack-1.aspx
However, most organizations don’t want to deploy pre-release software in their production environment. I’ve always said “don’t make your production network your Test Lab”
But you want to see all the new and cool things that UAG SP1 RC has to offer, especially the cool DirectAccess improvements. How do you do that?
Test Lab Guides!
You can test UAG SP1 RC in a safe and sane Test Lab using our new Test Lab Guide format. The new Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess will walk you through configuring a basic working DirectAccess configuration using UAG SP1 RC. You’ll all see the new DirectAccess Monitor – which allows you to get information on who’s connecting through the DirectAccess tunnels.
There will be many more UAG SP1 RC DirectAccess Test Lab Guides published this week, so stay tuned!
Download the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess over at:
So you’ve gone through our excellent Test Lab Guides (which you can find at http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx) and you’ve read the UAG DirectAccess design guide (http://technet.microsoft.com/en-us/library/ee406191.aspx) and the UAG DirectAccess deployment guide (http://technet.microsoft.com/en-us/library/dd857320.aspx). You’ve got the critical hands-on and the key background information after going through those.
What next?
What would be really handy is high level plan of the steps you need to go through as you roll out your pilot project. This is where Jason Jones, Forefront MVP, comes in. He’s published a very handy pair of documents that will really help you clarify your plan.
Check out Jason’s Deploy Forefront UAG DirectAccess in 8 Easy Steps at http://blog.msedge.org.uk/2010/10/deploying-forefront-uag-directaccess-in.html
And if you’re into creating a UAG DirectAccess Array (and most enterprises are going to be deploying arrays), check out his Deploying a Forefront UAG DirectAccess Array in 10 Easy Steps at http://blog.msedge.org.uk/2010/10/deploying-forefront-uag-directaccess.html
Make sure to put Jason’s blog in your Favorites – he’s always coming up with great design and deployment information for UAG DirectAccess on his blog.
“Why does SharePoint ask for credentials when I connect over DirectAccess?”
There is a very long thread on the TechNet forums regarding an unusual authentication issue when DirectAccess clients try to connect to SharePoint sites. There were a lot of posts and a lot of effort was made to determine the nature of the problem. The good news I have for you today is that we’ve solved the problem and have published a fix!
The problem was due to the fact that the automatic logon level for Windows HTTP Services (WinHTTP) is Medium. When the automatic logon level is set to Medium, it prevents the user credentials from being automatically sent to the web server. The end result is that the address is considered an Internet server when you try to access the WebDAV resource like SharePoint which leads to you being asked for credentials.
Here’s the fix for the problem:
http://support.microsoft.com/kb/2288297
Shannon Fritz, who’s well known on the UAG DirectAccess forums at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads for providing excellent community answers and insight, has put together a very nice UAG DirectAccess Configuration Guide. In Shannon’s configuration guide, you’ll find the following sections:
Check out all this and more over on Shannon’s blog at:
http://blog.concurrency.com/infrastructure/uag-directaccess-configuration-guide/
(Updated Oct 5, 2010)
I’ve seen a number of questions asking if there was a method you could use to migrate your Windows DirectAccess configuration to a UAG DirectAccess deployment.
The answer to this question is that there is no automated method to do this. However, the manual steps aren’t very difficult. Here’s what you need to do:
That’s all there is to it!
Now you can install UAG on the server that you had configured as the Windows DirectAccess server, or you can install UAG on a completely different server.
Let me know if you run into any issues with your migration from Windows DirectAccess to UAG DirectAccess. If this scenario is popular enough, I’ll put together a Test Lab Guide that demonstrates the process!
(Thanks to Yaniv Naor for the heads up on this)
(Thanks to Pat Telford for the information included in the update)
The answer is “no” – but its important to understand the function of ISATAP and why or why not you might consider deploying ISATAP in your environment.
ISATAP is the Intra-site Automatic Tunnel Addressing Protocol. The purpose of ISATAP is to allow you to use IPv6 aware applications on a network that hasn’t moved to an IPv6 infrastructure – or what we often call “native IPv6”.
A native IPv6 network has all it’s network infrastructure aware of and configured to support IPv6. This can include routers, switches, DNS, DHCP, network IDS and other network-centric applications. When the entire infrastructure is aware of IPv6 and all the clients and servers on the network work natively with IPv6 and use globally routable IPv6 addresses, then you have what we would call a native IPv6 network.
However, there are very few native IPv6 networks out there in the wild. One of the reasons for this is that not all of our server operating systems or server applications or client-side applications are IPv6 aware or IPv6-capable. Some are, but likely most aren’t.
So how do you enable your IPv6 aware applications to work in an IPv4 network infrastructure? One way to do that is to use something to help you during your transition to IPv6 (the time it takes to complete that transition may be months, years, or decades). That’s the function of ISATAP, to help you deploy IPv6 applications while you’re “in transition” from an IPv4 network to an IPv6 network.
The way it works is that the ISATAP adapter on the ISATAP enabled host will encapsulate the IPv6 packets in an IPv4 header to allow routing of those packets through your IPv4 infrastructure. The ISATAP adapter is assigned a “real” IPv6 address (an ISATAP address that is based on a IPv6 prefix obtained from an ISATAP router and a host ID based on the IPv4 address of the ISATAP enabled host), and that address is registered in DNS (if your DNS server is configured to accept dynamic updates).
Applications that are IPv6 capable will preferentially use the ISATAP adapter to communicate with other IPv6 systems on your network. The end result is that you have enabled IPv6 addressing on your clients and servers (that are ISATAP capable) and they can still communicate over your IPv4 routing infrastructure.
Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 are all IPv6 capable operating systems – which means you can assign them a globally routable IPv6 address (sometime referred to as a “native” IPv6 address), or you can assign them ISATAP addresses, which are still valid IPv6 addresses, they’re just not globally routable. However, in order for ISATAP capable hosts to configure their ISATAP IPv6 address, they need to get information from an ISATAP router. When you use the UAG DirectAccess solution, the UAG DirectAccess server or array will act as your ISATAP router.
If you’re using the Windows DirectAccess solution, which is part of the Windows Server 2008 R2 platform, you need to be able to assign IPv6 addresses to all intranet hosts that you want the DirectAccess clients to connect to. If you are using globally routable IPv6 addresses on your network then your work is done – and DirectAccess clients will be able to connect to all hosts with globally routable IPv6 addresses and reach all subnets on your intranet using your IPv6 aware routing infrastructure. However, if you don’t have a native IPv6 network yet, then you will need to find another way to assign IPv6 addresses to the hosts you want the DirectAccess clients to connect to – and that way is to deploy ISATAP.
However, if you are using the UAG DirectAccess solution, you have another option. You can avoid IPv6 addressing on your intranet altogether and take advantage of the UAG DirectAccess server’s NAT64/DNS64 IPv6/IPv4 protocol translator. When you use these two technologies that are available only with the UAG DirectAccess solution, DirectAccess clients can connect to IPv4 resources on your intranet. For more information on how NAT64/DNS64 work, check out the UAG Team Blog over at http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx
However, NAT64/DNS64 is similar to other NAT solutions. Some applications don’t work well with NAT. In addition, the NAT64 solution doesn’t allow for “reverse NAT” from the intranet to the DirectAccess clients. What this means is that if you want to initiate a connection from IPv4 only client or server on the intranet to a DirectAccess client on the Internet, you won’t be able to, because that would be a “reverse NAT” scenario and we don’t support reverse NAT with the current version of NAT64. Because of this, your “manage out” capabilities are limited somewhat.
So to answer the question “do you need ISATAP?”, the answer is “no”. However, your manage out capabilities will be limited.
“Manage out” is a term we use informally for remote management. There are actually two manage out scenarios:
When you have an IPv4 only network and none of your intranet resources are IPv6 capable through ISATAP, then only the first “manage out” scenario is available to you. The second one requires that the management server on the intranet be IPv6 capable, using either a native IPv6 address or one assigned by ISATAP.
The reason why you need IPv6 to manage out is related to the fact that the DirectAccess client only uses IPv6 to connect to the intranet. This connection is initially terminated as an IPv6 IPsec tunnel on the external interface of the UAG DirectAccess server. When the DirectAccess client establishes it’s connection to the UAG DirectAccess server, it also registers it’s own IPv6 address in the corporate DNS. If you want to connect to the DirectAccess client, you have to use its IPv6 address. You can do it directly by connecting to its IPv6 address, or you can connect to the DirectAccess client by the name it registered in DNS.
If an IPv4 server on the intranet tried to connect to the DirectAccess client, it would send a name query to the DNS server and receive only a AAAA record. Since the IPv4 only host doesn’t know what to do with a AAAA record, it will not be able to connect to the IPv6 address of the DirectAccess client.
The answer it that it depends on what you need and your constraints.
In general, if you don’t have a native IPv6 network yet, it’s a good idea to deploy ISATAP. That will enable the DirectAccess clients to connect to your ISATAP hosts on the intranet by using IPv6 from end to end – which creates fewer application/NAT related issues. It also allows your ISATAP capable management servers to support the manage out scenario where those servers need to initiate connections to the DirectAccess clients. The only reason why you might not want to deploy ISATAP is if you have investments in network IDS gear that doesn’t understand ISATAP. In addition, when using the UAG DirectAccess server as your ISATAP router, your entire IPv4 infrastructure will be represented as a single IPv6 ISATAP cloud. Depending on your environment, this may or may not be problematic.
In addition, you can reduce the load on the UAG DirectAccess servers by taking advantage of both ISATAP and NAT64/DNS64. The reason for this is that it takes memory and processor cycles to process the NAT64/DNS64 sessions. If you deploy ISATAP, you reduce the number of sessions that require NAT64/DNS64 and potentially increase the number of connections per server in your UAG DirectAccess array.
Of course, the best of all possible worlds is that you have a native IPv6 network, and all your network devices, servers and clients and IPv6 capable. Then you never have to worry about IPv4 only resources – but that’s not likely to happen in the near future.
I hope this clears up the issue for you a bit. if you still have questions, please feel free to write to me at the address you see in my sig line.
Over the last few months I’ve been having some conversations with a number of people about the Test Lab Guides and the Business Ready Security (BRS) demo environment. For those of you who haven’t seen the BRS Demo environment, it is a collection of virtual machines and step by step documentation that provides a “hands-on lab” experience for all the technologies and server applications that are part of the Forefront line of products. You can find a full description of the BRS demo and how to download the virtual machines and documentation over at
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=726f943e-d107-4b4d-a86e-dfb605e30ce5&displaylang=en
On the other hand, Test Lab Guides provide information on how you can create your own Test Lab, so that you can see how a product or technology works in your own Test Lab. Test Lab Guides have you build out both the front-end and back-end components of the solution so that you can learn more about how all the pieces that enable the solution to work fit together. You can find more information on Test Lab Guides over at
http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
And for a comprehensive list of the currently available Test Lab Guides, check out the Test Lab Guide clearinghouse over on the TechNet Wiki at
http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx
Both the BRS demo and the Test Lab Guides are useful for their intended purposes. The BRS demo provides a convenient method to demonstrate all the products that participate in the Forefront family of products. All the virtual machines are created for you, and both the front end and back end of each of the solutions is preconfigured. The scenarios are built out to support the scripts (documentation) that are included with the demo. Like “hands on labs” they provide a nice introduction to some of the things each of the products covered in the BRS demo can do.
We like to think of the BRS demo as the first step. After you see what the products can do, you’ll probably want to see how you can built out your own solutions based on the technologies you saw demonstrated in the BRS demo. The problem is “where do you start”? The BRS demo doesn’t document the comprehensive back-end configuration that was required to make the solutions work, nor does it provide you guidance so that you can replicate the BRS demo environment so to have a better understanding of the products and technologies that you’re interested in. In addition, it’s difficult to customize the environment or update it it to support new versions of the product, service packs, etc. Sure, you could cobble together your own test lab, pull down the planning and deployment guides for those technologies, and hope that you’ll be able to come up with a working solution. Sometimes that works, and sometimes it doesn’t – and whether it works or not, it takes a long time for you to figure out what needs to be done.
That’s where the Test Lab Guides come in. With the Test Lab Guides (TLGs), we provide you a standardized, tested, and proven methodology that you can use to quickly build your own Test Lab.The TLGs are designed to provide you with end-to-end information on how to build a Test Lab, using a modular format that enables you to re-use your Test Labs and test additional scenarios. You get coverage of both the front-end and back-end, and you learn the requirements and the terminology while building out the Test Labs. In addition, the labs include a lot of tips and tricks, as well as validation information so that you can avoid common pitfalls that you might run into when deploying the product or technology in your production environment. After you go through a Test Lab Guide, you’ll find that the information you read in the planning and design guides will end up making a lot more sense.
We’re working on trying to get all the Forefront product teams to produce some Test Lab Guides – however, since this is a new initiative, it takes a while to get everything in line. So, there are a number of products covered in the BRS demo that we don’t have Test Lab Guides out for yet. But if everything goes the way we want it to – there will be TLGs for all of them, and also for a number of cool features included in the Windows platform itself.
If you have any questions about the Test Lab Guides or the BRS demo, and which one might work best for you and your intended purpose, please feel free to write to me at the address in my sig line.