Answers UAG DirectAccess Contest Quiz 2 Round 1
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 (https://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 https://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 https://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 https://technet.microsoft.com/en-us/library/dd857262.aspx
====================================================
Leaderboard
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!
====================================================
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): https://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: https://twitter.com/tshinder
Facebook: https://www.facebook.com/tshinder