Great news! Last week we released the Release Candidate of UAG Service Pack 1. If you haven’t heard about this, then check out the UAG Team Blog post on this subject at http://blogs.technet.com/b/edgeaccessblog/archive/2010/10/21/announcing-forefront-uag-2010-service-pack-1.aspx
However, most organizations don’t want to deploy pre-release software in their production environment. I’ve always said “don’t make your production network your Test Lab”
But you want to see all the new and cool things that UAG SP1 RC has to offer, especially the cool DirectAccess improvements. How do you do that?
Test Lab Guides!
You can test UAG SP1 RC in a safe and sane Test Lab using our new Test Lab Guide format. The new Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess will walk you through configuring a basic working DirectAccess configuration using UAG SP1 RC. You’ll all see the new DirectAccess Monitor – which allows you to get information on who’s connecting through the DirectAccess tunnels.
There will be many more UAG SP1 RC DirectAccess Test Lab Guides published this week, so stay tuned!
Download the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess over at:
http://go.microsoft.com/fwlink/?LinkId=204993
HTH,
Tom
Tom Shinder tomsh@microsoft.com Microsoft DAIP iX/SCD iX UAG Direct Access/Anywhere Access Group (AAG) The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
So you’ve gone through our excellent Test Lab Guides (which you can find at http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx) and you’ve read the UAG DirectAccess design guide (http://technet.microsoft.com/en-us/library/ee406191.aspx) and the UAG DirectAccess deployment guide (http://technet.microsoft.com/en-us/library/dd857320.aspx). You’ve got the critical hands-on and the key background information after going through those.
What next?
What would be really handy is high level plan of the steps you need to go through as you roll out your pilot project. This is where Jason Jones, Forefront MVP, comes in. He’s published a very handy pair of documents that will really help you clarify your plan.
Check out Jason’s Deploy Forefront UAG DirectAccess in 8 Easy Steps at http://blog.msedge.org.uk/2010/10/deploying-forefront-uag-directaccess-in.html
And if you’re into creating a UAG DirectAccess Array (and most enterprises are going to be deploying arrays), check out his Deploying a Forefront UAG DirectAccess Array in 10 Easy Steps at http://blog.msedge.org.uk/2010/10/deploying-forefront-uag-directaccess.html
Make sure to put Jason’s blog in your Favorites – he’s always coming up with great design and deployment information for UAG DirectAccess on his blog.
“Why does SharePoint ask for credentials when I connect over DirectAccess?”
There is a very long thread on the TechNet forums regarding an unusual authentication issue when DirectAccess clients try to connect to SharePoint sites. There were a lot of posts and a lot of effort was made to determine the nature of the problem. The good news I have for you today is that we’ve solved the problem and have published a fix!
The problem was due to the fact that the automatic logon level for Windows HTTP Services (WinHTTP) is Medium. When the automatic logon level is set to Medium, it prevents the user credentials from being automatically sent to the web server. The end result is that the address is considered an Internet server when you try to access the WebDAV resource like SharePoint which leads to you being asked for credentials.
Here’s the fix for the problem:
http://support.microsoft.com/kb/2288297
Shannon Fritz, who’s well known on the UAG DirectAccess forums at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads for providing excellent community answers and insight, has put together a very nice UAG DirectAccess Configuration Guide. In Shannon’s configuration guide, you’ll find the following sections:
Check out all this and more over on Shannon’s blog at:
http://blog.concurrency.com/infrastructure/uag-directaccess-configuration-guide/
(Updated Oct 5, 2010)
I’ve seen a number of questions asking if there was a method you could use to migrate your Windows DirectAccess configuration to a UAG DirectAccess deployment.
The answer to this question is that there is no automated method to do this. However, the manual steps aren’t very difficult. Here’s what you need to do:
That’s all there is to it!
Now you can install UAG on the server that you had configured as the Windows DirectAccess server, or you can install UAG on a completely different server.
Let me know if you run into any issues with your migration from Windows DirectAccess to UAG DirectAccess. If this scenario is popular enough, I’ll put together a Test Lab Guide that demonstrates the process!
(Thanks to Yaniv Naor for the heads up on this)
(Thanks to Pat Telford for the information included in the update)
The answer is “no” – but its important to understand the function of ISATAP and why or why not you might consider deploying ISATAP in your environment.
ISATAP is the Intra-site Automatic Tunnel Addressing Protocol. The purpose of ISATAP is to allow you to use IPv6 aware applications on a network that hasn’t moved to an IPv6 infrastructure – or what we often call “native IPv6”.
A native IPv6 network has all it’s network infrastructure aware of and configured to support IPv6. This can include routers, switches, DNS, DHCP, network IDS and other network-centric applications. When the entire infrastructure is aware of IPv6 and all the clients and servers on the network work natively with IPv6 and use globally routable IPv6 addresses, then you have what we would call a native IPv6 network.
However, there are very few native IPv6 networks out there in the wild. One of the reasons for this is that not all of our server operating systems or server applications or client-side applications are IPv6 aware or IPv6-capable. Some are, but likely most aren’t.
So how do you enable your IPv6 aware applications to work in an IPv4 network infrastructure? One way to do that is to use something to help you during your transition to IPv6 (the time it takes to complete that transition may be months, years, or decades). That’s the function of ISATAP, to help you deploy IPv6 applications while you’re “in transition” from an IPv4 network to an IPv6 network.
The way it works is that the ISATAP adapter on the ISATAP enabled host will encapsulate the IPv6 packets in an IPv4 header to allow routing of those packets through your IPv4 infrastructure. The ISATAP adapter is assigned a “real” IPv6 address (an ISATAP address that is based on a IPv6 prefix obtained from an ISATAP router and a host ID based on the IPv4 address of the ISATAP enabled host), and that address is registered in DNS (if your DNS server is configured to accept dynamic updates).
Applications that are IPv6 capable will preferentially use the ISATAP adapter to communicate with other IPv6 systems on your network. The end result is that you have enabled IPv6 addressing on your clients and servers (that are ISATAP capable) and they can still communicate over your IPv4 routing infrastructure.
Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 are all IPv6 capable operating systems – which means you can assign them a globally routable IPv6 address (sometime referred to as a “native” IPv6 address), or you can assign them ISATAP addresses, which are still valid IPv6 addresses, they’re just not globally routable. However, in order for ISATAP capable hosts to configure their ISATAP IPv6 address, they need to get information from an ISATAP router. When you use the UAG DirectAccess solution, the UAG DirectAccess server or array will act as your ISATAP router.
If you’re using the Windows DirectAccess solution, which is part of the Windows Server 2008 R2 platform, you need to be able to assign IPv6 addresses to all intranet hosts that you want the DirectAccess clients to connect to. If you are using globally routable IPv6 addresses on your network then your work is done – and DirectAccess clients will be able to connect to all hosts with globally routable IPv6 addresses and reach all subnets on your intranet using your IPv6 aware routing infrastructure. However, if you don’t have a native IPv6 network yet, then you will need to find another way to assign IPv6 addresses to the hosts you want the DirectAccess clients to connect to – and that way is to deploy ISATAP.
However, if you are using the UAG DirectAccess solution, you have another option. You can avoid IPv6 addressing on your intranet altogether and take advantage of the UAG DirectAccess server’s NAT64/DNS64 IPv6/IPv4 protocol translator. When you use these two technologies that are available only with the UAG DirectAccess solution, DirectAccess clients can connect to IPv4 resources on your intranet. For more information on how NAT64/DNS64 work, check out the UAG Team Blog over at http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx
However, NAT64/DNS64 is similar to other NAT solutions. Some applications don’t work well with NAT. In addition, the NAT64 solution doesn’t allow for “reverse NAT” from the intranet to the DirectAccess clients. What this means is that if you want to initiate a connection from IPv4 only client or server on the intranet to a DirectAccess client on the Internet, you won’t be able to, because that would be a “reverse NAT” scenario and we don’t support reverse NAT with the current version of NAT64. Because of this, your “manage out” capabilities are limited somewhat.
So to answer the question “do you need ISATAP?”, the answer is “no”. However, your manage out capabilities will be limited.
“Manage out” is a term we use informally for remote management. There are actually two manage out scenarios:
When you have an IPv4 only network and none of your intranet resources are IPv6 capable through ISATAP, then only the first “manage out” scenario is available to you. The second one requires that the management server on the intranet be IPv6 capable, using either a native IPv6 address or one assigned by ISATAP.
The reason why you need IPv6 to manage out is related to the fact that the DirectAccess client only uses IPv6 to connect to the intranet. This connection is initially terminated as an IPv6 IPsec tunnel on the external interface of the UAG DirectAccess server. When the DirectAccess client establishes it’s connection to the UAG DirectAccess server, it also registers it’s own IPv6 address in the corporate DNS. If you want to connect to the DirectAccess client, you have to use its IPv6 address. You can do it directly by connecting to its IPv6 address, or you can connect to the DirectAccess client by the name it registered in DNS.
If an IPv4 server on the intranet tried to connect to the DirectAccess client, it would send a name query to the DNS server and receive only a AAAA record. Since the IPv4 only host doesn’t know what to do with a AAAA record, it will not be able to connect to the IPv6 address of the DirectAccess client.
The answer it that it depends on what you need and your constraints.
In general, if you don’t have a native IPv6 network yet, it’s a good idea to deploy ISATAP. That will enable the DirectAccess clients to connect to your ISATAP hosts on the intranet by using IPv6 from end to end – which creates fewer application/NAT related issues. It also allows your ISATAP capable management servers to support the manage out scenario where those servers need to initiate connections to the DirectAccess clients. The only reason why you might not want to deploy ISATAP is if you have investments in network IDS gear that doesn’t understand ISATAP. In addition, when using the UAG DirectAccess server as your ISATAP router, your entire IPv4 infrastructure will be represented as a single IPv6 ISATAP cloud. Depending on your environment, this may or may not be problematic.
In addition, you can reduce the load on the UAG DirectAccess servers by taking advantage of both ISATAP and NAT64/DNS64. The reason for this is that it takes memory and processor cycles to process the NAT64/DNS64 sessions. If you deploy ISATAP, you reduce the number of sessions that require NAT64/DNS64 and potentially increase the number of connections per server in your UAG DirectAccess array.
Of course, the best of all possible worlds is that you have a native IPv6 network, and all your network devices, servers and clients and IPv6 capable. Then you never have to worry about IPv4 only resources – but that’s not likely to happen in the near future.
I hope this clears up the issue for you a bit. if you still have questions, please feel free to write to me at the address you see in my sig line.
Over the last few months I’ve been having some conversations with a number of people about the Test Lab Guides and the Business Ready Security (BRS) demo environment. For those of you who haven’t seen the BRS Demo environment, it is a collection of virtual machines and step by step documentation that provides a “hands-on lab” experience for all the technologies and server applications that are part of the Forefront line of products. You can find a full description of the BRS demo and how to download the virtual machines and documentation over at
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=726f943e-d107-4b4d-a86e-dfb605e30ce5&displaylang=en
On the other hand, Test Lab Guides provide information on how you can create your own Test Lab, so that you can see how a product or technology works in your own Test Lab. Test Lab Guides have you build out both the front-end and back-end components of the solution so that you can learn more about how all the pieces that enable the solution to work fit together. You can find more information on Test Lab Guides over at
http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
And for a comprehensive list of the currently available Test Lab Guides, check out the Test Lab Guide clearinghouse over on the TechNet Wiki at
http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx
Both the BRS demo and the Test Lab Guides are useful for their intended purposes. The BRS demo provides a convenient method to demonstrate all the products that participate in the Forefront family of products. All the virtual machines are created for you, and both the front end and back end of each of the solutions is preconfigured. The scenarios are built out to support the scripts (documentation) that are included with the demo. Like “hands on labs” they provide a nice introduction to some of the things each of the products covered in the BRS demo can do.
We like to think of the BRS demo as the first step. After you see what the products can do, you’ll probably want to see how you can built out your own solutions based on the technologies you saw demonstrated in the BRS demo. The problem is “where do you start”? The BRS demo doesn’t document the comprehensive back-end configuration that was required to make the solutions work, nor does it provide you guidance so that you can replicate the BRS demo environment so to have a better understanding of the products and technologies that you’re interested in. In addition, it’s difficult to customize the environment or update it it to support new versions of the product, service packs, etc. Sure, you could cobble together your own test lab, pull down the planning and deployment guides for those technologies, and hope that you’ll be able to come up with a working solution. Sometimes that works, and sometimes it doesn’t – and whether it works or not, it takes a long time for you to figure out what needs to be done.
That’s where the Test Lab Guides come in. With the Test Lab Guides (TLGs), we provide you a standardized, tested, and proven methodology that you can use to quickly build your own Test Lab.The TLGs are designed to provide you with end-to-end information on how to build a Test Lab, using a modular format that enables you to re-use your Test Labs and test additional scenarios. You get coverage of both the front-end and back-end, and you learn the requirements and the terminology while building out the Test Labs. In addition, the labs include a lot of tips and tricks, as well as validation information so that you can avoid common pitfalls that you might run into when deploying the product or technology in your production environment. After you go through a Test Lab Guide, you’ll find that the information you read in the planning and design guides will end up making a lot more sense.
We’re working on trying to get all the Forefront product teams to produce some Test Lab Guides – however, since this is a new initiative, it takes a while to get everything in line. So, there are a number of products covered in the BRS demo that we don’t have Test Lab Guides out for yet. But if everything goes the way we want it to – there will be TLGs for all of them, and also for a number of cool features included in the Windows platform itself.
If you have any questions about the Test Lab Guides or the BRS demo, and which one might work best for you and your intended purpose, please feel free to write to me at the address in my sig line.
You might have noticed that the Edge Man has been absent for a while (at least I hope you’ve noticed). The reason for my absence is that I was doing some interesting work on the upcoming UAG Service Pack 1 over in the Israel Development Center (ILDC). And I have some great news for you! UAG Service Pack 1 is going to include a number of new features and capabilities that you’ve been asking for.
I tested most of these new features and found that the new user interface was cleaner and more intuitive than what we have now, which is really going to help the new UAG DirectAccess administrator. Even better, everything I tested worked!
While I can’t tell you the schedule for the release of the Service Pack at this time, you should be seeing a release candidate of UAG Service Pack 1 sometime in the next couple of months. I really hope you all get a chance to play with UAG SP1 in your own test labs, as I’m sure you are really going to like the new options we’ve exposed to you that will make it easier than ever to get a working DirectAccess configuration and deployment that meets your organization’s requirements.
Some more good news – I plan to release some updates to the UAG DirectAccess Test Lab Guides (TLGs) at the same time that the RC of the Service Pack is released. I consider this to be very important as a working TLG is the best way for you to get quickly up to speed on a new product or technology. If you haven’t seen the TLGs we already have, then check them out on the TechNet wiki over at http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx
If you haven’t got into the TLG swing of things yet, and you think you’ll want to check out UAG SP1 in a lab – then I recommend you prepare for it by building out the Base Configuration. Once you have the Base Configuration in place, putting together the UAG SP1 RC test lab will be a no brainer!
Check out the Base Configuration Test Lab Guide over at:
http://go.microsoft.com/fwlink/?LinkId=198140
I’m thinking of putting together a Test Lab Guide module for configuring end-to-end security for UAG DirectAccess clients and selected application servers on the intranet, so I configured the scenario in the Test Lab to see how it worked. I figured that since everything is working in the Test Lab now, I should take some time to share with you what end-to-end security looks like when you configure it using the UAG DirectAccess wizard.
If you want to follow along with what I’m describing in this blog post, you can fire up your UAG DirectAccess lab if you have a snapshot handy. If you haven’t completed the UAG DirectAccess lab yet, then you might want to download the Test Lab Guide: Demonstrate UAG DirectAccess (http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=c243c30c-6476-4061-9520-124710dbdd27) and you can get a snapshot saved. Then you can see how the same things I describe in this blog post in your own Test Lab.
Before I go into the details, it’s worth going over some basic UAG DirectAccess concepts. UAG DirectAccess supports two types of network security access models:
Note that ESP null encapsulation is different than (ESP)-NULL. With null encapsulation only the first packet of the connection is authenticated, so that the remainder of the communications are available to the IDS for inspection. For more information on this subject, see http://technet.microsoft.com/en-us/library/ee382325(WS.10).aspx
Also, if you want to do end-to-end security, the server on the intranet needs to be IPv6 capable, which means it has a native IPv6 address or an ISATAP address. This essentially limits your servers to being Windows Server 2008 and above, although there products available that you can use to enable non-Microsoft servers to participate end-to-end IPsec security, but I won’t go into those methods today.
If you want to enable end-to-end security, you’ll need to assign the intranet servers to groups that can be used by the object-picker used in the UAG management console. You can use existing groups if you like, but in most cases you’re probably better off creating your own groups for this purpose. The figure below shows that I’ve created a group called AppServers and I’ve added the APP1 computer account to that group.
Figure 1
Open the UAG management console on the UAG DirectAccess server after you create the group. In the UAG Management console, click the Configure or Edit button in the Application Servers section (it will say Edit if you’ve already configured DirectAccess, and it will say Configure if this is the first time you’ve configured DirectAccess).
Figure 2
On the Application Server Configuration page you’re given the option to Require end-to-edge authentication and encryption and Require end-to-end authentication and encryption to specified application servers. These “options” aren’t really options, as you must always have end-to-edge encryption and authentication. Remember, end-to-edge security represents the security delivered by the IPsec tunnels between the DirectAccess client and UAG DirectAccess server.
However, the Require end-to-end authentication and encryption to specified application servers option is an option. If you want to require end-to-end security between the DirectAccess client and the server on the intranet, you will need to select this option and then click Add to add the groups that contain the computer accounts of the servers that you want end-to-end security enforced.
Figure 3
Notice in Figure 3 that there is a link for Edit IPsec cryptography settings. You might run into some issues using that link if you’re using UAG RTM, so if you want to change the Quick Mode settings, it’s best to do it in the Group Policy Object that’s created for the Application Server connections. However, it should work fine with UAG Update 1 and above. Make sure to confirm. If you don’t use Update 1 (which shouldn’t be the case since you should always install it, but we didn’t have Update 1 available when the Test Lab Guide was written.) You can see where this is done in Figure 4. I won’t go into the details on how to do this, but if you are already comfortable with IPsec configuration, it’s relatively easy. However, each time you redeploy the UAG Group Policy settings when using the UAG DirectAccess wizard, you should confirm that your custom changes have been retained; you may need to reconfigure them.
Note that the name for the Application Servers Group Policy Object is:
Figure 4
(UAG DirectAccess: AppServer{f7b77f47-7c33-4d8c-bb9a-a913c5675d8d}
Figure 5
After you make the changes in the UAG DirectAccess wizard in the UAG management console, you need to deploy the settings. After the GPO settings are deployed, make sure you refresh Group Policy on the Application Servers and the DirectAccess clients so that they receive the new Connection Security Rules. You can use gpupdate /force to do this in the Test Lab.
After Group Policy is refreshed, you can go to a DirectAccess client and open the Windows Firewall with Advanced Security console and check the Connection Security Rules. You will see a new Connection Security Rule named UAG DirectAccess Client – Clients E2E Authentication.
Figure 6
If you double click on the rule you’ll see on the General tab the description that explains that the policy is to enable secure corporate resources over IPsec.
Figure 7
On the Computers tab, you see in the Endpoint 2 section that the rule is applied when the DirectAccess client connects to the IPv6 address of the secure server on the intranet. This is why end-to-end security only works when the DirectAccess client connects to IPv6 capable hosts – the Connection Security Rule needs to use the IPv6 address of the secure server on the intranet. In the example in Figure 8, that address is assigned to APP1.
Figure 8
When you click on the Protocols and Ports tab, you can see that the rule applies to all protocols, as seen in Figure 9.
Figure 9
Click on the Authentication tab. Note that the authentication mode is to Require inbound and outbound authentication. Click the Customize button.
Figure 10
This brings up the Customize Advanced Authentication Methods dialog box (Figure 11). Remember, you can’t change anything here because these settings are managed via Group Policy, but you can see what the Group Policy controlled settings are. Both Computer certificate and user Kerberos authentication is required to establish the secure IPsec connection between the DirectAccess client and secure server on the intranet.
Figure 11
Click on the Advanced tab (Figure 12) and you’ll see that this rule is active only for the Private and Public profiles. This is important because you want these settings to apply only when the DirectAccess client is acting as a DirectAccess client; that is to say, when the DirectAccess client is off the intranet. When the DirectAccess client is on the intranet, you don’t want this Connection Security Rule to activate. The reason for this is that you might have other Connection Security Rules and IPsec policies that you want your intranet clients to use, perhaps as part of your Server and Domain Isolation configuration.
Figure 12
After you establish a connection to the secure server (I did a net view \\APP1 in this example), click the Monitoring\Security Associations\Main Mode node and expand the Remote Address column. There you will see a Main Mode SA with APP1 to its IPv6 ISATAP address, using both Computer Certificate and User (Kerberos V5) authentication, as seen in Figure 13.
Figure 13
Double click on the Main Mode SA to the secure server on the intranet and you can be more details. As you can see in Figure 14, the name of the user is listed, as well as the encryption and integration methods used by the connection.
Figure 14
Similarly, if you click on the Quick Mode node in the left pane of the console, you’ll see the Quick Mode SA established with APP1 on the intranet. Here you can see the local and remote address, and the integrity and encryption methods used for the connection, as seen in figure 15.
Figure 15
Now that we’ve seen what things look like on the DirectAccess client, let’s move our attention to the secure server on the intranet. If you’re following along with the Test Lab Guide, open the Windows Firewall with Advanced Security console on APP1 and click on the Connection Security Rules node in the left pane of the console. Here you’ll see that there are two new rules: UAG DirectAccess AppServer – Clients E2E Authentication and UAG DirectAccess AppServer – HTTPS Clients E2E Authentication, as you can see in figure 16.
Figure 16
Why are there two Connection Security Rules? To get a clue, double click on the UAG DirectAccess AppServer – Clients E2E Authentication rule and click on the Computers tab (figure 17). Here you can see that Endpoint 1 has two IP address ranges. One of the ranges reflects the addresses that are assigned to Teredo DirectAccess clients and the other is for 6to4 DirectAccess clients. Endpoint 2 represents the secure server on the intranet, so no IP address needs to be assigned there.
Figure 17
Click on the Advanced tab (figure 18). Notice that the Connection Security Rule is assigned to the Domain profile. The reason for this is that the secure server on the intranet isn’t going to be moving anywhere, so there’s no reason to have the rule apply to Private or Public Profiles.
Figure 18
Now let’s take a look at the other Connection Security Rule, UAG DirectAccess AppServer – HTTPS Clients E2E Authentication. Double click on that rule and click on the Computers tab. Notice the address range for Endpoint 1. If you’re been working with DirectAccess for a while, you might recognize this IPv6 address range. If not, this range represents the DirectAccess clients that are using IP-HTTPS to connect to the UAG DirectAccess server.
Figure 19
In the article we took a short look at some of what you’ll see when configuring end-to-end security between the DirectAccess client on the Internet and a server on the intranet. In contrast to IPsec tunnel mode that is used to connect the DirectAccess client to the UAG DirectAccess server, the DirectAccess client uses IPsec transport mode to connect to the secure server on the intranet. When you configure end-to-end security, the UAG DirectAccess wizard will create new Connection Security Rule that are applied to the DirectAccess clients and secure servers on the intranet. You can use the Windows Firewall with Advanced Security console to see the Connection Security Rules and the status of the IPsec connections.
This article is just an short introduction to end-to-end security. I plan to put together a Test Lab Guide on configuring UAG DirectAccess with end-to-end security, so keep your eyes open for it! See you soon –Tom.
We’ve seen a lot of questions on how to get the Citrix client to work with DirectAccess. The following provide some information and procedures that may work to get the Citrix client to work over DirectAccess.
The Citrix client can use IPv6 to connect to one type of server only: the Citrix Secure Gateway (CSG). In order for the Citrix client to work over DA, you need to:
A key issue to be aware of is that Citrix clients do not support IPv6, with the exception of connecting to the Citrix Secure Gateway (CSG). Although it can sit directly on the internet, it’s preferred that it be put it on the LAN, with an IPv6 address (either native or ISATAP). Here’s how it works:
In configuring the CSG, note should be taken in http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp5fp-w2k8/sg-features-v2.html to use the IPv6 address to listen on.
Note: The client plug-in needs to be version 11 and above and must trust the CSG’s server certificate.
Finally, it appears that even though the Citrix client is able to connect over IPv6 to the CSG, it needs the CSG’s name to resolve to both the IPv4 address and the IPv6 address. For this to happen, we need to exempt the name of the CSG from the NRPT in the UAG DirectAccess configuration so that it uses an internal DNS server instead of the UAG DNS64. This is done by entering the IP address of the internal DNS server. Not doing this will default to the UAG DirectAccess server’s DNS64 services, which never returns IPv4 addresses (it always returns a NAT64 address), causing issues for the Citrix client.
An example of how you can configure this is included in the figure below.
A common question I see on the message boards and in conversations with our DirectAccess customers relates to the IPv6 transition technology interfaces that are active on the DirectAccess client at any point in time. Most often, the question comes up about why both the Teredo and IP-HTTPS interfaces are active at the same time. And when they are both active, which one is actually being used to transfer information between the DirectAccess client and UAG DirectAccess server?
I wondered the same thing for a long time – but the answer was available in the TechNet library and I didn’t even know it. The following is from the TechNet entry DirectAccess Client Connection is Slow which you can find at http://technet.microsoft.com/en-us/library/ee844161(WS.10).aspx :
“The DirectAccess client needs to determine which of these two transition technologies to use. IP-HTTPS and Teredo both attempt qualification of their interface state at the same time. If the Teredo interface is qualified, the IP-HTTPS client waits in an offline state for a computed delay for the DirectAccess client to detect corporate connectivity. The computed delay is either ten seconds or a network delay larger than ten seconds based on the round trip time of TCP packets from the client to the public IPv4 address of the DirectAccess server. If the DirectAccess client detects corporate connectivity within this network delay, the IP-HTTPS client will remain in an offline state. If the DirectAccess client does not detect corporate connectivity within this network delay, the IP-HTTPS client will attempt to qualify again.
Using IP-HTTPS for DirectAccess connectivity has higher overhead and lower performance than Teredo. If the DirectAccess client is using IP-HTTPS instead of Teredo, the DirectAccess client will have a lower performance connection.
However, due to network timing issues, it is possible for the DirectAccess client to have both Teredo and IP-HTTPS interfaces active, but use only the IP-HTTPS interface for traffic to the intranet. This condition occurs when the DirectAccess client takes more than the computed delay for the DirectAccess client to determine corporate connectivity over the Teredo interface. To test for this condition, run the ipconfig command at a command prompt. If you have global addresses on both the Teredo and IP-HTTPS tunnel interfaces, this condition has occurred.”
So there you have it. The Teredo and IP-HTTPS interfaces will both come up if corporate connectivity isn’t detected within the specified time interval. And when you see both interfaces active, it’s the IP-HTTPS adapter that’s passing the traffic.
For more information about Corporate Connectivity checking, see:
http://technet.microsoft.com/en-us/library/ee382273(WS.10).aspx
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
It’s done! The last in the set of UAG DirectAccess Test Lab Guides (at least for now, the effort is a continuous one).
If you haven’t heard about our Test Lab Guide efforts, check out:
In the troubleshooting UAG and NAP Test Lab Guide we go through a number of DirectAccess and NAP scenarios where we break something in the configuration and then use a number of DirectAccess and NAP troubleshooting tools to see what their output looks like when things get broken. Its a great way to get familiar with these tools and develop skills on how to troubleshoot problems with NAP in a UAG DirectAccess environment.
You can download the Troubleshooting UAG DirectAccess with NAP Test Lab Guide over at:
http://www.microsoft.com/downloads/details.aspx?FamilyID=e4037e34-09e7-41ab-a6d9-029394eb2d3d&displayLang=en
We also have a Troubleshooting UAG DirectAccess Test Lab guide which walks you through a number of scenarios where you break various components of UAG DirectAccess and then use a number of tools to solve the problem. It’s a fantastic way to learn some of the inner workings of DirectAccess and enables you to get that critical hands-on experience you need to troubleshoot UAG DirectAccess problems. You will learn something new about DirectAccess after going through this Test Lab Guide!
You can download the Troubleshooting UAG DirectAccess Test Lab Guide at:
Check out these Test Lab Guide and let me know what you think. We have other Test Lab Guides and we keep a clearinghouse of the available Test Lab Guides on the TechNet wiki. To see a list of currently available Test Lab Guides, head on over to:
If you have an idea for a new Test Lab Guide for us to put together, then let me know! Send a note to tomsh@microsoft.com and put in the title New Test Lab Guide Suggestion. Or, if you think you can do a better job, write your own Test Lab Guide extension on the wiki.
Also, if you have any questions about the UAG DirectAccess Test Lab Guides, please feel free to post questions on the UAG DirectAccess forum over at:
http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/threads
I’ve always recommend that you when learning about DirectAccess that you begin your trek with the UAG DirectAccess Test Lab Guide over at http://www.microsoft.com/downloads/details.aspx?familyid=CEEBFF8D-CDF9-4AFA-8DAA-918CDC884DC0&displaylang=en
However, I know there are a lot of cowboys out there (heck, I’m one of them) and often we want to try things out on a live production network just too see how it works. Then when things don’t work, we’ll go to the Test Lab Guides to figure out what didn’t work by creating something that’s known to work. That’s what the Test Lab Guides are all about!
I was talking to one of my “cowboy” friends a couple of weeks ago and he was telling me that he was having some problems getting IP-HTTPS working. His 6to4 configuration was working fine and DirectAccess connectivity was working through both the intranet and infrastructure tunnel.
Take a look at the figure below. What he did was create a DMZ behind his firewall that used public addresses so that he could test 6to4. This will work if the DA client is located between the firewall and the UAG DA server, but wouldn’t work from the Internet. That was OK, since he wasn’t trying to make it work from the Internet yet – he just wanted to do some live testing.
Key components of the configuration:
At this point can you figure out why his IP-HTTPS adapter wasn’t firing up?
The answer is that since the DA client in the DMZ was assigned a public DNS server address, and that there is a server that is authoritative for the domain.com domain that included a host record for uag.domain.com, the DA client tried to connect to the actual internet based server with that name and not the UAG DirectAccess server that he configured as his test DirectAccess server.
So if you want to be a cowboy and not start with the Test Lab Guides, then watch out for DNS issues! Or, you can take your momma’s advice
BTW – you can always ask questions about DirectAccess and Test Lab Guides over on the TechNet forums over at http://social.technet.microsoft.com/Forums/en-us/forefrontedgeiag/threads
Tom Shinder tomsh@microsoft.com Microsoft ISD iX/SCD iX UAG Direct Access/Anywhere Access Group (AAG) The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
One of the most difficult decisions you have to make as an administrator and network engineer is to decide how you’re going to allocate your limited time to evaluating new products and technologies. There are so many other things you need to do. So when you make the decision to try out a new technology you’re actually taking a significant risk and gambling with your time.
If you win, you’ll be the hero and can begin long process that goes toward a production deployment. If you lose, you’ve wasting many hours on something that you thought sounded good, but ended up not getting it to work.
I feel that pain and have felt that pain in the past. One thing that has created a lot of pain for me was trying to figure out how to do a proof of concept test of a new and complex technology. While I might have figured out how to make the thing work in a test lab, it’s an entirely different ball of yarn to translate that test lab experience to a useful proof of concept.
So I put my thinking cap on and asked around to get some ideas on how to create a proof of concept lab guide that would provide a simulated environment that could closely mirror what you would do in a “live” proof of concept, where you might have 10-20 people from the IT group and maybe some power users from the employee base to participate in.
What I came up with was a UAG DirectAccess Proof of Concept Lab Guide that would walk you through the steps of putting together a proof of concept test lab. The goals of the POC lab guide were:
A key issue with the POC guide is that we wanted to break out the UAG DirectAccess forest from the production forest. There are a few reasons for this:
After you finish the POC lab guide you’ll have a much better understanding of how you might approach the deployment of a limited POC. After completing the POC you’re ready to start a larger pilot program – where more users are involved and the machine accounts are in the production forest instead of the UAG DirectAccess forest.
You can find the UAG DirectAccess POC guide over at:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=2ba2e429-1385-4253-9667-63c2c85747e7
Finally, I have to tell you that the POC lab guide isn’t built to the Test Lab Guide specifications that I talk about over at http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx The reason for this is that I created this document before we had hammered down the TLG concept. I could have back-ported the POC guide but given that the Base Configuration is really focused on a single forest concept and we have two forests for the POC, I decided that it would be OK to not back port it to TLG specs. However, if you’re really interested in the POC guide, but desperately want to take advantage of your existing Base Configuration snapshot – then I’ll take the time and make v2 consistent with the TLG design.
Let me know what you think and as always, you’re welcome write to me if you want any questions about the POC guide or if you’re having problems getting it to work. Also, if there are any other TLGs (all future TLGs will be written to the TLG spec) you’re interested in, let me know!
In order for SSTP (Secure Socket Tunneling Protocol) and DirectAccess to work properly the SSTP and DirectAccess client must have access to the CRL (Certificate Revocation List) of the server certificate (if you are using Client Certificate or Smart Card authentication you will also need access from the client to the CRL)
If you are using internal Microsoft Certificate Authority (CA) you can publish the CRL through UAG based on the following procedures:
Important Note: If you are using Microsoft Certificate Authority (CA) make sure the Root CA certificate (If you are using in intermediate CA, also include the intermediate CA certificate) is located in the Trusted Root Certification Authorities of the Local Computer Store
Open UAG management Console, navigate to HTTP Connections, right click, and choose New Trunk
On the Welcome to the Create Trunk Wizard page click Next.
On the Step 1 – Select Trunk Type page, select the Portal trunk option and click Next.
On the Step 2 – Setting the Trunk page, enter the Trunk name and enter the Public host name, this part is very important! You must enter the exact URL that you configured in the CDP (CRL Distribution Point) setting on your certificates, then click Next.
Note: External clients must be able to resolve the public host name
On the Step 3 - Authentication page, choose any authentication repository (this is not relevant because in next phases we will disable the authentication for this Trunk because access to CRL doesn't require authentication) then click Next.
On the Step 4 – Endpoint Security page, click Next (you will disable Endpoint Security for this Trunk later so the choice made her is immaterial).
On the Step 5 Endpoint Policies page click Next.
On the Completing the Create Trunk Wizard page click Finish.
Now we will configure an Other Web Application (application specific hostname) application in the new trunk to publish the internal CRL.
In the UAG management console click Add.
On the Step 1 – Select Application page select the Web option and then select the Other Web Application (application specific hostname) option from the drop down list. Click Next.
On the Step 2 – Configure Application page enter the Application name and in the Application type text box, enter OtherWeb, then click Next.
On the Step 3 – Select Endpoint Policies page click Next.
On the Step 4 – Deploying an Application page click Next.
On the Step 5 – Web Servers page, in the Addresses text box, enter the name on your internal IIS server that hosts the CRL. Change Paths to the path defined for CRL Distribution Point, for example “/CertEnroll/* (your certificate distribution point will likely have a different name, enter the name that you have defined for your CDP). Define the Public host name as configured in the CDP (CRL distribution point). This name should be the same Public host name defined for the trunk. Click Next.
Note: External clients should be able to resolve this name
On the Step 6 - Authentication page click Next.
On the Step 7 – Portal Link page click Next.
On the Step 8 - Authorization page click Next.
On the Completing the Add Application Wizard page, click Finish.
In the UAG Management Console navigate to the Initial application and choose the application you created (this will allow access directly to the CRL and not through the UAG default portal).
In the UAG Management Console navigate to Trunk Configuration and choose Configure
Disable Require users to authenticate at session logon onthe Authentication tab in the Advanced Trunk Configuration dialog box.
Enable the option “Disable component installation and activation” on Sessions tab of Advanced Trunk Configuration dialog box. You need to do this because UAG client components are not required for publishing CRL. Also enable the option “Disable scripting for portal applications”
This article was originally written by Tarun Sachdeva, Sr. Support Engineer.
How’s that for a catchy title?
Test Lab Guides (TLGs) are a new method that Joe Davies and I have developed that makes learning complex technologies easier than ever. Using TLGs, you can significantly cut down on the time it takes for you to learn a new technology, product or an entire multi-tier solution by configuring a Test Lab using a TLG.
Now you might be wondering “what’s the difference between a Test Lab Guide and a Step by Step Guide?” In the past, we’ve used the term “step by step guide” to describe a lot of different types of content. It might be a collection of steps you do to issue a certificate, or maybe the steps required to enable and disable the Windows Firewall, or it could be a large collection of steps used in a lab type of environment.
The problem with step by step guides is that they don’t define a standard environment on which you could test out the steps and then validate that the steps actually worked. You could create your own test lab using what you think might be the best settings for a collection of clients and servers, but when you were done with it, you were done. The next time you wanted to go through a different step by step guide, you had to build out another lab, with different settings, clients, servers and services, and go through the steps. Then if you wanted to check out another step by step guide, you had to go through the entire drill all over again.
It was a time consuming process and many of us shied away from the valuable experience the step by step guidance could provide. Test Lab Guides solve this problem by enabling you to create a reusable environment that speeds your lab setups and allows you to get to testing the technology, product or solution faster than ever.
At the heart of the Test Lab Guide concept is the Base Configuration. The Base Configuration is a standard set of servers and clients that are used to simulate a private network and the Internet. The Base Configuration defines the names, IP addressing information and network services used in the Base Configuration setup. After you create the Base Configuration, you take a snapshot – as all subsequent Test Lab Guides will start with the Base Configuration. By creating a snapshot of the Base Configuration, you save a few hours each time you want to try out a new Test Lab Guide. Over the course of a year, this can save you literally days of effort!
The Base Configuration is shown in the figure below:
Now that you have a snapshot of the Base Configuration, what do you do with it? The next step is to build on it using Test Lab Guide modules.
A Test Lab Guide module always builds on the Base Configuration. For example, the figure below shows a Test Lab Guide module named Demonstrate UAG DirectAccess. When you go through the Demonstrate UAG DirectAccess module, the first step is to restore the Base Configuration and you start with the Base Configuration. The module then uses the servers and services already configured in the Base Configuration and adds what’s required to demonstrate DirectAccess.
When you finish the module, you can take a snapshot of the working solution, so that you can return to it later. This is very cool because you don’t have to go through the entire module again to see what the working solution looks like. But if you wanted to do the module all over again, you can restore the Base Configuration and start all over.
See how flexible this approach is?
Now let’s have even more fun. TLG modules build on the Base Configuration. But modules can also build on other modules, so that your TLG actually represents a stack of modules! Check out the figure below. You see three new TLG modules:
These three Test Lab Guides are modules that build on the Demonstrate UAG DirectAccess module. So, if you already did the Demonstrate UAG DirectAccess module and took a snapshot of that module, all you need to do is restore the snapshot of that module, and then go to work on one of the TLGs higher up in the stack. We like to call these “third level modules” since they’re the third module in the stack.
Of course, your stack can get as high as you want, and as long as you take a snapshot after each module, you don’t have to spend time going through all the steps all over again just to begin the new module. Again, a tremendous time saver that allows you to test a greater number of capabilities in the technology, product or solution that you want to learn about.
Virtualization is the key to success with TLGs because it allows you to easily take snapshots of the entire Test Lab and then restore them to proceed to the next module in a Test Lab Guide stack. Before the mainstreaming of virtualization, putting together Test Labs that provide a reasonable facsimile to a production environment would be very difficult. And the time it would take to image the disk drives and restore the images can take quite a while – with virtualization technology, regardless of the virtualization solution you’re interested in, snapshots and restoration is a “snap”.
And it doesn’t stop there. While I’m using DirectAccess as the example technology for Test Lab Guides, the TLG approach can be used for any technology, and we’re expecting that many of the teams at Microsoft will be adopting the Base Configuration and Test Lab Guide module approach so that mixing and matching TLGs will be easy and enable you to build on your collection of TLG snapshots.
For example, maybe the Exchange Team wants to build a TLG on demonstrating Exchange remote access. They could take the Demonstrate UAG Direct Access TLG and build on that, since UAG is part of that TLG and all they need to add is the Exchange configuration and the UAG Exchange publishing configuration. In that way, they don’t need to “reinvent the wheel'” and start from the beginning. Again, a big time saver and a way to get this key information out to you so that you can test it in record time.
What’s even better is that YOU can get into the Test Lab Guide game by creating Test Lab Guide Extensions. A Test Lab Guide Extension is something that you can create that extends the value of a Test Lab Guide. For example, suppose you wanted to create a Test Lab Guide module that built on the Demonstrate UAG DirectAccess and NAP TLG to show how smart cards work with UAG DirectAccess and NAP. What you could do is use the TLG Extension template and create a module that builds on top of the Demonstrate UAG DirectAccess and NAP TLG stack. That way, you don’t have to write out all the steps have already been written – you only need to include the steps required to add the smart card integration.
Of course, you could create your own stack and use the Base Configuration as the start of any technology that you’d like to create a TLG extension for. You start your own stack, beginning with the Base Configuration and then add a stack of TLG extensions. Then others can reuse your stack and create their own extensions. Everyone ends up saving time and learning more because the reusability of the Base Configuration, modules and extensions.
Go Ahead – give it a try – or as we like to say “The Test Lab Guide Base Configuration: Make Something of IT!”
So let’s put it all together.
The figure below shows the components of the Test Lab Guide approach to building out Test Labs using the theoretical example of the solution consisting of UAG DirectAccess, NAP, and SCCM. At the bottom is the core of all Test Lab Guides, which is the Base Configuration. Then modules are built out of the Base Configuration (second level modules). Then modules are built on the second level modules (third level modules) and so forth. You can also see where you can build out your own TLG extensions in the TechNet wiki. Notice on the right side a little icon of a woman taking a snapshot. These are points where you would want to take a snapshot of your configuration so that you can return to it to either redo the steps for a module, or to build a new module or extension.
There’s no doubt about it – you really don’t know how to do something until you actually do it, and that’s what Test Lab Guides are all about. With our reusable TLGs, you’ll be able to get up to speed on simple and more importantly, complex technologies faster than ever. And you’ll be learning the technology, product or solution using a tested and reliable TLG that you know will end up in a working configuration.
You’ll learn all the moving parts, all the tricky areas, and infrastructure requirements that go into making things work. You’ll also have more confidence in the solution, as there isn’t any “smoke and mirrors” configuration in the background – you’ll do every step to configure the front-end and the back-end so that you’ll understand how all the pieces fit together.
Try out some of the Test Lab Guides. You can find the TLG clearinghouse on the TechNet wiki. Right now we have TLGs stacks for Windows DirectAccess and UAG DirectAccess, but we’re expecting many more technologies to be included in the future, and we’ll update the wiki when they become available. Also, remember that anyone can update the wiki, so if you create a Test Lab Guide extension, make sure to update the wiki with your extension. We’re looking forward to some great contributions by the community of original and innovative TLG extensions.
Finally, I want to let you know that I’m here to help. If you have questions about Test Lab Guides let me know. If you want to create a new extension but not sure how to proceed, send me a note and I’ll try to help you. Test Lab Guides speed up all of our knowledge and knowledge is power – let’s go for the power!
Thanks!
Let’s face it – you can make it an avocation (or worse, a vocation) of reading all the documentation we have on UAG DirectAccess and still not be able to figure out how to actually put together a working DirectAccess solution. A big part of that is that there are a lot of moving parts, and until you get a good feeling for all those parts and how they work together, DirectAccess looks a more more complicated than it really is.
Believe me – if you can configure an Exchange or SharePoint server, DirectAccess will be a veritable no-brainer.
The real key to really understanding something is to actually do it. And that’s where your old buddy the Edge Man comes in to help. I’ve been in the Edge Man’s skunk works for the last few weeks frying up some tasty Test Lab Guides for you. After you run through these babies a few times, you’re going to feel like you have a pretty good handle on UAG DirectAccess and you’ll be chomping at the bit to plan and deploy your live proof of concept.
Did I say proof of concept? I sure did – and I’ll have a proof of concept guide for you by next week as well.
But enough of the sales job, it’s time to produce the goods:
Go ahead and give them a try!
These Test Lab Guides supersede the UAG DirectAccess Step By Step Guide and contain many bug fixes, exposure to new features, and tips and tricks on how to configure UAG DirectAccess and troubleshoot situations as they come up. The Test Lab Guide for Troubleshooting UAG DirectAccess is also a great way to get your hands wet with DirectAccess, IPv6 and IPsec and I think after you go through the troubleshooting Test Lab Guide you’ll gain new insights into how DirectAccess works and have even more confidence in how to deploy the UAG DirectAccess solution.
Let me know what you think of these new Test Lab Guides and if you have suggestions for more, let me know! I’m always looking for new ideas and if there are problems I can help you solve, then I’m here to help.
Also, remember if you have any DirectAccess questions, make sure to visit the UAG DirectAccess forum over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads
One of the key pieces of a working DirectAccess solution is the Network Location Server or NLS. The purpose of the Network Location Server is to help the computer configured as a DirectAccess client to know that it’s inside the corporate network. When the DirectAccess client is inside the corporate network, you don’t want it to use the DirectAccess tunnels to reach internal resources. Instead you want the DirectAccess client to connect directly to the resources when they’re on the corporate network.
There are actually two primary things that happen when the computer configured as a DirectAccess client enters the internal network:
You can tell that the NRPT has disabled itself by running the netsh namespace show effectivepolicy command. You’ll see the Note: DirectAccess settings would be turned off when computer is inside corporate network, as seen in the figure below.
Conversely, if the DirectAccess client can’t find a domain controller and it can’t connect to the Network Location Server, then it will try to enable the DirectAccess IPsec tunnels and it will enable the Name Resolution Policy Table (NRPT). When the NRPT is enabled, name resolution for requests for intranet resources will be sent over the DirectAccess tunnels (if they can be established) and resolved by the UAG DNS64 DNS proxy.
If the DirectAccess client can’t establish the DirectAccess tunnels to connect to the DNS64 component, then name resolution requests for intranet resources will fail. As you can imagine, not being able to resolve names on the intranet can have some pretty negative consequences, some of which I describe at http://blogs.technet.com/b/tomshinder/archive/2010/04/02/directaccess-client-location-awareness-nrpt-name-resolution.aspx and http://blogs.technet.com/b/tomshinder/archive/2010/04/06/when-good-network-location-servers-go-bad-preparing-against-nls-failure.aspx
Which brings us to a case we encountered a couple of weeks ago. Everything was set up right:
Things looked perfect. However, when the DA clients were returned to the intranet, the NRPT would not turn itself off. This would be consistent with a problem connecting to the NLS, but when we pointed the browser to the NLS, the default web page came up fine.
We did a network trace using NetMon 3.4 and found that the DA client was making repeated connection attempts to the NLS. This was a bit strange, so we dug deeper.
We found out that the web server (a non-IIS server, but that’s no problem, we support any web server for the NLS server) was returning a bad header. This lead WinHTTP to not be able to parse the web page response and conclude that there was a server failure. In contrast, when we connected to the site using the web browser (IE), the bad header was ignored by WinInet (used by IE) and the page was successfully rendered in the browser.
What surprised me about this was that I had the impression that all we needed to do for a successful NLS connection was to successfully establish an SSL connection to the NLS and receive a 200 OK response from the web server. In fact, we need a little more than that – WinHTTP needs to be able to successfully parse the web page response in order to create a successful NLS connection.
I don’t expect this to be an issue for the vast majority of DirectAccess admins, but it might be something to keep in your back pocket if you’re having problems with the NRPT not being disabled when the DirectAccess clients are on the intranet and when you are using non-IIS servers for your NLS server, where you’re more likely going to customize the headers and thus might experience a typo in the process.
One more thing – if you ever have any questions on DirectAccess make sure to head on over to the UAG DirectAccess forum over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads
You’re learning about DirectAccess and you like what you see. The next step is to build out a test lab. You can build out your own, or you can let me to the heavy lifting for you and use the UAG DirectAccess Step by Step Guide over at http://technet.microsoft.com/en-us/library/ee861167.aspx You’ll save a lot of time by using the lab I put together for you, and you’ll learn a lot about DirectAccess terminology and configuration issues.
When you do put your Test Lab together, you’ll find that there are a lot of technologies and a lot of steps involved with making it work. The reason for this is that DirectAccess is really a collection of product and platform technologies that work together to create a working remote access solution that we’ve named DirectAccess. All the components of the solution need to be configured correctly for it to work.
And that will likely be your first challenge when you start working with DirectAccess. You’ll have gone through all the steps in the Step by Step guide and BAM! It didn’t work. Don’t worry – a lot of the technologies are probably new to you. That means there’s a good chance that you missed a step. I’ve done it, other DirectAccess experts have done it. Consider this a normal part of the DirectAccess learning process. After you’ve gone through the test lab a few times, all the concepts and technologies will fall into place in your mind and you’ll actually get to a place where you’ll forget what it was like not to understand how all the DirectAccess pieces fit together.
With that in mind, I wanted to take a few minutes to talk to you about using ping to test DirectAccess connectivity. We’re all accustomed to using ping to test connectivity issues – this is something firmly ingrained in all of our years with working with the Windows network operating system. And while you definitely can take advantage of ping to help you troubleshoot DirectAccess connectivity issues, there are a few things that you need to keep in mind about ICMP and DirectAccess connectivity.
First, remember that DirectAccess uses IPsec tunnels between the DirectAccess client and DirectAccess server to allow DirectAccess clients access to intranet resources. There are two tunnels:
It is commonly said by DirectAccess experts (including myself) that all traffic moving through the DirectAccess client to resources on the intranet is through one of these tunnels. This is true for all traffic except ICMP traffic. In a UAG DirectAccess scenario, IPsec policy is configured to exempt ICMP from IPsec authentication and encryption. Therefore when you ping a resource on the intranet, you are sending those pings outside of the infrastructure and intranet IPsec DirectAccess tunnels.
Now you might be asking yourself “If the ping traffic isn’t going through the DirectAccess tunnels, how it is getting to the intranet”? That’s a good question and unless you’ve been in the IPv6 transition technology game for awhile, the answer is definitely not obvious.
Take a look at the figure below. What I tried to draw here are two tunnels. The larger tunnel is an IPv6 transition technology tunnel. IPv6 transition technologies can be used to allow the IPv6 communications between the DirectAccess client and DirectAccess server to be carried over the IPv4 Internet. The DirectAccess client can use one of three IPv6 transition technologies over the Internet: 6to4, Teredo or IP-HTTPS. The details of each these isn’t important here.
What is important is to understand is that each of these IPv6 transition technologies tunnel IPv6 packets inside an IPv4 header. Inside of the IPv6 transition technology IPv4 tunnel is the IPsec tunnel – where IPsec is used to authenticate and encrypt the IPv6 packets. When you think about DirectAccess tunnels, you should think of two tunnels – the IPv6 transition technology tunnel and the IPsec tunnel.
The above figure shows that ICMP messages are carried over the IPv6 transition technology tunnel, but that they are outside the IPsec tunnel. The reason why we decided to do this is to make Teredo work correctly, as Teredo requires ICMP access outside the IPv6 IPsec tunnel to determine what type of NAT device the DirectAccess client might be located.
Because of this decision, you need to be aware of a couple of issues:
Before going into the details of ICMP traffic and troubleshooting, I wanted to point out where the ICMP exemptions for IPsec traffic are configured. In the first figure below you can see the Group Policy Object (GPO) for the DirectAccess servers. When you right click the Windows Firewall with Advanced Security – LDAP {GUID} entry and click Properties, you’ll see what appears in the figure right below it – in the Windows Firewall with Advanced Security dialog box, on the IPsec Settings tab. In the IPsec exemptions frame, you’ll see the Exempt ICMP from IPsec option is set to Yes.
Now let’s take a look at what happens when the IPsec infrastructure and intranet tunnels fail. In this example, I took a working DirectAccess setup and broke it by configuring the UAG DirectAccess server to use the wrong root certificate for mutual computer authentication. Since the root certificate configured in the UAG DirectAccess configuration points to a root CA that didn’t issue the computer certificates used for computer certificate authentication, all IPsec tunnel connection attempts will fail.
One of the standard things we do when troubleshooting DirectAccess connections is to see if we can ping the 6to4 address of the UAG DirectAccess server itself. You can get this address by using the
netsh namespace show effectivepolicy
command on the DirectAccess client, as seen in the figure below.
Now that we have that address, let’s try and ping it.
Yay! That worked and shows that we have IPv6 connectivity with the DirectAccess server. This proves that at least the IPv6 transition technology is working enough so that we can ping the UAG DirectAccess server side of the Teredo (in this example) tunnel. What it doesn’t tell us is if the other components that allow address to resources behind the UAG DirectAccess server are functional.
To enable ICMP access to resources behind the UAG DirectAccess server, you will need to know the IPv6 address of the resource you want to connect to. This can be an ISATAP address or a native IPv6 address (or as well see later, a NAT64 address). It doesn’t matter which type – what matters is the fact that the DirectAccess client only communicates with the DirectAccess server and the networks behind it using IPv6 (except when NAT64/DNS64 is used, in which case the communications are “NATed” by the UAG DirectAccess server, so that between the DirectAccess client and the UAG DirectAccess server IPv6 is used and communications between the UAG DirectAccess server and the IPv4 resource on the intranet, IPv4 is used).
We can go to the domain controller on the network and use ipconfig /all to check it’s ISATAP address. In this example the ISATAP address of the domain controller (DC1) is 2002:836b:2:8000:5efe:10.0.0.1 so we’ll ping that ISATAP IPv6 address from the DirectAccess client on the Internet.
Yay again! It worked. Now we know that the Teredo tunnel between the DirectAccess client and the DirectAccess server is up, and that the Teredo relay configured on the UAG DirectAccess is working.
What if you’re not using ISATAP and you’re not using native IPv6 addresses behind the UAG DirectAccess server? This is a common scenario where you have an IPv4-only network behind the UAG DirectAccess server. In this case, you’re taking advantage of the UAG DirectAccess server’s NAT64/DNS64 capabilities. If you want to learn more about NAT64/DNS64, I highly recommend you read Meir Mendelovich’s excellent coverage of this subject over at http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx
The problem we have to solve is how do we figure out what the NAT64 address is of an IPv4 only host? Well, the answer comes from an exceptional blog post by Ben Bernstein over at http://blogs.technet.com/b/edgeaccessblog/archive/2009/10/13/deep-dive-into-uag-directaccess-ipv6-and-directaccess.aspx
The UAG NAT64 address of an IPv4 only host is:
2002:WWXX:YYZZ:8001:[Hex of IPv4 address] /96 (the /96 means that the prefix is 96 bits of the 128 bit IPv6 address)
The WWXX:YYZZ is the Hex representation of the first of the two consecutive IPv4 public address on the UAG DirectAccess Server. You can figure this out if you like, but UAG has already done this work for you. If you look in the figure above, you can see these components of the IPv6 address:
836b:2: – this is the WWXX:YYZZ Hex representation of the IPv4 address
8000: – this is the value used to represent the ISATAP prefix (this is covered in more detail in Ben’s article if you want more information in this)
What we can do is take this information and build out our NAT64 address for the IPv4 only resource. First, we can define our prefix, which is:
2002:836b:2:8001 /96 (the 8001 value is used to represent the NAT64 prefix)
The last 32 bits of the address is Hex representation of the IPv4 only resource. In this example, the IPv4 only resource has the IPv4 address 10.0.0.4. We convert to this to Hex:
10 = 0a in Hex (8 bits)
0 = 00 in Hex (8 bits)
4 = 04 in Hex (8 bits)
Or – 0a00:0004 (32 bits represented by two 16 bit blocks)
Now we can put our prefix and address together and get:
2002:836b:2:8001:0000:0000:0a00:0004 /96
You might be wondering where the 0000:0000 entry came from. First, you need to know that each “block” (the value between the colons) represents 16 bits. There are eight blocks in a 128 bit IPv6 address. We defined the first 64 bits of the NAT64 prefix with the four blocks 2002:836b:2:8001. However, the NAT64 prefix is 96 bits, so we need to add another 32 bits to the prefix to make it add up to 96. We can do this by adding two blocks of zeros. That gives us the 96 bit prefix. Then we just append the Hex presentation of the 32 bit IPv4 address at the end.
NOTE: There is something called “zero suppression” when describing IPv6 addresses where leading zeros can be left out and where they can be replaced with a double colon “::”. We don’t need to get into that now, but you’ll notice that is done automatically by the operating system when it converts the WWXX:YYZZ and also in the ping responses.
Let’s give it a try.
Yay for a third time! It worked again. This proves that we have ICMP connectivity to both IPv6 and IPv4 resources on the intranet. At this point we must be feeling pretty good, as we’ve successfully pinged the UAG DirectAccess server and a IPv4 and IPv6 resources on the intranet.
But what about traffic isn’t ICMP? A quick check can be done by using the web browser. In the figure below I’m using the ISATAP address of a web server on the intranet. Notice that if you want to use IPv6 addresses in Internet Explorer, you have to surround them with brackets.
This connection fails because it’s using HTTP, which isn’t ICMP. The reason for the failure is that in order to transport HTTP, the DirectAccess IPsec tunnels must be available. And because I broke IPsec, there are no tunnels. You can prove that to yourself by using the Windows Firewall with Advanced Security console and finding no Main Mode or Quick Mode Security Associations. There is a process to troubleshoot IPsec tunnel establishment failure, but that’s not why we’re here today :)
The key points I want you to remember from this article include:
Secure Endpoint: DirectAccess and Microsoft Forefront Unified Access Gateway 2010, the Complete Remote Access Solution
Spend an hour learning about Microsoft's complete remote access vision and how UAG and Direct Access Technology together provide seamless remote access to users while reducing IT risks and costs. This session includes a live demonstration of the features and the remote access solution in action
http://www.msteched.com/2010/NorthAmerica/SIA301
End-to-End Remote Connectivity with DirectAccess
DirectAccess is a new feature in the Windows 7 and Windows Server 2008 R2 operating systems that gives users the experience of being seamlessly connected to their corporate network any time they have Internet access. With DirectAccess, users are able to access corporate resources (such as email servers, shared folders, or intranet Web sites) securely without connecting to a virtual private network (VPN). This chalk talk addresses questions on setup and troubleshoots a DirectAccess infrastructure
http://www.msteched.com/2010/NorthAmerica/WSV207
I hear a lot of folks talking about deploying DirectAccess as a replacement for their current VPN solution. They often want to move large numbers of their users from working at the office to home offices. This is a great idea, as it saves on the infrastructure costs related to heating and cooling offices, fuel costs related to driving back and forth to work, and ideally increase the employees overall productivity because they could use the time they were driving to work to actually get work done.
That’s all consistent with the goal of DirectAccess – to provide your users an intranet computing experience from anywhere in the world. And when I speak of “users” I’m not just talking about end-users - “users” also include IT, as your IT group will be able to have the same connectivity to, and command and control over, DirectAccess clients as they have with any other client they manage on the intranet today.
When talking to people about DirectAccess, it’s best to not think of DirectAccess as a “VPN” solution – since the vision of DirectAccess is to keep the DirectAccess client continuously connected to the intranet – thus bringing the intranet “out” to all DirectAccess clients. In contrast, VPN connections (SSL and network level) are about temporary connectivity that enables the VPN client “into” the intranet. It might seem like hair splitting, but the practical implications are significant, both from the end-user productivity perspective and the IT management and control perspective.
Because this vision is all about highly managed corporate controlled systems, you still might want to provide VPN access for machines that don’t fit into this vision. You might need to enable partners full network access at times, or perhaps the IT group needs VPN access from unmanaged machines of their own to get work done when out of the office. In this scenario, the DirectAccess and VPN solution can site side by side, or if your VPN clients support SSTP as a remote access VPN protocol (clients are Windows Vista SP1 and above), you can co-locate the SSTP VPN server on the DirectAccess server or array.
So when carrying out your DirectAccess deployment planning, remember that VPN is something that you’ll want to bake into the overall remote access solution.
That's a good question. But before we go there, we have to think about connectivity between the DirectAccess server and the DirectAccess client. The DirectAccess client always communicates with the DirectAccess server using IPv6. There is no IPv4 application traffic moving between the DirectAccess client and DirectAccess server. This means that the client side applications running on the DirectAccess client must be IPv6 aware.
On the server side it doesn't matter - you can run IPv4 only server applications on an IPv6 capable operating system, or you can run IPv6 aware server applications on an IPv4 only operating system. IPv4 isn't an issue when using UAG DirectAccess, because we have the DNS64/NAT64 feature to support IPv4 communications between the DirectAccess server and the destination server on the intranet. There are some exceptions to this, such as not being able to initiate a connection from an IPv4 only server or server application to a DirectAccess client, or when there are “call-backs” required or when there are addresses imbedded in the application protocol, but for the most part the IPv4 only server application will not be a problem.
This means that if your client side applications don't support IPv6, you're going to have to think about a solution. Some things to consider include:
Something that I want to make clear is that if you are running into problem with your client-side applications, we’re here to help you. We’ve helped customers get some applications working with DirectAccess that at first didn’t seem to work. If you want to deploy DirectAccess but are facing a difficult application that doesn’t seem to work with DirectAccess, we want to know about your problem and see if we can help you solve it. Please contact me at tomsh@microsoft.com and I will put you in contact with the team who can help you move forward in helping to solve the application issue.
There is one important issue that you should be aware of, and this relates to those organizations that plan on using Force Tunneling. By default, UAG DirectAccess (as well as the Windows DirectAccess) enables a form of split tunneling, by virtue of the fact that requests for non-intranet resources are sent directly to the Internet server, and not tunneled through the DirectAccess links to the DirectAccess server and out through the corporate firewall or proxy.
Some IT groups are hesitant to support split tunneling based on assumptions made during the 1990s regarding VPN client behavior and the nature and capabilities of malware at that time in history. The networking and threat management landscape is very different now and issues that we're important in a split tunneling configuration 15 years ago are no longer extant. However, not all IT groups have caught up with this or have their hands forced by other decision makers, and therefore may choose to disable the split tunneling configuration by enabling Force Tunneling.
If you do enable Force Tunneling, be aware that all communications will be sent through the DA tunnels. This means you will not have the option to use a Internet facing proxy or relay for your non-IPv6 compliant client applications and you will not be able to fall back to using an SSTP VPN, PPTP VPN, L2TP/IPsec VPN, or even an SSL VPN.
The decision to use Force Tunneling should be made with the knowledge that all your client side applications must be IPv6 aware - as they will not be able to use any fall back mechanism that requires them to connect to the Internet.
(Updated July 21, 2010)
Interesting post on the TechNet forums regarding problems with configuration.exe:
“I currently have a working DirectAccess single server UAG deployment (using at trunk as well). It is working fine and i have updated the deployment to Update roll-up 1.
I am due to demo to a client DirectAccess with UAG and they are also interested in using NAP. So I have built and deployed a NAP server, but now every time I try to change any of the settings in UAG for the "DirectAccess Server" component the console hangs (50% CPU) and i have to kill configuration.exe .... I get this no matter what i edit on the last stage of that screen (i.e smart card auth, certificates etc... it literally hangs the second I click anything!).
I have tried running a procmon trace but without much insight, I've also made sure i disabled any Anti-Virus on the server.”
http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/45a79cc3-da73-460a-a267-6a0d8e59c6a3
===============================
The solution to the problem is to run:
C:\Program Files\Microsoft Forefront Unified Access Gateway\utils\ConfigMgr>configmgrutil -del -
and give it another try.
WARNING: Be aware that executing this command will delete the entire UAG configuration, including DirectAccess configuration and trunks, and you will need to reconfigure your UAG server manually to its previous configuration. If you have an uncorrupted backup you can restore the configuration from backup.
Apparently, this happens when you select an Intermediate Certificate Authority on the NAP configuration (checkbox) page. You can’t use an Intermediate Certification Authority for IPsec (with UAG, at least at this time).
There is also an issue with NAP enforcement with the RTM version of UAG, so make sure you upgrade to UAG Update 1.
Tom Shinder tomsh@microsoft.com Microsoft ISD iX/SCD iX UAG Direct Access/Anywhere Access Team 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
Jim Harrison recently pointed out to me that there’s a small problem with the UAG DirectAccess Test Lab Guide, which you can find over at http://technet.microsoft.com/en-us/library/ee861167.aspx If you haven’t seen the Test Lab Guide yet, or if you haven’t had a chance to run it, I highly recommend that you do. We recently updated it with new extensions that enable you to see how UAG specific scenarios such as “manage out”, array deployment, NLB configuration, and access to IPv4 only resources works.
However, back to the “small” problem. Part of the Test Lab Guide walks you through how to install and configure the Microsoft Certificate Server so that Certificate Revocation Checks won’t fail when the DirectAccess client tries to connect to the IP-HTTPS listener on the UAG DirectAccess server.
As I point out in the Test Lab Guide, this isn’t something that you would do in a production environment. If you use a commercial certificate for the IP-HTTPS listener, the certificate provider will make sure the CRL is reachable and highly available. If you create your own certificate for the IP-HTTPS listener, then you’ll have to publish your CRL and make sure it’s highly available – a lot of work for some people, not so much for others. The point is, you can do it either way.
If you go to http://technet.microsoft.com/en-us/library/ee861152.aspx#BKMK_O you’ll find that you’re in Section O – Remove CRL Distribution Settings on the Certificate Authority on DC1. In step 3, you’ll read the following:
“3. Click the Extensions tab. In Specify locations for which users can obtain a certificate revocation list, check all locations of the CRL Distribution Point (CDP) Authority Information Access (AIA), and verify that Publish CRLs to this location or Publish Delta CRLs to this location is not selected.”
The problem with these instructions is that they are incomplete and won’t prevent CRL check failure when the DirectAccess client is later configured to connect to the UAG DirectAccess server using its IP-HTTPS adapter. You’ll know that you’re running into this problem when you run the command
netsh interface httpstunnel show interface
you’ll see a Last Error Code of 0x80092013. You might also see an error code of 0x274c on the way to the the interface finally failing. The 0x80092013 code indicates that the CRL check failed.
In the figure below you can see the Properties dialog box for the Certificate Authority we use in the Test Lab Guide. The problem you’re encounter with the Test Lab Guide is related to the ldap:// URI. When you select that option from the Specify location from which users can obtain a certificate revocation list (CRL), you have to make sure that you deselect (uncheck) the option Include in the CDP extension of issued certificates. That step is not called out in the Test Lab Guide. I will add that as soon as I can, but until then, make sure you uncheck that option.
What if you already configured the Test Lab and everything worked except for the IP-HTTPS connection? What you can do is request a new certificate for the IP-HTTPS listener and run the UAG DirectAccess Wizard again so that the new certificate is bound to the IP-HTTPS listener. Here are the general steps
When you see it work, your output will look something like the figure below
In a recent blog post about an interesting problem we had with understanding Outlook performance issues and the IP-HTTPS adapter, we had the opportunity to review how the various IPv6 transition technology adapters worked in terms of when they were enabled and when they were disabled. If you haven’t seen that post, head on over to The Mystery of the IP-HTTPS Listener, an Outlook Client and an IPv4 Only Network at http://blogs.technet.com/edgeaccessblog/archive/2010/05/09/the-mystery-of-the-ip-https-listener-an-outlook-client-and-an-ipv4-only-network.aspx
One of the things that we got a better understanding of was Teredo adapter behavior. First, Teredo is an IPv6 transition technology that is used by DirectAccess clients when they are located behind a NAT device, and thus are typically assigned a private IP address (RPC 1918). Teredo encapsulates the IPv6 packets in an IPv4 packet with a UDP header. The UAG DirectAccess server listens for connections from Teredo clients on UDP port 3544. Therefore, if the DirectAccess Teredo client has outbound access to the UAG DA server’s UDP port 3544, the Teredo connection can be established.
However, before that Teredo connection can be established, the adapter needs to be configured. When you run the UAG DirectAccess Wizard, one of the many things it does it configure a DirectAccess clients Group Policy Object (GPO). The DA Clients GPO (The actual name of the GPO is UAG DirectAccess: Client [GUID]) contains settings for the IPv6 transition technologies used by the UAG DirectAccess clients, and one of these is the Teredo client configuration.
If you go to the following path: Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies you will find Teredo GPO configuration options, as seen in the figure below.
There are two settings that are of the most interest to us. The first one is the Teredo Default Qualified setting, as seen in the figure below. The UAG DirectAccess Wizard leaves this setting at its default. As you can see in the description, “qualified” means that the Teredo interface is ready to communicate. The default setting is Enabled State, which means that the Teredo adapter will go through the process of trying to connect to the UAG DirectAccess server to obtain information required to communicate. Qualification includes determining what type of NAT device the Teredo client is located behind.
The second setting of interest is the Teredo State setting. The UAG DirectAccess wizard leaves the Teredo State at its default setting. The default setting is to set the Teredo state as Client. With this state enabled, the Teredo adapter will come up only if the DirectAccess client is not on a network that has a domain controller on it. If the DirectAccess client detects that it’s on a network with a domain controller, it will disable the Teredo adapter, and the IP-HTTPS adapter will take over, assuming that the IP-HTTPS adapter can establish a connection with the UAG DirectAccess server’s IP-HTTPS listener.
Now the celebrity question is “how does the DirectAccess client determine is there is a domain controller on the network?” That’s a great question, and it’s not easy to find an answer to it. At least it wasn’t easy, until this article was published.
To determine if the DirectAccess client is on a “managed network”, the client performs a DNS query looking for SRV records in the path _ldap._tcp.dc._msdcs.DnsDomainName, where DnsDomainName is the name of the DNS suffix assigned to the current connection. If SRV records are located, the client assumes it is in a managed network, and Teredo is disabled. If no records are located, the Teredo interface is enabled.
What’s important to know here is that the detected domain can be any domain. It does not need to be the domain that the computer belongs to. Given this to be the case, a DirectAccess client that’s connected to a home network with a domain (a lot of us computer geeks have domains on our home networks) or to a customer’s network that has domain controllers on it, if a DNS query for that SRV record is successful, the Teredo adapter will disable itself when the “Client” state is enabled for the Teredo client. Another important thing to know is that the DA client doesn’t need to connect to the domain controller, it only needs to be able to resolve the name.
As you can imagine, this might cause some problems. For example, suppose you connect to your corporate network from your domain-based home network (that’s my situation – I work from home and connect to the Microsoft corpnet over DirectAccess). Because my corporate laptop is connected to a domain-based network, it will detect a domain, and disable the Teredo adapter. In this situation, my Teredo adapter will be disabled and I’ll be forced to use IP-HTTPS, which is a lower performance adapter. Most users would prefer a higher-performance solution (including me), so is there anything we can do about that?
Yes there is – but you’ll need to customize your Group Policy. In Figure 3 , notice that there is another option for setting the Teredo State – that option is Enterprise Client. When you set the Teredo State to Enterprise Client, the Teredo interface will always be present, even if the host is on a network that includes a domain controller. Now, the Teredo adapter will try to activate even when a domain (managed network) is detected.
MSIT decided to do this, as evidence by the figure below. Here you can see the output of the
netsh interface teredo show state
command. Notice that the State is set as qualified – which means that the adapter was able to determine what type of NAT device it was behind, which involves being about to connect to the UAG DirectAccess server. Also, notice the Network setting, which reports as managed. This combination shows that the Teredo adapter was able to connect to the UAG DirectAccess server, it detected a domain network, but remains activated and functional because the Type is set as enterpriseclient (Group Policy).
I need to point out before moving on that if you make these “hand edits” to the UAG DirectAccess Wizard GPO, that they will be overwritten the next time you use the UAG DirectAccess Wizard to update the DirectAccess Client GPO. So you’ll need to create a change control reminder that you need to manually set the Teredo State to Enterprise Client.
Now, while this is a good thing for those of us who want to connect from managed networks (successful domain detection), it does have the potential to cause problems. One example of this is when NLS (Network Location Server)failure takes place, NLA (Network Location Awareness) isn’t able to succeed at domain detection for setting Windows Firewall with Advanced Security (WFAS), with an end result being the WFAS Profile is set to Public or Private (which enables the DirectAccess Connection Security Rules), and the network firewall allows outbound access to UDP port 3544 to the IP address on the external interface of the UAG DirectAccess server. In this scenario (admittedly uncommon) the Teredo adapter will be enabled and intranet communications will take place through the UAG DirectAccess server.
However, given how common domain networks are, and how uncommon the combination of events noted above are, it makes sense to make the default Teredo State Enterprise Client.
Cannot Reach the DirectAccess Server with Teredo
http://technet.microsoft.com/en-us/library/ee844188(WS.10).aspx