One of the most mysterious errors you’ll see when working with DirectAccess are related to failures in IP-HTTPS connectivity. I did a blog post on this problem last year and you can find it at http://blogs.technet.com/b/tomshinder/archive/2010/03/30/troubleshooting-the-no-usable-certificate-s-ip-https-client-error.aspx
Phillip Sand clued me into another possible cause of IP-HTTPS connectivity problems. First, whenever you suspect a problem with IP-HTTPS connectivity, you should run the command:
netsh interface httpstunnel show interface
If you see the following:
Role : client URL : https://da.domain.com:443/IPHTTPS Last Error Code : 0x103 Interface Status : no usable certificate(s) found
Where da.domain.com is the FQDN used to connect to the IP-HTTPS listener on the external interface of the UAG DirectAccess server, then you know you have a problem.
In addition to the cause I mentioned in the earlier blog post is a situation related to the CA certificate not being installed in the NTAUTH store of the UAG DirectAccess server. You can find out if the CA certificate is installed by running the command:
certutil –v –store –enterprise ntauth
on the UAG DirectAccess server. If everything is OK, then you’ll see something like what appears in the figure below (this is what you’ll see if you’re using the UAG DirectAccess Test Lab Guide for your UAG DA lab):
If you don’t see any certificate listed, then that can cause the 0x103 error on the client.
You can fix the problem by running the command:
certutil –addstore –enterprise –ntauth IssuingCACert.cer
Where IssusingCACert.cert is the root CA certificate.
Hat tip to Philipp Sand for this great info!
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
For companies thinking about deploying DirectAccess, the question of whether or not you need to deploy ISATAP will invariably come up. The answer to this question is “no” and the reasons for why you don’t need ISATAP in a DirectAccess deployment are covered in my article over at http://blogs.technet.com/b/tomshinder/archive/2010/10/01/is-isatap-required-for-uag-directaccess.aspx
However, ISATAP does have a place in a DirectAccess deployment, as I discussed in that article. If you don’t have an existing native IPv6 network infrastructure in place, then you might want to consider enabling ISATAP to fully realize the “manage out” capabilities that are part of a comprehensive DirectAccess solution.
However, in all the coverage of ISATAP, I’ve left out some critical information that can help you decide on how you deploy ISATAP in your organization. It’s at this point I get to tell you that the ole “Edge Man’s” favorite food is crow. When I get to eat crow, it means I said something in public and then find out later I was wrong (or at least not entirely right). I like crow because when I eat it, it means that I’ve learned something new.
Now with that are an introduction, let’s get into what led to this “crow eating” session. If you read this blog on a regular basis, you might remember my article on using a HOSTS file entry to control which systems configure themselves as ISATAP hosts. If you didn’t see it you can check it out at http://blogs.technet.com/b/tomshinder/archive/2011/02/14/use-a-hosts-file-entry-to-control-isatap-host-configuration.aspx
In that article, I said:
“In general, ISATAP is a good thing…”
Now that seems like a pretty benign statement, doesn’t it? I thought so. But if you look at the Intra-site Automatic Tunnel Addressing Protocol Deployment Guide at http://www.microsoft.com/downloads/en/details.aspx?familyid=0F3A8868-E337-43D1-B271-B8C8702344CD&displaylang=en you will find the following statement:
“Appropriate Uses for ISATAP on Intranets ISATAP in Windows is not designed for production networks [italics mine]. On a production network, ISATAP should be used in a limited capacity for testing while you deploy native IPv6 capabilities. Microsoft does not recommend the use of ISATAP across entire production networks. Instead, you should deploy native IPv6 routing capability…”
Ah, well, ahem, er, kaff-kaff, aaaa.., that doesn’t really align with my comment regarding “in general, ISATAP is a good thing”.
Let me explain.
To get a better appreciation for the situation, it’s a good start to think about what ISATAP actually does. For most of us, our introduction to ISATAP is with DirectAccess. In fact, for many of us, our introduction to IPv6 is with DirectAccess. When reading about DirectAccess you see that the DirectAccess server is configured as an ISATAP router, as well as a router or relay for Teredo and IP-HTTPS. This gives you the initial impression that ISATAP must be a required component of the UAG DirectAccess solution, and that perhaps it’s a standard for all IPv6 deployments. In truth, ISATAP has limited utility and is designed to support a very specific scenario.
ISATAP is an IPv6 transition technology and is designed as a temporary solution to help you transition your IPv4 network to an IPv6 network. ISATAP enables ISATAP capable hosts to automatically assign an address to an ISATAP adapter, and to communicate with an ISATAP router to get IPv6 routing table information. The purpose of ISATAP then is to provide ISATAP capable hosts with information that enables them to connect to hosts on an IPv6 only network. That connection is made through an ISATAP router.
The ISATAP router has an interface on the IPv4 only network and a second interface on an IPv6 only network. The ISATAP router will take the IPv6 packets that are encapsulated in an IPv4 header, and forward them to the IPv6 only network by removing the IPv4 header before forwarding them. When hosts on the IPv6 only network want to connect to hosts on the IPv4 network, the ISATAP router will receive the packets, put an IPv4 header on them, and forward them to the ISATAP enabled hosts on the IPv4 only network.
When ISATAP enabled hosts on an IPv4 only network communicate with each other, they will preferentially use their ISATAP adapters to communicate. They will query DNS and if they receive both A and AAAA records, they will use the AAAA record’s address and use IPv6 to communicate with the other ISATAP enabled host on the IPv4 only network. This is done because Windows hosts that are capable of using ISATAP (Vista and above, Windows 2008 and above) use IPv6 preferentially. It doesn’t matter that the IPv6 packets are encapsulated with an IPv4 header. Keep in mind that in order to reach the ISATAP adapter on the destination host, the source host also needs the address in the A record to get the IPv4 address of the destination.
In Figure 1, you can see three networks:
When a host on the IPv4 only network wants to connect to a host on the IPv6 only network, it uses routing table entries that indicate that it should use its ISATAP adapter to send the IPv6 packets to the IPv4 address ISATAP router. The ISATAP router then removes the IPv4 header to expose the IPv6 header and forwards the IPv6 packet to the host on the IPv6 network.
The UAG DirectAccess server is also configured as an ISATAP router, and it advertises IPv6 routes that ISATAP capable hosts on the IPv4 only network can use to connect to DirectAccess clients. The DirectAccess clients network (which includes network prefixes for the Teredo, 6to4 and IP-HTTPS address spaces) is an IPv6 only network. Therefore, when a host on the IPv4 only network wants to connect to a DirectAccess client, it checks its routing table and finds that it should use its ISATAP adapter to send the IPv6 packets to the IPv4 address on the internal interface of the UAG DirectAccess server. The UAG DirectAccess server (acting as an ISATAP router) removes the IPv4 header and forwards the un-encapsulated IPv6 packet to the DirectAccess client.
Figure 1
As you can see, ISATAP is used to enable connections from an IPv4 only network (meaning the routing infrastructure only supports IPv4 routing) to an IPv6 only network (meaning that the routing infrastructure supports IPv6 and the hosts on the network use only IPv6 addressing) by using an ISATAP router. The idea here is that as you transition to an IPv6 network, you will create dedicated segments devoted to IPv6 and that during this transition, you still need to enable connectivity between the “old” IPv4 only network and the “new” IPv6 only network. The transition phase isn’t meant to be indefinite and when the transition phase of the deployment is over, you’ll disable ISATAP in DNS and take down the ISATAP routers.
However, DirectAccess is a special case when it comes to ISATAP and IPv6 enablement. We want you to be able to use DirectAccess now. However, we also realize that very few networks are IPv6-only at this time and that it will take several years before the predominate network protocol is IPv6. To solve this problem, we enabled the UAG DirectAccess server as an ISATAP router. For the UAG DirectAccess server, the purpose is to enable full “manage out” capability, so that management servers on the IPv4 intranet can initiate connections with DirectAccess clients. We don’t need ISATAP to support connections initiated by DirectAccess clients to IPv4 resources on the intranet because we have the NAT64/DNS64 solution.
The “manage out” scenario where management servers on the intranet initiate connections to the DirectAccess clients is a relatively limited one in terms of scope. You won’t have that many management servers that need to be able to do this (although you might want to allow Help Desk to connect to DirectAccess clients over RDP, in which case the number of hosts that need to initiate a “manage out” connection will be larger). Since you know in advance who these machines are, you might want to consider using a HOSTS file entry on these “manage out” machines instead of enabling ISATAP for your entire network using DNS. This gets around problems you might run into if you’ve decided to disable IPv6 on the computers on your network (you can find out the details of this situation in my blog post at http://blogs.technet.com/b/tomshinder/archive/2011/02/14/use-a-hosts-file-entry-to-control-isatap-host-configuration.aspx).
In conclusion, we can reconcile my statement that ISATAP is generally a good thing when we think about the special case of the DirectAccess. However, the purpose of ISATAP in a DirectAccess scenario is a bit different than it is when you’re using ISATAP to transition your intranet to IPv6. Because a limited number of hosts on the intranet need to be IPv6 capable to initiate connections (manage out) DirectAccess clients, there is a good argument for not enabling ISATAP in DNS (it is disabled by default) and only using HOSTS file entries on the machines that require “manage out” capability to DirectAccess clients.
Most of you probably know this, but before I joined Microsoft I spent most of my time with ISA Server and Threat Management Gateway (TMG). A big part of my life was ISAserver.org (www.isaserver.org). My affiliation with ISAserver.org started in mid-2000 and continued uninterrupted until I joined Microsoft in December 2009. However, even after joining Microsoft, I’ve continued to post to the web forums on ISAserver.org because the community for ISA and TMG and UAG is so active there.
The web forums were my favorite experience at ISAserver.org. From those forums I got to know many people, and became friends with a lot of them, over the years. ISAserver.org brought together people from all over world to have professional and interesting discussions about our favorite firewall: ISA Server (now TMG). I can honestly say that my life would have been a poorer experience if I hadn’t participated and met so many great people because of my involvement with the ISAserver.org web forums.
So yesterday was a big day for me – I hit my 50,000th post on the web forums!
It took 10 years to do it, which means I averaged something like 5,000 posts per year. Of course, the number of posts per day was significantly higher in the days of ISA 2000 and ISA 2004 – ISA 2000 was a complete remake of Proxy Server 2.0 and somewhat of a challenge to understand and then when ISA 2004 was released, it represented a major remake of the user interface and required a lot of new learning. It was with the introduction of ISA 2004 that ISA became a true enterprise ready network firewall.
Because something like this only happens once, I decided to do a short movie of the event. If you’d like to watch the momentous occasion, then check out the video below.
Thanks!
Talk TechNet enables you to get your questions about hot technologies answered in real time. In this session, Dr. Tom Shinder will be here to discuss DirectAccess and what Unified Access Gateway 2010 brings to the DirectAccess table. Tom is a Principal Writer in the Anywhere Access Group and is responsible for UAG DirectAccess content and promoting DirectAccess in the community.
Bring your hard questions about IPv6, IPv6 transition technologies, IPsec, Teredo, 6to4, IP-HTTPS, Name Resolution Policy Table (NRPT), CRL checking and more! DirectAccess is wide and deep, so here's you unique opportunity to "stump the chump!"
Presenters: Keith Combs, Senior Program Manager, Microsoft Corporation, Matt Hester, Senior IT Pro Evangelist, Microsoft Corporation, and Dr. Tom Shinder, Principal Technical Writer, Microsoft Corporation
Head on over to:
https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032477770&EventCategory=4&culture=en-US&CountryCode=US
to Register for the event.
I’ll make sure to remind everyone a couple of days before we go live.
A few people have mentioned on the web forums and in email discussions that they’d like an easy way to disable the IP-HTTPS interface on the DirectAccess client for testing purposes. They don’t want to disable it completely for all clients (which you can do through Group Policy), they just want to disable it for a specific client for a short period of time to figure out what the problem might be with something else.
If you open the network shell (netsh) and check the syntax that you should use to disable the IP-HTTPS interface, you’ll see something like the following:
Syntax set interface [[ url= ] ( url )] [[ state= ] ( enabled | disabled | default )] [[authmode= ] ( none | certificates )]
However, if you try it, you’ll see something like this:
What’s up with that?
Apparently, there is a problem with using netsh to disable the IP-HTTPS interface. Therefore, we’re going to have to consider an alternate approach to temporarily disable the IP-HTTPS interface.
To do this, open the Registry Editor and navigate to:
HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition\IPHTTPS\IPHTTPSInterface\IPHTTPS_ClientState
To disable the interface, set the value to 3.
Keep in mind that this setting is controlled through the UAG DirectAccess client Group Policy. When Group Policy is refreshed on the client, this setting will be overwritten and the IP-HTTPS interface will activate again.
An interesting question came up a few weeks ago regarding DirectAccess and expiring computer accounts. I thought it was an topical question that brought up some issues worth exploring, so I’m sharing with you some thoughts on the problem here.
First a little background. UAG DirectAccess (and Windows DirectAccess) enables the DirectAccess client to connect to the intranet through the use of two tunnels:
The infrastructure tunnel enables the DirectAccess client to reach computers on the intranet that are part of an administrator defined “management servers” group. The DirectAccess client uses this tunnel to communicate with domain controllers, update servers and other servers that you’d like the DirectAccess client to be able to connect to before the user logs on.
The intranet tunnel is opened after the user logs onto the DirectAccess client computer. This tunnel enables access to the rest of the intranet.
Both the intranet and the infrastructure tunnels require two forms of authentication to succeed before the tunnels are established.
For the infrastructure tunnel, the DirectAccess client must be able to succeed at:
For the intranet tunnel, the DirectAccess client must be able to succeed at:
Note that in order to perform Kerberos authentication, you need to have connectivity to a domain controller. The domain controller should be reachable through the infrastructure tunnel that was established before the user attempts to log on.
With that understanding in place, you can see if that a computer account had expired for some reason, the infrastructure tunnel could not be created, since it depends on computer account (NTLMv2) authentication. And if you can’t get the first tunnel opened, you can’t get the second tunnel opened (the intranet tunnel), since the Kerberos authentication required for the second tunnel depends on the first tunnel coming up.
So what would happen if a computer account password expired? Nothing. The reason for this is that the computer itself is responsible for changing its password. If the computer is offline for six months and then brought online, nothing bad will happen. The computer will change its password when it starts up. This means that if for some reason a DirectAccess client computer is offline for more than 30 days (the default value for computer account password expiration) there won’t be any problems connecting to the intranet and establishing both of the IPsec tunnels.
For more information on how computers change their computer account passwords, see http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx
However, there is one scenario that might be problematic, and if you manage a DirectAccess deployment, you might want to take this into consideration. Some firms “clean up” their computer accounts on a periodic basis. During the clean-up, they might disable the stale computer accounts, or they might delete them. In this scenario, the DirectAccess client will not be able to establish the infrastructure tunnel and therefore will not be able to establish the intranet tunnel. If the computer account is disabled, it will need to be enabled. If it was deleted, the computer will need to leave the domain and rejoin the domain; this can be done over an SSTP connection.
ISATAP is an optional configuration option you can take advantage of when working with UAG DirectAccess. What ISATAP allows you to do is automatically assign IPv6 addresses to computers on the network that already have IPv4 addresses (which is going to be all of them). The advantage conferred when using ISATAP is that you can have an entirely IPv4 infrastructure (that is to say, your routers don’t support IPv6 and you haven’t done anything to enable IPv6 on your network) is that you can initiate connections from computers on the intranet to DirectAccess clients that are located somewhere on the Internet.
ISATAP clients can do this because they tunnel IPv6 messages inside an IPv4 tunnel. When traveling over the intranet, the IPv6 messages move over the network inside the IPv4 header and when they reach the destination, the IPv4 header is removed and the IPv6 header is exposed and the packet is then received by the ISATAP tunnel adapter. When the ISATAP host connects to a DirectAccess client, it connects to an IPv6 only host (the DirectAccess client), since DirectAccess clients only communicate over IPv6 when connecting to resources on the intranet.
This works by sending the packets from the ISATAP enabled host on the intranet to the ISATAP router on the UAG DirectAccess server. When the ISATAP enabled host on the intranet tries to connect to a DirectAccess client, it sends the IPv4 encapsulated IPv6 packet to the ISATAP router on the UAG DirectAccess server. When the packet arrives at the UAG DirectAccess server, the ISATAP router removes the IPv4 header and forwards the IPv6 packet to the DirectAccess client. And when the DirectAccess client returns its response, the IPv6 packet is sent to the UAG DirectAccess server, and then the ISATAP router on the UAG DirectAccess server encapsulates that IPv6 packet with an IPv4 header and forwards it to the ISATAP host on the intranet.
In general, ISATAP is a good thing, but it can create some potential issues. First, you need to be aware that in order to configure their ISATAP adapters, the ISATAP enabled hosts need to be able to resolve the name ISATAP. Usually, you put a host (A) record for ISATAP in your DNS and all machines can then resolve this name to configure their ISATAP adapters. Since all Vista and above and Windows Server 2008 and above hosts are automatically configured as ISATAP enabled hosts, all of these machines will automatically configure their ISATAP adapters after they resolve the ISATAP name.
The problem is that not everyone wants to enable IPv6 on their networks. For a number of reasons, some firms want to disable IPv6 on the machines on their networks. The problem is that if you disable IPv6, but leave the ISATAP adapter enabled, the NAT64/DNS64 feature won’t work when the DirectAccess clients try to connect to these machines. The reason for this is that when the ISATAP adapter initializes, it registers its IPv6 ISATAP address in DNS automatically. When the DirectAccess client resolves the name of the host that has IPv6 disabled but ISATAP adapter enabled, it will get a quad A (AAAA) record and try to connect to that host using its IPv6 address. But since IPv6 is disabled on that host, the connection attempt will fail.
In practice, very few hosts on the intranet need to be able to initiate connections to the DirectAccess clients. Only management servers, and maybe computers assigned to corporate IT need this kind of access, and perhaps computers run by the Help Desk. If you’ve decided to disable IPv6 on your network, you might be better served by not putting the ISATAP address in DNS. Instead, put the ISATAP entry into the HOSTS file of the machines that need to initiate connections to the DirectAccess clients.
In this case, there is no ISATAP entry in DNS, so hosts without an ISATAP entry in their HOSTS file will not enable their ISATAP adapters. The machines that have an ISATAP entry in their HOSTS files will be able to resolve the name ISATAP and they will enable their ISATAP adapters and they will then be able to initiate connections to DirectAccess clients. With this configuration, the DirectAccess clients can use the UAG DirectAccess server’s NAT64/DNS64 to connect to the hosts that don’t have ISATAP enabled, and they will be able to use IPv6 to connect to the ISATAP enabled hosts that have the ISATAP entry in their HOSTS files.
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!
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!