Here you go:
Answer to Question 1:
When the DirectAccess client connects to the UAG DirectAccess server, it establishes two IPsec tunnels – the infrastructure tunnel and the intranet tunnel. All traffic destined to the intranet travels through these two IPsec tunnels with the exception of what type of traffic?
D. SIP (Session Initiation Protocol)
The answer to Question 1 is A.
From http://social.technet.microsoft.com/wiki/contents/articles/directaccess-forcing-encryption-for-icmpv6-traffic.aspx (DirectAccess: Forcing Encryption for ICMPv6 Traffic on the TechNet wiki):
“…By default, the DirectAccess Setup Wizard creates Group Policy objects for DirectAccess clients and servers for settings that allow the following behaviors:
- Internet Control Message Protocol (ICMP) traffic, for both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6), is exempted from Internet Protocol security (IPsec) protection
- Teredo discovery traffic does not travel within the IPsec tunnels between DirectAccess clients and servers on the intranet…”
The trick here is in the question: “All traffic destined to the intranet travels….” The DirectAccess client only understands IPv6 and therefore does not send any ICMPv4 traffic to the intranet – only ICMPv6 traffic can be sent from the DirectAccess client to the intranet. Therefore, B cannot be true because ICMPv4 is never destined for the intranet. DCOM and SIP traffic are treated like any other non-ICMP traffic and both protocols are always sent through an IPsec tunnel when destined for the intranet.
A DirectAccess client is connecting from behind a home NAT device to a UAG DirectAccess server. The user calls the Help Desk and says that he isn’t able to connect to anything on the intranet. You tell the user to open a command prompt and ping the name of a domain controller and the ping succeeds. Then you tell the user to ping the name of a file server and that ping succeeds. Next, you tell the user to ping the name of a web server and that ping succeeds. Then you tell the user to use the net use command to connect to a share on the file server and that fails. Next you tell the user to connect to a share on the domain controller and that attempt is successful. Finally, you tell the user to connect to the web server and that connection attempt fails.
What is the most likely reason for this user’s failure to connect to the resources he needs?
A. The Internet Service Provider is blocking IP Protocol 41
B. Kerberos authentication is failing
C. NTLMv2 authentication is failing
D. The DirectAccess client doesn’t trust the UAG server’s computer certificate
The answer to Question 2 is B.
Let’s look at what’s happening here:
- User says that he can’t connect to “anything” on the intranet. We know what that actually means – it means the user can’t connect to the stuff that he is interested in – as for the rest of the intranet, we don’t really know.
- The ping to the domain controller succeeds. This tells use that IPv6 transition technology and DNS64 on the UAG DirectAccess server is working. It doesn’t tell us much more than that.
- The ping to the file server is working. Again, this really only tells us that the IPv6 transition technology is working and that name resolution is working (well, it also tells us that the path to the file server is intact)
- Again, the ping to web server tells us that the IPv6 transition technology is working and that name resolution is working and the path to the web server is intact
- When the user tries to net use to the file server, it will use a non-ICMP protocol to do this. In order to use a non-ICMP protocol, the connection has to go over an IPsec tunnel. Since the file server is unlikely to be a management server, the DirectAccess client will need to connect to the file server using the intranet tunnel. The intranet tunnel requires both machine certificate and user (Kerberos V5) authentication. So, the problem might be with the certificate or the user Kerberos V5 authentication. We don’t have enough information yet to determine which one of these might be the culprit
- When the user tries to net use to the domain controller, the connect attempt succeeds. This indicates that the user can use a non-ICMP protocol to connect to the domain controller. Since domain controllers are always included in the Management Servers list, they are accessible over the infrastructure tunnel. To establish the infrastructure tunnel connection, you need both computer certificate and NTLMv2 machine account authentication. Since net use worked, we can assume that both computer certificate and machine account NTLMv2 authentication succeeded.
- Finally, you told the user to connect to the web server. I didn’t mention how the user could connect, but let’s assume both net use and web browser. Since the web server is unlikely to be a member of the Management Servers group, it would need to use the intranet tunnel to connect to the web server. We know that computer certificate authentication is good because the client was able to establish the infrastructure tunnel, so the problem must be with the Kerberos authentication required to establish the intranet tunnel.
When we look at this analysis, it becomes clear that the answer is B – that Kerberos authentication is failing. A is not correct because IP Protocol 41 is used by 6to4 – if the client were using 6to4, then even the pings would fail as the IPv6 transition technology would have failed; in addition, the client is connecting from behind a home NAT device, so 6to4 would not be used – IP-HTTPS or Teredo would be used in a NAT scenario. We know that NTLMv2 is not failing, because the infrastructure tunnel is working. And we know that the DirectAccess client trusts the UAG server’s computer certificate, since the client was able to establish the infrastructure tunnel.
Which of the following are new features included with UAG DirectAccess Service Pack 1?
A. Wizard based configuration of the DirectAccess Connectivity Assistant (DCA)
B. Wizard based configuration of “manage only” DirectAccess client connectivity
C. Support for Smart Card Authentication
D. Support for One Time Password (OTP) Authentication
The answer to question 3 is A, B and D.
Support for Smart Card authentication was available in pre-SP1 UAG DirectAccess.
For more information on what’s new and improved with DirectAccess in UAG SP1, check out UAG 2010 SP1: The New and Improved DirectAccess Features http://blogs.technet.com/b/edgeaccessblog/archive/2010/10/27/uag-sp1-da-overview.aspx
Leaderboard for Contest 1 Round 2/Contest 2 Round 1
This quiz was a pretty tough one that required you to have a pretty good understanding of the IPv6 transition technologies and authentication for DirectAccess IPsec tunnels. In the next quiz we’ll go more into IPv6 related questions to test some of your IPv6 chops.
The next quiz will be posted late in the day on Thursday, January 13, 2011.
See you then!
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: https://twitter.com/tshinder
Visit the TechNet forums to discuss all your UAG DirectAccess issues
Stay up-to-date with “just in time” UAG DirectAccess information on the TechNet wiki http://social.technet.microsoft.com/wiki/tags/DirectAccess/default.aspx