Came across a very handy tip on the TechNet forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/8965b7de-8814-40ed-b189-37b53bb1b88b
In this thread, UAG DirectAccess Pro Ken Carvel provides a nice tip on what to do when you see the DirectAccess Monitor report that Network Security is not healthy.
Just in case that thread disappears, I’ll repost what Ken had to say here:
“I have seen this before as well and it has to do with IPSec DOS protection.
I saw that one of the servers in my array showed as Not Healthy. I ran the "netsh ipsecdosprotection show interfaces" from the command line and got an "Element not Found" error. What had happened was one of the IPv6 tunneling interfaces had changed names, like the Teredo Tunneling interface was now "Local Area Connection* 10". I'm not sure why this happens, but I have seen it on several different UAG DirectAccess servers.
What I did to fix it was run the "netsh int ipv6 show int" command and figure out the names of all of the interfaces. Then I ran "netsh ipsecdos reset" and manually added the interfaces back like this:
netsh ipsecdos add interface isatap.contoso.com internal netsh ipsecdos add interface External public netsh ipsecdos add interface "6TO4 Adapter" public netsh ipsecdos add interface IPHTTPSInterface public netsh ipsecdos add interface "Local Area Connection* 10" public”
Great tip Ken! Thanks!
HTH,
Tom
Tom Shinder tomsh@microsoft.com Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management Anywhere Access Group (AAG) The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
Visit the TechNet forums to discuss all your UAG DirectAccess issues http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads
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
I shouldn’t have to say it – but you should always enable Microsoft Update on your UAG DirectAccess servers and arrays. In the third step of the UAG Getting Started Wizard you are given the opportunity to enable Microsoft Update (and also join the Microsoft Customer Experience Improvement Program, something I highly recommend). After you complete the step and activate the configuration, you would expect that the UAG server or array is going to update itself.
The problem is that sometimes (all the time?) Microsoft Updates fail. How to fix this?
One solution is found on the UAG TechNet forum. All you need to do is open an elevated command prompt and enter:
netsh winhttp set proxy localhost:8080
and press ENTER and BAM! Microsoft updates start working.
The most likely reason for this is that the UAG server needs to be configured as a web proxy client of the TMG server running on the same machine. When you run the netsh command, the proxy configuration is set to send web requests to the web listener on the local host network (the local host network is defined as all IP addresses assigned to the TMG firewall – which is the same as all the IP addresses assigned to the UAG DirectAccess server).
This is the big day! The results are in for the last quiz in Contest 1.
First, I’ll go over the questions and answers and explain some interesting things that came up when I reviewed the answers I received, which had the effect of leading to two correct answers for one of the questions.
At the end I’ll post the “unofficial” results. The reason why they’re unofficial is that I like to wait until the next day to hear from anyone who might not have their answers scored correctly, in which case I update the leaderboard.
When the results are official on Wednesday, I’ll post the winners and the prizes (yes – there is going to be more than one prize!).
So let’s get to it!
================================================
Question 1:
Regarding Certificate Revocation List (CRL) checks, which is the following answers is true? (Choose all true answers): A. If the client certificate CRL check fails, the IPsec tunnels cannot be established B. If the server certificate CRL check fails, the IP-HTTPS tunnel cannot be established C. You must publish the private CRL Distribution Point if you use a commercial CA for your IP-HTTPS listener D. A CRL check is not performed when the DirectAccess client connects to the NLS
The answer to question 1 is B.
Answer A is incorrect because if the CRL check on the client certificate fails, the DirectAccess IPsec tunnels can be established. This is one of the reasons why revoking the computer certificate of the DirectAccess client is not the recommended way to blocking connections from potentially compromised DirectAccess clients. For more information check out http://blogs.technet.com/b/tomshinder/archive/2011/01/25/certificate-related-questions-and-test-lab-guide-guidance.aspx
Answer B is correct because the if the CRL check on the certificate bound to the IP-HTTPS listener on the UAG DirectAccess server fails, then the IP-HTTPS session establishment will fail. This is a hard coded option which is not configurable. For more information check out http://technet.microsoft.com/en-us/library/ee382307(WS.10).aspx
Answer C is incorrect because the commercial certificate provider publishes the CRL for you – there is no need for you to publish the CRL for the commercial certificate provider. The only time you would need to publish the CRL yourself is if you choose to bind a private certificate to the IP-HTTPS listener.
Answer D is incorrect because a CRL check is done when the client connects to the Network Location Server (NLS). For more information on this requirement, please see http://technet.microsoft.com/en-us/library/ee382275(WS.10).aspx ================================================
Question 2:
True or False: The DirectAccess client can use IP-HTTPS to connect to the UAG DirectAccess server when located behind an authenticating proxy where authentication is required: A. True B. False
The answer to this question is A or B.
When I wrote this question I had it in mind that the proxy would be transparently authenticating connections in the background for each new connection, like what the TMG firewall does. IP-HTTPS will not work in this scenario because there is no mechanism available to configure the IP-HTTPS client component to send credentials to the authenticating proxy.
However, there are other types of authenticating proxies that require you to authenticate you once (for example, what you see in hotels with captive portals). After you authenticate with the portal, the proxy will allow you outbound access without requiring credentials (except in the case where there is a time-out period and you have to authenticate again). Since several of your explicitly called out this scenario (the one that I didn’t think of when writing the question), I decided that both answers are correct because of the ambiguity of the question. So congrats to everyone! You all got this one right .
For more information on this issue, please see http://technet.microsoft.com/en-us/library/ee844126(WS.10).aspx
Question 3: For the default settings for end-to-end Authentication and encryption with UAG SP1, which of the following statements are true (select all true statements): A. End to End security uses IPsec tunnel mode from DA client to intranet server B. End to End security uses Authentication with null encapsulation C. End to End security authenticates only the first packet to the destination server D. End to End security uses ESP-NULL
The answer to this question is D.
Answer A is incorrect because End-to-End security uses IPsec transport mode to connect the DirectAccess client to the secure server on the intranet. IPsec tunnel mode is used to connect the DirectAccess client to the UAG DirectAccess server. For more information on this, check out http://blogs.technet.com/b/tomshinder/archive/2010/12/01/uag-directaccess-and-the-windows-firewall-with-advanced-security-things-you-should-know.aspx
Answer B is incorrect because by default, End-to-End security uses IPsec with null encapsulation, sometime referred to as ESP-NULL. This is different from Authentication with null encapsulation, when is enabled by AuthIP and available only when the secure server is Windows Server 2008 R2 – ESP-NULL is available when connecting to Windows Server 2008 and Windows Server 2008 R2. This is a configurable option. You can find more information on this at http://technet.microsoft.com/en-us/library/ee382325(WS.10).aspx and http://blogs.technet.com/b/tomshinder/archive/2010/09/12/a-short-introduction-to-uag-directaccess-end-to-end-security.aspx
Answer C is incorrect because this describes the behavior you see with IPsec Authentication with null encapsulation, which is not used by default, as discussed in the previous question.
Answer D is correct because ESP-NULL is the default method used by End-to-End security.
Question 4: Bob wants to enable a “manage out” scenario where intranet management servers can initiate connections to DirectAccess clients over the Internet. To do some basic testing, he wants the intranet management servers to be able to ping the DirectAccess client. When Bob tries to ping the DirectAccess client from the management server, the ping requests fail.
Bob checks the Firewall Rule he created to support inbound ping to the DirectAccess client and sees the following:
Figure A
Figure B
Figure C
Figure D Which of these figures most likely explains the ping failure (Pick one)?: A. Figure A B. Figure B C. Figure C D. Figure D
The answer to question 4 is D.
There isn’t a whole lot of information contained in these screenshots except for the last one.
The first screenshot (A) just tells us that the connection is allowed.
The second screenshot (B) shows that ICMPv6 is allowed, so that shouldn’t be a problem.
The third screenshot (C) shows that the connection is allowed between the DirectAccess client and the IP address of the management station. There is a possibility that this is the wrong IP address, but there is nothing in the question that indicates that maybe the wrong IP address was included in the firewall rule. I’d keep this in mind, but look for a better explanation.
The fourth screenshot (D) has the interesting information – this graphic shows that Edge Traversal is blocked. When the DirectAccess client is using either Teredo or IP-HTTPS, Edge Traversal must be enabled for protocols that you want to allow inbound to the DirectAccess client from management stations on the intranet. This is not required when the DirectAccess client is using 6to4 to connect to the DirectAccess server. For more information on this, check out http://technet.microsoft.com/en-us/library/ee649264(WS.10).aspx (note that IP-HTTPS isn’t called out, but if you perform your own test, you’ll see that it is required for IP-HTTPS as well). While we don’t know for sure that the client isn’t using 6to4, it is the most likely answer to this question.
Question 5: Review the following figure:
Based on this figure, which of the following can you state are correct (pick all correct answers)?: A. The intranet tunnel is active B. The infrastructure tunnel is active C. The DirectAccess client is using IP-HTTPS as its active IPv6 transition technology D. The DirectAccess client is a domain member
The answer to question 5 is A, B, and D.
Answer A is correct because the DirectAccess client needs to authenticate using a computer certificate and machine account (NTLMv2) to establish the infrastructure tunnel. The intranet tunnel enables the DirectAccess client to connect to machines that you define in the “management servers” list in the UAG DirectAccess server configuration.
Answer B is correct because the DirectAccess client need to authenticate using a computer certificate and user account (Kerberos V5) to establish the intranet tunnel.
Answer C is incorrect because DirectAccess clients that use IP-HTTPS always use 2002 for their high order “quartet”, and the screenshot shows that the client is using 2001.
Answer D is correct because all DirectAccess clients must be domain members. The DirectAccess client doesn’t need to be a member of the same domain as the UAG DirectAccess server, but it must be a domain member for authentication and Group Policy assignment.
Now for the scores! The figure below shows the final score for Round 2 in Contest 1 (which is also Round 1 in Contest 2).
The final score for Contest 1 is based on the points assigned to the top three finishers in Round 1 and the points assigned to the top three finishers in Round 2. You can see the Round 1 and Round 2 points in the chart. If there was a tie for the first, second or third places in a Round, each member of the tie received the points for that position. The top score for a Round received 5 points, the second highest score received 3 points and the third highest score received 1 point.
The unofficial Contest 1 Results (note that these results are not official until FRIDAY – this is to make sure you have time to tell me I might have made a mistake on the scoring of your entry – therefore, like they say in horse racing, hold on to your tickets until the results are declared official!) are:
WINNER:
jasonj – 8 points PRIZE: Personalized Starbucks Card and Hard Copies of our UAG and TMG books!
2nd PLACE:
oblaba – 6 points PRIZE: Hard Copies of our UAG and TMG books!
christophf – 6 points PRIZE: Hard Copies of our UAG and TMG books!
3rd PLACE:
mika – 4 points PRIZE: Hard Copy of either our UAG or TMG book (your choice)
In addition, I’d like to acknowledge the participation of those who didn’t end up in the top three – but participated in each of the quizzes in the second round. It was a long haul and for those who stuck it out this long deserve some recognition. Therefore richardf, kenc, mrshannon and benl will all receive PDF copies of our UAG and TMG books.
I will be writing to each of you to obtain your mailing information after the results are made official. As for the unofficial winner – Jason Jones is a Forefront MVP and will be attending the MVP worldwide conference next month, so I will be able to present him his prizes in person.
So there you go! Thanks for participating in the Contest! It was a ton of fun and I hope you all learned some things along the way (I know I did!).
We’ll start Round 2 of Contest 2 next week – so you can take the rest of this off .
See you then!
Thanks!
Wow! This is it – the last quiz in Contest 1. That’s right – this is quiz 4 of the second round.
To celebrate this occasion and to make things more interesting, we’re going to have FIVE questions. This will give those who are behind a better chance of catching up and put some pressure on the leaders.
Let the game begin!
There you go! Five questions with five answers ready for you to send to me.
Send me your answer with the following email link:
tomsh@microsoft.com
by 11AM Central Standard Time (-0600 UTC) on Monday January 31.
UAG 2010 (UAG) supports two types of network level SSL VPN:
Network Connector is aimed at legacy clients and SSTP for Windows 7 clients.
Network Connector supports both split and non-split tunneling configurations while SSTP, when accessed through the UAG portal, supports only non-split tunneled connections.
This can be a problematic for firms that want to enable a split tunneled configuration to reduce the bandwidth drain that VPN clients can extract when split tunneling isn’t supported. And with current network security opinions moving away from disabling split tunneling as a security solution (see my articles on split tunneling for more information at http://blogs.technet.com/b/tomshinder/archive/2010/03/02/why-split-tunneling-is-not-a-security-issue-with-directaccess.aspx), it makes sense that admins would want to enable split tunneling for their UAG SSTP clients.
Faisal Hussain provides a solution on his blog and you can find it at:
http://blogs.technet.com/b/fsl/archive/2011/01/26/uag-sstp-split-tunnel.aspx
WARNING: This is an unsupported solution and has not been tested or validated by CSS.
A couple of good questions were asked on a recent blog post and I figured it was worthwhile to answer them in more detail in a separate post.
====================================
“Can you clarify a couple points related to Certificate Authorities and CRLs? I plan on getting a commercial certificate for the IP-HTTPS listener as you recommended, but how does that affect all of the other certificate related configurations in the test lab guide? The CA created on the domain server is completely separate from this commercial certificate, right?…”
The IP-HTTPS listener needs a web site certificate (intended use is server authentication) so that DirectAccess clients can establish an IP-HTTPS connection to the UAG DirectAccess server before establishing the DirectAccess IPsec tunnels. This requires mutual client and server authentication, something that is the default setting for UAG DirectAccess (the default for Windows DirectAccess is server authentication only).
The primary advantage of using a commercial certificate for the IP-HTTPS listener is that the commercial certificate provider maintains the Certificate Revocation List (CRL) and Distribution Points for you. Not only do they maintain that list for you, they also make sure that the CRL is highly available. While you could use your private PKI for the IP-HTTPS listener, you would then be responsible for maintaining the CRL and making sure that it it highly available.
Now how does this relate to what we did in the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess Test Lab Guide (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=71be4b7b-e0e9-4204-b2b5-ac7f3c23b16d)?
In the Test Lab we actually created a certificate template that removed CRL related information so that the DirectAccess client would not fail its IP-HTTPS connection when the CRL wasn’t published. This simplified the TLG environment because we didn’t need to go through the steps of publishing the CRL. In your production environment, you do want to make sure that the CRL is available for your private PKI; so you wouldn’t use the special configuration we did for the web site certificate template we used in the TLG. However, you don’t need to publish your private CRL because the commercial provider is handling the IP-HTTPS certificate’s CRL Distribution Points.
You still want to use your private PKI to distribute computer certificates to the DirectAccess clients and the UAG DirectAccess server. You also want to distribute computer certificates to any machines that you want end-to-end IPsec transport mode protection. And you want to make sure that the CRL is available so that you can revoke certificates (however, revoking certificates for DirectAccess clients is not an effective way to prevent them from connecting to the DirectAccess server – other methods should be used, such as disabling the computer account for the suspect DirectAccess client and changing the password of the user who lost the DirectAccess enabled computer). And you want to be able to use autoenrollment to make is easy to distribute the certificates.
The commercial certificate and the private certificates have no relationship to each other and don’t need any. The commercial certificate provider should be included in the Enterprise Root Certificate Authorities store on all your DirectAccess enabled machines.
========================================================
“And you mentioned that you wouldn't want to host the CRL on the DirectAccess server in a production environment. Is this only because of performance reasons or because of something else? And is this CRL not related to the IP-HTTPS listener? So, just to make sure I'm getting it, there is one CA and a corresponding CRL for the active directory domain, and then another CA/CRL (in this case commercial) for the DirectAccess connections. Is that right?…”
There are a number of reasons why you wouldn’t want to host the CRL Distribution Point web site on the UAG DirectAccess server, but probably the main one is that every time you reconfigure the DirectAccess settings using the UAG DirectAccess wizard, it will end up resetting your CRL Distribution Point web site. There are also traffic related reasons – since the CRL check requires anonymous access to the CRL Distribution Point web site, you increase both the amount of traffic and the attack surface on the UAG DirectAccess server.
You are correct that there are two CRLs in use in the DirectAccess scenario discussed here:
It’s important to note here that only a “soft” CRL check is done when the DirectAccess client connects to the UAG DirectAccess server. If the DirectAccess client fails the CRL check, it will still be allowed to connect. So whether or not the CRL is available doesn’t determine connectivity for your DirectAccess clients.
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
Now for the moment you’ve all been waiting for – the answers to UAG SP1 DirectAccess Contest 1–Round 2/Quiz 2 and Contest 2 Round 1/Quiz 2!
Last week’s quiz was a bit different with some practical problem solving scenarios based on screenshots. Let’s see how you did:
===========================================
Question 1: Review the information in figure 1. (UAG1 is the UAG DirectAccess server and DC1 is on the intranet)
Figure 1
From the information provided to you in Figure 1, which of the following answers is most likely? (choose 1 answer) A. The Teredo server was moved off the UAG DirectAccess server B. The 6to4 relay router was moved off the UAG DirectAccess server C. The NAT64/DNS64 service was moved off the UAG DirectAccess server D. The ISATAP Router was moved off the UAG DirectAccess server
The answer to question 1 is D.
To be better understand the scenario, the figure below shows the network diagram for the test environment from which this screenshot was taken.
If you look at the screenshot we have three pieces of information we can use to determine the answer.
The first piece of information is the ping uag1 result. This returns a native IPv6 address assigned to the UAG DirectAccess server. In typical scenarios, when you ping the UAG server you will either see an ISATAP address returned, of if you’re using an IPv4 only network with the help of NAT64/DNS64, then you would see an IPv4 address. This indicates that the UAG DirectAccess server has a native IPv6 address assigned to its internal interface and is not using ISATAP to communicate with the internal network.
The second piece of information from from ping dc1. The ICMP Echo Reply is returned from an ISATAP address, indicating that ISATAP is being used on the internal network.
The third piece of information we have comes from tracert –d dc1. You’ll notice that the second hop returns an address on the same network ID as the IP address returned from the ping uag1. The last hop is to DC1, which is on an ISATAP subnet.
When you put these three pieces of information together, the best conclusion that you can draw is that there is a network device between the UAG DirectAccess server that is routing native IPv6 packets to an ISATAP enabled subnet. This device is an ISATAP router, which you can see in the network diagram as ISATAP1. Normally, the UAG DirectAccess server hosts the ISATAP server role – but in this scenario, the ISATAP router was moved to a separate machine.
Note that this network diagram is part of a larger network diagram that describes how to configure a multi-site UAG DirectAccess solution using ISATAP routers and a single ISATAP cloud for the intranet. I hope to be able to complete the documentation on that scenario soon and will post it here.
Question 2: Review the information in figure 2. (UAG1 is the UAG DirectAccess server and DC1 is on the intranet) (choose 1 answer)
Figure 2
From the information provided to you in Figure 2, what is the most likely roll for the machine with the IP address 2002:836b:4:8000:0:5efe:10.0.0.20 ? A. ISATAP router B. Windows Server 2008 R2 IPv6 RRAS router C. IP-HTTPS relay D. Teredo relay
The answer to question 2 is A.
Again, we have three pieces of information that we can work with to solve the problem.
The first piece of information comes from the ipconfig output. Here we can see the IPv4 and IPv6 addressing assigned to this computer – which is DC1 because we recognize the ISATAP address from the previous question. We also see a default gateway assigned to the ISATAP adapter, which is a link-local ISATAP address assigned to the machine with the IPv4 address 10.0.0.20. This indicates that 10.0.0.20 must be an ISATAP gateway (router).
The second piece of information comes ping uag1. Like in the first question, we see that UAG1 resolves to a native IPv6 address, which is consistent with the UAG DirectAccess server being assigned a native IPv6 on its internal interface and not using ISATAP itself.
The third piece of information comes from a tracert –d client1. The first hop address is the ISATAP assigned address to the machine that is assigned as the default gateway for the ISATAP adapter on DC1. The second hop comes from the native IPv6 addresses assigned to the internal interface of the UAG DirectAccess server. The third hop comes from a machine that is assigned an Teredo address, which you might not know since you don’t know the IP addressing on the external interface of the UAG DirectAccess server, but you do recognize that it is a native IPv6 address that is on a different network ID as the internal interface of the UAG DirectAccess server.
When we put these three pieces of information together it becomes clear that in order for DC1 to ping CLIENT1, it must travel over an ISATAP subnet, to an ISATAP router, which forwards the IPv6 packet over the native IPv6 subnet to the internal interface of the UAG DirectAccess server, which then routes the connection to the IP-HTTPS enabled DirectAccess client on the Internet.
Question 3:
Review the information in figure 3. Figure 3
Why is the first “quartet” for CLIENT1 different than the other IPv6 addresses on the network? (choose one answer) A. CLIENT1 is on a different ISATAP subnet B. CLIENT1 is on the Internet and has registered its IP-HTTPS address C. CLIENT1 is located behind a web proxy and has registered its 6to4 address D. CLIENT1 is located behind a NAT device and has registered its Teredo address
The answer to question 3 is D.
Answer A is incorrect because CLIENT1 is not assigned an ISATAP address. For more information on ISATAP addressing, see http://technet.microsoft.com/en-us/library/bb727021.aspx
Answer B is incorrect because CLIENT1 is “on the Internet” which implies that the machine is assigned a public IP address. When the machine is assigned a public IP address, it will register its 6to4 address. In addition, IP-HTTPS clients’ IPv6 address always start with 2002:
Answer C is incorrect because CLIENT1 is located behind a web proxy – which means that only IP-HTTPS is available to client and not 6to4.
Answer D is correct because CLIENT1 is located behind a NAT device and Teredo is used preferentially when the DirectAccess client is located behind a NAT device.
Wow! That was a good one – everyone did great and it shows that our DirectAccess contestants are pretty sharp when it come to IPv6. That’s a good thing, because I think that 2011 is going to be the Year of IPv6 given that we’ll run out of IPv4 allocations very soon.
Next Thursday I’ll post the last quiz in Content 1 and announce the winner! To make it even more interesting – I’m going to include FIVE questions. That will make it possible for anyone to get in the last jump to take home a winner for this round.
So set yourself up a reminder to check for the quiz on Friday January 28, 2011.
It’s time for your weekly UAG DirectAccess quiz! We’re getting close to the end of contest 1, so make sure you don’t miss a step for the next two weeks.
Last week’s quiz was definitely tricky and introduced some obscure or difficult to find information. This week I’m going to try something a little different.
Remember to send your entries before 11AM Central Standard Time (-0600 UTC) on Monday January 24th.
To the questions!
Let’s see if this more “practical” approach to the questions is a bit less tricky than the quiz we had last week. This quiz is a nice test of your basic IPv6 knowledge – so good luck and have fun!
Send me your answers at:
by 11AM Central Standard Time (-0600 UTC) on Monday January 24th.
This question comes up frequently when introducing admins to UAG DirectAccess. It makes sense, since public IPv4 addresses are getting more difficult to come by and in fact it’s predicted that there will be an exhaustion of the entire IPv4 address space by next month. So, why do you need two public IP addresses on the external interface of the UAG DirectAccess server?
There’s a short answer and a long answer. Let’s begin with the short answer (hat tip to Ben Ben Ari, Senior Support Engineer at Microsoft):
“When the Teredo adapter is active on the DirectAccess client, it will check the Teredo server’s public IPv4 addresses to determine what type of NAT device the client is located behind. The assessment is performed to determine which on of the follow four types of NAT are in use: One-to-one NAT, also known as Full-cone NAT Address restricted cone NAT Port-restricted cone NAT Symmetric NAT The detection process starts with the Teredo client sending a Router Solicitation (RS) message to the Teredo server’s IP first address (the first of the two consecutive IPv4 addresses on the external interface on the UAG server used by DirectAccess). UAG then replies from the 2nd IP address. If the Teredo client receives the reply, it deduces that the NAT type is “Cone” (option 1 or 2 above). If the client does not receive this reply, then it issues a second RS message, but this time, UAG will reply from its first IP, instead of the second. If the client gets this reply, it now knows that the NAT type is either Port-restricted cone (type 3) or Symmetric (type 4) NAT. Next, the client sends a request to the UAG server’s second IP address (which also acts as a Teredo server), and waits for another answer. When the answer comes, if it is from the same IP as the first, this signals to the client that the NAT type is Port-restricted cone (type 3). If they are different, this means that NAT is mapping the same internal address and port number to different external addresses and port numbers, which means that this is a Symmetric NAT (type 4).”
“When the Teredo adapter is active on the DirectAccess client, it will check the Teredo server’s public IPv4 addresses to determine what type of NAT device the client is located behind. The assessment is performed to determine which on of the follow four types of NAT are in use:
The detection process starts with the Teredo client sending a Router Solicitation (RS) message to the Teredo server’s IP first address (the first of the two consecutive IPv4 addresses on the external interface on the UAG server used by DirectAccess). UAG then replies from the 2nd IP address. If the Teredo client receives the reply, it deduces that the NAT type is “Cone” (option 1 or 2 above). If the client does not receive this reply, then it issues a second RS message, but this time, UAG will reply from its first IP, instead of the second. If the client gets this reply, it now knows that the NAT type is either Port-restricted cone (type 3) or Symmetric (type 4) NAT.
Next, the client sends a request to the UAG server’s second IP address (which also acts as a Teredo server), and waits for another answer. When the answer comes, if it is from the same IP as the first, this signals to the client that the NAT type is Port-restricted cone (type 3). If they are different, this means that NAT is mapping the same internal address and port number to different external addresses and port numbers, which means that this is a Symmetric NAT (type 4).”
If you want even more detail, this may help check out the Teredo Overview:
http://technet.microsoft.com/en-us/network/cc917486.aspx
DirectAccess is about being “always-on”. When I start my laptop in the morning, I’m ready to get to work. Even though I don’t work on the Microsoft campus, I’m able to connect to anything I want (that I have permissions to connect to) on the Microsoft intranet without thinking about connecting to an SSL VPN portal, some web application gateway, or a traditional network layer VPN connection. I just start the laptop and BAM! I’m connected. And IT is always connected to me too, so my laptop is always up to date and managed by Microsoft IT.
DirectAccess connections consist of two IPsec tunnels that fire up when the Private or Public Windows Firewall with Advanced Profiles are assigned to the machine configured as a DirectAccess client. When the Public or Private Profile is active, the machine configured to be a DirectAccess client will attempt to establish two IPsec tunnels with the DirectAccess server:
The infrastructure tunnel is established after computer certificate authentication and computer account NTLMv2 authentication. The infrastructure tunnel allows the DirectAccess client to connect to key resources on the intranet, such as domain controllers and management servers (WSUS, SCCM, SCOM, etc.). Intranet tunnel connectivity enables you to always manage the DirectAccess client, even if the user isn’t logged on to the computer. In addition, the intranet tunnel provides the connectivity required for the user to log on and establish the intranet tunnel.
The intranet tunnel is established after both computer certificate and user account Kerberos authentication is successful. In order to complete the user account authentication (Kerberos), the user needs access to a domain controller. That’s why you need the infrastructure tunnel to come up before the second tunnel can be established. The intranet tunnel cannot be established by using cached credentials on the client.
So what does this all to do with 3G connectivity? Mobile computers with 3G adapters are becoming increasingly popular. These 3G adapters are tremendously convenient, as you no longer need to depend on being able to connect to whatever local network where you might be physically located . All of us have gone through “the drill” of trying to connect to a customer’s network, a hotel network, or some public Wi-Fi network. Sometimes it’s easy, but more often than not there are some bumps that eat into your productivity. The 3G adapter allows you to get around those time-eating complications.
The problem is that not all 3G adapters and their supporting software are the same. The following describes an interesting issue that came up when a customer was using a particular 3G adapter:
“This morning I tested the “always-on” 3G connection scenario with my Rogers 3G adapter (http://www.rogers.com/web/content/wireless_network) and the built-in 3G GOBI (built-in mobile broadband technology - http://www.gobianywhere.com/) adapter in my HP Tablet and found that when using the Rogers USB 3G adapter an “always-on” connection is not possible, but when using an integrated 3G GOBI module it is possible (it really comes down to the software that is provided). The details of my test methodology and results are below… Rogers Rocket™ Stick – The Rogers Communication Manager software runs in User Mode only (does not run as a Service), so the connection is invoked when a user is logged on and disconnected when the user logs off. There is an “Auto-Connect” checkbox, but it only makes the connection when a user logs on to the device. Therefore the current software provided by Rogers does not support an “always-on” scenario. I verified this by looking at the activity light on the USB stick itself – Red is device is not ready, solid Blue is network detected, blinking Blue is network connected and active. For the duration of the test the activity light remained sold Blue, indicating that a connection to the 3G network was never established. It only began blinking after I logged in to the computer. HP Built-In 3G GOBI Adapter – The HP software is installed as a Service that can be configured to automatically start at boot (in the Services console), and there is also an option to “Auto-Connect” to the 3G broadband. Since the HP Tablet does not have external lights to indicate network activity I had to find another method to determine if the 3G connection was active prior to logon, so I did the following: Disabled the wireless adapter, so that the HP Tablet could only connect using the 3G broadband Installed the Windows Live Mesh software on the HP Tablet, added the HP Tablet to my managed device list and configured it to allow remote connections I completely shut down the HP Tablet, then turned it on (cold boot) and left it alone (did not log on) At my other computer (Lenovo laptop), I logged on to http://mesh.live.com and was able to successfully Remote Desktop to my HP Tablet via the website To verify that only the 3G broadband connection was active, from the Remote Desktop session I checked the active network connections on the HP Tablet, then double-checked by logging on to the HP Tablet locally – and yes, throughout the entire time the only active connection was the 3G broadband. Therefore the HP built-in 3G adapter (with a Rogers SIM), appropriately configured, will allow for an “always-on” 3G connection that could be used for device management prior to user logon. A similar test would have to be run for the any other 3G adapter you will be using to verify if the 3G adapter’s software provides the same capability.”
“This morning I tested the “always-on” 3G connection scenario with my Rogers 3G adapter (http://www.rogers.com/web/content/wireless_network) and the built-in 3G GOBI (built-in mobile broadband technology - http://www.gobianywhere.com/) adapter in my HP Tablet and found that when using the Rogers USB 3G adapter an “always-on” connection is not possible, but when using an integrated 3G GOBI module it is possible (it really comes down to the software that is provided). The details of my test methodology and results are below…
Rogers Rocket™ Stick – The Rogers Communication Manager software runs in User Mode only (does not run as a Service), so the connection is invoked when a user is logged on and disconnected when the user logs off. There is an “Auto-Connect” checkbox, but it only makes the connection when a user logs on to the device. Therefore the current software provided by Rogers does not support an “always-on” scenario. I verified this by looking at the activity light on the USB stick itself – Red is device is not ready, solid Blue is network detected, blinking Blue is network connected and active. For the duration of the test the activity light remained sold Blue, indicating that a connection to the 3G network was never established. It only began blinking after I logged in to the computer.
HP Built-In 3G GOBI Adapter – The HP software is installed as a Service that can be configured to automatically start at boot (in the Services console), and there is also an option to “Auto-Connect” to the 3G broadband. Since the HP Tablet does not have external lights to indicate network activity I had to find another method to determine if the 3G connection was active prior to logon, so I did the following:
Therefore the HP built-in 3G adapter (with a Rogers SIM), appropriately configured, will allow for an “always-on” 3G connection that could be used for device management prior to user logon. A similar test would have to be run for the any other 3G adapter you will be using to verify if the 3G adapter’s software provides the same capability.”
Later another interesting finding was that with the HP GOBI 3G adapter, if the user logged off the computer the 3G adapter shut down and does not start again until the user logs on again or until the machine is restarted.
When considering a 3G solution to work with your DirectAccess capable mobile computer, make sure to check on the adapter software’s connectivity behavior. The adapter should be able to initialize and connect to the 3G network before the user logs on to the DirectAccess client computer. You can use the methods described in this article to determine if the adapter is capable of this behavior.
(Hat tip to Pat Telford for informing me of this issue.)
Here you go:
ISATAP is an IPv6 transition technology that enables computers to tunnel IPv6 packets inside an IPv4 header. Which of the following scenarios are enabled when ISATAP is enabled on your network (select all correct answers):
A. ISATAP hosts on an IPv4 only network can communicate with hosts on an IPv6 only network B. ISATAP hosts on an IPv4 only network can initiate connections to DirectAccess clients C. DirectAccess clients can only communicate with ISATAP hosts on the intranet D. ISATAP is required for all DirectAccess deployments
The answer to question 1 is A and B.
An ISATAP router can be placed on an intranet and enable routing from an IPv4 network to an IPv6 network. The ISATAP hosts on the IPv4 network can tunnel their IPv6 communications inside an IPv4 header and send the IPv4 encapsulated packets to the ISATAP router. When they reach the ISATAP router, the IPv4 header is removed and the IPv6 packet is forwarded to its destination on the IPv6 portion of the intranet. DirectAccess clients “live” in an IPv6 only network, since all communications sent and received by DirectAccess clients are IPv6. When an ISATAP host on the intranet initiates a connection to a DirectAccess client, it tunnels an IPv6 packet in an IPv4 header and forwards it to an ISATAP router (typically installed on the UAG DirectAccess server itself). Then the IPv4 header is removed and the IPv6 packet is forwarded to the DirectAccess client.
DirectAccess clients can communicate with non-ISATAP (and non-IPv6 capable) hosts on the intranet because UAG DirectAccess includes the NAT64/DNS64 service that performs IPv6/IPv4 protocol translation. For this reason, ISATAP is not required for all IPv6 deployments. However, only ISATAP hosts and machines that have native IPv6 addressing can initiate connections to DirectAccess clients.
Question 2: The number of concurrent Teredo clients per UAG DirectAccess server is determined by the Neighbor cache limit. What is the default number of Teredo clients per server support for UAG DirectAccess? A. 64 B. 128 C. 256 D. 512
The answer to question 2 is C.
If you check the TechNet article at http://technet.microsoft.com/en-us/library/ee382271(WS.10).aspx you would have been led to believe that the answer is 128. However, if you go to your UAG server and run the command netsh interface ipv6 show global, you will see the following:
We then need to ask “is the 256 value specific for UAG DirectAccess”? I can’t tell you for sure as I don’t have any Windows DirectAccess labs up to check the default value. But the question was specific regarding “UAG DirectAccess server” and the default value for a UAG DirectAccess server is 256.
OK – it was a tricky question, but sometimes you have to check these things out on a live server
IP-HTTPS is a IPv6 transition technology that enables a DirectAccess clients to connect to the UAG DirectAccess server even when the clients are located behind web proxy or port restricted firewalls. Which of the following statements are true regarding IP-HTTPS? A. IP-HTTPS has higher protocol overhead than Teredo and 6to4 B. IP-HTTPS has higher processing overhead than Teredo and 6to4 C. IP-HTTPS is required when Force Tunneling is enabled D. IP-HTTPS requires client certificate authentication to establish the SSL session
The answer to question 3 is A, B, C and D.
IP-HTTPS has higher protocol overhead because it puts an HTTP header on top of the IPv4 header that’s used by all three IPv6 transition technology. IP-HTTPS has higher processing overhead because in addition to the IPsec processing required by all DirectAccess connections, it adds SSL processing on top of that. IP-HTTPS is required when you want to do Force Tunneling, which is one of the reasons why you want to avoid Force Tunneling if you can.
The answer that tripped most of you was D. While not obvious, you can find information on this behavior at http://social.technet.microsoft.com/wiki/contents/articles/troubleshooting-the-no-usable-certificate-s-ip-https-client-error.aspx and http://technet.microsoft.com/en-us/library/ee731901(WS.10).aspx
This quiz was pretty tough – and the game is really close because of it!
I’m pretty sure I got all of the entries this time (I missed a couple of you in the last quiz). If you sent in an entry and don’t see your score recorded, please let me know so that I can score your entry and get it into the leaderboard.
Make sure to check late Thursday or Friday this week for the next quiz. I’m hoping to get a “video question” up so that you’ll need to watch a short video to solve the problem.
(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 Contest 1-Round 2/Quiz 2 and Contest 2-Round 1/Quiz 2
Send your entries until 11AM Central Standard Time (-0600 UTC) on Monday January 17th.
The scores are really close and at this point, anyone can end up winning this round!
Now for the questions!
Now send your answers to me at (make sure to use this link since it contains the subject line I need):
This week was a big “catch up” week after the holidays so I didn’t get to put as much on the Edge Man blog this week. Next week I should have some nice “goodies” for you – so you’ll have something to look forward to.
Take a look at the figures below and see if you can guess what device is in the request/response path that you don’t typically see a UAG DirectAccess deployment.
First, the ipconfig output on a DirectAccess client located behind a NAT device:
Now let’s ping DC1:
Now let’s do a tracert from CLIENT1 and DC1:
Figure 3
With this information you should be able to figure out what the “novel” device is in the path between CLIENT1 and DC1. If you know, then consider yourself pretty well-versed with IPv6 addressing. If you don’t know, then here’s a great opportunity to learn something new!
Now take a look at figures 4 and 5 and determine what device was removed from the path:
Figure 4
Figure 5
Think about the solutions and put your answer in the comments section. Give your reasoning. I’ll post the answer and a network diagram of the solution tomorrow.
Have fun!
Now for the moment you’ve all been waiting for – the answers to UAG SP1 DirectAccess Contest 1–Round 2/Quiz 1 and Contest 2 Round 1/Quiz 1!
==========================================================
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?
A. ICMPv6 B. ICMPv4 C. DCOM 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…”
“…By default, the DirectAccess Setup Wizard creates Group Policy objects for DirectAccess clients and servers for settings that allow the following behaviors:
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.
Question 2: 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:
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.
========================================================== Question 3: 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
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.
Visit the TechNet forums to discuss all your UAG DirectAccess issues http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads 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
It that time again! The UAG DirectAccess Contest. If you’ve been participating in Contest 1 Round 1, you know the drill.
If you’re new – don’t worry about Contest 1 – you’ll be automatically entered into Contest 2 and you’ll be participating in Round 1. And if you participated in Round 1 of Contest 1 but didn’t do so well, there’s still a chance to improve in Contest 2 – so make sure you send your entries.
You can find 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
There you go!
Send your entries until 9AM Central Standard Time (-0600 UTC) on Monday January 9th.
Good luck!
Just a quick note about the UAG DirectAccess contest. We didn’t have a quiz last week because of the entire world was on vacation
We’ll continue the contest this week with the next quiz being tomorrow, January 6, 2011.
The first round of the first contest is complete. The second round of the first contest starts with tomorrow’s quiz, which will be Quiz 1, Round 2.
Tomorrow quiz will also represent the first round in Contest 2. So even if you didn’t do well in Round 1 of Contest 1, you can get back in the game for Contest 2!
Quiz Dates for Contest 1/Round 2 and Contest 2/Round1 are:
The standings for Contest 1/Round 1:
For a review of the scoring methods, check out the first quiz at http://blogs.technet.com/b/tomshinder/archive/2010/12/02/uag-sp1-directaccess-contest-quiz-one-round-one.aspx
For Contest 1 Round 2/Contest 2 Round1 – I’m thinking of doing some more interesting things with the questions, like screenshots of something gone wrong and then looking for the answer to the most likely reason for the finding or what should you do next to determine the problem.
I’m looking forward to seeing your entries this week!
While I spend most (all) of my time working with the UAG DirectAccess solution, UAG DirectAccess is functionality essentially represents a superset of Windows DirectAccess functionality. Therefore, I thought it might be interesting to share with you all some questions I received from a fellow who is interested in deploying Windows DirectAccess. Maybe the questions and answers contained here will help you with your own planning for deploying DirectAccess in your SMB environment.
==============================
Question/issue 1: I’m in the process of putting together a DirectAccess solution for a small client of mine that needs the features of DirectAccess but can’t lay down the cash for multiple physical servers or UAG. They don’t need the additional complexities of access to IPv4 only resources as this is basically going to be a new network starting from scratch.
I know this may not be ideal from a performance perspective because of the many shared roles and limited scalability, but this is not going to be a network with many users; rather it will be a network of a dozen or so kiosks that will always be remotely connected. I’m starting to experiment some but haven’t found many resources for the absolute simplest implementation of DirectAccess.
I will certainly be going through the test lab documentation and other papers from Microsoft regarding the set up, but I thought I’d ask just in case anyone knows of some resources I haven't found yet (or just has some good tidbits of info themselves).
My concept is this:
What I’d ultimately really love is a "test lab" document similar to the one already out there from Microsoft but designed to interface with the real internet instead of a fake internet. The document makes several references to "problems" trying to adapt that test environment into a real world scenario, but it doesn’t give a whole lot of information about what "problems" they are referring to.
ANSWER: First off, these are great questions and thanks for sending them my way. Examples of planning for real-world deployments help everyone on their trek to DirectAccess goodness.
Since your customer can’t afford UAG at this time (maybe he will in the future as the company grows), the place to start is with the Windows DirectAccess solution. You are right that you will not have support for IPv4-only resources on the intranet, and your high availability options are somewhat limited. But you recognize these conditions and we can work within these parameters.
We generally recommend that you don’t put the Network Location Server on the domain controller, especially in pure IPv6 scenarios for some reasons regarding interface timings. While I don’t have the details in front of me, I have received information from a DirectAccess PM who strongly recommends that the Network Location Server not be placed on a DC – so if you could create a VM for the NLS, that would be a good way to go.
You can put the DirectAccess server in a virtual machine. However, there are performance implications and therefore we generally recommend that you put the DirectAccess servers on physical machines. With that said, you mention that this is going to be a relatively lightly used configuration, and therefore you might be able to get acceptable performance. You’ll need to monitoring your deployment and see if you are running into processor bottlenecks.
It is good that you’re planning on dedicated NICs for the virtual and physical interfaces. DirectAccess will perform better this way.
It’s also good you recognize that the firewall in front of the DirectAccess server will perform only firewall functionality and not NAT, because DirectAccess is not supported from behind a NAT device (although it can be done with the help of a few routing tricks, but that configuration is not supported by the product group).
Windows 7 Enterprise or Ultimate is required – so you’re good with the OS on your clients. Keep in mind that these must be domain members.
Regarding the problems that we suggest with the Test Lab Guides here are a few things that I can think of:
With those things in mind, you can create a “live” pilot deployment. I’d recommend that you obtain a commercial certificate for the IP-HTTPS listener, and not use the CRL checking disablement steps I deployed in the UAG DirectAccess Test Lab Guides.
-----------------------------------------
Question 2: What are the advantages/disadvantages of using a native IPv6 infrastructure (with a tunnel broker like Hurricane Electric) vs just using ISATAP? Are there any compelling reasons to go ahead and go native (especially if the network is going to be new with no legacy devices)?
ANSWER:
ISATAP is useful if your network infrastructure isn’t IPv6 aware, since you can tunnel your IPv6 traffic over IPv4 and use your current IPv4 routing infrastructure. However, if your routing, DNS and DHCP infrastructure is all IPv6 capable, there’s no need to deploy ISATAP and I’d recommend that you go native IPv6. You will need to configure your routers (and maybe the hosts) on your network so that they know the route back to the DirectAccess clients.
In most cases that will require that you make the DirectAccess server the IPv6 route of last resort since this is the only way to get the messages back to the 6to4 DirectAccess clients – or better, you can disable 6to4 on your DirectAccess clients and they will use Teredo instead – then your routing tables will be a bit “cleaner” and you want need to make the DirectAccess server the IPv6 route of last resort.
Question 3: What are the security implications with opening up inbound IPv6 traffic into your network? Since DirectAccess requires Protocol 41 traffic to be let through the firewall directly to the external NIC on the DirectAccess server, doesn't this open up some potential security issues without an IPv6 firewall in place? Maybe I am missing something, but since Protocol 41 is encapsulating ALL IPv6 traffic in IPv4 packets isn't letting Protocol 41 traffic through essentially the same thing as having a computer directly connected to the IPv6 internet with no firewall at all?
IP Protocol 41 is used to indicate that there is direct encapsulation of IPv6 packets within an IPv4 header to support 6to4. So, we’re not really allowing all IPv6 traffic through the firewall, just 6to4 traffic. Also, keep in mind that both of infrastructure tunnel and the intranet tunnel require authentication – for the infrastructure tunnel, both computer certificate and NTLMv2 authentication is required, and for the intranet tunnel, both computer certificate and Kerberos v5 authentication is required.
While all IPv6 traffic is allowed through the IPv4 tunnel – traffic to the DirectAccess server is allowed only after the client authenticates and establishes a valid IPv6 IPsec connection . We also have some Denial of Service Protection technology built into to take care of malicious users who try to take advantage of this situation, though. However, if you don’t think this is enough – you can take my earlier recommendation and disable 6to4 on the DirectAccess clients and let them use only Teredo or IP-HTTPS. Keep in mind that this is the same situation – the Teredo and IP-HTTPS clients are also encapsulating all IPv6 traffic. But the same protections still apply regarding IPsec and DoSP.
I hope you find these answers helpful and would be happy to carry on the conversation in the comments section.
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
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!
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.
There you go! I know you’re all busy this week and next, so the questions are short and sweet.
Send your entries until 9AM Central Standard Time (-0600 UTC) on Monday December 27th.
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
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!
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!