(If you didn’t participate in Quiz 1 – you can read the rules of the game over at http://blogs.technet.com/b/tomshinder/archive/2010/12/02/uag-sp1-directaccess-contest-quiz-one-round-one.aspx)
It’s time for Quiz 2-Round 1!
I got started late on this one today and I was also reminded that there are plenty of UAG DirectAccess fans who aren’t in North America
For this reason, I’m going to change one of the rules for the contest which will allow more people to participate. From this point forward, you don’t have to send your answer until 9AM Central Standard Time (-0600 UTC) on Monday December 13th.
All the other rules remain the same.
Now for the questions!
There you go! Now click the following link (which will populate the subject line on the email message) to email me your answers:
tomsh@microsoft.com
I must receive your entry by December 13, 2010 9:00 AM Central Time
Have fun and good luck!
HTH,
Tom
Tom Shinder tomsh@microsoft.com Knowledge Engineer, Microsoft DAIP iX/Forefront 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
When I’m between doing things that I sort of want to do, but not enough where I want to start on them right away, I’ll do a little ego surfing. If you haven’t heard the term “ego surfing”, it’s the act of going to your favorite search engine (or multiple search engines) and searching for the results returned on your name. I do this from time to time because, well, ahhh – for the same reason anybody else does it!
Today I was doing some ego surfing for someone else. That “someone else” in this case was DirectAccess. I wanted to see what the top search engine results were for DirectAccess using a number of search engines. On more than one search engine, I found an article that left me a little perturbed. The title of the article is Microsoft DirectAccess: The ugly truth. Now, I know that headline writers write outrageous headlines because they get more attention, but I felt that I needed to write a response to show that the ugly really isn’t there and that there is beauty in its place.
In fact, when it comes to UAG DirectAccess, much of the ugliness is swept away and what we see is a real thing of beauty. Hence the name of this article Microsoft UAG DirectAccess: The Beautiful Truth. To find this beautiful truth about UAG DirectAccess, let’s take a look as some quotes from the Network World article.
“The following list of DirectAccess requirements comes directly from Microsoft TechNet: One or more DirectAccess servers running Windows Server 2008 R2 with two network adapters: one connected directly to the Internet, and a second connected to the intranet. On the DirectAccess server, at least two consecutive, public IPv4 addresses assigned to the network adapter that's connected to the Internet. DirectAccess clients running Windows 7. At least one domain controller and DNS server running Windows Server 2008 SP2 or Windows Server 2008 R2. A public key infrastructure (PKI) to issue computer certificates, smart card certificates, and for NAP, health certificates. IPsec policies to specify protection for traffic. IPv6 transition technologies available for use on the DirectAccess server: ISATAP, Teredo, and 6to4. Optionally, a third-party NAT-PT device to provide access to IPv4-only resources for DirectAccess clients”
“The following list of DirectAccess requirements comes directly from Microsoft TechNet:
Let’s look at each one of these:
Now that we’ve debunked many of the issues regarding DirectAccess for UAG, let’s take a look at another quote from the article:
“That is no small list of requirements. What it means is that to implement DirectAccess, I have to change, replace, or upgrade just about everything at my network edge. In addition to maintaining a public-facing firewall for Internet access, I have to add another direct-to-Internet server to act as the DirectAccess termination point. As servers are replaced and updated, I can see the enterprise eventually getting to the point where all of these things are already in place. But for most of us, this set of conditions can be a showstopper.”
Everyone already has a firewall at the edge of their networks. So, there’s nothing to add there. And, firewalls and NAT are not the same thing. All you need to do is create a small block of public addresses for the UAG DirectAccess server and route the connections through the firewall (firewalls still provide firewall protection without NAT) – so there’s nothing to add there when it comes to hardware, and subnetting is pretty easy for the network guys. Yes, it is true that you need to add the DirectAccess server as an Internet facing device – but you already have a lot of those, so what’s one more? Again, this is something most network admins do frequently and it isn’t a odd “one off” situation. There really don’t appear to be any show stoppers here – and with UAG DirectAccess, I think we end up with the “star of the show” when both users and IT tip their hats to you for giving them what they’ve actually wanted since the first PPTP VPN was deployed.
Let’s finish up with another quote that we can easily address:
“Also, because other releases of Windows server operating systems don't support dual-layer IP, DirectAccess can't natively talk to them. If your enterprise has a bank of Windows Server 2003 or older machines that won't be upgraded anytime soon, that data is in a silo that DirectAccess can't directly access.”
With UAG DirectAccess and its built-in NAT64/DNS64 service, the only Windows Server 2008 or above machine you need on your network is the UAG DirectAccess server. Your entire network can be full of Windows Server 2003, Windows 2000 Server, and Windows XP. DirectAccess clients will be able to connect to these network resources just fine. In addition, you can run your domain on Windows Server 2003 domain controllers and DNS servers. Like I said – only the UAG DA server needs to be running Windows Server 2008 R2. That means there is no silo – DirectAccess users can access whatever they need on legacy operating systems.
There you go. Microsoft UAG DirectAccess – The Beautiful Truth. I hope that you’ve had a chance to read this article before you read the ugly truth article, but if you read the ugly truth article first, at least you know what the truth is regarding UAG DirectAccess. And with these truths in mind, I hope that you’ll consider researching a possible DirectAccess deployment for your company. If you have any questions on how to do this, send me a note at the address in the sig line below.
Tom Shinder tomsh@microsoft.com Microsoft ISD 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
I’ve seen a few people ask if there are problems with access to IPv4 only resources after installing UAG Service Pack 1 (UAG SP1).
The cause of the problem is that after you install UAG SP1, the DNS64 service is set to Manual. You need to reconfigure the DNS64 service to start automatically. This issue is documented in the UAG SP1 Release Notes at http://technet.microsoft.com/en-us/library/gg315322.aspx
After installing SP1 RTM on a Forefront UAG server running SP1 RC and acting as a DirectAccess server, the DNS64 service will be set to Manual. Following the installation, set the DNS64 service to Automatic and start the service.
BTW – if you were trying to troubleshoot this issue, you would have been exposed to this scenario in the Test Lab Guide: Troubleshoot UAG DirectAccess which you can find http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=d2e460c8-b4bf-4fda-9f86-ecc4b7add5d1 (just thought you’d like to know - there’s a lot of other cool troubleshooting scenarios and information in that Test Lab Guide, so give it a try when you have a chance).
When a DirectAccess client computer is on the Internet, it connects to the corporate network using DirectAccess. All communications between the DirectAccess client and DirectAccess server are done over IPv6 (encapsulated by an IPv4 tunnel to carry the IPv6 traffic over the IPv4 Internet). In fact, the client application assumes that the connection is IPv6 from end-to-end, even when the destination server on the intranet is an IPv4-only capable resource. UAG DirectAccess can enable IPv4 connectivity to an intranet resource by using its NAT64/DNS64 IPv6/IPv4 protocol translation feature, which allows the UAG DirectAccess server to map an IPv6 address associated with the IPv4 address of the intranet resource. This mapped IPv6 address is used by the DirectAccess client to connect to the IPv4 resource on the intranet. The UAG DirectAccess server will translate this to an IPv4 address and forward the connection to the desired IPv4-only resource on the intranet.
While NAT64/DNS64 solves the problem of IPv4-only capable systems on the intranet, the client side application on the DirectAccess client must be IPv6 capable. If the client-side application is not IPv6 capable, it must use a non-DirectAccess method to reach the application server, such as an Internet accessible application gateway.
In the context of connectivity to SAP resources, you had to use an alternate method outside the DirectAccess tunnels before the release of SAP GUI version 7.1. With the introduction of SAP GUI 7.1, the DirectAccess client can connect to SAP resources on the intranet over the DirectAccess tunnels. However, to get this to work, you need to set a specific environment variable, which we will discuss later in this post. This solves the IPv6 problem on the client side.
If the SAP server is not IPv6 capable (meaning that it isn’t using ISATAP or native IPv6 addressing), then the UAG DirectAccess server’s NAT64/DNS64 feature will be used for IPv6/IPv4 protocol translation. While this will allow access to a SAP server, it will break SAP load balancing. The end result is that if you don’t need SAP load balancing, then all you need is to do is set the environment variable on the SAP GUI client and connectivity will work over DirectAccess because NAT64/DNS64 will take care of the protocol translation for you.
However, if you need load balancing for your SAP servers, NAT64/DNS64 isn’t going to do all the work. In this case you’re going to need to bring in another component, called a SAPRouter.
A SAProuter is a non-transparent gateway that can accept both IPv4 and IPv6 connections and do protocol translation between IPv4 and IPv6. NAT64/DNS64 are not used. Instead, the DirectAccess client connects to the SAPRouter using the SAPRouter’s IPv6 address, and then the SAPRouter can route the connections to the IPv4-only SAP servers behind the SAPRouter. At this point the SAP servers are able to load balance the connections and also return the responses to the SAPRouter, which is then able to return the responses to the DirectAccess clients through the UAG DirectAccess server.
Figure 1 illustrates the request/response path between the DirectAccess client and the SAP resource servers (note that the load balancing component of the SAP servers is called out to make the path easier to understand).
Figure 1
The following are instructions should configure the SAP GUI 7.1 client to work with DirectAccess:
If you are using a saprouter you would have to add an entry in the field "SAProuter String", for example "/H/saprouterxy".
If you have further questions regarding this issue, please write to the address in the sig line below.
Authors:
Noam Ben-Yochanan, Senior Program Manager, DA
If you’re not aware of Test Lab Guides, they’re part of a new initiative we have at Microsoft that is intended to make life easier for you when it comes to adopting new products and technologies. We realize that when you consider bringing in a new product and technology, you have to consider how long its going to take to learn how it works. Sure, you might try a hands-on lab or a virtual lab to see what the product or technology can do, but after that, then what?
You’re likely going to try to set it up in a test lab. But do you know all the front-end and back-end components that go into making the product or solution work? Maybe – but only after you dig through a pile of design and deployment guides and maybe a few KB articles and some obscure forum posts. That “paper chase” takes a lot of time and if you’re like me, you consider the risk/benefit ratio when it comes to your time before you try out something new.
That’s where Test Lab Guides come in. Using a Test Lab Guide, you can test a new product or technology in a well-defined and pre-tested lab environment that covers all the front-end and back-end components. You configure everything in the test lab, you see all the moving parts, and you see how everything works together. Many people have told us already that the Test Lab Guides allowed them to quickly learn complex technologies because they could see how all the parts worked together – something that would have taken a long time using the traditional approach of sifting through hundreds of pages of documentation. Even better, after you go through the Test Lab Guide and get a working configuration, you can save a snapshot of the working setup and return to it later, either to check out how things look like when they’re working, or to extend it on your own with custom settings that mirror your current production environment.
As you can imagine, the key to test lab success is virtualization. Sure, you could scare up a bunch of PCs and create a lab network, but who has the time and resources for putting together a physical test network that contains 10, 15, 20 or even more clients and servers? While I know that can be done because that’s how we used to do things, the idea of saving disk images and exporting them and then importing them again to extend the configuration is just too time consuming for today’s busy admin. Nope – the reality is that with the advent of client and server virtualization on commodity hardware, test labs are almost exclusively done in a virtualized environment.
Test Lab Guides were designed with virtualization in mind. But if that’s true, why isn’t there any virtualization related information contained in the Test Lab Guides outside of the last step in each guide that tells you that you should snapshot your configuration? The reason for this is that when I’ve written Test Lab Guides, I’ve assumed that the admin using the Test Lab Guide is already well versed in his or her virtualization platform of choice, and would easily be able to translate the TLG instructions into that virtualization platform. While we naturally would prefer that you use Hyper-V as your Test Lab Guide virtualization platform, we realize that there are a number of different virtualization platforms to choose from: VMware Workstation, ESX, Xen and other’s are all capable environments on which you can run your Test Lab Guide scenarios.
Providing virtualization specific information would mean that we would include information that is specific for some platforms and not others. In addition, for the non-Hyper-V platform, if there are changes, we might not necessarily know about them, as it’s not in our charter to stay on top of each version of each virtualization offering.
However, I think it is important to share some virtualization information that will help you with your Test Lab Guide experience. Some of this is Hyper-V specific, but hopefully most of it will be easily applied to to non-Hyper-V platforms. And if you’re not currently using Hyper-V, you might want to give it a look. I was a big VMware user prior to joining Microsoft. However, after joining Microsoft I felt it was important for me to have some basic understanding of Hyper-V. The result is that I’ve been using Hyper-V almost exclusively in my Test Lab Guide development process and am very impressed with it. So if you’re a “VMware guy or gal” and never looked at Hyper-V, I recommend that you give it a look. If for no other reason, you might want to use Hyper-V for Test Lab Guides.
Another thing to consider when using virtualized environments for Test Lab Guides is memory. Some virtualization platforms enable something called "memory overcommit" what allows you to assign your virtual machines more memory than is available on the physical host machine. However, some virtualization do not - and Hyper-V is one of those solutions. While in some cases you can run a Test Lab Guide scenario with a machine that has 8 GB of memory, I have made the assumption that most organizations are using virtualization platforms that support at least 16 GB of memory, and ideally can support 24 GB or more. This allows you to run more complex, but more realistic scenarios in the Test Lab.
When working with virtualization, you need a good working understanding of how its virtual networking feature operates. With Hyper-V, there is the concept of “virtual networks” – with each virtual network acting as a type of virtual switch. VMware has a similar concept, which are called “VMNet’s”. Each virtual machine you connect to the same virtual network or VMNet is on the same virtual network segment, or in other words, in the same Ethernet broadcast domain. If you want to create a multi-segmented network, you would create a virtual network for each segment.
When working with Test Lab Guides, you can create virtual networks for each of the subnets called out the in the Test Lab Guide. For example, in the Base Configuration Test Lab Guide (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ab6c61af-9c34-4692-815c-4396b482d31b), you are asked to create a “Corpnet subnet” and an “Internet subnet”. When using Hyper-V, you would create a virtual network for the Corpnet subnet and another virtual network for the Internet subnet.
If you need more network segments, you would create more virtual networks. For example, in the Test Lab Guide: Demonstrate UAG DirectAccess (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=71be4b7b-e0e9-4204-b2b5-ac7f3c23b16d), you need to create a new subnet called the “Homenet” subnet. To support the Homenet subnet, you just create a new virtual network.
If you are working with Hyper-V, you need to be aware that there are three types of virtual networks that you can choose from. These are:
When I create the Base Configuration, I create two Private virtual networks: one for the Corpnet subnet and one for the Internet subnet. You can name them whatever you want and it’s probably best to name them Corpnet subnet and Internet subnet. Do the same for any other virtual networks you need to create to support the Test Lab. The Test Lab Guide will provide you some guidance on the name of the network (such as calling the new network the “Fabrikam” network), in which case you create a new virtual network for the Fabrikam subnet.
Now you might be wondered what to do if you need to provide Internet access to a machine on a Private virtual network. Remember that virtual machines connected to a Private virtual network are able to communicate with other VMs on the same Private virtual network, but aren’t able to communicate with any other physical or virtual machine. You’ll have to do something to else to provide a virtual machine actual Internet access.
You might want to provide a VM actual Internet access if you want to download some applications or updates. The approach you use to provide this access will vary with the role the virtual machine is playing on the Test Lab network. For example, CLIENT1 (from the Base Configuration) is a Windows 7 client machine that’s designed to move between the Corpnet subnet, the Internet subnet and the Homenet subnet (and even the Fabrikam subnet if you choose to use the Fabrikam Base Configuration [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=4521421f-bd0c-4eed-b280-a7aaf2fde321]). You can create an External virtual network and connect CLIENT1 to that network. It will then pick up IP addressing from the “live” network’s DHCP server and you can then download the information you need from the Internet. After you get the information you need, you can move CLIENT1 from the External virtual network back to the Corpnet subnet (which is a Private virtual network).
While this approach works fine for virtual machines that are designed to be mobile, it gets a bit more tricky when you want to provide Internet access for more “sessile” machines. Examples of these types of machines would be domain controllers and Exchange Servers; both of which really aren’t designed to be moved from one network to the other and be DHCP clients. We’re going to have to think of a different approach for these servers.
In addition, there might be scenarios when you need to demonstrate actual Internet from specific client types access or you want to provide Internet access to all machines so that you can demonstrate things like Windows Update Services.
To do this, you might consider what I did in the Test Lab Guide: Demonstrate UAG SP1 RC Force Tunneling (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=756e35c6-d706-4b18-80c2-881e9bccda3c). In that Test Lab Guide, I configured INET1 with a second network interface and then configured that network interface to use an External virtual network so that it could connect to the Internet. I then configured the default gateway settings on the computers in the Test Lab so that Internet bound traffic would go through INET1. There were some network gateway and DNS configurations that were required to make it work, but it did allow all the computers in the Test Lab Internet access, including DirectAccess clients.
Note: We plan to update the Base Configuration Test Lab Guide so that Internet access is made a default option. I hope to have that update to the Base Configuration Test Lab Guide to you before the end of January. If you need help before that, please let me know and I’d be happy to show you how to provide Internet access to your Test Lab.
Make sure to always create the virtual networks you need before you create the virtual machines that you’ll to connect to them. It’s better to have the virtual network ready for the virtual machines instead of having the virtual machines wait for you to create the networks to connect to them.
For more information about configuring virtual networks on a Hyper-V server, check out the following video: http://www.screencast.com/t/Ft4Dpm4tLZ (around 7 mins)
This is one area where there are a number of options and everyone has their favorite. One popular option is to use parent/child disk configurations, where you essentially create a parent disk that subsequent virtual machines can take advantage of when you want to quickly create new virtual machines for your Test Lab. Kurt Hudson did a great job describing how you do this in his TechNet wiki article Hyper-V Virtual Machine (VM) Parent-Child Configuration Using Differencing Disks http://social.technet.microsoft.com/wiki/contents/articles/hyper-v-virtual-machine-vm-parent-child-configuration-using-differencing-disks.aspx
While this is a valid and popular approach for quickly creating new virtual machines, and something that can be done with VMware and other virtualization platforms, I’ve have chosen not to use this approach when it comes to building out Test Labs. This and similar approaches that “key” into a parent disk introduce dependencies and potential points of failure that reduce the flexibility of the solution. It also makes it more complicated. However, it does have the advantages of allowing you to create virtual machines more quickly, and even more significant is the amount of disk space you can save by using this approach.
If disk space isn’t an issue for you, and if you’re willing to put in a few more minutes per virtual machine to reduce the risks of a parent/child configuration to your entire virtual lab infrastructure, then you might want to consider my approach. My approach is easy and it’s simple (which pretty much describes me). The approach I use for virtual machines:
Creating virtual machines and snapshots are closely related topics. Each virtual machine you create and configure represents a good chunk of invested time. If you don’t snapshot that virtual machine at the end of your Test Lab, you’ve wasted your efforts (OK, not wasted completely because you probably learned something during the process). When you snapshot the virtual machines in your Test Labs, you can quickly restore the snapshots and start at the end of that Test Lab. At that point you can create a new Test Lab, you can play with the settings to see what happens, or you can use troubleshooting and diagnostic tools and see what they look like when the system is working correctly. Snapshots are unique to virtualization and are a powerful tool to speed your ability to create advanced, realistic and actionable Test Lab scenarios that enable you to learn about your products and communicate more effectively than ever.
However, you need to be systematic about snapshotting. Over my years of using VMware Workstation I had created hundreds of virtual machines to support thousands of possible scenarios for ISA Server and TMG. I didn’t have a co-ordinated system for managing the snapshots and as you can imagine this lead to snapshot sprawl. Over time the sprawl got so bad that my carefully saved snapshots didn’t provide me value and I ended up often having to recreate Test Lab scenarios that I had already done.
At the end of each Test Lab Guide there is a step that informs the reader to snapshot the lab. The step also includes instructions on what to name the Test Lab. The reader should be instructed to shut down each of the virtual machines gracefully at the end of the lab and then snapshot all the virtual machines at the same time after all machines have shut down. After the snapshot it complete, rename the snapshot from its default name to the name suggested in the Test Lab Guide.
Something that we don’t include in the Test Lab Guides regarding virtualization, but something that most virtualization savvy admins are already aware, is that the order you start the VMs is important. In general, you want to start the domain controllers first. Then start servers that provide key infrastructure services to other servers and clients.
This requires that the reader understand the overall solution – and this might not be a reasonable expectation, since the reason for going through the Test Lab Guides is to learn about the product. For example, in the Demonstrating UAG DirectAccess Test Lab Guide, you should start the DC1 virtual machine (a domain controller) first, and then start the UAG DirectAccess server. The reason for this is that the UAG DirectAccess server acts as an ISATAP router for the rest of the network, and it should be available when the ISATAP hosts on the network start up and configure their ISATAP adapters as they start up.
I have not included this start up information in the Test Lab Guides, which is something we will fix in the next version of the Test Lab Guide specification.
Three suggestions for you, and things I plan to implement in the next version of Test Lab Guides are:
To get a better idea of how snapshots are created, restored and named, please see my video on this subject at http://www.screencast.com/t/pGpBxCoZO4QO (around 7 mins).
In this article I provided a handful of tips and tricks that I use with virtualization when creating Test Lab Guides. These are methods that have worked for me and many of them come from habits of working with virtualization for the last decade; some of the habits might be good and some might need improvement. But if you starting on your trek of writing Test Lab Guides and also beginning your work with virtualization, I hope that these notes help you creating your Test Lab Guides faster than might have otherwise.
Here are the answers to Quiz 1, Round 1:
====================================================
Question 1: Which Operating System(s) can be configured as DirectAccess clients? (choose the best answer)
A. Windows 7 B. Windows Vista SP2 C. Windows Server 2008 R2 D. Windows 7 and Windows Vista SP2 E. Windows Server 2008 R2 and Windows 7
A. Windows 7
B. Windows Vista SP2
C. Windows Server 2008 R2
D. Windows 7 and Windows Vista SP2
E. Windows Server 2008 R2 and Windows 7
The answer to question 1 is E. Actually, a couple of people pointed out to me that I should have mentioned that you needed Enterprise or Ultimate Edition of Windows 7. While that is true, the editions are different SKUs, and not different operating systems. Therefore, the answer is Windows 7 and Windows Server 2008 R2 when asked which operating system.
Question 2: What happens when the DirectAccess client successfully connects to the Network Location Server (NLS)?
A. The DirectAccess client turns on the Windows Firewall Domain Profile B. The DirectAccess client disables its ISATAP interface C. The DirectAccess client disables the Name Resolution Policy Table
A. The DirectAccess client turns on the Windows Firewall Domain Profile
B. The DirectAccess client disables its ISATAP interface
C. The DirectAccess client disables the Name Resolution Policy Table
(note: there was a typo in answer C – I left out the word “client”, but the meaning of the answer remains unchanged)
The answer to question 2 is C. When the DA client connects to the intranet and successfully connects to the Network Location Server and receives a 200 HTTP response that is acceptable to WinHTTP (that is to say, that WinHTTP is able to successfully parse the web page) it will disable the NRPT. You can see the result of this turning off of the NRPT by using the command netsh namespace show effectivepolicy. You can see the result is Note: DirectAccess settings would be turned off when computer is inside corporate network in the figure below.
http://blogs.technet.com/b/tomshinder/archive/2010/07/19/what-defines-a-functional-connection-to-a-network-location-server.aspx
Question 3: When you do an ipconfig /all in a command prompt window and see both the Teredo and IP-HTTPS interfaces assigned an address, which interface is actually being used to transfer data?
A. The Teredo interface B. The IP-HTTPS interface C. Both the Teredo and IP-HTTPS interfaces D. None of the interfaces – when both appear it indicates that the Windows Firewall Domain Profile is active
A. The Teredo interface
B. The IP-HTTPS interface
C. Both the Teredo and IP-HTTPS interfaces
D. None of the interfaces – when both appear it indicates that the Windows Firewall Domain Profile is active
The answer to question 3 is B. This condition occurs when the DirectAccess client takes more than the computed delay for the DirectAccess client to determine corporate connectivity over the Teredo interface. To test for this condition, run the ipconfig command at a command prompt. If you have global addresses on both the Teredo and IP-HTTPS tunnel interfaces, this condition has occurred.
http://blogs.technet.com/b/tomshinder/archive/2010/08/24/why-are-both-the-teredo-and-ip-https-interfaces-active.aspx
I want to thank everyone who participated in Quiz 1, Round 1. This was a difficult quiz and I pulled some pretty tough questions first time around. Some of the quizzes will be easier, some will be more difficult. But I hope you will continue to play and that you find this a useful and fun learning experience. Quiz 2, Round 1 will be posted on December 9, 2010 – so make sure you put that on your calendar so you don’t miss the quiz because if you do, someone who’s ahead of you now might miss the next quiz and that will be your chance to take the lead! For the same reason, those of you who didn’t participate in Quiz 1 still have a chance – so make sure to take next week’s quiz and get yourself on the leaderboard!
With all the excitement coming from the upcoming release of UAG Service Pack 1, I thought we might do something fun (OK, DirectAccess is always fun, but maybe we can do something closer to what other people would consider fun). What’s more fun than a contest? I know, a contest where you’re the winner! OK, even more fun is a contest where you’re the winner and you actually win something.
How about a Starbucks card? I have one in my hot little hands and its really wanting to go the the winner of the UAG DA Contest winner!
So here’s how the contest is going to work:
Since the contest hasn’t started yet, the leaderboard looks like this (I put my name in there just as an example):
Ready to play? Here are the three questions for Quiz 1/Round 1:
A. The DirectAccess client turns on the Windows Firewall Domain Profile B. The DirectAccess client disables its ISATAP interface C. The DirectAccess disables the Name Resolution Policy Table
C. The DirectAccess disables the Name Resolution Policy Table
Great! Now click the following link (which includes the subject line I need to track the entries) and email me your answers:
I must receive your entry by December 3, 2010 3:00PM Central Time
Both the Windows DirectAccess and the UAG DirectAccess solutions are heavily dependent on the Windows Firewall with Advanced Security. DirectAccess clients take advantage of both firewall rules and Connection Security Rules. Connection Security Rules are IPsec rules that control the IPsec tunnel mode connections between the DirectAccess clients and the DirectAccess server. In addition to the IPsec tunnel mode connections, Connection Security Rules are used to enable IPsec transport mode connections for servers for which you want the DirectAccess clients to connect using end-to-end security.
In order to get the most out of DirectAccess and how DirectAccess works, it helps to have a better understanding of the different components of the Windows Firewall with Advanced Security and how some of the important settings work and how they interact with DirectAccess
Windows Firewall offers three firewall profiles: domain, private and public. The domain profile applies to networks where the host system can authenticate to a domain controller. The private profile is a user-assigned profile and is used to designate private or home networks. Lastly, the default profile is the public profile, which is used to designate public networks such as Wi-Fi hotspots at coffee shops, airports, and other locations.
Different firewall and connection security rules can be configured for each profile. There are default settings that are applied to each profile, but the administrator can customize their default settings.
The different profiles are important because a computer only works as a DirectAccess client when it is not on the corporate network. In order words, if the DirectAccess client detects that it can connect to its domain controller and is on the corporate network, it will use the domain profile. The DirectAccess client will only act as a DirectAccess client when the Private or Public Profiles are enabled. The reason for this is that the Connection Security Rules that enable the IPsec tunnel mode connections to the DirectAccess server are included only in the Public or Private Profiles. There are no Connection Security Rules that enable IPsec tunnel mode connections to the DirectAccess server in the Domain Profile.
The UAG DirectAccess server (as well as the Windows DirectAccess server) will create the Connection Security Rules that allow for the creation of the DirectAccess IPsec tunnels (and the end-to-end IPsec transport mode connections for servers configured for end-to-end security). However, the UAG DirectAccess wizard does not import any firewall rules that you might have configured to work on the corporate network. Those rules that you created for the intranet hosts were created for the Domain Profile. If you want your Domain Profile firewall rules to apply to DirectAccess clients, you will need to enable those rules on the Public Profile and Private Profile too.
In order for intranet computers to connect to DirectAccess clients, there need to be firewall rules in place on the DirectAccess clients that allow the incoming connections from the intranet servers. In addition, if you are blocking outbound connections, you may need to create rules that enable required protocols outbound. There are several things you need to know about these firewall rules:
While it’s possible for you to create your firewall rules in the DirectAccess Clients GPO, that’s not a good idea because your rules will be overwritten the next time you use the UAG DirectAccess wizard and deploy updated GPO settings. Instead, create a new GPO with the firewall settings and apply it to your DirectAccess clients security group or OU.
For a very good tutorial on configuring firewall rules for DirectAccess client, check out How to enable Remote Desktop Sharing (RDS/RDP) from corporate machines to DirectAccess connected machine at http://blogs.technet.com/b/edgeaccessblog/archive/2010/09/14/how-to-enable-remote-desktop-sharing-rds-rdp-from-corporate-machines-to-directaccess-connected-machines.aspx
And if you want to try it out for yourself in your UAG DirectAccess Test Lab, check out Test Lab Guide: Demonstrate UAG DirectAccess Remote Management over at http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=385a3144-8e84-4335-896b-a2927e4d46cd
I’m glad you asked! Yes, there are a few more things you should think about when configuring firewall rules for DirectAccess clients. These are:
Yaniv Naor, SDE Tom Shinder tomsh@microsoft.com Knowledge Engineer, Microsoft DAIP iX/Forefront 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
Shannon Fritz, and up and comer in the world of UAG DirectAccess found a very interesting issue with the UAG Management Console and loading of the DirectAccess interface. It turns out that if the UAG server has a NetBIOS name that is longer than the allowed 15 characters, the DirectAccess configuration interface won’t open.
Here’s a screenshot from the TechNet forums of what Shannon saw:
The Product Group is now aware of this issue, and we’ll make plans to update documentation to warn against using NetBIOS names longer than 15 characters.
You should also check out Shannon’s blog over at:
http://blog.concurrency.com/infrastructure/uag-cannot-load-the-directaccess-view-0
for more information on what he found.
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 with Secure Socket Tunneling Protocol (SSTP) and Remote Desktop Gateway (RDG) check out:
http://go.microsoft.com/fwlink/?LinkId=206505
==================================================
DirectAccess is a new feature in the Windows 7 and Windows Server 2008 R2 operating systems that gives users the experience of being seamlessly connected to their intranet any time they have Internet access. With DirectAccess enabled, requests for intranet resources (such as e-mail servers, shared folders, or intranet Web sites) are securely directed to the intranet, without requiring users to connect to a VPN. DirectAccess provides increased productivity for a mobile workforce by offering the same connectivity experience both inside and outside the office.
Forefront Unified Access Gateway (UAG) SP1 RC extends the value of the Windows DirectAccess solution by adding features that meet the requirements of many enterprise deployments:
To learn more about UAG DirectAccess, see the following resources:
· Forefront UAG DirectAccess Design Guide
· Forefront UAG DirectAccess Deployment Guide
UAG SP1 RC supports hosting multiple roles on a single UAG server or UAG array. For example, you might want to host both the DirectAccess server and SSTP VPN server roles on the same server or array. Windows 7 clients that are configured DirectAccess clients will automatically use DirectAccess to connect to intranet resources. Windows 7 clients that are not domain members, or who are not configured as DirectAccess clients can use SSTP to connect to the intranet using a network level VPN connection. Windows 7, Windows Vista and Windows XP clients can connect to Remote Desktop and RemoteApps through a UAG server that is configured to host the Remote Desktop Gateway role. In this guide, we demonstrate how a UAG server can support the combined, DirectAccess, SSTP and Remote Desktop Gateway server roles.
This guide provides step-by-step instructions for configuring UAG DirectAccess SP1 RC with SSTP and Remote Desktop Gateway in a test lab so that you can see how it works. You will set up and deploy UAG DirectAccess SP1 RC using five server computers, two client computers, Windows Server 2008 R2 Enterprise edition, and Windows 7 Ultimate Edition. The Test Lab simulates intranet, Internet, and a home networks, and demonstrates a co-located Forefront UAG DirectAccess and SSTP VPN server role deployment. The starting point for this paper is the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess .
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, please see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide
In this test lab scenario, Forefront UAG DirectAccess SP1 RC 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 DirectAccess in the test lab:
This Test Lab Guide demonstrates a combined UAG SP1 RC DirectAccess and SSTP deployment.
Important
The following instructions are 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 clearly show the desired functionality. It is important to remember that this configuration is neither designed to reflect best practices nor does it reflect a desired or recommended configuration for a production network. The configuration, including IP addresses and all other configuration parameters, is designed only to work on a separate test lab network.
Attempting to adapt this test lab configuration to a pilot or production deployment can result in configuration or functionality issues. To ensure proper configuration and operation of UAG DirectAccess and SSTP, please refer to the Forefront UAG DirectAccess Deployment Guide for the steps to configure the UAG DirectAccess server and supporting infrastructure servers.
The following sections describe how to configure UAG1 as a DirectAccess, SSTP VPN and Remote Desktop Gateway server. After UAG1 is configured, this guide provides steps for demonstrating the DirectAccess, SSTP VPN and Remote Desktop Server functionality for CLIENT1 when it is connected to the Homenet subnet.
Note
You must be logged on as a member of the Domain Admins group or 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. For all tasks described in this document you can use the CONTOSO\User1 account created when you went through the steps in the UAG DirectAccess Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.
The following procedures are performed to enable and allow you to test the UAG SP1 RC DCA:
· Step 1: Complete the Demonstrate UAG SP1 RC DirectAccess with SSTP Test Lab Guide – The first step is to complete all the steps in the Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess with Secure Socket Tunneling Protocol (SSTP).
· Step 2: Install and Configure the RDS Session Host on APP1. In order to test UAG1 publishing of Remote Desktops and RemoteApps we need an RDS Session Host server on the corpnet subnet. In this step you will install the RDS Session Host Role on APP1.
· Step 3: Generate the RemoteApp Configuration File on APP1. You will publish a RemoteApp on UAG1. In order to publish the RemoteApp, you need to generate a RemoteApp configuration file on APP1. In this step you will generate the RemoteApp configuration file and copy it to UAG1.
· Step 4: Publish Remote Desktops on UAG1. To publish Remote Desktops you need to add the Remote Desktops Application to the portal. In this step you will add the Remote Desktop applications to the UAG1 portal page.
· Step 5: Publish RemoteApps on UAG1. To publish RemoteApps you need to add the RemoteApps application to the portal. In this step you will add the RemoteApps application to the portal page.
· Step 6: Test DirectAccess, SSTP and Remote Desktop Connectivity from CLIENT1. After the portal configuration is completed, you can test connectivity to resources through the UAG portal. In this step you will confirm DirectAccess and SSTP connectivity, and test Remote Desktop and RemoteApp connectivity through the portal.
· Step 7: Snapshot the configuration. After completing the Test Lab, take a snapshot of the working UAG DirectAccess, SSTP and Remote Desktop Gateway Test Lab so that you can return to it later to test additional scenarios.
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.
The first step is to complete all the steps in the Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess with Secure Socket Tunneling Protocol (SSTP). 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 DirectAccess with SSTP and RDG. If you have already completed the steps in that Test Lab Guide and saved a snapshot or disk image of the Test Lab, you can restore the snapshot or image and begin with the next step.
In order to test UAG1 publishing of Remote Desktops and RemoteApps we need an RDS Session Host server on the corpnet subnet. In this step you will install and configure the RDS Session Host Role on APP1.
Install the RDS Session Host on APP1:
Configure the RDS Session Host on APP1:
You will publish a RemoteApp on UAG1. In order to publish the RemoteApp, you need to generate a RemoteApp configuration file on APP1. In this step you will generate the RemoteApp configuration file and copy it to UAG1.
To publish Remote Desktops you need to add the Remote Desktops Application to the portal. In this step you will add the Remote Desktop application to the UAG1 portal page.
To publish RemoteApps you need to add the RemoteApps application to the portal. In this step you will add the RemoteApps application to the portal page.
After the portal configuration is completed, you can test connectivity to resources through the UAG portal. In this step you will confirm DirectAccess and SSTP connectivity, and then test Remote Desktop and RemoteApp connectivity through the portal.
Confirm DirectAccess Connectivity to the Corpnet subnet:
Confirm SSTP Connectivity to the Corpnet subnet:
Confirm Remote Desktop Connectivity to the Corpnet subnet:
Confirm RemoteApp Connectivity to the Corpnet subnet:
This completes the UAG SP1 RC DirectAccess with SSTP and Remote Desktop Gateway test lab. To save this configuration so that you can quickly return to a working UAG SP1 RC DirectAccess with SSTP and Remote Desktop Gateway configuration from which you can test other DirectAccess modular TLGs, TLG extensions, or for your own experimentation and learning, do the following:
For more information on UAG and SSTP, see Setting up Remote Network Access.
For more information on UAG and Remote Desktop Gateway, see Remote Desktop Services publishing solution guide.
For procedures to configure the Base Configuration test lab on which this document is based, see the Test Lab Guide: Base Configuration.
For procedures to configure UAG SP1 RC DirectAccess on which this document is based, see the Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess.
For procedures to configure UAG SP1 RC DirectAccess on which this document is based, see Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess with Secure Socket Tunneling Protocol (SSTP)
For a comprehensive list of Test Lab Guides, please see Test Lab Guides.
For a list of UAG DirectAccess related Test Lab Guides, please see UAG DirectAccess Test Lab Guide Portal Page
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, see the DirectAccess Troubleshooting Guide.
For information on troubleshooting UAG DirectAccess in a Test Lab, see Test Lab Guide: Troubleshooting UAG DirectAccess.
For more information about DirectAccess, see the DirectAccess Getting Started Web page and the DirectAccess TechNet Web page.
OK folks, this is the last TLG for a week or two. Yes, I still have a couple of important ones that need to be done (TLGs that demonstrate how UAG DirectAccess works with BranchCache [very cool!] and a Pilot Deployment Test Lab Guide where the UAG DirectAccess server belongs to a different forest than the computers and users).
So what is this Test Lab Guide? Nothing other than the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess with Secure Socket Tunneling Protocol (SSTP) and Remote Desktop Gateway (RDG). For a while I wondered if it was worth the effort to do this one, because I don’t know of many people who are using the RDG feature included with the UAG server. But then I thought about it and realized that maybe no one is using the RDG feature because no one is writing about it For this reason (and also because I wanted to see if it actually worked), I decided to move forward on this Test Lab Guide.
The good news is that it works! Indeed, the combined DirectAccess, SSTP and Remote Desktop Gateway deployment works a treat. I don’t know why I didn’t think of this earlier, not only for writing a Test Lab Guide, but for deploying myself in my home office (actually, my wife Deb Shinder did the live deployment after she tested the Test Lab Guide for me).
The RDG setup also supports down-level clients such as XP and Vista, which helps in those occasional situations when I don’t have a worked laptop and have to borrow one (like when I’m on the road and my laptop dies and I get a “loaner” that is running XP SP2). Accessing the Remote Desktop works great, and also the RemoteApp feature is even more useful – since I can use that together with my DirectAccess client configuration when I need access to an app that’s not installed on my laptop.
I hope you like this Test Lab Guide and find it useful. As always, if you have any questions or problems with this Test Lab Guide, let me know! Send me a note to the email address in my sig line and I’ll get back to you as soon as I can.
For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess with SSTP check out:
http://go.microsoft.com/fwlink/?LinkId=206283
UAG SP1 RC supports hosting multiple roles on a single UAG server or UAG array. For example, you might want to host both the DirectAccess server and SSTP VPN server roles on the same server or array. Windows 7 clients that are configured DirectAccess clients will automatically use DirectAccess to connect to intranet resources. Windows 7 clients that are not domain members, or who are not configured as DirectAccess clients can use SSTP to connect to the intranet using a network level VPN connection. In addition, DirectAccess clients hosting applications that are not compatible with DirectAccess can connect to the SSTP VPN when they need to use the non-compatible application.
Non-Windows 7 operating systems (such as Windows Vista, Windows XP) can use the UAG Network Connector to connect to the intranet using a network level SSL VPN connection. However, you cannot host the Network Connector application on the same server or array that is also hosting DirectAccess. To support network level VPN connectivity for non-Windows 7 clients, you will need to deploy a second UAG server or array.
This guide provides step-by-step instructions for configuring UAG DirectAccess SP1 RC with SSTP in a test lab so that you can see how it works. You will set up and deploy UAG DirectAccess SP1 RC using five server computers, two client computers, Windows Server 2008 R2 Enterprise edition, and Windows 7 Ultimate Edition. The Test Lab simulates intranet, Internet, and a home networks, and demonstrates a co-located Forefront UAG DirectAccess and SSTP VPN server role deployment. The starting point for this paper is the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess .
The following sections describe how to configure UAG1 as both a DirectAccess and SSTP VPN server. After UAG1 is configured, this guide provides steps for demonstrating the DirectAccess and SSTP VPN functionality for CLIENT1 when it is connected to the Homenet subnet.
· Step 1: Complete the Demonstrate UAG SP1 RC DirectAccess Test Lab Guide – The first step is to complete all the steps in the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.
· Step 2: Create the HTTPS Trunk. UAG uses the concept of “trunk” as the primary listener for incoming SSL connections to a UAG portal page. In this step you will create an SSL Trunk that can be used to create a portal page that includes the SSTP VPN application.
· Step 3: Configure the Remote Network Access Settings. The SSTP application requires configuration of a number of settings before it can be deployed. In this step you will configure these settings.
· Step 4: Add the SSTP Remote Network Access Application to the Trunk. In order for users to access the SSTP VPN application, that application must be added to a trunk. In this step you will add the SSTP application to the HTTPS trunk.
· Step 5: Activate the Configuration and View Activation in the Activation Monitor. You need to activate the configuration after adding the SSTP VPN application to the trunk. In this step you will activate the configuration and view the activation process in the Activation Monitor.
· Step 6: Test DirectAccess and SSTP Connectivity. After activation is complete, you are ready to test both DirectAccess and SSTP connectivity. In this step you will confirm DirectAccess connectivity and then start an SSTP VPN connection through the portal.
· Step 7: Snapshot the configuration. After completing the Test Lab, take a snapshot of the working UAG DirectAccess with SSTP Test Lab 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 the UAG DirectAccess DCA. If you have already completed the steps in that Test Lab Guide and saved a snapshot or disk image of the Test Lab, you can restore the snapshot or image and begin with the next step.
UAG uses the concept of “trunk” as the primary listener for incoming SSL connections to a UAG portal page. In this step you will create an SSL Trunk that can be used to create a portal page that includes the SSTP VPN application.
The SSTP application requires configuration of a number of settings before it can be deployed. In this step you will configure these settings.
In order for users to access the SSTP VPN application, that application must be added to a trunk. In this step you will add the SSTP application to the HTTPS trunk.
You need to activate the configuration after adding the SSTP VPN application to the trunk. In this step you will activate the configuration and view the activation process in the Activation Monitor.
After activation is complete, you are ready to test both DirectAccess and SSTP connectivity. In this step you will confirm DirectAccess connectivity and then start an SSTP VPN connection through the portal.
This completes the UAG SP1 RC DirectAccess with SSTP test lab. To save this configuration so that you can quickly return to a working UAG SP1 RC DirectAccess Connectivity Assistant configuration from which you can test other DirectAccess modular TLGs, TLG extensions, or for your own experimentation and learning, do the following:
I am happy to tell you that today I’ve released the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess with Secure Socket Tunneling (SSTP) Test Lab Guide. This is one that I was looking forward to doing because this is such an important deployment model.
As you might know, a single UAG server or UAG array can support all of the roles that are supported by UAG (with the exception that a UAG server or array that acts in the DirectAccess role cannot also host the Network Connector). In general, I recommend that you use different UAG servers or array based on their functional roles:
This is not a hard and fast rule, and I certainly wouldn’t fault anyone for taking a different approach. But I’ve found that if you separate the services provided on the server or array in this manner, it’s easier to “size” your deployment, given the high processing requirements for the DirectAccess server deployment.
Having SSTP on the DirectAccess server makes it easy to have a “fall back” solution for any applications that don’t work with DirectAccess. While we haven’t seen too many of them, there are still a few and SSTP makes it easy to access the corporate network for DirectAccess client when they need to use these applications. In addition, you may have Windows 7 clients that are not domain members, and thus can’t be DirectAccess clients. Or you might even have domain member Windows 7 computers, but these aren’t configured for DirectAccess. These non-DirectAccess clients can easily connect to the corporate network using the Secure Socket Tunneling Protocol (SSTP), which is firewall and NAT friendly, so that users can connect using SSTP from almost anywhere.
In this Test Lab Guide you will build out a co-located DirectAccess and SSTP server and then test the deployment. You’ll configure the UAG server as both a DirectAccess and SSTP VPN server and then test DirectAccess and SSTP VPN connectivity, and look at several key areas to confirm connectivity and what normal connectivity looks like in these scenarios.
I hope you like the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess with Secure Socket Tunneling (SSTP) Test Lab Guide. As always, if you have any questions on this Test Lab Guide, or have suggestions for improvements or if you find errors, then please let me know! Just write to the email address in my sig line and I’ll get back to you as soon as I can.
For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess Connectivity Assistant check out:
http://go.microsoft.com/fwlink/?LinkId=205738
The Microsoft DirectAccess Connectivity Assistant (DCA) supports a DirectAccess client computer that is running Windows 7 by clearly indicating the state of DirectAccess connectivity to corporate network resources. It provides easy access to troubleshooting information and makes it simple to create and send log files to support personnel.
Without the DCA, when a user’s Internet connection (for example, http://www.bing.com) appears to be available, but corporate network resources are not accessible, there is no way that the user can verify if the problem is caused by DirectAccess not working correctly. This can result in user frustration and increased Help Desk support calls. The DCA clearly indicates the operational status of DirectAccess by using an icon in the notification area and informational messages. This helps the user identify the problem area and helps direct troubleshooting efforts.
If DirectAccess is not working correctly, the DCA clearly indicates the status by changing the icon in the notification area and by sending informational messages that provide more detail about the failure. The DCA provides the user with easy access to an extranet URL. For example, this URL might point to a Web site that hosts support information for the organization’s user community. The user can easily send diagnostic log files to the DirectAccess support staff. The log files can contain the default information. The UAG SP1 RC DCA includes comprehensive advanced diagnostics built-in. The administrator can also include a script in the DCA configuration that creates additional diagnostic information that is included in the log files sent to the support team.
This guide provides step-by-step instructions for configuring UAG DirectAccess SP1 RC with the DirectAccess Connectivity Assistant in a test lab so that you can see how it works. You will set up and deploy UAG DirectAccess SP1 RC using five server computers, two client computers, Windows Server 2008 R2 Enterprise edition, and Windows 7 Ultimate Edition. The Test Lab simulates intranet, Internet, and a home networks, and demonstrates the Forefront UAG DirectAccess Connectivity Assistant. The starting point for this paper is the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess .
This Test Lab Guide demonstrates the UAG DirectAccess SP1 RC DirectAccess Connectivity Assistant.
For more information about the different modes of NAP, see Stages of a NAP Deployment.
Attempting to adapt this test lab configuration to a pilot or production deployment can result in configuration or functionality issues. To ensure proper configuration and operation of UAG DirectAccess , please refer to the Forefront UAG DirectAccess Deployment Guide for the steps to configure the UAG DirectAccess server and supporting infrastructure servers.
The following sections describe how to configure UAG1, DC1 and CLIENT1 for UAG SP1 RC and the DCA. After UAG1, DC1 and CLIENT1 are configured, this guide provides steps for demonstrating the DCA functionality for CLIENT1 when it is connected to the Homenet subnet.
· Step 2: Configure INET1 with a Help.txt file. The DCA can provide DirectAccess users information about a web site they can go to in order to get help with DirectAccess related problems. In this step you will configure a web page that CLIENT1 can reach to get that help.
· Step 3: Install and Configure the Web Server Role on DC1. The DCA uses a number of connectivity verifiers to determine intranet connectivity over the DirectAccess IPsec tunnels. In this step you will configure DC1 as a web server so that the DCA can use HTTPS to DC1 for a connectivity verifier.
· Step 4: Run the UAG DirectAccess DCA Configuration Wizard on UAG1. UAG SP1 RC includes a new integrated DCA wizard that automatically configures and deploys GPO settings that enable the DCA. In this step you will run the UAG SP1 RC DCA wizard.
· Step 5: Update Group Policy on CLIENT1 and Test DCA Functionality. The new DCA settings are deploy via the DirectAccess clients GPO. In this step you will update Group Policy on CLIENT1 and then test some of the DCA features.
· Step 6: Snapshot the configuration. After completing the Test Lab, take a snapshot of the working UAG DirectAccess with NAP Test Lab so that you can return to it later to test additional scenarios.
The DCA can expose to DirectAccess users a link to a location where they can find help. This location is configured in the UAG DirectAccess DCA wizard. In this step you will configure a Help.txt file that CLIENT1 will connect to when acting as a DirectAccess client.
The UAG DCA uses connectivity verifiers to determine DirectAccess connectivity to the intranet over the DirectAccess tunnels. Connectivity verifiers can use HTTP, HTTPS and SMB to assess the current connectivity status to the intranet over the DirectAccess IPsec tunnels. In this step you install the web server role on DC1 and then bind a certificate to the web site so that the DCA can establish an SSL session with DC1 to determine intranet connectivity.
UAG SP1 RC includes a new wizard that enables you to configure the DCA so that you don’t have to manually configure Group Policy to support the DCA. In this step you will run the DCA wizard so that it will automatically provision Group Policy to configure the DCA on DirectAccess clients.
In this step you will update Group Policy on CLIENT1 so that it receives the new DCA related settings. Then you will install the DCA client software and finally test DCA functionality when CLIENT1 is located on the Homenet subnet.
Update Group Policy on CLIENT1:
Install the DCA software on CLIENT1:
Test DCA Functionality on CLIENT1:
It is important to note that the DCA icon may show a red “x” even when there is connectivity to the intranet. The red “x” appears when any of the connectivity verifiers is unavailable to the DirectAccess client. It is recommended that you specify a diverse set of resources for your connectivity verifiers. This diversity helps ensure that a failure to access a resource is an unambiguous indication of a problem with DirectAccess rather than a problem with another component.
For example, if all of the specified resources are behind a network address translating application layer gateway (NAT64), the failure of DCA to access the test resources might indicate a failure of the NAT64 rather than a failure of DirectAccess. Instead, identify one resource behind the NAT64, another behind an ISATAP gateway, and so on. Also note that you must not use the Network Location Server as a connectivity verifier, since the name of the Network Location Server cannot be resolved by the DirectAccess client.
This completes the UAG SP1 RC DirectAccess Connectivity Assistant test lab. To save this configuration so that you can quickly return to a working UAG SP1 RC DirectAccess Connectivity Assistant 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 TLG UAG DirectAccess SP1RC DCA. If your lab uses physical computers, create disk images to save the DirectAccess test lab configuration.
For a comprehensive list of UAG DirectAccess Test Lab Guides, please see Test Lab Guides.
Yay! Another Test Lab Guide hits the download center today.
Today’s Test Lab Guide is the Test Lab Guide: Demonstrate UAG DirectAccess Connectivity Assistant. In this Test Lab Guide you’ll go over the installation and configuration of the DirectAccess Connectivity Assistant (known as the DCA). The DCA allows DirectAccess users to receive information about the status of their DirectAccess connections and also includes advanced diagnostic tools that make it simple for the user to create comprehensive troubleshooting logs that can be emailed to the UAG DirectAccess administrator with a single click.
I hope you like the Test Lab Guide: Demonstrate UAG DirectAccess Connectivity Assistant. Let me know what you think of it! If there are additional scenarios you’d like to see covered in this Test Lab Guide, or if there are areas that you think need clarification or enhancement, let me know. Just send me a note to the email address in my sig line and I’ll get right back to you.
Jason Jones, one of our ace Forefront MVPs, has put together a great blog post on DirectAccess application compatibility.
If you’re in the process of planning a UAG DirectAccess rollout, you might want to check out this list.
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
Just wanted to give all you Edge Man Blog followers a heads-up on the new Test Lab Guides Blog.
Test Lab Guides are definitely catching on internally at Microsoft and we are expecting a flood of them coming to you in the next few months. In addition, I’ve been hearing from a number of you that you want to create your own Test Lab Guide extensions for the TechNet wiki – rock on!
My esteemed and accomplished colleague Joe Davies and I will maintain the Test Lab Guides blog and you can use it as a central place to hear news and views about Test Lab Guides.
Remember, with Test Lab Guides, you Make Something of IT!
For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess Force Tunneling check out:
http://go.microsoft.com/fwlink/?LinkId=205354
Forefront Unified Access Gateway (UAG) 2010 SP1 RC DirectAccess 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.
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:
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.
Encryption. DirectAccess uses IPsec to provide encryption for communications across the Internet.
Access to IPv4-only intranet resources. UAG SP1 RC 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, which is referred to as Force Tunneling.
The following figure shows a DirectAccess client on the Internet.
This paper contains instructions for configuring and demonstrating UAG SP1 RC DirectAccess using six server computers and two client computers. The starting point for this paper is a Test Lab based on the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess. The resulting DirectAccess test lab simulates an intranet, the Internet, and a home network and demonstrates DirectAccess functionality in different Internet connection scenarios when DirectAccess Force Tunneling is enabled.
Force tunneling is used when you want all traffic, both intranet and Internet, to go through the UAG DirectAccess server. The default setting for UAG DirectAccess is split tunneling. When Force Tunneling is enabled, all traffic must go through the DirectAccess tunnels. For a DirectAccess client to reach the Internet, the client must be configured to use a web proxy server, or to use the NAT64/DNS64 service on the UAG DirectAccess server to route connections to the Internet (sometimes referred to “bouncing” the connections off the UAG DirectAccess server to the Internet). This guide provides step by step instructions that allow you to demonstrate how to use both methods of Internet access for Force Tunneling enabled DirectAccess clients.
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:
The test lab consists of four subnets that simulate the following:
This guide provides step by step instructions on how to build a test lab that will enable you to test the new UAG SP1 RC Force Tunneling configuration feature. Force Tunneling forces DirectAccess clients to always use the DirectAccess tunnels for any kind of communication, including both intranet and Internet communications. When you configure DirectAccess clients to use Force Tunneling, you can enable one of two methods of Internet access for the DirectAccess client.
These methods include:
· Web proxy – You can configure the force tunneling DirectAccess clients on the Internet to use a web proxy on your intranet to gain Internet access. When using the web proxy option, the DirectAccess clients are limited to using web proxy supported protocols when connecting to Internet resources, which typically are HTTP and HTTPS.
· UAG NAT64/DNS64 – If you need your force tunneling DirectAccess clients to access Internet using protocols other than those supported by a web proxy, and you configure them to use the UAG server’s NAT64/DNS64 service to route the connections through the UAG server to the Internet. You can put a web proxy or other web content filtering device in front of the UAG DirectAccess server if you want to control site access and perform malware filtering.
Note that the default configuration for DirectAccess clients is split tunneling. When split tunneling is enabled, connections to the intranet are forwarded through the DirectAccess IPsec tunnels and connections to the Internet are made through the client’s existing Internet connection. Force Tunneling represents a departure from the default configuration.
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, and show how Force Tunneling DirectAccess clients connect to the Internet using both Internet access models (web proxy and NAT64/DNS64).
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.
· Step 1: Complete the UAG SP1 RC DirectAccess Test Lab Guide. The UAG SP1 RC Test Lab Guide provides step by step instructions on how to create a working DirectAccess solution. The steps in this Test Lab Guide build on the steps in the UAG SP1 RC Test Lab Guide.
· Step 2: Configure INET1 for Internet Access. INET1 is currently configured with a single network adapter that is connected to the Internet subnet. In this step you will add a second network adapter and connect that adapter to a “live” network that provides a path to the actual Internet. You will then install and configure RRAS on INET1 so that it can act as a NAT router for live Internet connections from UAG1 and TMG1.
· Step 3: Install and Configure TMG1. When force tunneling is enabled for DirectAccess clients, you can provide DirectAccess clients access to the Internet through a web proxy server. In this step you will install the operating system on TMG1 and then install Forefront Threat Management Gateway 2010 on TMG1 so that TMG1 can provide web proxy services to CLIENT1.
· Step 4: Configure the Default Gateway on UAG1 and DC1. UAG1 requires a path to the Internet. In this step you will configure UAG1 to use INET1 as its default gateway to provide that path. DC1 requires a path to the Internet to provide Internet name resolution. In this step you will configure DC1 to use TMG1 as its default gateway to provide that path.
· Step 5: Configure UAG1 for Force Tunneling and Web Proxy Access to the Internet. In this step you will configure UAG1 to require DirectAccess client Force Tunneling and enable Internet access for DirectAccess clients through the TMG web proxy on TMG1.
· Step 6: Update CLIENT1 and Test Proxy Access to the Internet. In this step you will update the Group Policy configuration on CLIENT1 and test its ability to reach the Internet through the web proxy on TMG1.
· Step 7: Configure UAG1 for Force Tunneling and NAT64/DNS64 Internet Access. In this step you will configure UAG1 to require DirectAccess client Force Tunneling and enable Internet access for DirectAccess clients through UAG1 by taking advantage of the UAG NAT64/DNS64 feature.
· Step 8: Update CLIENT1 and Test NAT64/DNS64 Access to the Internet. In this step you will update the Group Policy configuration on CLIENT1 and test its ability to reach the Internet through the NAT64/DNS64 service on UAG1.
· Step 9: 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.
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 within the same section.
This Test Lab Guide uses the UAG SP1 RC DirectAccess Test Lab Guide as a starting place. Please complete the steps in Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess before proceeding with the remainder of the steps in this guide. If you have already completed the steps in the UAG SP1 RC DirectAccess Test Lab Guide and have saved a disk image or a virtual machine snapshot of the working DirectAccess configuration, then you can restore the configuration and proceed to the next step.
In order to demonstrate a Force Tunneling DirectAccess client’s ability to access the Internet, you need a gateway to the live Internet. The Corpnet subnet, the Internet subnet, and the Homenet subnets you created when you completed the Base Configuration are isolated from the live network. In order to provide actual Internet access for CLIENT1 when acting as a DirectAccess client, you need to provide an Internet gateway that UAG1 and TMG1 can use to reach the Internet. INET1 will be this Internet gateway.
You will perform the following operations to configure INET1:
A. Add and Configure a Second Network Adapter on INET1. INET1 is currently connected to the Internet subnet. The first step is to add a second network adapter to INET1 and connect that adapter to a “live” network that provides access to the Internet.
B. Install the Routing and Remote Access Service. In this step you will install the Routing and Remote Access Service on INET1 so that it can provide NAT-based access to the Internet for UAG1 and TMG1.
C. Configure INET1 as a NAT server. In this step you will configure the Routing and Remote Access service so that INET1 can act as a NAT server.
The first step is to install a second network adapter on INET1. This adapter must be connected to your live network and be assigned IP addressing information that enables it to reach the Internet through your existing Internet gateway. If your live network is configured to provide addressing information through DHCP, you can configure this second network adapter to use DHCP. If your network doesn’t provide IP addressing information that would enable Internet access automatically, then you will need to manually configure the IP addressing information on the second adapter to provide INET1 Internet access. In both cases, make sure that the IP addressing information provided includes a DNS server that can resolve Internet host names so that you can test Internet connectivity from INET1.
After the second adapter is installed and configured, test Internet connectivity on INET1. To test Internet connectivity, open a command prompt on INET1 and enter ping www.arin.net and press ENTER. You should receive four responses to your ping request. You can then close the command prompt window.
Now that you have installed the second network adapter on INET1, you are ready to install the Routing and Remote Access service. Perform the following steps to install the Routing and Remote Access Service on INET1:
You are now ready to configure INET1 as a NAT server. Perform the following steps to configure INET1 as a NAT server:
When Force Tunneling is enabled for DirectAccess clients, they cannot access the Internet the Internet directly as split tunneling is disabled. There are two methods available that provide DirectAccess clients Internet access when Force Tunneling is enabled: Internet access through a web proxy device, or Internet access through the UAG DirectAccess server’s NAT64/DNS64 service. When Internet access is enabled through a web proxy, only HTTP and HTTPS Internet access is enabled.
In this step you will perform the following procedures:
A. Install the Operating System on TMG1. TMG1 is a new computer that is in first introduced in this Test Lab Guide. There you need to start by installing the operating system on the TMG1 computer or virtual machine. TMG1 must have two network adapters installed prior to installing the operating system.
B. Configure TCP/IP Properties on TMG1. After installation of the operating system is complete, the next step is to configure the IP addressing settings on the internal and external interfaces of TMG1.
C. Rename TMG1 and Join TMG1 to the CORP Domain. As a security best practice, the TMG firewall should be configured as a domain member. In this step you will rename the computer or virtual machine to TMG1 and join it to the CORP domain.
D. Install Forefront Threat Management Gateway (TMG) 2010 Standard Edition. After the operating system is installed and IP addressing is assigned, and the machine renamed and joined to the domain, the next step is to install the Threat Management Gateway 2010 software.
E. Configure the TMG Firewall for Internet Access. By default, the TMG firewall does not allow traffic to pass through it. In this step you will configure the TMG firewall to allow Internet traffic outbound.
Perform the following steps to install the operating system on the TMG1 computer or virtual machine:
Perform the following steps to configure the TCP/IP Properties on the adapters installed on TMG1:
Perform the following steps to rename the TMG1 computer or virtual machine and join it to the CORP domain:
TMG1 will act as a web proxy server to support Internet access for Force Tunneling enabled DirectAccess clients. Perform the following steps to install Threat Management Gateway (TMG) 2010, which will provide web proxy services to CLIENT1:
By default, the TMG firewall does not pass any traffic. In this step you will configure the TMG firewall with important initial configuration settings and then create a firewall rule that allows outbound traffic. Perform the following steps to configure the firewall and create the firewall rule:
When DirectAccess clients are configured for Internet access using the UAG NAT64/DNS64 services, the UAG server must be able to forward the connections to the Internet. This requires that UAG1 be configured with a default gateway that provides a route to the Internet. The default gateway for UAG1 is the Internet subnet interface on INET1. DC1 needs a gateway to the Internet in order to resolve Internet host names for the UAG server’s DNS64 service and for the web proxy service on TMG1. DC1 will use TMG1 as its gateway to the Internet.
The following operations are performed to configure UAG1 and DC1:
A. Configure the Default Gateway on UAG1. In this step you will configure UAG1 to use the Internet subnet interface on INET1 as its default gateway.
B. Configure the Default Gateway on DC1. In this step you will configure DC1 to use the Corpnet subnet interface on TMG1 as its default gateway.
Perform the following steps to configure the default gateway on UAG1:
Perform the following steps to configure the default gateway on DC1:
When DirectAccess clients are configured to use Force Tunneling, they are not able to reach the Internet except through the DirectAccess tunnel. There are two methods available for providing the Force Tunneling DirectAccess client access to the Internet: web proxy and NAT64/DNS64. In this step you will configure Force Tunneling on the UAG DirectAccess server so that Internet access is provided by the web proxy on TMG1. Perform the following steps to configure Force Tunneling and web proxy Internet access:
In this step you will update the Group Policy settings on CLIENT1 so that it uses Force Tunneling when acting as a DirectAccess client. You will then move CLIENT1 to the Homenet subnet to test the force tunneling configuration. After CLIENT1 connects to the Internet, you will review the log file entries on TMG1 to prove that the Internet connection was make through the web proxy.
The following operations configure CLIENT1:
A. Update Group Policy on CLIENT1. CLIENT1 needs updated Group Policy to enable Force Tunneling. In this step you will update Group Policy on CLIENT1.
B. Test Internet Access from CLIENT1 when Connected to Homenet. In this step you will move CLIENT1 to the Homenet subnet and test DirectAccess and Internet connectivity using Force Tunneling.
C. View CLIENT1 Internet Activity in TMG1 Log Files. In this step you will review the log file on TMG1 to confirm that CLIENT1 accessed the Internet through the TMG1 web proxy.
Perform the following steps to update Group Policy on CLIENT1:
In this step, you will connect CLIENT1 to the Homenet subnet and test Internet access across the DirectAccess tunnel through the web proxy on TMG1. Perform the following steps to test Internet access from the CLIENT1 DirectAccess client:
To demonstrate that the web connections were made over the web proxy on TMG1, we will look at the log file on the TMG1 computer or virtual machine. Perform the following steps to view the log file:
The second method DirectAccess clients configured for Force Tunneling can use to access the Internet is by using the NAT64/DNS64 service. When you use the UAG NAT64/DNS64 service, the connection is routed to the Internet by the UAG DirectAccess server. Perform the following steps to configure Force Tunneling to enable DirectAccess client access to the Internet through the NAT64/DNS64 services:
In this step you will update the Group Policy settings on CLIENT1 so that it uses Force Tunneling when acting as a DirectAccess client. After CLIENT1 connects to the Internet, you will review the log file entries on TMG1 to prove that the Internet connection was make through the web proxy.
A. Update Group Policy on CLIENT1. CLIENT1 is currently connected to the Homenet subnet. You will update Group Policy over the DirectAccess connection.
B. Test Internet Access from CLIENT1 when Connected to Homenet. In this step you will test Internet access from CLIENT1 through the UAG NAT64/DNS64 services.
C. View CLIENT1 Internet Activity in UAG1 TMG Log Files. In this step you will view the TMG log files on UAG1 to demonstrate that Internet connectivity is provided through UAG1.
Perform the following steps to test Internet access from CLIENT1 to the Internet:
Perform the following steps to view the TMG log file on the UAG1 machine:
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 procedures to configure the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess on which this document is based, see the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.
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.
I’m happy to announce the release of the latest UAG DirectAccess Test Lab Guide – Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess Force Tunneling, which you can download now at http://go.microsoft.com/fwlink/?LinkId=205454
I found this Test Guide to be especially interesting to put together. If you haven’t heard of Force Tunneling – here’s a little background.
By default, when you configure DirectAccess clients (both Windows DirectAccess and UAG DirectAccess), connections to the intranet are sent through the DirectAccess IPsec tunnels. Connections to Internet resources are sent directly to the Internet servers. This means there are two active paths: one path (the DirectAccess IPsec tunnels) carries traffic to and from the intranet, and a second path, for everything else (including Internet access). If this seems familiar to you, then you’re probably right – this configuration is sometimes referred to as “split tunneling”.
Now, split tunneling has a bit of a history behind it and like all issues that have a history, there are many people who might carry the historical baggage with them. Split tunneling had been considered in the past to be a potential security issue for remote access VPN client connections, and that’s where the idea of split tunneling got it’s checkered reputation. Because of this, many firms will not allow split tunneling. However, this attitude is slowly changing, as we’ve found that about half of enterprises now allow split tunneling for their remote access VPN client connections.
For more information on split tunneling issues, check out my articles:
Why Split Tunneling is not a Security Issue with DirectAccess http://blogs.technet.com/b/tomshinder/archive/2010/03/02/why-split-tunneling-is-not-a-security-issue-with-directaccess.aspx
More on DirectAccess Split Tunneling and Force Tunneling http://blogs.technet.com/b/tomshinder/archive/2010/03/30/more-on-directaccess-split-tunneling-and-force-tunneling.aspx
Although we don’t consider split tunneling to introduce security issues when compared to non-split tunneling configurations, many organizations still do. For that reason, we’ve made it possible to disable split tunneling for DirectAccess clients, using a configuration that we refer to as “Force Tunneling”. When Force Tunneling is enabled, all traffic is sent over the DirectAccess IPsec tunnels, so that both intranet bound and Internet bound traffic is sent over the DirectAccess tunnels. While this will exact a performance toll on the DirectAccess server, it does enable you to force all traffic over the DirectAccess connections.
So what happens to the Internet bound traffic after it goes over the DirectAccess tunnels? UAG SP1 provides you two options:
In the Test Lab Guide I go over both of these configuration options. When testing access through a web proxy, you’ll be using TMG 2010 as the web proxy provider.
I hope you like this Test Lab Guide! Let me know if there’s anything that you think I should add to it, or if there are some other configuration options you’d like to have included to make it more comprehensive. If you have problems with this Test Lab Guide, or any other Test Lab Guide, let me know! Just write to the email address in my sig line and I’ll get right back to you.
For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess with NAP check out:
Network Access Protection (NAP), built into Windows Server 2008 R2 and Windows 7, enforces health requirements by monitoring and assessing the health of client computers when they attempt to connect or communicate on a network. Client computers that are not in compliance with system health requirements can be provided with restricted network access until their configuration is updated and brought into compliance.
Combining DirectAccess with NAP allows you to verify that DirectAccess client computers meet your system health requirements before allowing access to the intranet.
To learn more about NAP, see the Network Access Protection Product Information Web site.
UAG DirectAccess SP1 RC enables you to deploy DirectAccess and NAP in two different ways. You can deploy a NAP infrastructure on your intranet that can be used by all systems on your network where the NAP infrastructure components are installed on one or more servers on your intranet. This option was available prior to UAG DirectAccess SP1 RC. A new option available with UAG DirectAccess SP1 RC is the ability to host the NAP server (Network Policy Server) and the Health Registration Authority on the UAG servers themselves. This option is useful if you don’t already have an established NAP deployment and want to focus your NAP design on DirectAccess clients only. We will enable the new NAP option in this Test Lab Guide.
This guide provides step-by-step instructions for configuring UAG DirectAccess SP1 RC with NAP in a test lab so that you can see how it works. You will set up and deploy UAG DirectAccess SP1 RC using five server computers, two client computers, Windows Server 2008 R2 Enterprise edition, and Windows 7 Ultimate Edition. The Test Lab simulates intranet, Internet, and a home networks, and demonstrates Forefront UAG DirectAccess with NAP. The starting point for this paper is the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess .
This Test Lab Guide demonstrates UAG DirectAccess SP1 RC with NAP in full enforcement mode where the UAG DirectAccess SP1 RC server requires health certificates for authentication to access resources through the intranet tunnel. Noncompliant UAG DirectAccess SP1 RC clients cannot access the intranet and cannot use their computer certificate for authentication of the intranet tunnel.
Attempting to adapt this test lab configuration to a pilot or production deployment can result in configuration or functionality issues. To ensure proper configuration and operation of UAG DirectAccess with NAP for your pilot or production DirectAccess deployment, use the information in Planning Forefront UAG DirectAccess with Network Access Protection (NAP) for your planning and design decisions and Forefront UAG DirectAccess Deployment Guide for the steps to configure the UAG DirectAccess server and supporting infrastructure servers.
The following sections describe how to configure UAG1, APP1 and CLIENT1 for UAG DirectAccess SP1 RC with NAP. After UAG1, APP1 and CLIENT1 are configured, this guide provides steps for demonstrating NAP functionality for CLIENT1 when it is connected to the Homenet subnet.
The following procedures are performed to enable and allow you to test each of them:
· STEP 2: Install the CA Server Role on APP1. In this step you will install a subordinate Certification Authority on APP1 so that it will be able to create health certificates for DirectAccess NAP clients.
· STEP 3: Configure the Subordinate CA and CA Permissions on APP1. In this step you will configure the subordinate CA on APP1 so that it will automatically grant certificates when requested by the UAG1, which is configured as a Health Registration Authority. You will also configure permissions on the CA to enable UAG1 to issue and manage certificates, manage the CA and request certificates.
· STEP 4: Configure UAG1 as an NPS Server and NAP health Registration Authority (HRA). In this step you will reconfigure the DirectAccess settings on UAG1 to support NAP policy enforcement for DirectAccess clients. After you complete this step, UAG1 will be configured as a Network Policy Server that provides NAP server functionality, as well as a Health Registration Server (HRA).
· STEP 5: Verify NAP Configuration on CLIENT1. In this step you will confirm that CLIENT1 received the Group Policy settings required for NAP clients and confirm that CLIENT1 received a health certificate from UAG1.
· STEP 6: Install Microsoft Security Essentials on CLIENT1. In this step you will connect CLIENT1 to a live portion or your network so that it can download and install Microsoft Security Essentials.
· STEP 7: Confirm that CLIENT1 Passes NAP Evaluation. In this step you will move CLIENT1 to the Homenet subnet and confirm that CLIENT1 can pass NAP evaluation and access resources on the intranet through the intranet tunnel.
· STEP 8: Confirm that CLIENT1 cannot access the Intranet Tunnel when NAP Non-Compliant. In this step you will confirm that when CLIENT1 does not meet health requirements it will not be able to connect to resources through the DirectAccess intranet tunnel.
· Step 9: Snapshot the configuration. After completing the Test Lab, take a snapshot of the working UAG DirectAccess with NAP Test Lab 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 DirectAccess with NAP. If you have already completed the steps in that Test Lab Guide and saved a snapshot or disk image of the Test Lab, you can restore the snapshot or image and begin with the next step.
In this step you will install a subordinate Certification Authority on APP1 so that it will be able to create health certificates requested by the Health Registration Authority (HRA) on UAG1 for DirectAccess NAP clients.
In this step you will configure the subordinate CA on APP1 so that it will automatically grant certificates when requested by UAG1. You will also configure permissions on the CA to enable UAG1 to issue and manage certificates, manage the CA and request certificates.
8. In the console tree of the Certification Authority snap-in, right-click corp-APP1-SubCA, and then click Properties.
9. Click the Security tab, and then click Add.
10. Click Object Types, select Computers, and then click OK.
11. Type DC1, and then click OK.
12. Click DC1, select the Issue and Manage Certificates, Manage CA, and Request Certificates check boxes under Allow, and then click OK.
13. Close the Certification Authority console
In this step you will reconfigure the DirectAccess settings on UAG1 to support NAP policy enforcement for DirectAccess clients. After you complete this step, UAG1 will be configured as a Network Policy Server that provides NAP server functionality, as well as a Health Registration Server (HRA). In addition the Connection Security Rule on the UAG DirectAccess server that controls access to the intranet tunnel will require DirectAccess clients to present a health certificate to successfully authenticate.
In this step you will confirm that CLIENT1 received the Group Policy settings required for NAP clients and confirm that CLIENT1 received a health certificate from DC1.
The UAG SP1 RC DirectAccess wizard has configured the SHV on the NAP server to use the default settings. One of these settings is to require that that a healthy client have an anti-virus application installed and that it is up to date. In this step you will connect CLIENT1 to a live portion or your network so that it can download and install Microsoft Security Essentials.
In this step you will move CLIENT1 to a Homenet subnet and confirm that CLIENT1 can pass NAP evaluation and access resources on the intranet through the intranet tunnel.
In this step you will confirm that when CLIENT1 does not meet health requirements it will not be able to connect to resources through the DirectAccess intranet tunnel. In the test lab, DC1 is accessible through the infrastructure tunnel and APP1 is accessible through the intranet tunnel. When the UAG DirectAccess NAP client fails validation, it can only access resources available through the infrastructure tunnel.
This completes the UAG SP1 RC DirectAccess with NAP test lab. To save this configuration so that you can quickly return to a working UAG SP1 RC DirectAccess with NAP configuration from which you can test other DirectAccess modular TLGs, TLG extensions, or for your own experimentation and learning, do the following:
2. If your lab is based on virtual machines, save a snapshot of each virtual machine and name the snapshots TLG UAG DirectAccess SP1RC NAP. If your lab uses physical computers, create disk images to save the DirectAccess test lab configuration.
The march of the Test Lab Guides continues!
Today I’m offering up to you a Test Lab Guide I think you’re really going to like – the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess with NAP. In this Test Lab Guide, we change up the NAP settings by putting the Network Policy Server (NPS) and Health Registration Authority (HRA) on the UAG DirectAccess server itself. This is in contrast to how we did it in the previous Test Lab Guide for NAP (Test Lab Guide: Demonstrate UAG DirectAccess and NAP), where we set up the NPS server and the HRA server on DC1. The ability to put the NPS and HRA servers on the UAG server itself is new with UAG SP1.
Why would you want to put the NPS and HRA servers on the UAG server or the servers in the UAG DirectAccess array?
Some reasons why you might want to do this include:
Of course, there might be other reasons why you’d like to put the NPS and HRA servers on the UAG DirectAccess server or array members. And, you might find that you like NAP so much that after you’ve deployed it for your DirectAccess clients, you’ll want to create a larger deployment. That option is still available to you.
I hope you like the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess with NAP!
Let me know if there is anything I can do to improve it – or if there are other features or configuration options regarding DirectAccess and NAP that you’ll want to see in the RTM version of the document. Also, if you want any questions or need help with the TLG, just let me know! Write to me at the address in my sig line and I’ll get right back to you.
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.
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 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.
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:
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 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 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.
===================================
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.
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.
· 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.
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.
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 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.
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.
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.