Yay! This is the end of round 1. Remember, each of two rounds in the contest have four quizzes – and this is the fourth quiz of round one.
Let’s first get to the answers for Quiz 4 and then we’ll look at the leaderboard and the assignment of points for the round.
===========================================
Question 1: When a DirectAccess client is directly connected to the Internet and is assigned a public IP address, the only IPv6 transition technology the DirectAccess client can use to connect to the UAG DirectAccess server is 6to4. A. True B. False
The answer to question 1 is B.
A DirectAccess client can use one of three IPv6 transition technologies to tunnel IPv6 messages over an IPv4 Internet. You have probably read that when the DirectAccess client is on the Internet and assigned a public IP address, it will use 6to4 as its IPv6 transition technology. While that is true, that doesn’t mean that the DirectAccess client is limited to using 6to4 when assigned a public IP address. While the algorithm for determining which IPv6 transition technology will be used at any point in time, when the DirectAccess client is assigned a public IP address it will try to activate its 6to4 adapter. However, if the 6to4 adapter fails to initiate, the DirectAccess client can attempt to enable its Teredo or IP-HTTPS adapters. Several people have noticed that when a DirectAccess client is connected to some wireless carriers, the 6to4 adapter fails to start and Teredo is used in its place. While we’re not sure what the root cause of this situation is in all instances, there is a chance that the wireless carriers are blocking IP Protocol 41 somewhere between the DirectAccess client and DirectAccess server.
You can find more information on how the DirectAccess client choose an IPv6 transition technology to use at http://blogs.technet.com/b/edgeaccessblog/archive/2010/05/09/the-mystery-of-the-ip-https-listener-an-outlook-client-and-an-ipv4-only-network.aspx
Question 2: Which of the following UAG DirectAccess component technologies require certificates and PKI? A. IP-HTTPS Listener B. Infrastructure tunnel C. Intranet tunnel D. Network Location Server E. Client authentication for IP-HTTPS F. All of the above G. None of the above
The answer to question 2 is F.
Certificates and PKI are used in a number of places in the DirectAccess solution architecture. The IP-HTTPS listener requires a certificate bound to it so that an SSL session can be established between the DirectAccess client and server.
The infrastructure tunnel is an IPsec tunnel that allows the DirectAccess client access to management servers on the intranet. The intranet tunnel is an IPsec tunnel that allows the DirectAccess client access to all other resources on the intranet. Both IPsec tunnels require that the DirectAccess client and DirectAccess server have computer certificates to enable both authentication and encryption for both of the IPsec tunnels.
The Network Location Server is used to help the DirectAccess client determine if it is currently on or off the intranet. If the DirectAccess client can establish an HTTPS connection to the Network Location Server, the Name Resolution Policy Table will be disabled and the DirectAccess client will use the DNS server configured on its local NIC for name resolution. A certificate is required on the Network Location Server’s web site so that the SSL session can be established.
When a DirectAccess client uses IP-HTTPS to connect to the DirectAccess server, the DirectAccess client uses client certificate authentication to authenticate itself before successful establishment of the IP-HTTPS tunnel. In the case of IP-HTTPS, certificates are used by the IP-HTTPS listener and by the client to authenticate before the IP-HTTPS tunnel is established.
Question 3: In order to support DirectAccess client access to the intranet tunnel using NAP, you must deploy at least one Windows-based CA. A. True B. False
The answer to question 3 is A.
When the DirectAccess client starts, it automatically negotiates the infrastructure DirectAccess tunnel. The infrastructure tunnel enables the DirectAccess client access to key management servers on the intranet, such as domain controllers, DNS servers, and management servers that are used by IT to command and control DirectAccess clients. The second DirectAccess tunnel, called the intranet tunnel, allows the DirectAccess client to connect to all other resources on the intranet. Normally, the DirectAccess client uses computer certificate authentication and Kerberos (user) authentication to start the intranet tunnel.
However, you can improve the level of security applied to enabling the intranet tunnel by requiring the DirectAccess client to pass NAP inspection. However, in order to deploy NAP-based access control over the intranet tunnel, you must have at least one Windows-based CA on the intranet to support NAP.
For more information on DirectAccess with NAP requirements, check out http://technet.microsoft.com/en-us/library/gg315299.aspx
Here are the results of Round 1:
Winner – christophf (5 points)
2nd – mika (3 points) jasonj (3 points) oblaba (3 points)
3rd - olivier (1 point)
Point assignment is based on the rules described on Quiz 1 Round 1 at http://blogs.technet.com/b/tomshinder/archive/2010/12/02/uag-sp1-directaccess-contest-quiz-one-round-one.aspx
Next week we begin Round 2. There will be 4 quizzes in Round 2.
Now for those of you who think you’re out of the running – don’t give up! Even if you’re mathematically out of the running for this contest (which ends with the end of round 2), there will be another contest where round 2 of this contest (which starts with the next quiz) will be round 1 of contest 2! So – keep playing!
Tom Shinder tomsh@microsoft.com Principal 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
(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 4 Round 1!
This is the last quiz in Round 1. If you’re in front, make sure you don’t miss this one – and if you’re playing catch up, it’s even more important, as I suspect some of the leaders will miss today’s quiz because of Christmas, which give you a chance to move ahead.
Now for the questions!
There you go! I know you’re all busy this week and next, so the questions are short and sweet.
Now send your answers to me at (make sure to use this link since it contains the subject line I need):
tomsh@microsoft.com
Send your entries until 9AM Central Standard Time (-0600 UTC) on Monday December 27th.
Good luck!
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
You’ve deployed DirectAccess on your network as a pilot project for your IT group over the holidays and everything is working great. When the users are behind a wide open NAT device, they use Teredo to connect to the UAG DirectAccess server. When they’re behind a port-restricted firewall or web proxy only, then they fall back to IP-HTTPS. Of course, you’d prefer that they use Teredo because it’s better performance. But IP-HTTPS connectivity is better than no connectivity at all.
Then it happens – the unthinkable!
Performance seems to slow down. You do an ipconfig and find that the Teredo interface isn’t starting up and only IP-HTTPS is being used. You move the client around, first behind a wide open NAT device and nothing changes. Then you disable the 6to4 interface and connect the client directly to the Internet. Still, only the IP-HTTPS interface comes up.
What’s up with that?
Here are some hints:
First, check out http://blogs.technet.com/b/edgeaccessblog/archive/2010/05/09/the-mystery-of-the-ip-https-listener-an-outlook-client-and-an-ipv4-only-network.aspx
Next, check out the graphic below:
Finally, check Ben Lee’s blog where he puts all the pieces together to come up with a solution over at http://www.bibble-it.com/2010/12/19/uag-directaccess-only-connects-via-ip-https
HTH,
Tom
Happy Holidays guys! We got a great response to this weeks quiz and added some new contestants. That’s great! Even with the busy holiday it’s cool to see you all interested in playing and learning more about UAG DirectAccess.
Now for the answers:
Question 1: You must be running IPv6 on your corporate network in order to deploy a UAG DirectAccess server that enables DirectAccess clients to connect to intranet resources from virtually anywhere. A. True B. False
The answer to Question 1 is B. When you use the UAG DirectAccess server solution, there are no IPv6 dependencies for resources on the intranet. Because the UAG DirectAccess server includes the NAT64/DNS64 service, all the machines behind the UAG DirectAccess server can be IPv4-only operating systems. When you use the UAG DirectAccess server, the only machine that needs to be Windows Server 2008 R2 on the network is the UAG DirectAccess server. Note that when you use an IPv4-only network behind the UAG DirectAccess server, you will not be able to take advantage of a full “manage-out” deployment. In a full “manage-out” deployment, hosts on the intranet can initiate connections to DirectAccess clients. IPv4-only hosts cannot initiate connections from DirectAccess clients, but DirectAccess clients can initiate connections to IPv4-only hosts on the intranet.
Question 2: You have installed UAG RTM and you want to begin the configuration of the DirectAccess feature. The UAG Management console opens and you are able to see the information on all nodes except for the DirectAccess node in the left pane of the console. When you click on the DirectAccess node in the left pane of the console, you see the following error dialog box:
(Cannot Load the DirectAccess view (0).)
What is a possible cause of this problem? A. The NetBIOS name of the UAG server contains more than 15 characters B. In order to configure DirectAccess, you must first install UAG Update 1 C. The DirectAccess server is a member of a Windows Server 2003 domain D. A firewall behind the UAG server is blocking the SNA (TCP/UDP 108) protocol
The answer to Question 2 is A. This is an interesting problem that was discovered by Shannon Fritz, which he shared on the TechNet forums and discusses in his blog post over at http://blog.concurrency.com/infrastructure/uag-cannot-load-the-directaccess-view-0/ The solution was to rename the machine so that the host name portion of the FQDN was 15 characters or less.
=========================================== Question 3: A UAG DirectAccess server must be a domain member. However, the UAG DirectAccess server does not need to be a member of the same forest or domain as the resources that DirectAccess users will connect to. What Active Directory domain functional level is required for the domain that the UAG DirectAccess server belongs to for DirectAccess to work correctly? A. Windows Server 2008 R2 B. Windows Server 2008 C. Windows Server 2003 D. None of the above
The answer to Question 3 is D. This is a tricky question. Many of you answered C because you might have read that Windows Server 2003 domain functional level is the minimum domain functional level. I can’t confirm or deny that is true, since it’s not documented anywhere and I suspect that no testing was done with Windows 2000 Server domain functional level. However, regardless of what the minimal domain functional level might be, the question asked which was required. Because you can use any of these domain functional levels in answers A, B and C, none of them are required – you can use any one of them. This makes answer D the correct answer.
The race remains pretty close as we enter into the last quiz of the first round. Six contestants are within two points for the lead. Also, note that the zeros you see in the results are due to contestants that didn’t send an entry for that quiz – no one has scored a zero on any of their entries. The blue highlighting on the cell indicates that no entry was received. But you can see that a few of the new entrants have some strong performances and could end up in the top three if any of those near the top decide to take a Christmas vacation for Quiz 4 .
I want to thank everyone who participated in Quiz 3, Round 1. Quiz 4 and the last quiz in Round 1 will be posted on December 23, 2010 – so make sure you put that on your calendar so you don’t miss the quiz because if you do, someone behind you might sneak up and take your position! But even if you don’t end up in the top three, you’ll learn a lot and remember more when you have some “skin in the game”. And then there’s always Round 2. See you then!
Thanks!
Test Lab Guides provide a method for you to try out a new product or technology and see how it works in your own test lab. When you use Test Lab Guides you see all the working parts, all the front-end and back-end components, and most importantly, see how that all work together to create a working solution.
Test Lab Guides enable you to get your hands on each configuration setting for simple to extremely complex scenarios. In fact, I’m working on a Test Lab Guide now that will require 10 virtual machines – but provides a demonstration of a very complex multi-site deployment of UAG DirectAccess using a single ISATAP cloud to enable multi-point access to the intranet. You’ll see what it looks like in about two weeks.
There are three types of Test Lab Guides:
The following troubleshooting TLGs are available:
The Troubleshooting Test Lab Guides are actually based on a working configuration that you have already created when you did one of the “Demonstrating” Test Lab Guides.
For example, the Test Lab Guide: Troubleshoot UAG DirectAccess is based on the completion of another Test Lab Guide called Test Lab Guide: Demonstrate UAG DirectAccess. In the troubleshooting Test Lab Guide you begin with a working configuration and then break stuff on purpose (we give you instructions on what to break, in what we call “Break-Me’s). After you break the stuff, you use a variety of troubleshooting tools and techniques to troubleshoot the broken configuration.
For an example of how “Break-me’s” work, check out this video.
The goal of the Troubleshooting Test Lab Guides is to show you what tools are available to troubleshoot the product, technology or scenario and what their output looks like when things are working right, and then what the output looks like when things aren’t working (because you’ve broken it on purpose).
We have received various feedback regarding the “Troubleshooting” guides and we would like to get input from the community on whether or not you find this approach valuable and if we should continue investing in the troubleshooting guides. Of course, we think the Troubleshooting Test Lab Guides are a great idea because you get hands-on experience with the troubleshooting tools and some insight into what things should look like and what they might look like when they’re broken. In the guides we try to focus on the most common troubleshooting scenarios so that you get the most “bang for your buck”.
What do you think? Are the troubleshooting Test Lab Guides valuable to you? Would you like to have more troubleshooting Test Lab Guides? Is there something missing from the current approach to Troubleshooting Test Lab Guides that would make them more useful for you?
Let us know! You can write to me at tomsh@microsoft.com and let me know what you think about the Troubleshooting Test Lab Guides or you can write your thoughts and ideas about Troubleshooting Test Lab Guides in the comments section below. I do subscribe to the RSS feed for the comments section, so I’ll know when you’ve posted a comment and I’ll acknowledge your input and address your issues.
Thanks for the help!
It’s time for Quiz 3-Round 1!
Send your entries until 9AM Central Standard Time (-0600 UTC) on Monday December 20th.
The scores are really close and at this point, anyone can end up winning Round 1. So make sure to send your answers in this week and next week.
The questions in Quiz 1 and Quiz 2 were pretty tough – so I hope you find these a bit easier. So far everyone is doing great and learning a lot! If you know any UAG DirectAccess admins, let them know about the contest so that they play too. Even though they might not win the first round (winner of the first four quizzes), remember there is a second round. So it’s possible to win by cleaning up in the second round. And they can join in on the fun of taking the quizzes and learning from the answers.
When the contest is over I’d like to put together a LiveMeeting and talk about the contest and if the winner is willing to be interviewed, take the opportunity to interview the winner and get his or her thoughts on UAG DirectAccess.
Troubleshooting is always a challenging topic. Challenging from the point of view of the person who has to do the troubleshooting, and challenging to the product group who wants to provide valuable troubleshooting information so that you can solve your troubleshooting issues.
Because information on troubleshooting is so dynamic, we need a way to share information on what we learn about troubleshooting as soon as possible. For this reason, we’ve decided to publish UAG DirectAccess troubleshooting information to the TechNet wiki. With the TechNet wiki, we can provide you “just in time” information about how to troubleshoot problems you might encounter with UAG DirectAccess.
And even more important, if you find that you have a valuable troubleshooting information that will help other UAG DirectAccess admins, you can share that information on the TechNet wiki!
As we begin this effort, we’ve created a main UAG DirectAccess troubleshooting page – Forefront UAG DirectAccess Troubleshooting. On this page you will find useful links to UAG DirectAccess troubleshooting content. Right now, you’ll find links to the following wiki docs:
The great utility of the wiki is that if you find other UAG DirectAccess troubleshooting information, you can add to this list – as another logged onto the wiki can edit and enhance the content. Make sure to add the RSS feed for this page so that you receive automatic updates when this troubleshooting page is updated.
Here are the answers to Quiz 2, Round 1:
====================================================
Question 1: You have installed UAG Service Pack 1 and find that you are unable to connect to resources on the intranet using fully qualified domain names. What is the most likely reason for this failure?
A. The ISATAP adapter on the DirectAccess client failed to start B. The Teredo interface on the UAG DirectAccess server failed to start C. The DNS64 service failed to start D. The IP-HTTPS certificate needs to be renewed
The answer to Question 1 is C. The DNS64 service is used by the UAG DirectAccess server to resolve names on behalf of DirectAccess clients. Although we often talk about DNS64 as providing name resolution support for IPv4 only hosts in conjunction with it’s integration with NAT64, the DNS64 service also provides what you can consider to be a “DNS proxy” to support UAG DirectAccess client name resolution. If you perform a netsh name show eff command on a UAG DirectAccess client, you will see something similar to what appears in the figure below. Notice the DirectAccess (DNS Servers) setting for Settings for .corp.contoso.com. This address is the 6to4 address of the UAG DirectAccess server. When the DNS64 service receives the name query request from the DirectAccess client, it forwards the query to the DNS servers configured on the internal interface of the UAG DirectAccess server and then it receives and caches the DNS server responses before returning the results to the DirectAccess client.
It now should make sense that if the DNS64 services does not start, intranet name resolution for DirectAccess clients will fail. However, why did the DNS64 service fail to start? If you check the UAG Service Pack 1 Release Notes (http://technet.microsoft.com/en-us/library/gg315322.aspx) You will see the following:
“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.”
This explains why the DNS64 service failed to start. After applying UAG SP1, you will need to manually configure the DNS64 service to start automatically. Jason Jones provides some information on how to do this on his blog at http://blog.msedge.org.uk/2010/12/microsoft-forefront-uag-dns64-service.html
Answer A is incorrect because the ISATAP adapter on the DirectAccess client isn’t used to connect to the intranet through the DirectAccess tunnels. Answer B is incorrect because if the Teredo adapter failed to start, the IP-HTTPS adapter could enable connectivity – recall that only name resolution is affected, which suggests that connectivity through an IP address was still available. Answer D is incorrect because the IP-HTTPS listener’s certificate status would not have selective effects on name resolution.
Question 2: A Help Desk professional is trying to provide assistance to a DirectAccess user who is connected to the intranet from a hotel on another continent. The DirectAccess connection is working for the user and the user is able to connect to all required resources on the intranet. However, the user is having problems with some editing software and would like the Help Desk Professional to take a look at her system. When the Help Desk Professional tries to RDP into the user’s computer, the connection attempt fails. What is the most likely reason for the connection failure?
A. A Windows Firewall rule on the client exists for inbound RDP with Edge Traversal enabled B. The Help Desk Professional is connecting from a Windows 2000 Workstation Computer C. The hotel where the user is staying blocks outbound RDP connections D. The user is connecting to the UAG DirectAccess server using IP-HTTPS
The answer to Question 2 is B. In this scenario the Help Desk professional is trying to establish a connection from the intranet to the DirectAccess client on the Internet. This is what we often refer to as a “manage out” scenario. In order for hosts on the intranet to initiate connections to DirectAccess clients on the Internet, there must be a Windows Firewall with Advanced Security Firewall Rule in place on the DirectAccess client to support that connection.
In addition, if the DirectAccess client is using Teredo or IP-HTTPS, the the Firewall Rule will need to have Edge Traversal enabled (because these protocols will be used when the DirectAccess client is located behind a NAT device). You can find more information about Edge Traversal and DirectAccess clients at http://technet.microsoft.com/en-us/library/gg315320.aspx In addition to a Firewall Rule that allows the desired protocol inbound to the UAG DirectAccess client with Edge Traversal enabled, the system on the intranet that’s initiating the connection must be an IPv6 capable machine that is able to consume the IPv6 AAAA resource record returned in a name query for the DirectAccess client (and the system must be assigned an IPv6 address, either through native IPv6 addressing or via ISATAP). Since the Help Desk Professional is using Windows 2000 Workstation, the system is not IPv6 capable and therefore the Help Desk Professional will not be able to initiate a connection to the DirectAccess client.
Answer A is incorrect because we do need a firewall rule on the client to support inbound RDP with Edge Traversal enabled. Answer C is incorrect because all communications in this scenario are taking place over the IPsec tunnels used by DirectAccess – which means the firewalls are actually only seeing the IPv6 transition technology headers (most likely Teredo or IP-HTTPS). Answer D is incorrect because “manage out” scenarios are supported for all IPv6 transition technologies the DirectAccess client might use when connecting to the UAG Direct Access server.
Question 3: A UAG DirectAccess server benefits from being placed behind a front-end firewall in order to reduce the firewall filtering load on the TMG server that is also installed on the UAG server. Which of the following protocol(s) is/are not required through the front-end firewall to the UAG DirectAccess server when the server is connected to an IPv4 Internet? (Choose all that apply):
A. IP Protocol 50 B. UDP Port 3544 C. TCP Port 443 D. IP Protocol 41
The answer to Question 3 is A. The question asks which protocol(s) are NOT required access through the front-end firewall to the UAG DirectAccess server when the server is connected to the IPv4 Internet. UDP Port 3544 inbound and outbound to and from the UAG DirectAccess server is required to support Teredo. TCP port 443 is required to and from the UAG DirectAccess server to support IP-HTTPS, and IP Protocol 41 is required to and from the UAG DirectAccess server to support 6to4. Teredo, IP-HTTPS and 6to4 are IPv6 transition technologies that allow the DirectAccess client to tunnel IPv6 messages over the IPv4 Internet.
In contrast, when the UAG DirectAccess server is connected to the IPv6 Internet. there is no need to support the IPv6 transition technologies and the DirectAccess client won’t be tunneling their IPv6 messages inside of these protocols. Instead, the DirectAccess clients will establish IPsec connections to the UAG DirectAccess server directly – these IPsec connections won’t be encapsulated by the IPv6 transition protocol headers because there is no need for them. In this scenario, the front-end firewall needs to allow IP Protocol 50 (ESP) inbound and outbound to and from the UAG DirectAccess server, and UDP port 500 (IKE) inbound and outbound to and from the UAG DirectAccess server. In addition, ICMPv6 inbound and outbound to and from the UAG DirectAccess is also required, because by default, ICMP messages are not encapsulated by IPsec.
Therefore, the answer to the question is A since it is NOT required when the UAG DirectAccess server is connected to an IPv4 Internet.
You an find more information on firewall configuration requirements for the UAG DirectAccess server over at http://technet.microsoft.com/en-us/library/dd857262.aspx
Looks like we have a real horse race going right now! Six contestants are within one point of each other, and eight are within three points of each other. I should note that all the “zero” point results are because the contestant didn’t send an entry for that quiz. No contestant has actually actually submitted an entry where none of the answers were correct. Also, its not too late to come from behind and win! If the leaders fail to submit an entry, or get the questions wrong, you can still circle the field and run in-the-money for round 1.
I want to thank everyone who participated in Quiz 2, Round 1. This was another tough one! 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 3, Round 1 will be posted on December 16, 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 2 you still have a chance – so make sure to take next week’s quiz and get yourself on the leaderboard! And even if you don’t win, you’ll learn a lot and remember more when you have some “skin in the game”. See you then!
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.
There you go! Now click the following link (which will populate the subject line on the email message) to email me your answers:
I must receive your entry by December 13, 2010 9:00 AM Central Time
Have fun and good luck!
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