(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)
In order for the DirectAccess (DA) client to determine whether to turn on it’s DirectAccess client configuration (which connects the DA client to the DA server), it must know if it is on the corporate network or not. If the DA client is not on the corporate network, then the DA client components are turned on, and if the DA client is on the corporate network, then the DA client components are not turned on.
The DA client uses a Network Location Server (NLS) to find out if it is on the corporate network. The NLS is a web server that is accessible only when the client is on the corporate network. That means there must never be a DNS entry on the public Internet that matches the name of your NLS server. For example, if the name of your NLS server is nls.contoso.com, then that name must not be resolvable by any public DNS server. However, that name must be resolvable by your internal NLS servers.
The URL used to connect to the NLS server is contained in the Registry of the DA client, and this setting is delivered over Group Policy. The Registry setting is stored at:
HKLM\software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\ CorporateConnectivity\DomainLocationDeterminationUrl
and is pictured in the figure below.
The DA client always assumes that it is on the outside. Whenever the DA client detects that there has been a network status change (such as when the network interface is unplugged and then plugged in again, or after waking from sleep), the DA client tries to connect to the NLS server URL over an HTTPS connection. If the DA client receives a 200 HTTP success code, then it assumes that it on the corporate network and will then use Network Location Awareness to determine if it should switch the the domain profile. NLA is part of the users decision making process when they select “which type of network are you on” when they change networks. When they choose the “work network” the Domain Profile (part of the Windows Firewall with Advanced Security) is enabled, which turns off the DA client components.
NOTE: In order to successfully connect to the NLS server, the DA client must have access to the CRL location(s) listed on the web site certificate presented by the NLS server. If the CRL checks, then the connection will fail, and the DA client components will remain enabled, even if the DA client is on the corporate network.
This is an important point to understand. The DA client configuration is driven by Group Policy settings and Windows Firewall for Advanced Security. The Windows Firewall with Advanced Security maintains three profiles: public, private, and domain. When the client is on a public or private network, the DA client components are enabled via the WFAS configuration for those profiles. When the DA client is on the corpnet and the domain profile is enabled, the DA client settings in WFAS are disabled.
When the DA client has disabled its DA client components, it resolves names based on the DNS server IP address settings on its NIC. However, when the DA client has enabled its DA client configuration, name resolution depends on the settings on the Name Resolution Policy Table or NRPT.
The NRPT provides a form of “DNS server routing” based on the names configured on the NRPT. You configure the NRPT during the setup of the Windows DA server or the UAG DA server. The figure below shows the configuration interface for the NRPT using the UAG DA wizard. Notice that there are two entries in this example:
NOTE: The UAG DA server DNS proxy is a component of the UAG DNS64 feature set. You can learn more about this feature at http://blogs.technet.com/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx
If a name does not match any entry on the NRPT, then the name resolution request is sent to the DNS server configured on the DA client computer’s NIC. Since public DNS servers do not contain entries for your private network addresses, connection are made to public servers over the local connection the client has to the Internet and not over the DA link to the UAG DA server.
Let’s take a closer look at what happens when the NRPT name resolution policies are active (and remember that they are only active when the DA client components are turned on):
At this point things get a bit more tricky, because name resolution fallback depends on what type of name was queried for initially. This relates into the options seen on the bottom of the figure above and reproduced in the figure below. If the original query to the UAG DA server was for a FQDN and the query fails, then that’s it and there’s no fall back. However, if the name query was for a single-label name (note that the user interface assumes that you know that local name resolution is the same as “single-label name”), then there are three fall back options for name resolution.
Fall back for single label names will always happen if the client receives a “name not found” response from the UAG DA DNS proxy.
However, if the Fall back to local name resolution if the name does not exist in DNS or the DNS servers are unreachable when the client computer is on a private network (recommended) option is selected, fall back will take place if the name doesn’t exist in DNS or if DNS server isn’t reachable and the user selected the “Home” or “Work” option for the type of network their connected to. (that is to say, they didn’t select the “public” network option).
However, if the Fall back to local name resolution for any kind of DNS resolution error (least secure) option is selected, fall back will also take place for any kind of DNS query error and will take place if the user is located on a public Network. As you can imagine, this can be a bit problematic if you’re concerned about your private names being broadcasted to the DA client’s local link. A determined attacker might be able to leverage this information in a focused attack on your network.
It’s worth repeating that fall back only takes place for single-label names and never takes place for FQDNs. Another thing to be aware of is that LLMNR only works on the local segment (similar to NetBIOS Name Query broadcasts) and that NetBIOS name resolution only works on the local segment (actually subnet) unless a WINS server is configured, and it’s unlikely that the client is going to be assigned a WINS server that’s going to resolve the name of the server the client is actually interested in, and if there is a name match in WINS, it’s almost impossible that this is going to be the correct computer, since the DA client computer is not located on the corpnet.
At this point you now should have a better understanding of the Network Location Server and how its used to determine whether the DA client is on or of the corpnet. You should also understand how DNS query behavior changes when the DA client components are enabled – and that the NRPT determines what DNS server will be used to service a DNS query when the DA components are enabled on the client.
In the next blog post on network location awareness and detection, we’ll build on this understanding and looking into what happens when the DA client is unable to determine if it’s on the corpnet, and what happens to corpnet located clients when they are not able to turn off their DA client configuration.
HTH,
Tom
Tom Shinder tomsh@microsoft.com Microsoft ISDiX/SCDiX 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
Your first decision when planning a publishing solution using Forefront TMG 2010 (TMG) or Forefront UAG 2010 (UAG) is to determine which of the two products best fits the needs of the deployment.
Both TMG and UAG can securely publish Exchange, SharePoint, Terminal Services and web-based line of business applications to the Internet. However TMG and UAG offer some features or support some scenarios that the other does not. So, the first step in choosing which product to use is deciding what features you need or think you may need.
Some deployments may actually benefit from using both TMG and UAG to satisfy specific requirements. For example, you might use UAG to provide a unified portal experience for your inbound Web-based client access, use TMG to protect Internet access for your internal users, and use Forefront TMG to provide certificate-based authentication to your mobile device-enabled workforce.
The following table compares both products at a functional level:
Feature or Capability
Forefront Threat Management Gateway 2010
Forefront Unified Access Gateway 2010
Scale Out Using Arrays
Arrays enable you to apply the same configuration setting to multiple machines participating in the same array
X
Network load balancing of the publishing array
Network Load Balancing (NLB) enables high availability and transparent failover for participants in the NLB array
Load Balancing of Back-End Servers
Integrated Web Farm load balancing enables you to load balance connections to back-end web servers, removing the need for a hardware load balancer behind the web gateway
Single network interface deployment
The web gateway can be deployed in a single NIC configuration, so that NICs do not span multiple networks
Enterprise Management (multiple nodes in one array)
Enterprise Management enables the administrator to manage multiple arrays located throughout the organization from a single management interface; in addition, configuration for all arrays is stored in a centralized location which located off any of the array members
Integrated Windows Authentication
Integrated Windows Authentication enables SPNEGO, Kerberos or NTLM authentication with the web gateway
Support two-factor authentication for web applications
Two-factor (multi-factor) authentication enables the administrator to require users to present two or more pieces of information to access resources
Certificate Authentication with ActiveSync
Certificate authentication with ActiveSync increases the overall ActiveSync security scenario by requiring the device to present a certificate before allow access to Exchange Server resources
Upgrade Path from ISA 2006
While it’s not possible to do an in-place upgrade from ISA to TMG (because ISA was 32bit only and TMG is 64bit only), there is a clear and easy to perform upgrade path.
Authorization Using Endpoint Policies
Endpoint detection determines the state of the device connecting to the gateway and enforces access policy based on the results of the endpoint detection
SharePoint rich client support (MSOFBA)
MSOFBA is a protocol that provides forms based authentication, instead of basic authentication, when you use Office client applications
Federation support with ADFS
Use integration support for ADFS to enable federated identity scenarios
Endpoint Session Cleanup
Endpoint session cleanup provides a mechanism to remove information obtained from the server during the course of the session; removal takes place on log off.
Port Scalability
Port scalability enables you to publish more resources while using fewer ports on the receiving interface of the web gateway
Password Lockout Protection (at a node level)
Password lockout protection protects the user account from being inadvertently locked out by either a friendly or malicious user; user is locked out of the gateway, but not in the Active Directory.
Granular access policies
Granular access policies enable the administrator to control access to applications and to components of applications, based on the results of user and device assessments.
Support for DirectAccess
DirectAccess is a new remote access technology that enables users to be always connected to the intranet and enables IT to always be connectivity to the users – all done transparently without user intervention
Portal functionality to publish multiple line-of-business applications
Portal functionality enables users to connect to a single URL to access a portal page that contains applications and services available to the user, based on the results of user and device assessment.
Load balancing support for HTTP-based protocol access from the Internet
Load balancing enables an array of web gateway to handle more requests more efficiently by evenly distributing connections among members of the load balanced array.
Highly Customizable
Customizable according to the support guidelines and the development policies and processes for Microsoft partners
Built-in Wizards for Exchange
Built-in wizard for publishing Exchange web services makes it simple to publish these resources using a secure default configuration
Outlook Web Access “Look and Feel”
Both UAG and TMG provide a log on page experience that is similar to the one provided by Exchange Outlook Web Access (OWA).
Publish Microsoft Office Outlook Web App and the Exchange Control Panel (ECP) using forms-based authentication
Forms based authentication enables users to enter credentials in an easy to use form to authenticate with the web gateway
Publish Outlook Anywhere using Basic or NTLM authentication
Publish Microsoft Exchange ActiveSync using Basic authentication
Support two-factor authentication for Exchange ActiveSync
Provide certificate-based authentication for Exchange ActiveSync, Outlook Web App, and ECP
Perform mail hygiene for Exchange with installation of the Edge Transport server role and Microsoft Forefront Protection 2010 for Exchange Server
Email inspection can be performed on the web gateway to protect against spam and malware
Protect and filter Internet access for internal users from malware and other Web-based threats
The web gateway can perform URL filtering to block undesirable web sites and scan and block malware delivered from the web
Provide support for scaled up Outlook Anywhere deployments by using multiple source IP addresses
UAG has a Port Scalability feature that allows UAG to use multiple source IP address on its internal interface to contact the published CAS servers, allowing it to overcome the limit of 60000 ports maximum in a single IP address.
Check a client computer accessing Outlook Web App for presence of approved antivirus software, updates, etc.
Endpoint detection can be performed to insure that the client attempting to access the OWA Exchange web service meets corporate security standards before allowing access
Built-in features for SharePoint publishing
The web gateway has wizards and other technologies that make intelligent decisions on how to best publish SharePoint resources
Thanks to Fernando Cima and Carsten Kinder for developing this table.
Tom Shinder tomsh@microsoft.com Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management Anywhere Access Group (AAG) The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
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.
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
In a recent article on The Edge Man blog, I talked about the Network Location Server (NLS) and how it’s used to help the DirectAccess (DA) client determine if it’s on or off the corporate network. If you missed that article, or need a refresher, check it out at http://blogs.technet.com/tomshinder/archive/2010/04/02/directaccess-client-location-awareness-nrpt-name-resolution.aspx
Now that you have a basic understanding of what the NLS server does and its critical role in a DirectAccess solution, the next step is to figure out what happens when the NLS server is unreachable by the DA client when the DA client is on the corpnet.
----------------------------------------------------------------------------------------- Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag -----------------------------------------------------------------------------------------
What might make the NLS server unreachable? Consider the following:
There are probably many other things that could cause problems when the DA client tries to connect to the NLS server. If this happens, what is the result?
What happens at this point is determined by whether or not the DA client on the corpnet has connectivity to the UAG DA server on the Internet. That is to say, the results differ depending on whether or not the DA client on the corpnet can connect to the external IP address on the UAG DA server.
What happens when the DA client is not able to connect to the UAG DA server’s external IP address when a connection to the NLS fails?
Next, what happens when the DA client is able to connect to the external interface of the UAG DA server? Remember, the UAG DA server cannot enable outbound connections from hosts on the internal network, not even outbound connections from its internal interface to its external interface. That means that some other gateway on the network must be available to allow the connection to the external interface of the UAG DA server.
In this case the DA client tries to connect to the resource first by using a FQDN. Depending on the connectivity the DA client has with the external interface of the UAG DA server, the client might use Teredo or IP-HTTPS to bounce back to the internal network through the UAG DA server. Since the DA client can connect to the UAG DA server’s DNS proxy, it will be able to resolve the name of the internal network destination host.
However, the request/response path is not going to be efficient:
The request/response path will look something like this (from a very high level view):
As you can imagine, performance is likely to suffer, depending on the number of interposed devices and the traffic profiles on the networks that the packets have to traverse. Also, there are a number of potential points of failure, which doesn’t help either. However, this scenario does allow the DA clients to connect to corporate resources in the event of a NLS failure, which could buy you time while you’re trying to fix the primary problem.
The fact is that bad things happen to good computers. Server failure is not a matter of “if” it will happen, it’s a matter of “when” it will happen. Since you know that your NLS servers and all the other dependent components are going to fail at some point in time, what can you do to mitigate these failures and have your users experience the least amount of pain during the event?
There are some additional measures you can take to make sure that NLS failure causes the least disruption as possible:
The Network Location Server allows the DA client to know when it’s on or off the corpnet. However, when there is an issue preventing the DA client from connecting to the NLS server when the DA client is on the corpnet, the client will act as if it off the corpnet, and this can cause a number of problems, depending on the current network configuration and whether or not the DA client can reach the external interface of the UAG DA server when the DA client is on the corpnet. This article summarized a number of things you can do to mitigate NLS connectivity failures and help insure that these failures have less negative impact on network operations and your users when they occur.
In the near future we will publish a white paper on this issue and it will expand a bit on what I’ve covered in these two blog posts on Network Location Servers. I’ll make sure to post the URL to that paper on this blog when it becomes available.
Its seems like we’ve run into a little confusion recently regarding how to deploy the UAG DA server in a firewalled environment.
If you look at our documentation for Packet Filtering for the Internet Firewall (http://technet.microsoft.com/en-us/library/ee809062.aspx) you’ll see that we fully support putting a firewall in front of the UAG DA server.
To quote Packet Filtering for the Internet Firewall:
“Most organizations use an Internet firewall between the Internet and the computers on their perimeter network. The firewall is typically configured with packet filters that allow specific types of traffic to and from the perimeter network computers. When you add a Forefront UAG DirectAccess server to your perimeter network, you must configure additional packet filters, to allow the traffic to and from the Forefront UAG DirectAccess server for all the traffic that a DirectAccess client uses to obtain IPv6 connectivity to the Forefront UAG DirectAccess server.
The following describes the type of traffic you can configure on your Internet firewall depending on whether the Forefront UAG DirectAccess server is on an IPv4 or IPv6 Internet.
Configure packet filters on your Internet firewall to allow the following types of IPv4 traffic for the Forefront UAG DirectAccess server:
Configure packet filters on your Internet firewall to allow the following types of IPv6 traffic for the Forefront UAG DirectAccess server:
=====================================
However, there has been a cause for confusion in this documentation because some admins confuse firewalling with NAT. While it is true that most firewalls are deployed with NAT enabled, that doesn’t mean you must NAT connections coming through the firewall. In fact, the UAG Infrastructure and Planning Guide (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=110b4c77-b411-4845-9b82-40a733b17003) states:
“Are you deploying Forefront UAG as a DirectAccess server?─A Forefront UAG DirectAccess server can be located behind a firewall or between a frontend and backend firewall, but note that a public IPv4 address is required, and therefore the server should not be located behind a NAT (Network Address Translation) device” [italics mine]
So to answer the question - “can you put the UAG DA server” behind a front-end firewall, the answer is yes. However, that firewall cannot NAT connections between the DirectAccess clients and the UAG DirectAccess Server.
When you configure a Windows DA server or UAG DA server-based DirectAccess (DA) solution, the default setting is to enable split tunneling. What split tunneling refers to is the fact that only connections to the corpnet are sent over the DA IPsec tunnels. If the user wants to connect to resources on the Internet, the connection is made over the local link (that is to say, the connection is sent directly to the Internet based on the IP addressing configuration on the DA client computer’s NIC).
The advantage of split tunneling is that users have a much better computing experience, especially when accessing Internet based resources. In addition, users on the corpnet are likely to have a better computing experience when accessing resources on the Internet, since the DA client traffic isn’t consuming corporate Internet bandwidth to connect to Internet resources. The combined advantages of improved DA client and corpnet client Internet computing experience makes it worthwhile to make split tunneling the default configuration for DA client/server communications.
However, you might not want to enable split tunneling. If that is the case, then all traffic from the DA client to any resource must go over the DA IPsec tunnels. Traffic destined for the intranet goes over the DA IPsec tunnels, and traffic destined to the Internet also goes over the DA IPsec tunnels. Split tunneling is disabled when you enable Force Tunneling for the DA client connections. Force Tunneling is enabled via Group Policy:
Computer Configuration\Administrative Templates\Network\Network Connections\Route all traffic through the internal network
When Force Tunneling is enabled, all traffic is sent over the DA client tunnel using the IP-HTTPS protocol. IP-HTTPS is one of the three IPv6 transition protocols that the DA client can use to connect to the DA server. The other two protocols are 6to4 (used when the DA client is assigned a public IP address) and Teredo (used when the DA client is assigned a private IP address and has outbound access to UDP port 3544 to the DA server). IP-HTTPS is used when the DA client is assigned a private address and outbound access to UDP port 3544 to the DA server is not available.
The problem with IP-HTTPS is that it should be considered, and is instantiated as, a protocol of last resort. There are a number of reasons for this, with the primary reason being that it’s the lowest performing of the IPv6 transition technology protocols. Think about it – the client and server have to negotiate and use IPsec encryption and then also has to negotiate and encrypt the HTTPS (SSL) session. This “double encryption” takes a toll on the processor. In addition, IP-HTTPS has a much higher protocol overhead, so that the area available for the payload for each packet is smaller, requiring more packets to be sent to communicate the same amount of data, thus impairing performance even more.
In addition to the performance issues are the Internet access issues for the IP-HTTPS client. Remember that all communications from the DA client to the DA server are over IPv6. The DA client never uses IPv4 to connect to resources through the DA client/server channel. Because of this, you will need to deploy an IPv6 aware web and winsock proxy server on the network that the DA clients can use to connect to the Internet, or use the UAG DirectAccess solution, which includes an IPv6/IPv4 protocol translator that allows the DA client to connect to Internet resources through a IPv4 web and winsock proxy server, such as the ISA or TMG firewall. This adds more complexity to an already problematic situation.
And there is one more “gotcha” when you use Force tunneling. As I’ve said, all communications between the DA client and server are over IPv6. What this means in practice is that the client application must be IPv6 aware. This is not to say that the server side of the application needs to be IPv6 aware and in most cases the server side will work fine with the help of the UAG NAT64/DNS64 IPv6 protocol translator if the server side is only IPv4 aware – but the client side must always be IPv6 capable.
Thus, Force Tunneling can be a problem in those scenarios where the client side is not IPv6 aware. For example, the Office Communications Server Client (at the time of this writing) is not IPv6 aware. In order for the DA client to reach the OCS server, it will need to use the direct connection to the Internet to connect to the OCS server located on the corpnet. If you try to force the OCS client/server communications over the DA connection, the attempt will fail because the OCS client is not IPv6 aware. Any other non-IPv6 aware client application will fail, as it won’t be able to connect over the Internet because split tunneling is disabled.
At this point it’s worthwhile to think about split tunneling and the reasons why you wouldn’t want to enable split tunneling to determine if those reasons are actually applicable in a DA client/server solution. It might turn out that the assumptions you made when deciding against split tunneling weren’t as valid as you thought, and that the perceived risks of split tunneling were overstated to the extent that split tunneling may no longer be an issue.
Most network admins developed their opinions regarding split tunneling based on their understanding of how VPN clients work, and in many (most?) cases these opinions were derived from issues that were extant in the early to mid 1990s and with non-Microsoft VPN clients.
What are some of the reasons why you think you need to disable split tunneling? Two of them might include:
Now let’s examine the relationship to VPN and split tunneling, since this is usually the basis for wanting to disable split tunneling:
So the question at this point should be “what are the problems with allowing users to connect to the Internet and the intranet at the same time?” – as this appears to the crux of the split tunneling issue.
From this assessment, it seems clear that there is only one valid scenario where you would want to disable split tunneling and that’s when you want to force all traffic through the corporate web and/or winsock proxy server so that the traffic is filtered to reduce the risk that malware can be downloaded to the DA client over the Internet. I admit, that if there is a weak link in the DA story, that this is it.
However, this weak link isn’t a DA issue because the fact is that there are no longer any “bolted down” corpnet clients. Most organizations have moved to laptops for their employees, and those mobile devices travel between the Internet filtered corpnet and the non-filtered Internet on whatever external network those clients are connected to. Therefore, unless you’re using a 3rd party solution that enforces Internet access policy to computers that aren’t connected to the corpnet, there is little to be gained by forcing the DA clients over the corporate web filters. Of course, the ideal situation would be to use an Internet based web filtering solution so that the DA clients have corporate web access policy forced on them as well.
Another thing that should be clear at this point is that the issue of “routing” communications from an Internet based host to the corpnet doesn’t happen on Windows clients of today. So that concern, perhaps inherited from the 1990s, is no longer an issue and doesn’t represent a security issue for VPN or DirectAccess clients. Whether the client is connected intermittently (as with VPN clients) or is “always on” (as with DA clients) really doesn’t make a difference in terms of the overall security posture provided by the DA client.
In sum, I highly recommend that you do not disable split tunneling for your DirectAccess clients. The benefits from doing so are virtually none, but the cost, complexity and productivity hits imposed by enabling Force Tunneling can be substantial.
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:
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 mysterious errors you’ll see when working with DirectAccess are related to failures in IP-HTTPS connectivity. I did a blog post on this problem last year and you can find it at http://blogs.technet.com/b/tomshinder/archive/2010/03/30/troubleshooting-the-no-usable-certificate-s-ip-https-client-error.aspx
Phillip Sand clued me into another possible cause of IP-HTTPS connectivity problems. First, whenever you suspect a problem with IP-HTTPS connectivity, you should run the command:
netsh interface httpstunnel show interface
If you see the following:
Role : client URL : https://da.domain.com:443/IPHTTPS Last Error Code : 0x103 Interface Status : no usable certificate(s) found
Where da.domain.com is the FQDN used to connect to the IP-HTTPS listener on the external interface of the UAG DirectAccess server, then you know you have a problem.
In addition to the cause I mentioned in the earlier blog post is a situation related to the CA certificate not being installed in the NTAUTH store of the UAG DirectAccess server. You can find out if the CA certificate is installed by running the command:
certutil –v –store –enterprise ntauth
on the UAG DirectAccess server. If everything is OK, then you’ll see something like what appears in the figure below (this is what you’ll see if you’re using the UAG DirectAccess Test Lab Guide for your UAG DA lab):
If you don’t see any certificate listed, then that can cause the 0x103 error on the client.
You can fix the problem by running the command:
certutil –addstore –enterprise –ntauth IssuingCACert.cer
Where IssusingCACert.cert is the root CA certificate.
Hat tip to Philipp Sand for this great info!
Visit the TechNet forums to discuss all your UAG DirectAccess issues http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads
Stay up-to-date with “just in time” UAG DirectAccess information on the TechNet wiki http://social.technet.microsoft.com/wiki/tags/DirectAccess/default.aspx
An interesting case came in last week and I thought it would be useful to share it with you all. It’s especially interesting because it covers some not so well documented features of the IP-HTTPS client configuration and how it works.
For those of you who haven’t worked with DirectAccess, or who are in the process of learning about it, IP-HTTPS is a new protocol introduced with Windows 7 and Windows Server 2008 R2 for Microsoft DirectAccess that allows a DirectAccess client to connect to the DirectAccess (DA) server by using HTTP (SSL) as a transport. This enables the DA client to connect to the DA server even when the client is located behind a firewall or web proxy that only allows outbound HTTP/HTTPS.
In this example, the admin had a problem with getting IP-HTTPS connectivity to work. As part of his troubleshooting process, he ran the command
The results were:
Role : client
URL : https://da.domain.com:443/IPHTTPS
Last Error Code : 0x103
Interface Status : no usable certificate(s) found
The problem seemed to be related to the interface status: no usable certificate(s) found.
When the admin checked whether there was a computer certificate installed on the computer, he saw that there was, so it didn’t make sense that there was no usable certificate. Perhaps there was something missing from the computer certificate itself?
To understand the problem, it helps to understand how the computer certificate is used in establishing the IP-HTTPS connection. The DA IP-HTTPS client uses the computer certificate to establish the IPsec tunnel, just as it does when it’s acting as a 6to4 or Teredo client. However, when acting as an IP-HTTS client, the computer certificate is also used to provide credentials for client authentication when connecting to the IP-HTTPS listener on the DA server.
Client certificate authentication is a default setting on the UAG DA server when the client connects over IP-HTTPS, but it is not a default setting on the Windows DA server. If you want to require client certificate authentication to the Windows DA server (which protects the IP-HTTPS listener against denial of service attacks) you can configure the setting manually by using the information in the article Configure Client Authentication and Certificate Mapping for IP-HTTPS Connections. These instructions will enable the DS Mapper usage feature on the DA server. However, keep in mind that if you are using a UAG DA server, you do not need to do this – the UAG DA wizard takes care of this configuration for you.
You can confirm that DS Mapper Usage is enabled by using the netsh http show sslcert command on the DA server, as seen in the figure below.
Notice the title of that article. Not only does the setting configure Client Authentication, but it also configure Certificate Mapping.
What is this certificate mapping of which I speak?
If you look in Active Directory Users and Computers and right click on a DA client computer account, you will see the Name Mappings option in the context menu, as seen in the figure below.
After selecting the Name Mappings option, you’ll see the Security Identity Mapping dialog box, as seen in the figure below. Here you see that the mapped user account (which is mapped in the Active Directory) is to domain1.corp.company.com/Computers/CLIENT2.
This name maps to the DNS name assigned to the computer account, which you can see in the Properties dialog box of the computer account, as seen in the figure below.
In order for client certificate authentication to work, the subject name or a SAN on the certificate must match the DNS name assigned to the computer account. For example, in the figure below you can see that the first SAN shows the DNS name of the computer, which is the same DNS name used by the computer account for this DA client computer.
So what could cause this problem? It might be that the certificate template used to create the computer certificate didn’t include DNS name of the computer account in the subject name or the first SAN. If you use the default Computer certificate template, you will see that the DNS computer name is used as the subject name in the certificate, as shown in the figure below.
(Note: the certificate above is from a different client computer than those shown in the other figures, that’s why it shows CLIENT1 instead of CLIENT2).
However, if you use a custom certificate or another certificate template to assign the computer certificate, you will need to configure the template so that the DNS name of the computer is included in the subject name or in a SAN entry.
For example, look at the Properties dialog box for the Workstation Authentication certificate template. On the Subject Name tab, you can select the option Build from this Active Directory information option and then select your preferred Subject name format. If you don’t choose the Common Name or DNS Name option, then you’ll want to make sure that the DNS Name checkbox is selected from the Include this information in alternate subject name list. In fact, even if you choose the Common Name or DNS name option, it’s not a bad idea to select the DNS name entry for the first SAN, as there are scenarios that require this.
It is important to note that this is one of the reasons why you want to use an Enterprise CA in your environment, so that this AD mapping takes place automatically. When the UAG DA server receives the computer certificate from the DA IP-HTTPS client, it will use the DNS name to forward to the domain controller for authentication. If this name does not match the name associated with the computer’s account, authentication will fail.
CONCLUSIONS:
Let me know if you have any questions on this and I’ll follow up in another blog post.
[Props to Billy Price for coming up with this solution]
Thanks!
Tom Shinder tomsh@microsoft.com MS ISD 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
For companies thinking about deploying DirectAccess, the question of whether or not you need to deploy ISATAP will invariably come up. The answer to this question is “no” and the reasons for why you don’t need ISATAP in a DirectAccess deployment are covered in my article over at http://blogs.technet.com/b/tomshinder/archive/2010/10/01/is-isatap-required-for-uag-directaccess.aspx
However, ISATAP does have a place in a DirectAccess deployment, as I discussed in that article. If you don’t have an existing native IPv6 network infrastructure in place, then you might want to consider enabling ISATAP to fully realize the “manage out” capabilities that are part of a comprehensive DirectAccess solution.
However, in all the coverage of ISATAP, I’ve left out some critical information that can help you decide on how you deploy ISATAP in your organization. It’s at this point I get to tell you that the ole “Edge Man’s” favorite food is crow. When I get to eat crow, it means I said something in public and then find out later I was wrong (or at least not entirely right). I like crow because when I eat it, it means that I’ve learned something new.
Now with that are an introduction, let’s get into what led to this “crow eating” session. If you read this blog on a regular basis, you might remember my article on using a HOSTS file entry to control which systems configure themselves as ISATAP hosts. If you didn’t see it you can check it out at http://blogs.technet.com/b/tomshinder/archive/2011/02/14/use-a-hosts-file-entry-to-control-isatap-host-configuration.aspx
In that article, I said:
“In general, ISATAP is a good thing…”
Now that seems like a pretty benign statement, doesn’t it? I thought so. But if you look at the Intra-site Automatic Tunnel Addressing Protocol Deployment Guide at http://www.microsoft.com/downloads/en/details.aspx?familyid=0F3A8868-E337-43D1-B271-B8C8702344CD&displaylang=en you will find the following statement:
“Appropriate Uses for ISATAP on Intranets ISATAP in Windows is not designed for production networks [italics mine]. On a production network, ISATAP should be used in a limited capacity for testing while you deploy native IPv6 capabilities. Microsoft does not recommend the use of ISATAP across entire production networks. Instead, you should deploy native IPv6 routing capability…”
Ah, well, ahem, er, kaff-kaff, aaaa.., that doesn’t really align with my comment regarding “in general, ISATAP is a good thing”.
Let me explain.
To get a better appreciation for the situation, it’s a good start to think about what ISATAP actually does. For most of us, our introduction to ISATAP is with DirectAccess. In fact, for many of us, our introduction to IPv6 is with DirectAccess. When reading about DirectAccess you see that the DirectAccess server is configured as an ISATAP router, as well as a router or relay for Teredo and IP-HTTPS. This gives you the initial impression that ISATAP must be a required component of the UAG DirectAccess solution, and that perhaps it’s a standard for all IPv6 deployments. In truth, ISATAP has limited utility and is designed to support a very specific scenario.
ISATAP is an IPv6 transition technology and is designed as a temporary solution to help you transition your IPv4 network to an IPv6 network. ISATAP enables ISATAP capable hosts to automatically assign an address to an ISATAP adapter, and to communicate with an ISATAP router to get IPv6 routing table information. The purpose of ISATAP then is to provide ISATAP capable hosts with information that enables them to connect to hosts on an IPv6 only network. That connection is made through an ISATAP router.
The ISATAP router has an interface on the IPv4 only network and a second interface on an IPv6 only network. The ISATAP router will take the IPv6 packets that are encapsulated in an IPv4 header, and forward them to the IPv6 only network by removing the IPv4 header before forwarding them. When hosts on the IPv6 only network want to connect to hosts on the IPv4 network, the ISATAP router will receive the packets, put an IPv4 header on them, and forward them to the ISATAP enabled hosts on the IPv4 only network.
When ISATAP enabled hosts on an IPv4 only network communicate with each other, they will preferentially use their ISATAP adapters to communicate. They will query DNS and if they receive both A and AAAA records, they will use the AAAA record’s address and use IPv6 to communicate with the other ISATAP enabled host on the IPv4 only network. This is done because Windows hosts that are capable of using ISATAP (Vista and above, Windows 2008 and above) use IPv6 preferentially. It doesn’t matter that the IPv6 packets are encapsulated with an IPv4 header. Keep in mind that in order to reach the ISATAP adapter on the destination host, the source host also needs the address in the A record to get the IPv4 address of the destination.
In Figure 1, you can see three networks:
When a host on the IPv4 only network wants to connect to a host on the IPv6 only network, it uses routing table entries that indicate that it should use its ISATAP adapter to send the IPv6 packets to the IPv4 address ISATAP router. The ISATAP router then removes the IPv4 header to expose the IPv6 header and forwards the IPv6 packet to the host on the IPv6 network.
The UAG DirectAccess server is also configured as an ISATAP router, and it advertises IPv6 routes that ISATAP capable hosts on the IPv4 only network can use to connect to DirectAccess clients. The DirectAccess clients network (which includes network prefixes for the Teredo, 6to4 and IP-HTTPS address spaces) is an IPv6 only network. Therefore, when a host on the IPv4 only network wants to connect to a DirectAccess client, it checks its routing table and finds that it should use its ISATAP adapter to send the IPv6 packets to the IPv4 address on the internal interface of the UAG DirectAccess server. The UAG DirectAccess server (acting as an ISATAP router) removes the IPv4 header and forwards the un-encapsulated IPv6 packet to the DirectAccess client.
Figure 1
As you can see, ISATAP is used to enable connections from an IPv4 only network (meaning the routing infrastructure only supports IPv4 routing) to an IPv6 only network (meaning that the routing infrastructure supports IPv6 and the hosts on the network use only IPv6 addressing) by using an ISATAP router. The idea here is that as you transition to an IPv6 network, you will create dedicated segments devoted to IPv6 and that during this transition, you still need to enable connectivity between the “old” IPv4 only network and the “new” IPv6 only network. The transition phase isn’t meant to be indefinite and when the transition phase of the deployment is over, you’ll disable ISATAP in DNS and take down the ISATAP routers.
However, DirectAccess is a special case when it comes to ISATAP and IPv6 enablement. We want you to be able to use DirectAccess now. However, we also realize that very few networks are IPv6-only at this time and that it will take several years before the predominate network protocol is IPv6. To solve this problem, we enabled the UAG DirectAccess server as an ISATAP router. For the UAG DirectAccess server, the purpose is to enable full “manage out” capability, so that management servers on the IPv4 intranet can initiate connections with DirectAccess clients. We don’t need ISATAP to support connections initiated by DirectAccess clients to IPv4 resources on the intranet because we have the NAT64/DNS64 solution.
The “manage out” scenario where management servers on the intranet initiate connections to the DirectAccess clients is a relatively limited one in terms of scope. You won’t have that many management servers that need to be able to do this (although you might want to allow Help Desk to connect to DirectAccess clients over RDP, in which case the number of hosts that need to initiate a “manage out” connection will be larger). Since you know in advance who these machines are, you might want to consider using a HOSTS file entry on these “manage out” machines instead of enabling ISATAP for your entire network using DNS. This gets around problems you might run into if you’ve decided to disable IPv6 on the computers on your network (you can find out the details of this situation in my blog post at http://blogs.technet.com/b/tomshinder/archive/2011/02/14/use-a-hosts-file-entry-to-control-isatap-host-configuration.aspx).
In conclusion, we can reconcile my statement that ISATAP is generally a good thing when we think about the special case of the DirectAccess. However, the purpose of ISATAP in a DirectAccess scenario is a bit different than it is when you’re using ISATAP to transition your intranet to IPv6. Because a limited number of hosts on the intranet need to be IPv6 capable to initiate connections (manage out) DirectAccess clients, there is a good argument for not enabling ISATAP in DNS (it is disabled by default) and only using HOSTS file entries on the machines that require “manage out” capability to DirectAccess clients.
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.
As a member of the Anywhere Access Team with a primary focus on UAG DirectAccess (DA), one of the questions that I hear a lot relates to the security of the solution, due to the fact that split tunneling is enabled by default.
If you’re a VPN guy, you are probably aware of the issue of split tunneling. When split tunneling is disabled, the VPN client uses the VPN gateway as its default gateway, so that all off subnet communications must go through the VPN gateway. It also prevents the the VPN clients from potentially routing communications between two networks, such as the client’s network and the corporate network.
For this reason, most experienced VPN admins disable split tunneling by default. This has become a habit for VPN admins and they don’t think twice about it. However, what they gain in security is lost in performance for the corporate Internet connection.
The reason for this is that the VPN client must go through the VPN gateway to access Internet content, so that the request/response path for Internet content is from the VPN client, to the VPN gateway, to an Internet gateway on the corpnet, to the Internet, and then the response is returned using the same path in the opposite direction.
As you can imagine, if you have more than a few VPN clients, this could become a major bottleneck on your Internet bandwidth.
The DA team understands this problem very well. If the DA client connection isn’t highly performant, users will likely be unsatisfied with the solution. The productivity gains you expected will evaporate, as users won’t use DA to connect to the corpnet, and they’ll return to their old inefficient ways of working.
So, DirectAccess by default enables split tunneling. All traffic destined to the corpnet is sent over the DA IPsec tunnels, and all traffic destined for the Internet is sent directly to the Internet over the local interface. This prevents DA clients from bringing the corporate Internet connection to its knees.
However, it has left the issue of potential risks of split tunneling in the minds of admins who are considering DA. One option is to use “force tunneling”. You can find out more about force tunneling at http://technet.microsoft.com/en-us/library/dd637812(WS.10).aspx One of the primary disadvantages of force tunneling is reduced performance, especially in the context of reaching IPv4 only resources.
But this begs the question: is DA split tunneling really a problem? The answer is no.
Why? Because the risks that exist with VPNs, where the machine can act as a router between the Internet and the corporate network is not valid with DirectAccess. IPsec rules on the UAG server require that traffic be from an authenticated source, and all traffic between the DA client and server is protected with IPsec.
Thus, in the scenario where the DA client might be configured as a router, the source of the traffic isn’t going to be the DA client, and authentication will fail – hence preventing the type of routing that VPN admins are concerned about.
Tom Shinder Microsoft ISDUA Anywhere Access Team/UAG DirectAccess
A few people have mentioned on the web forums and in email discussions that they’d like an easy way to disable the IP-HTTPS interface on the DirectAccess client for testing purposes. They don’t want to disable it completely for all clients (which you can do through Group Policy), they just want to disable it for a specific client for a short period of time to figure out what the problem might be with something else.
If you open the network shell (netsh) and check the syntax that you should use to disable the IP-HTTPS interface, you’ll see something like the following:
Syntax set interface [[ url= ] ( url )] [[ state= ] ( enabled | disabled | default )] [[authmode= ] ( none | certificates )]
However, if you try it, you’ll see something like this:
What’s up with that?
Apparently, there is a problem with using netsh to disable the IP-HTTPS interface. Therefore, we’re going to have to consider an alternate approach to temporarily disable the IP-HTTPS interface.
To do this, open the Registry Editor and navigate to:
HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition\IPHTTPS\IPHTTPSInterface\IPHTTPS_ClientState
To disable the interface, set the value to 3.
Keep in mind that this setting is controlled through the UAG DirectAccess client Group Policy. When Group Policy is refreshed on the client, this setting will be overwritten and the IP-HTTPS interface will activate again.
Windows Server 2012 is the greatest operating system Microsoft has ever unleashed on your data center. There are so many new features and capabilities that it would take several books to illuminate them all. And with all that goodness comes a number of new and improved security technologies. This is what the book Windows Server 2012 Security from End to Edge and Beyond written by me, Yuri Diogenes and Debra Littlejohn Shinder is all about.
Why did we pick the name “From End to Edge and Beyond”? The “End” is the endpoint – the client device that connects to server based applications and services and the servers themselves. The “Edge” is the edge of the network, a firewall or a remote access server. And “Beyond” is about the cloud. Windows Server 2012 Security from End to Edge and Beyond addresses all of these issues, security has it applies to the endpoint, network edge and the cloud.
What’s inside? Check this out:
And there’s an added bonus – Tim Rains from the Microsoft Trustworthy Computing Group will be writing a forward for the book! Tim Rains is the Director of Product Management in Microsoft’s Trustworthy Computing group. Tim and his team of product managers support the Microsoft Security Response Center (MSRC), the Microsoft Malware Protection Center (MMPC), and the Microsoft Security Engineering Center (MSEC) which includes the Security Development Lifecycle (SDL) and Security Science. Among other things, Tim’s team manages production of the Microsoft Security Intelligence Report (www.microsoft.com/sir). Tim has worked in several roles at Microsoft including the Senior Public Relations Manager of Security Response at Microsoft, Senior Product Manager of the Microsoft Malware Protection Center, Program Manager of the Windows Network Diagnostics team, Technical Lead on the Security Incident Response team in the Product Support Services (PSS) Security team and Technical Lead on the PSS Windows Server Networking team.
It’s quite a compliment to have Tim endorse our book. Not only will he write a forward for the book, he has made several key suggestions that enhance the overall value of the book to any security minded administrator who needs that extra leg up to secure his data center. Yuri, Debi and I truly appreciate Tim’s insights and we hope you will benefit from Tim’s input into this book.
We just about done with the writing and expect that the book will be available in December or January. Stay tuned!
Tom Shinder tomsh@microsoft.com Principal Knowledge Engineer, SCD iX Solutions Group Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
Go Social with Private Cloud Architecture! Private Cloud Architecture blog Private Cloud Architecture Facebook page Private Cloud Architecture Twitter account Private Cloud Architecture LinkedIn Group Private Cloud TechNet forums TechNet Private Cloud Solution Hub Private Cloud on the TechNet Wiki
Forefront UAG supports an enhanced version of DirectAccess that adds several features and capabilities that aren't available with the Windows only version of DirectAccess. After installing UAG on your Windows Server 2008 R2 server, you can then enable DirectAccess using the UAG DirectAccess wizard.
Some administrators have received the message:
"The adapter configured as external-facing is connected to a domain"
after running the DirectAccess wizard. If you receive this message, the DirectAccess wizard will not complete and DirectAccess will not be configured on the UAG DirectAccess server. The reason for this failure is that if the external interface detects that it can reach a domain controller, it will set the Windows Firewall with Advanced Security Profile to "Domain Profile", which will disable the GPO settings required for the DirectAccess server to receive connections from DirectAccess clients (connection security rules, firewall rules, etc).
The cause of this problem isn't well defined right now, but it appears that the problem is related to the UAG DirectAccess activation assuming that the external interface it set for the domain profile in Windows Firewall with Advanced security, although NLA (Network Location Awareness) no longer recognizes that to be true. It could be that the external interface at one time had connectivity to the domain, but later was reconfigured so that subsequently the external interface no longer could access the domain.
If you do run into this issue, you can fix the problem by using the Registry Editor to navigate to the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache\IntranetAuth
Delete all the entries that apply to the external interface - those will be the ones that have the IP addresses assigned to the external interface. From the figure above, those would be:
I’ll continue to follow up on this issue and update the blog with new information as it comes in. But until then, you have a workaround that will allow you to activate your UAG DirectAccess configuration.
What would you be willing to pay for a really cool IPv6 and DirectAccess troubleshooting cheat sheet?
$5? $10? $100? ONE HUNDRED BILLION DOLLARS?
Since these cheat sheets are priceless we’re going to give them away. Thanks to DirectAccess guru and all around good guy Pat Telford, we’re making the .vsd file for these cheat sheets available for download.
You haven’t seen these cheat sheets? Here’s what they look like:
You can download the .vsd for these sheets HERE.
Tom Shinder tomsh@microsoft.com Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management/ICG Anywhere Access Group (AAG) The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
Talk TechNet enables you to get your questions about hot technologies answered in real time. In this session, Dr. Tom Shinder will be here to discuss DirectAccess and what Unified Access Gateway 2010 brings to the DirectAccess table. Tom is a Principal Writer in the Anywhere Access Group and is responsible for UAG DirectAccess content and promoting DirectAccess in the community.
Bring your hard questions about IPv6, IPv6 transition technologies, IPsec, Teredo, 6to4, IP-HTTPS, Name Resolution Policy Table (NRPT), CRL checking and more! DirectAccess is wide and deep, so here's you unique opportunity to "stump the chump!"
Presenters: Keith Combs, Senior Program Manager, Microsoft Corporation, Matt Hester, Senior IT Pro Evangelist, Microsoft Corporation, and Dr. Tom Shinder, Principal Technical Writer, Microsoft Corporation
Head on over to:
https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032477770&EventCategory=4&culture=en-US&CountryCode=US
to Register for the event.
I’ll make sure to remind everyone a couple of days before we go live.
The following are some troubleshooting steps if you run into problems getting inside-out management working. Inside-out management is the ability for a machine on the internal corporate network, such as a helpdesk machine, to be able to initiate communications to remote, internet-based DirectAccess clients, such as by using RDP sessions, remote registry, or mapping drives.
1. Ensure the remote DirectAccess client has registered its IPv6 address and name in DNS and that it can be resolved by the Inside-Out management machine. The IPv6 address will correlate to which ever connection mechanism the client is using, either:
a. Native IPv6 (unlikely)
b. 6to4
c. Teredo
d. IP-HTTPS
Note. A link local IPv6 address will not work.
2. Ensure the Inside-Out management machine is configured with IPv6 via ISATAP (this could also be native IPv6 but we will assume ISATAP).
If the Inside-Out management machine is not receiving an ISATAP address, check
a. All the ISATAP IP addresses are registered (see point 4 below)
b. That all the ISATAP IP addresses are all in the same subnet, and that the subnet mask allocated is correct
c. That the Intranet firewall is allowing Protocol 41 (See point 5 below)
3. Ensure the Inside-Out management machine has registered its IPv6 address and name in DNS and can be resolved successfully. This will be the machines ISATAP IPv6 address.
If the helpdesk machine does not have an ISATAP address refresh ISATAP (and other) settings from the command line using one of the following commands:
i. SC CONTROL IPHLPSVC PARAMCHANGE
Or
ii. NET STOP IPHLPSVC then NET START IPHLPSVC
4. Ensure the ISATAP router name is resolving to the internal interfaces of the DirectAccess server acting as the ISATAP router from the internal network, or other ISATAP router if you are using one.
a. In a WNLB 2-node array, this would be the 2 x servers dedicated IP addresses plus the virtual IP address, so 3 addresses in total all resolving to the ISATAP name.
5. Ensure that the Intranet Firewall is allowing Protocol 41 (IPv6 encapsulation) to UAG servers in both directions. Do not confuse Protocol 41 with Port 41. IPv6 Encapsulation is a protocol like TCP or UDP, not a Port.
6. Ensure any required client side firewall rules are in place on the remote DirectAccess clients with Edge traversal allowed
a. ICMPv4 for pinging IPv4 addresses
b. ICMPv6 for pinging IPv6 addresses
c. F&P for whichever services you require, such as SMB file share mapping
d. Remote Desktop
e. Etc. Etc.
7. Ensure all the DirectAccess Servers have a valid ISATAP configuration.
a. NETSH INT IPV6
a.1. Find the index number for ISATAP
b. NETSH INT IPV6 SH INT Index#
b.1. Ensure that Forwarding, Advertising and Advertise Default Route, are all enabled
b.2. If not
b.2.1. NETSH INT IPV6 SET INT Index# FORWARDING =EN ADVERTISE=EN ADVERTISEDEFAULTROUTE=EN
b.3. Validate changes
b.3.1. NETSH INT IPV6 SHOW INT Index#
b.4. NET STOP IPHLPSVC
b.5. NET STOP IPHLPSVC
8. Collect some trace logs:
a. NETSH TRACE START SCENARIO=DIRECTACCESS CAPTURE=YES REPORT=YES
b. NET STOP IPHLPSVC
c. NET START IPHLPSVC
d. Wait 10 seconds
e. NETSH TRACE STOP
The logs are called NETTRACE.ETL and NETTRACE.CAB files and will be located in the %TEMP%\NetTraces folder. Either analyse the logs yourself or send them to your support representative.
9. Note. If you want to be able to manage the remote DirectAccess computers even when no one is logged on to them, add the Inside-Out management machines to the management servers group on the DirectAccess servers, where you define Domain Controllers, SCCM and AV machines. Machines defined in these groups can access the client when only the infrastructure tunnel is up, i.e. before the remote user logs on and establishes the Intranet tunnel. If you have been trying to connect to a remote machine that is not logged on, this could be your problem.
Finally, if the troubleshooting steps have still not helped, just be aware of the issue in this knowledge base article, DirectAccess Manage Out fails for any non-ICMP traffic in Forefront Unified Access Gateway 2010, caused by custom security policies regarding the local security rights for the DirectAccess Manage-Out machine and clients (e.g. modifying the setting "Access this computer from the network").
If you are still having problems you will need to set up network traces from the inside-out management machine, the DirectAccess servers, and the remote DirectAccess client to see where things are going wrong.
HTH.
Colin Brown, Architect.
Microsoft Consulting Services.
Hey folks – since the TLGs are typically put up only on the download center, it makes discoverability of some of the cool content inside of them hard when it comes to search engines. Therefore, I’m going to post the full text of the TLGs on the Edge Man blog. However, I recommend that you download the Word .doc version of the TLGs when you actually put together your Test Lab using the Test Lab Guides.
For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess check out:
http://go.microsoft.com/fwlink/?LinkId=204993
==================================================
Forefront Unified Access Gateway (UAG) 2010 SP1 RC provides users with the experience of being seamlessly connected to their intranet any time they have Internet access. When DirectAccess is enabled, requests for intranet resources (such as e-mail servers, shared folders, or intranet Web sites) are securely directed to the intranet, without the need for users to connect to a VPN. DirectAccess enables increased productivity for a mobile workforce by offering the same connectivity experience both inside and outside of the office. Forefront UAG 2010 SP1 RC DirectAccess extends the benefits of Windows DirectAccess across your infrastructure by enhancing availability and scalability, as well as simplifying deployments and ongoing management. For more information, see Overview of Forefront UAG DirectAccess.
IT professionals can benefit from UAG 2010 SP1 RC DirectAccess in many ways:
· Improved Manageability of Remote Users. Without DirectAccess, IT professionals can only manage mobile computers when users connect to a VPN or physically enter the office. With DirectAccess, IT professionals can manage mobile computers by updating Group Policy settings and distributing software updates any time the mobile computer has Internet connectivity, even if the user is not logged on. This flexibility allows IT professionals to manage remote computers on a regular basis and ensures that mobile users stay up-to-date with security and system health policies.
· Secure and Flexible Network Infrastructure. Taking advantage of technologies such as Internet Protocol version 6 (IPv6) and Internet Protocol security (IPsec), DirectAccess provides secure and flexible network infrastructure for enterprises. Below is a list of DirectAccess security and performance capabilities:
o Authentication. DirectAccess authenticates the computer, enabling the computer to connect to the intranet before the user logs on. DirectAccess can also authenticate the user and supports two-factor authentication using smart cards and one-time passwords, such as RSA SecurID.
o Encryption. DirectAccess uses IPsec to provide encryption for communications across the Internet.
o Access to IPv4-only intranet resources. UAG DirectAccess extends the value of Windows DirectAccess with NAT64/DNS64, an IPv6/IPv4 protocol transition technology that enables DirectAccess client connectivity to IPv4-only resources on the intranet.
· High availability and array configuration. UAG DirectAccess extends the value of Windows DirectAccess by adding integrated support for Network Load Balancing and array configuration, which work together to enable a highly available DirectAccess deployment.
· IT Simplification and Cost Reduction. By default, DirectAccess separates intranet from Internet traffic, which reduces unnecessary traffic on the intranet by sending only traffic destined for the intranet through the DirectAccess server. Optionally, IT can configure DirectAccess clients to send all traffic through the DirectAccess server.
The following figure shows a DirectAccess client on the Internet.
This paper contains instructions for configuring and demonstrating UAG2010 SP1 RC DirectAccess using five server computers and two client computers. The starting point for this guide is a Test Lab based on the “Steps for Configuring the Corpnet Subnet “ and “Steps for Configuring the Internet Subnet“ sections of the Test Lab Guide: Base Configuration. The resulting UAG 2010 SP1 RC DirectAccess test lab simulates an intranet, the Internet, and a home network and demonstrates DirectAccess functionality in different Internet connection scenarios.
Important:
These instructions are designed for configuring a Test Lab using the minimum number of computers. Individual computers are needed to separate the services provided on the network, and to show clearly the required functionality. This configuration is not designed to reflect best practices, nor does it reflect a required or recommended configuration for a production network. The configuration, including IP address assignment and all other configuration parameters, is designed to work only on a separate Test Lab network. For more information on planning and deploying DirectAccess with Forefront UAG for your production network, please see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide
In this test lab scenario, Forefront UAG DirectAccess is deployed with:
The test lab consists of three subnets that simulate the following:
Computers on each subnet connect using either a physical or virtual hub or switch, as shown in the following figure.
CLIENT1 initially connects to the Corpnet subnet and joins the intranet domain. After UAG1 is configured as a Forefront UAG DirectAccess server, and CLIENT1 is updated with the DirectAccess client Group Policy settings, CLIENT1 later connects to the Internet subnet and the Homenet subnet, and tests DirectAccess connectivity to intranet resources on the Corpnet subnet.
The following components are required for configuring Forefront UAG DirectAccess in the test lab:
The following steps describe how to configure the server and client computers, and configure the Forefront UAG DirectAccess server, in a test lab. Following these configurations you can verify DirectAccess connectivity from the Internet and Homenet subnets.
Note:
You must be logged on as a member of the Domain Admins group or as a member of the Administrators group on each computer to complete the tasks described in this guide. If you cannot complete a task while you are logged on with an account that is a member of the Administrators group, try performing the task while you are logged on with an account that is a member of the Domain Admins group.
· Step 1: Complete the Base Configuration. The Base Configuration is the core of all Test Lab Guide scenarios. The first step is to complete the Base Configuration.
· Step 2: Configure DC1 - DC1 is a Windows Server 2008 R2 computer that is the domain controller, Certificate server, DNS server, File Server and DHCP server for the corp.contoso.com domain.
· Step 3: Configure APP1- APP1 is a Windows Server 2008 R2 computer that acts in the role of the Network Location Server on the network.
· Step 4: Install and Configure APP3 - APP3 is a Windows Server 2003 Enterprise Edition computer that acts as an IPv4 only host and is used to demonstrate DirectAccess connectivity to IPv4 only resources using the UAG DNS64 and NAT64 features. APP3 hosts both HTTP and SMB resources that the DirectAccess client computer will be able to access from other the simulated Internet.
· Step 5: Configure UAG1 – UAG1 acts as UAG SP1 RC DirectAccess.
· Step 6: Configure CLIENT1 – CLIENT1 is a DirectAccess client that is used to test DirectAccess connectivity in several Internet network access scenarios.
· Step 7: Install and Configure NAT1 – NAT1 acts as a simulated NAT router that enables CLIENT1 access to the UAG DirectAccess server over the simulated Internet.
· Step 8: Test DirectAccess Connectivity from the Internet – CLIENT1 is connected to the simulated Internet subnet to demonstrate DirectAccess connectivity using the 6to4 IPv6 transition technology.
· Step 9: Test DirectAccess Connectivity from Behind a NAT Device – CLIENT1 is connected to the simulated private address network to demonstrate DirectAccess connectivity using the Teredo and IP-HTTPS IPv6 transition technologies.
· Step 10: View DirectAccess Connections in the UAG SP1 RC DirectAccess Monitor. UAG SP1 RC includes a new DirectAccess Web Monitor. In this step you will view information about the UAG SP1 RC DirectAccess server and DirectAccess client connections in the new DirectAccess Monitor application.
· Step 11: Test Connectivity When Returning to the Corpnet – CLIENT1 is connected again to the Corpnet subnet to demonstrate how DirectAccess components are automatically disabled to connect to local resources.
· Step 12: Snapshot the Configuration – At the completion of the lab, snapshot the configuration so that you can later return to a working UAG DirectAccess Test Lab.
Note
You will notice that there are several steps that begin with an asterisk (*). The * indicates that the step requires that you move to a computer or virtual machine that is different from the computer or virtual machine you were at when you completed the previous step.
This Test Lab Guide uses the Base Configuration network as a starting place. Please complete all the steps in Test Lab Guide: Base Configuration before proceeding with the remainder of the steps in this guide. If you have already completed all the steps in the Base Configuration Test Lab Guide and saved a disk image or a virtual machine snapshot of the Base Configuration, then you can restore the Base Configuration and proceed to the next step.
DC1 acts as a domain controller, Certificate server, DNS server, File Server and DHCP server for the corp.contoso.com domain. The following steps build on the Base Configuration to prepare DC1 to carry out these roles to support a working DirectAccess solution:
A. Create a Reverse Lookup Zone on the DNS Server on DC1. A reverse lookup zone for network ID 10.0.0.0/24 is required to create a pointer record for DC1. The pointer record allows reverse name resolution for DC1, and prevents name resolution errors during DNS related configuration steps. The reverse lookup zone is not required for a functional DirectAccess solution.
B. Enter a Pointer Record for DC1. A pointer record for DC1 will allow services to perform reverse name resolution for DC1. This is when performing DNS related operations. It is not required for a functional DirectAccess solution.
C. Enable ISATAP Name Resolution in DNS on DC1. By default, the Windows Server 2008 R2 DNS server will not answer queries for the ISATAP and WPAD host names. The DNS server is configured so that it will answer queries for ISATAP.
D. Create DNS Records for NLS and ISATAP on DC1. The DirectAccess client uses a Network Location Server (NLS) to determine if the computer is on or off the corporate network. If on the corporate network, the DirectAccess client can connect to the Network Location Server using an HTTPS connection. A DNS record is required to resolve the name of the NLS. In addition, a DNS record for ISATAP is required so that ISATAP capable hosts on the network can obtain IPv6 addressing and routing information from the ISATAP router configured on UAG1.
E. Create a Security Group for DirectAccess Clients on DC1. When DirectAccess is configured on the UAG DirectAccess server, it automatically creates Group Policy Objects and GPO settings that are applied to DirectAccess clients and servers. The DirectAccess client GPO uses security group filtering to assign the GPO settings to a designated DirectAccess security group. This group is populated with DirectAccess client computer accounts. This is a required component of a DirectAccess solution.
F. Create and Deploy a Certificate Template for the IP-HTTPS Listener Certificate and the Network Location Server Certificate. A Web site certificate is required for the Network Location Server so that computers can use HTTPS to connect to it when they are on the corporate network. The UAG DirectAccess server uses a Web site certificate on its IP-HTTPS listener so that it can accept incoming connections from DirectAccess clients that are behind network devices that limit outbound connections to only HTTP/HTTPS. A Web site certificate template is created and used for certificate requests to the Microsoft Certificate Server installed on DC1. A Web site certificate bound to the UAG DirectAccess server’s IP-HTTPS is a required component of a working DirectAccess solution.
G. Create ICMPv4 and ICMPv6 Echo Request Firewall Rules in Domain Group Policy on DC1. ICMP v4 and v6 echo requests inbound and outbound are required for Teredo support. Firewall Rules are configured using the Windows Firewall with Advanced Security GPO snap-in to distribute the configuration.
H. Create a Shared Folder on the C:\ Drive on DC1. A shared folder is created on the C:\drive of DC1 to test SMB connectivity for DirectAccess clients to a resources on the CORP domain.
A reverse lookup zone on DC1 for network ID 10.0.0.0/24 is required to create a pointer record for DC1. The pointer record will allow reverse name resolution for DC1, which will prevent name resolution errors during several DNS related configuration steps. The reverse lookup zone is not required for a functional DirectAccess solution and is used as a convenience in this lab.
A pointer record for DC1 will allow services to perform reverse name resolution for the DC1 computer. This will be useful when performing several DNS related operations. It is not required for a functional DirectAccess solution and is configured as a convenience for this lab.
By default, the Windows Server 2008 R2 DNS server will not answer queries for ISATAP and WPAD host names. These names are included in the DNS server’s Global Query Block List. The following procedures configure the DNS server so that it will answer queries for ISATAP by removing ISATAP from the Global Query Block List.
For more information on configuring the global query block list, please see http://download.microsoft.com/download/5/3/c/53cdc0bf-6609-4841-a7b9-cae98cc2e4a3/DNS_Server_Global_%20Query_Block%20List.doc
DirectAccess clients use a Network Location Server to determine if the computer is on or off the intranet. If the DirectAccess client can connect to the Network Location Server using HTTPS, it determines that it is on the corporate network and the Name Resolution Policy Table (NRPT) is disabled. If the DirectAccess client cannot connect to the Network Location Server when on the intranet, the Name Resolution Policy Table remains enabled which can cause name resolution and connectivity problems when the DirectAccess client is situated on the intranet. A DNS record is required for the DirectAccess client to resolve the name of the Network Location Server.
In addition, all IPv6 capable hosts on the corpnet need to resolve the name ISATAP to the internal IP address of the UAG DirectAccess server, so a DNS record is required for ISATAP. The UAG DirectAccess server will act as an ISATAP router for the organization and provides prefix and routing information for ISATAP hosts on the corporate network.
When you run the UAG DirectAccess wizard on the UAG1 computer, the wizard will create Group Policy Objects and deploy them in Active Directory. One GPO is created for the UAG DirectAccess server, and another is created for DirectAccess clients. Security Group filtering is used to apply the DirectAccess GPO settings to the DirectAccess Clients security Group. To obtain the settings required to be a DirectAccess client, the computer must be a member of this security group. Do not use any of the built-in security groups as your DirectAccess client security Group. Use the following procedure to create the DirectAccess security group. This group is required for a working DirectAccess solution.
A Web site certificate is required for the Network Location Server so that computers can use HTTPS to connect to it when the DirectAccess client is on the intranet. In addition, the UAG DirectAccess server uses a web site certificate on its IP-HTTPS listener so that it can accept incoming connections from DirectAccess clients that are behind network devices that limit outbound connections to only HTTP/HTTPS. The following procedures describe how to create a web site certificate template to use for requests to the Microsoft Certificate Server installed on DC1. A web site certificate bound to the UAG DirectAccess server’s IP-HTTPS listener and a web site certificate bound to the Network Location Server Web site are both required for a working DirectAccess solution.
Support for incoming and outgoing ICMPv4 and v6 is required for Teredo clients. DirectAccess clients will use Teredo as their IPv6 transition technology to connect to the UAG DirectAccess server over the IPv4 Internet when they are assigned a private (RFC 1918) IP address and are located behind a NAT device or firewall that allows outbound UDP port 3544. In addition, enabling ping facilitates connectivity testing between participants in the DirectAccess solution.
DirectAccess clients should be able to connect to SMB resources on the intranet when the DirectAccess client is connected to the simulated Internet, or connecting from behind a NAT device over the Internet. A network share is created on DC1 to test DirectAccess client connectivity to SMB resources over the infrastructure tunnel.
APP1 is a Windows Server 2008 R2 Enterprise Edition computer that acts in the role of the Network Location Server for the intranet. We have chosen to not to install the Network Location Server on the domain controller, even though that would have reduced the number of machines required for the lab network. The reason for this is that NLS on the DC can be a problematic if the DC is IPv6 based and can cause potential problems with network location detection. For this reason we have chosen to install the NLS on APP1.
You will perform the following operations to configure APP1:
A. Obtain an NLS Certificate for SSL Connections to the Network Location Server on APP1. APP1 acts as the Network Location Server. To enable this role, APP1 needs a web site certificate so that the DirectAccess clients are able to establish an SSL connection to a Web site on APP1. DirectAccess clients access this site by connecting to Network Location Server name, which is nls.corp.contoso.com in this lab.
B. Configure the HTTPS Security Binding on the NLS Web Site on APP1. The web site certificate needs to be bound to a web site on APP1 so that it can respond to SSL connection requests from the DirectAccess clients on the intranet.
The Network Location Server requires a Web site certificate to enable SSL session establishment with the DirectAccess client. The subject name on this certificate must match the name that the DirectAccess client uses to connect to the Network Location Server. On this Test Lab network, the DirectAccess client tries to connect to connect to the NLS at nls.corp.contoso.com. This name is used later in the DirectAccess configuration wizard on the UAG server.
After the web server role is installed, the web site certificate must be bound to the Network Location Server web site. This is required for the web server to establish an SSL connection with the computer configured as a DirectAccess client, and is a required component of a DirectAccess solution.
APP3 is a Windows Server 2003 SP2 Enterprise Edition computer that acts as an IPv4 only host and is used to demonstrate DirectAccess connectivity to IPv4 only resources using the UAG DNS64 and NAT64 features. APP3 hosts both HTTP and SMB resources that the DirectAccess client computer will be able to access from other the simulated Internet. The UAG NAT64/DNS64 feature set enables organizations to deploy DirectAccess without requiring them to upgrade network resources to native IPv6 or even IPv6 capable.
For more information on NAT64/DNS64 please see Deep Dive Into DirectAccess – NAT64 and DNS64 in Action
The following operations are performed to configure APP3:
A. Install the operating system on APP3 and Disable the Firewall The first step is to install Windows Server 2003 Enterprise Edition SP2 on APP3. This is not a requirement. You could use another IPv4 only operating system, such as Windows 2000 Server or even Windows XP. The goal is to provide an IPv4 resource for the DirectAccess clients to connect to from over the Internet.
B. Install Web services on APP3 Install IIS Web services on APP3 so that HTTP connectivity over the DirectAccess connection to an IPv4 only host is demonstrated.
C. Create a shared folder on APP3 Create a shared folder on APP3 to demonstrate SMB connectivity over the DirectAccess connection.
The first step is to install Windows Server 2003 Enterprise Edition SP2 on APP3. This is not a requirement. You could use another IPv4 only operating system, such as Windows 2000 Server or even Windows XP. The goal is to provide an IPv4 resource for the DirectAccess clients to connect to from over the Internet.
Note: If you install Windows Server 2003 RTM, there is no Windows Firewall and you will not need to disable the firewall.
Install IIS Web services on APP3 so that HTTP connectivity can be demonstrated over the DirectAccess connection.
Create a shared folder on APP3 to demonstrate the ability to connect to an SMB resource on a IPv4 only computer on the DirectAccess connection over the Internet.
UAG1 acts as the UAG DirectAccess server for the network. UAG1 will be connected to both the simulated Internet and the intranet and will need one network interface connected to each of these networks. The UAG DirectAccess server provides the following network services:
· ISATAP router An ISATAP router is an IPv6 router that advertises subnet prefixes to ISATAP hosts and forwards IPv6 traffic between ISATAP hosts and hosts on other IPv4 subnets. The ISATAP router provides ISATAP clients the information they need to properly configure their ISATAP adapters. For more information about ISATAP, please see http://technet.microsoft.com/en-us/magazine/2008.03.cableguy.aspx
· Teredo server A Teredo server is an IPv6/IPv4 node that is connected to both the IPv4 Internet and the IPv6 intranet, supports a Teredo tunneling interface over which packets are received. The general role of the Teredo server is to assist in the address configuration of Teredo clients and to facilitate the initial communication between Teredo clients and other Teredo clients or between Teredo clients and IPv6 hosts. The Teredo server listens on UDP port 3544 for Teredo traffic. DirectAccess clients located behind NAT devices and firewalls use Teredo to connect to the UAG DirectAccess server. For more information on Teredo, please see http://technet.microsoft.com/en-us/library/bb457011.aspx
· IPsec gateway The Full Intranet access model (which is used in this lab document) allows DirectAccess clients to connect to all resources inside the intranet. It does this by using IPsec-based tunnel policies that require authentication and encryption and IPsec sessions terminate at the IPsec Gateway. The IPsec Gateway is a function that is hosted on the UAG DirectAccess server.
· IP-HTTPS server IP-HTTPS is a new protocol for Windows 7 and Windows Server 2008 R2 that allows DirectAccess clients behind a Web proxy server or firewall to establish connectivity by tunneling IPv6 packets inside an IPv4-based HTTPS session. HTTPS is used instead of HTTP so that Web proxy servers will not attempt to examine the data stream and terminate the connection. The UAG DirectAccess server uses an IP-HTTPS listener to accept incoming IP-HTTPS connections. Note that IP-HTTPS does not work behind authenticating web proxies (when authentication is required) or from behind web proxies that perform outbound SSL inspection (such as the TMG 2010 firewall when outbound SSL inspection is enabled).
· NAT64/DNS64 IPv6/IPv4 protocol translator The UAG DirectAccess server includes NAT64 and DNS64, which enables DirectAccess clients on the Internet to connect to IPv4 resources on the intranet. DirectAccess clients always use IPv6 to communicate with intranet servers. When a DirectAccess client needs to connect to IPv4 resources on the intranet, it issues a DNS query for the FQDN of the resource. DNS64 intercepts the request, sends the query to the intranet DNS server, and obtains the IPv4 address of the resource. DNS64 then dynamically generates an IPv6 address for the client to connect to; in addition, DNS64 informs NAT64 of the IPv4/IPv6 mapping. The client issues a request for the dynamically generated IPv6 address, which is intercepted by NAT64, and then NAT64 forwards the request to the IPv4 address of the intranet resource. NAT64 also returns the response based on entries in its state table. For more information about DNS64 and NAT64, please see http://blogs.technet.com/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx
· 6to4 relay router A 6to4 relay router can accept traffic from DirectAccess clients using the 6to4 IPv6 transition technology and forward the traffic over an IPv4 intranet. The UAG DirectAccess server acts as the 6to4 relay router and provides addressing information to the DirectAccess clients. DirectAccess clients use this information to configure their 6to4 tunnel adapters to forward IPv6 messages over the IPv4 Internet to the UAG DirectAccess servers. For more information on 6to4 please see http://technet.microsoft.com/en-us/library/cc756770(WS.10).aspx
The following procedures are performed on the UAG1 computer or virtual machine:
A. Rename UAG1 Change the computer name assigned during setup of the Base Configuration to UAG1.
B. Obtain a Certificate for the IP-HTTPS Listener on UAG1 The UAG DirectAccess server uses an IP-HTTPS listener to accept incoming IP-HTTPS connections from DirectAccess clients on the Internet. The IP-HTTPS Listener requires a web site certificate to support the SSL connection between itself and the DirectAccess client.
C. Install Forefront UAG on UAG1 Install the Forefront Unified Access Gateway software on UAG1.
D. Run the UAG Getting Started Wizard on UAG1 The UAG Getting Started Wizard walks you through the process of initial configuration of the UAG server.
E. Run the UAG DirectAccess Configuration Wizard on UAG1 DirectAccess is not enabled by default. You must run the UAG DirectAccess wizard to enable DirectAccess features and capabilities on UAG1.
F. Confirm Group Policy Settings on UAG1 The UAG DirectAccess wizard configures GPOs and settings that are automatically deployed to the Active Directory. One GPO is assigned to the UAG DirectAccess server, and one is deployed to machines that belong to the DirectAccess Clients security group. The step confirms that the Group Policy settings were deployed to the UAG DirectAccess server.
G. Confirm IPv6 Settings on UAG1 For the DirectAccess solution to function, the IPv6 settings on must be correct. This step confirms these setting on UAG1.
H. Update IPv6 Settings on DC1 DC1 is capable of being an ISATAP host. However, this functionality might not be immediately available. This step expedites DC1 setting itself up as an ISATAP host by updating its IPv6 configuration.
I. Update IPv6 Settings on APP1 APP1 is capable of being an ISATAP host. However, this functionality might not be immediately available. This step expedites APP1 setting itself up as an ISATAP host by updating its IPv6 configuration.
J. Confirm IPv6 Address Registrations in DNS IPv6 capable hosts can communicate with one another over IPv6 using their ISATAP adapters. However, they must be able to resolve the destination host to an IPv6 address to use this capability. This step confirms that the IPv6 ISATAP addressees are registered in DNS.
K. Confirm IPv6 Connectivity between DC1/APP1/UAG1 After activity the IPv6 settings on DC1, APP1 and UAG1, test IPv6 connectivity by using the ping utility.
Change the computer name of EDGE1 to UAG1.
The UAG DirectAccess server uses an IP-HTTPS listener to accept incoming IP-HTTPS connections from DirectAccess clients on the Internet. The IP-HTTPS Listener requires a web site certificate to support the SSL connection between itself and the DirectAccess client. The common name on this certificate must be the name the external DirectAccess client uses to connect to the IP-HTTPS Listener, and must be resolvable using an Internet based DNS server to the first of the two consecutive IP addresses bound to the external interface of the UAG DirectAccess server. Perform the following steps to obtain the IP-HTTPS certificate. In addition, you will request a new computer certificate for UAG1 that supports the machine’s new computer name.
In order to connect to the IP-HTTPS listener on UAG1, the DirectAccess client needs to be able to resolve the subject name listed on the IP-HTTPS certificate. In this step you will configure INET1 with a Host (A) DNS record with the name uag1.contoso.com that resolves to 131.107.0.1.
Install the Forefront Unified Access Gateway software on UAG1.
The UAG Getting Started Wizard walks you through the process of initial configuration of the UAG server. This will set up the basic information required to configure the networking settings on the server, define the server topology (standalone or array) and whether or not to join Microsoft update for updating the server.
DirectAccess is not enabled by default. To enable DirectAccess features and capabilities on UAG1, you need to run the DirectAccess Configuration wizard. After running the DirectAccess Configuration Wizard, two new Group Policy objects are created – one is linked to the computer account for the UAG DirectAccess server, and the second is linked to the DirectAccess clients security group (DA_Clients) you configured earlier. In addition, the IPv6 components, including support for IPv6 transition technologies and IPv6/IPv4 protocol transition technologies are enabled on the UAG DirectAccess server.
The UAG DirectAccess wizard configures GPOs and settings that are automatically deployed to the Active Directory. One GPO is assigned to the UAG DirectAccess server, and one is deployed to machines that belong to the DirectAccess Clients security group. The following steps confirm that the Group Policy settings were deployed to the UAG DirectAccess server.
For the DirectAccess solution to function, the IPv6 settings on must be correct. The following steps confirm these setting on UAG1.
DC1 is capable of being an ISATAP host. However, this functionality might not be immediately available. You can expedite DC1 setting itself up as an ISATAP host by updating its IPv6 configuration.
APP1 is capable of being an ISATAP host. However, this functionality might not be immediately available. You can expedite DC1 setting itself up as an ISATAP host by updating its IPv6 configuration.
IPv6 capable hosts can communicate with one another over an IPv4 network with IPv6 using their ISATAP adapters. However, they must be able to resolve the destination host to an IPv6 address to use this capability. The following steps confirm that the IPv6 ISATAP addressees are registered in DNS.
Note that the ISATAP addresses listed in the DNS resource records do not use the dotted decimal format for the last 32 bits of the IPv6 address that you see when using ipconfig to view IP addressing information on the hosts. However, these addresses represent the same information; the only difference is that the last 32 bits are represented in HEX instead of dotted decimal format.
After activating the IPv6 settings on DC1, APP1 and UAG1, test IPv6 connectivity by using the ping utility
CLIENT1 is a computer or virtual machine running Windows 7 Ultimate Edition that is used demonstrate how DirectAccess works in a number of scenarios. CLIENT1 is first connected to the corpnet subnet to receive the DirectAccess Group Policy settings. CLIENT1 is later moved to the simulated Internet to test DirectAccess connectivity over 6to4 and CLIENT1 is moved behind a NAT device to test both Teredo and IP-HTTPS DirectAccess connectivity.
NOTE: CLIENT1 is a Windows 7 computer and after installation the default power plan is applied. CLIENT1 may go to sleep before you reach the end of the lab configuration. To prevent this from happening, select the High Performance power plan in the Control Panel.
The following operations configure CLIENT1:
A. Add CLIENT1 to the DA_Clients Active Directory Security Group The DirectAccess client settings are assigned only to members of the security group designated for DirectAccess clients. Place CLIENT1 in the DA_Clients security group so that the Group Policy settings are assigned to CLIENT1.
B. Test IPv6 Configuration, Confirm Group Policy Settings and Machine Certificate on CLIENT1 Before moving CLIENT1 out of the corpnet and onto the simulated Internet and behind a NAT device, check the IPv6 configuration on CLIENT1, confirm that DirectAccess client Group Policy Settings are enabled on CLIENT1, and that CLIENT1 has the computer certificate required to establish the IPsec connections to the UAG DirectAccess server.
C. Test Connectivity to a Network Share and Network Location Server The final check on CLIENT1 before moving it outside the corpnet is to confirm connectivity to a network share on the corpnet and to the Network Location Server. Connectivity to the Network Location Server is required so that the DirectAccess client can determine if it is on-network or off-network.
The DirectAccess client settings are assigned only to members of the security group designated for DirectAccess clients. You will place CLIENT1 in the DA_Clients security group so that the Group Policy settings are assigned to CLIENT1.
Before moving CLIENT1 out of the corpnet subnet and onto the simulated Internet and behind a NAT device on the Internet, check the IPv6 configuration on CLIENT1, confirm that DirectAccess client Group Policy Settings are enabled on CLIENT1, and that CLIENT1 has the computer certificate required to establish the IPsec connections to the UAG DirectAccess server.
The final check on CLIENT1 before moving it outside the corpnet subnet is to confirm connectivity to a network share on the corpnet subnet and to the Network Location Server. Connectivity to the Network Location Server is required so that the DirectAccess client can determine if it is on or off the corporate network.
NAT1 is a Windows 7 computer configured as a NAT device that separates a private network from the Internet. The built-in Internet Connection Service (ICS) is used to provide the NAT server functionality. ICS includes DHCP server-like functionality and automatically assigns IP addressing information to clients located behind the NAT1 ICS NAT device. NAT1 has two network interfaces – one connected to the simulated Internet and one connected to a Homenet subnet.
NOTE: NAT1 is a Windows 7 computer and after installation the default power plan is applied. NAT1 may go to sleep before you reach the end of the lab configuration. You can prevent this from happening by selecting the High Performance power plan in the Control Panel.
Perform the following operations to configure NAT1 as a NAT device:
A. Install the operating system on NAT1 The first step is to install the Windows 7 operating system.
B. Rename the interfaces on NAT1 Rename the network interfaces in the Network Connections window to make them easier to identify. Note that this is not required, but makes applying the correct settings on the appropriate interface easier.
C. Disable 6to4 functionality on NAT1 Disable 6to4 functionality on NAT 1. The reason for this is that if you don’t disable 6to4 on NAT1, it will act as a 6to4 router and issue a 6to4 address to CLIENT1 when it is connect to the Homenet subnet. This will prevent CLIENT1 from acting as a Teredo or IP-HTTPS DirectAccess client.
D. Configure ICS on the External Interface of NAT1 Internet Connection Services enable NAT1 to act as a NAT device and DHCP server for clients located behind NAT1. This enables CLIENT1 to automatically obtain IP addressing information and connect to the simulated Internet when connected to the Homenet subnet behind NAT1.
The first step is to install the Windows 7 operating system.
In this step you rename the network interfaces in the Network Connections window to make them easier to identify. Note that this is not required, but makes applying the correct settings on the appropriate interface easier.
In the lab environment we use a Windows 7 computer to simulate a NAT device located in a remote location. One issue with Windows 7 when configured as an Internet Connection Service server is that it can act as a 6to4 router. When this is the case, it might assign the CLIENT1 computer behind the NAT1 ICS computer a 6to4 address and prevent it from acting as a Teredo and IP-HTTPS client. In order to demonstrate both Teredo and IP-HTTPS functionality, 6to4 functionality on the NAT1 is disabled.
Internet Connection Services enable NAT1 to act as a NAT device and DHCP server for clients located behind NAT1. This enables CLIENT1 to automatically obtain IP addressing information and connect to the simulated Internet when connected to the Homenet subnet behind NAT1.
CLIENT1 is now ready for DirectAccess testing. In the first set of tests, you connect CLIENT1 to the simulated Internet. When connected to the simulated Internet, CLIENT1 is assigned a public IPv4 address. When a DirectAccess client is assigned a public IPv4 address, it will try to establish a connection to the DirectAccess server using an IPv6 6to4 connection over its 6to4 tunnel adapter. After connecting to the simulated Internet and establishing the DirectAccess connection, you perform a number of tests to confirm IPv6 connectivity and connectivity to corpnet assets from over the simulated Internet.
When a DirectAccess client is connected to the Internet from behind a NAT device or a Web proxy server, the DirectAccess client uses either Teredo or IP-HTTPS to connect to the DirectAccess server. If the NAT device enables outbound UDP port 3544 to the DirectAccess server’s public IP address, then Teredo is used. If Teredo access is not available, the DirectAccess client falls back to IP-HTTPS over outbound TCP port 443, which enables access through firewalls or Web proxy servers over the traditional SSL port. Teredo is the preferred access method, because of its superior performance over IP-HTTPS. In addition, if the web proxy requires authentication, the IP-HTTPS connection will fail. IP-HTTPS connections also fail if the web proxy performs outbound SSL inspection, due to the fact that the HTTPS session is terminated at the web proxy instead of the UAG DirectAccess server. In this section you will perform the same tests performed when connecting using a 6to4 connection in the previous section.
The following procedures are performed on CLIENT1:
A. Test Teredo Connectivity. The first set of tests are performed when the DirectAccess client is configured to use Teredo. This is the automatic setting when the NAT device allows outbound access to UDP port 3544
B. Test IP-HTTPS Connectivity. The second set of tests are performed when the DirectAccess client is configured to use IP-HTTPS. In order to demonstrate IP-HTTPS connectivity, Teredo is disabled on CLIENT1.
The DirectAccess client can use either Teredo or IP-HTTPS when connecting to the DirectAccess server from behind a NAT device. You will first examine the settings and test connectivity using Teredo.
When the DirectAccess client is unable to establish a Teredo connection with the DirectAccess server (typically when a firewall or router has blocked outbound UDP port 3544), the DirectAccess client configures itself to use IP-HTTPS to tunnel IPv6 messages over the IPv4 Internet. In the following exercises you confirm that the host is configured as an IP-HTTPS host and check connectivity.
1. Open an elevated command prompt. In the command prompt window, enter netsh interface teredo set state disabled and press ENTER. This disables Teredo on CLIENT1 and enables CLIENT1 to configure itself to use IP-HTTPS.
2. Open an elevated command prompt. In the command prompt window, enter ipconfig /all and press ENTER. An Ok response appears when the command completes.
3. Examine the output of the ipconfig command. This computer is now connected to the Internet from behind a NAT device and is assigned a private IPv4 address. Teredo is disabled and the DirectAccess client falls back to IP-HTTPS. When you look at the output of the ipconfig command, you see a section for Tunnel adapter iphttpsinterface with an IP address that starts with 2002:836b:2:8100 consistent with this being an IP-HTTPS address. You will not see a default gateway listed for the IP-HTTPS tunnel adapter.
4. In the command prompt window, enter ipconfig /flushdns and press ENTER. This will flush name resolution entries that may still exist in the client DNS cache from when CLIENT1 was connected to the corpnet.
5. In the command prompt window, enter ping dc1 and press ENTER. You should see replies from the ISATAP address assigned to DC1, which in this case is 2002:836b:2:8000:0:5efe:10.0.0.1
6. In the command prompt window, enter ping app1 and press ENTER. You should see replies from the ISATAP address assigned to APP1, which in this case is 2002:836b:2:8000:0:5efe:10.0.0.3
7. In the command prompt window, enter ping uag1 and press ENTER. You should see replies from the ISATAP address assigned to UAG1, which in this case is 2002:836b:2:8000:0:5efe:10.0.0.2
8. In the command prompt window, enter ping app3 and press ENTER. You should see replies from the NAT64 address assigned by UAG1 to APP3, which in this case is 2002:836b:2:8001::a00:4
9. In the command prompt window, enter netsh namespace show effectivepolicy and press ENTER. The output shows the current settings for the Name Resolution Policy Table (NRPT). These settings indicate that all connections to .corp.contoso.com should be resolved by the DirectAccess DNS Server, which is the UAG DirectAccess server, with the IPv6 address of 2002:836b:3::836b:3. Also, note the NRPT entry indicating that there is an exemption for the name nls.corp.contoso.com; names on the exemption list are not answered by the DirectAccess DNS server. You can ping the DirectAccess DNS server IP address to confirm connectivity to the DirectAccess server; for example, you can ping 2002:836b:3::836b:3 in this example.
10. In the Internet Explorer address bar, enter http://app1.corp.contoso.com and press ENTER. You will see the default IIS site on APP1.
11. In the Internet Explorer address bar, enter http://app3.corp.contoso.com and press ENTER. You will see the default web site on APP3.
12. Click Start and in the Search box, enter \\App3\Files and press ENTER. Double click on the New Text Document file. This demonstrates that you were able to connect to an IPv4 only server using SMB to obtain a resource on an IPv4 only host.
13. Click Start and in the Search box, enter Firewall and press ENTER.
14. In the Windows Firewall with Advanced Security console, notice that only the Private profile is active. The Windows Firewall must be enabled for DirectAccess to work correctly. If for some reason the Windows Firewall were disabled, DirectAccess connectivity would fail.
15. Expand the Monitoring node in the left pane of the console and click the Connection Security Rules node. You should see the active connection security rules: UAG DirectAccess Client – Client Access Enabling Tunnel – All, UAG DirectAccess Client – Clients Corp Tunnel and UAG DirectAccess Client – Exempt NLA. Scroll the middle pane to the right to expose the 1st Authentication Methods and 2nd Authentication Methods columns. Notice that the first rule uses NTLMv2 to establish the infrastructure tunnel and the second rule uses Kerberos V5 to establish the intranet tunnel.
16. In the left pane of the console, expand the Security Associations node and click the Main Mode node. Notice the infrastructure tunnel security associations using NTLMv2 and the intranet tunnel security association using Kerberos V5. When you right click the Kerberos security association, you will see authentication for CORP\User1. This indicates that the client was able to authenticate with the CORP domain using Kerberos to establish the second (intranet) tunnel.
17. Close the System Control Panel window and the Windows Firewall with Advanced Security console. Close all other open windows before moving to the next step.
A new feature included in UAG 2010 Service Pack 1 DirectAccess is the new DirectAccess Monitor feature that is included in the UAG Web Monitor applications. You can use the DirectAccess Monitor to obtain information about current and historical connections to the UAG DirectAccess server.
Perform the following steps to view the DirectAccess client connections in the UAG 2010 Service Pack 1 DirectAccess Monitor:
Many of your users will move between remote locations and the corpnet, so it’s important that when they return to the corpnet that they are able to access resources without having to make any configuration changes. UAG DirectAccess makes this possible because when the DirectAccess client returns to the corpnet, it is able to make a connection to the Network Location Server. Once the HTTPS connection is successfully established to the Network Location Server, the DirectAccess client disables it DirectAccess client configuration and uses a direct connection to the corpnet.
This completes the DirectAccess test lab. To save this configuration so that you can quickly return to a working DirectAccess configuration from which you can test other DirectAccess modular TLGs, TLG extensions, or for your own experimentation and learning, do the following:
For procedures to configure the Base Configuration test lab on which this document is based, see the Test Lab Guide: Base Configuration.
For the design and configuration of your pilot or production deployment of DirectAccess, see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide.
For information about troubleshooting DirectAccess, see the DirectAccess Troubleshooting Guide.
For information about troubleshooting DirectAccess in a Test Lab, see the Test Lab Guide: Troubleshoot UAG DirectAccess.
For a comprehensive list of UAG DirectAccess Test Lab Guides, see the TechNet wiki Test Lab Guide clearinghouse at Test Lab Guides.
For more information about DirectAccess, see the DirectAccess Getting Started Web page and the DirectAccess TechNet Web page.
ISATAP is an optional configuration option you can take advantage of when working with UAG DirectAccess. What ISATAP allows you to do is automatically assign IPv6 addresses to computers on the network that already have IPv4 addresses (which is going to be all of them). The advantage conferred when using ISATAP is that you can have an entirely IPv4 infrastructure (that is to say, your routers don’t support IPv6 and you haven’t done anything to enable IPv6 on your network) is that you can initiate connections from computers on the intranet to DirectAccess clients that are located somewhere on the Internet.
ISATAP clients can do this because they tunnel IPv6 messages inside an IPv4 tunnel. When traveling over the intranet, the IPv6 messages move over the network inside the IPv4 header and when they reach the destination, the IPv4 header is removed and the IPv6 header is exposed and the packet is then received by the ISATAP tunnel adapter. When the ISATAP host connects to a DirectAccess client, it connects to an IPv6 only host (the DirectAccess client), since DirectAccess clients only communicate over IPv6 when connecting to resources on the intranet.
This works by sending the packets from the ISATAP enabled host on the intranet to the ISATAP router on the UAG DirectAccess server. When the ISATAP enabled host on the intranet tries to connect to a DirectAccess client, it sends the IPv4 encapsulated IPv6 packet to the ISATAP router on the UAG DirectAccess server. When the packet arrives at the UAG DirectAccess server, the ISATAP router removes the IPv4 header and forwards the IPv6 packet to the DirectAccess client. And when the DirectAccess client returns its response, the IPv6 packet is sent to the UAG DirectAccess server, and then the ISATAP router on the UAG DirectAccess server encapsulates that IPv6 packet with an IPv4 header and forwards it to the ISATAP host on the intranet.
In general, ISATAP is a good thing, but it can create some potential issues. First, you need to be aware that in order to configure their ISATAP adapters, the ISATAP enabled hosts need to be able to resolve the name ISATAP. Usually, you put a host (A) record for ISATAP in your DNS and all machines can then resolve this name to configure their ISATAP adapters. Since all Vista and above and Windows Server 2008 and above hosts are automatically configured as ISATAP enabled hosts, all of these machines will automatically configure their ISATAP adapters after they resolve the ISATAP name.
The problem is that not everyone wants to enable IPv6 on their networks. For a number of reasons, some firms want to disable IPv6 on the machines on their networks. The problem is that if you disable IPv6, but leave the ISATAP adapter enabled, the NAT64/DNS64 feature won’t work when the DirectAccess clients try to connect to these machines. The reason for this is that when the ISATAP adapter initializes, it registers its IPv6 ISATAP address in DNS automatically. When the DirectAccess client resolves the name of the host that has IPv6 disabled but ISATAP adapter enabled, it will get a quad A (AAAA) record and try to connect to that host using its IPv6 address. But since IPv6 is disabled on that host, the connection attempt will fail.
In practice, very few hosts on the intranet need to be able to initiate connections to the DirectAccess clients. Only management servers, and maybe computers assigned to corporate IT need this kind of access, and perhaps computers run by the Help Desk. If you’ve decided to disable IPv6 on your network, you might be better served by not putting the ISATAP address in DNS. Instead, put the ISATAP entry into the HOSTS file of the machines that need to initiate connections to the DirectAccess clients.
In this case, there is no ISATAP entry in DNS, so hosts without an ISATAP entry in their HOSTS file will not enable their ISATAP adapters. The machines that have an ISATAP entry in their HOSTS files will be able to resolve the name ISATAP and they will enable their ISATAP adapters and they will then be able to initiate connections to DirectAccess clients. With this configuration, the DirectAccess clients can use the UAG DirectAccess server’s NAT64/DNS64 to connect to the hosts that don’t have ISATAP enabled, and they will be able to use IPv6 to connect to the ISATAP enabled hosts that have the ISATAP entry in their HOSTS files.
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
This question comes up frequently when introducing admins to UAG DirectAccess. It makes sense, since public IPv4 addresses are getting more difficult to come by and in fact it’s predicted that there will be an exhaustion of the entire IPv4 address space by next month. So, why do you need two public IP addresses on the external interface of the UAG DirectAccess server?
There’s a short answer and a long answer. Let’s begin with the short answer (hat tip to Ben Ben Ari, Senior Support Engineer at Microsoft):
“When the Teredo adapter is active on the DirectAccess client, it will check the Teredo server’s public IPv4 addresses to determine what type of NAT device the client is located behind. The assessment is performed to determine which on of the follow four types of NAT are in use: One-to-one NAT, also known as Full-cone NAT Address restricted cone NAT Port-restricted cone NAT Symmetric NAT The detection process starts with the Teredo client sending a Router Solicitation (RS) message to the Teredo server’s IP first address (the first of the two consecutive IPv4 addresses on the external interface on the UAG server used by DirectAccess). UAG then replies from the 2nd IP address. If the Teredo client receives the reply, it deduces that the NAT type is “Cone” (option 1 or 2 above). If the client does not receive this reply, then it issues a second RS message, but this time, UAG will reply from its first IP, instead of the second. If the client gets this reply, it now knows that the NAT type is either Port-restricted cone (type 3) or Symmetric (type 4) NAT. Next, the client sends a request to the UAG server’s second IP address (which also acts as a Teredo server), and waits for another answer. When the answer comes, if it is from the same IP as the first, this signals to the client that the NAT type is Port-restricted cone (type 3). If they are different, this means that NAT is mapping the same internal address and port number to different external addresses and port numbers, which means that this is a Symmetric NAT (type 4).”
“When the Teredo adapter is active on the DirectAccess client, it will check the Teredo server’s public IPv4 addresses to determine what type of NAT device the client is located behind. The assessment is performed to determine which on of the follow four types of NAT are in use:
The detection process starts with the Teredo client sending a Router Solicitation (RS) message to the Teredo server’s IP first address (the first of the two consecutive IPv4 addresses on the external interface on the UAG server used by DirectAccess). UAG then replies from the 2nd IP address. If the Teredo client receives the reply, it deduces that the NAT type is “Cone” (option 1 or 2 above). If the client does not receive this reply, then it issues a second RS message, but this time, UAG will reply from its first IP, instead of the second. If the client gets this reply, it now knows that the NAT type is either Port-restricted cone (type 3) or Symmetric (type 4) NAT.
Next, the client sends a request to the UAG server’s second IP address (which also acts as a Teredo server), and waits for another answer. When the answer comes, if it is from the same IP as the first, this signals to the client that the NAT type is Port-restricted cone (type 3). If they are different, this means that NAT is mapping the same internal address and port number to different external addresses and port numbers, which means that this is a Symmetric NAT (type 4).”
If you want even more detail, this may help check out the Teredo Overview:
http://technet.microsoft.com/en-us/network/cc917486.aspx
Tom Shinder tomsh@microsoft.com Principal Knowledge Engineer, Microsoft DAIP iX/Forefront iX UAG Direct Access/Anywhere Access Group (AAG) The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
A question that I see frequently regarding UAG DirectAccess is “what topology options are available to me? Where’s the best place to put the UAG DA server?”. As with all questions of this type, the answer depends on what your requirements are and what you existing infrastructure looks like.
While there’s probably an unlimited number of options available for placement of the UAG DA server, I think there are three general scenarios on which you can build out a deployment plan. These three scenarios are:
Figure1 show a high level overview of what the UAG between a front-end and back-end firewall configuration would look like. Of course, the nature of the DMZ between the firewalls might be more complex than this. In the figure, I describe only a single segment in front of the UAG DA server and a single segment behind the UAG DA server. Typical enterprise networks will have multiple segments on their DMZs.
In this configuration the front-end firewall must be configured to:
The back-end firewall must be configured to:
We assume that this is going to be the most common deployment model for the UAG DA server, and that’s why you’ll see it as the only one described on TechNet. Something that should be made clear at this point is that just because this is the only deployment model described on TechNet doesn’t mean that it’s the only supported configuration. The following two configurations to be discussed are also viable options and are supported.
Figure 1: UAG DA server placed between two firewalls
Figure 2 describes a deployment model where the UAG DA server is placed in parallel with the front-end firewall. This is a secure option because the UAG DA server and the network behind it are protected by the TMG firewall that is also installed on the UAG DA server. It’s important to note that while the TMG firewall is installed on the UAG DA server, it is not to be used outside of its ability to protect the UAG DA server and the network behind the UAG DA server. No outbound traffic is supported through the UAG DA server, and no DMZ NICs are supported on the UAG DA server (by DMZ, I refer to the fact that TMG supports an unlimited number of network interfaces; the UAG DA server will always have only two interfaces).
In this configuration, the UAG DA server does not require any packet filters on a front-end firewall, since there is no front-end firewall in front of the UAG DA Server. The UAG DA server sits in parallel with the current firewall. In addition, there is no back-end firewall, so no filters need to be configured on a back-end firewall.
One could argue that just because you have the UAG DA server sitting in parallel with the current front-end firewall, then way not put a back-end firewall “just in case”. There’s no reason why you can’t do that. However, noting the packet filters used on the back-end firewall in the first scenario, there’s really no point in placing another point of failure between the UAG DA server and the resources behind it – since the back-end firewall is essentially allowing all traffic between its internal interface and the corpnet behind it.
Figure 2: UAG server placed in parallel with front-end firewall
Figure 3 represents the third general deployment option. In this scenario, the UAG DA server sits behind a front-end firewall with no back-end firewall behind it. In this configuration, the packet filters for the front-end firewall as the same as those applied in the first scenario. And the back-end packet filters don’t apply, since there is no back-end firewall. This might be considered the preferred solution by many organizations, since the packet filters required on the back-end firewall (at least at the beginning of the deployment) essentially allow all traffic between the internal interface of the UAG DA server and the corpnet. I suspect that this will be a persistent configuration in most organizations, so why not simplify the configuration and delete a point of failure by eliminating the back-end firewall entirely?
Figure 3: UAG server placed behind front-end firewall with no back-end firewall
It’s important to note that all of these are supported deployment scenarios and none is necessarily superior to the other. However, there may be performance advantages to putting the UAG DA server behind a front-end firewall, since this will reduce that packet processing overhead on the UAG DA server and end up improving the overall performance of the UAG DA solution. A similar argument can be made for the back-end firewall, but that can only be said if you have worked up your traffic profiles and know what traffic is going to be required between the UAG DA server and all the servers and other networked devices the UAG DA clients are going to connect to on the corpnet.
Finally, be aware that these are simplified diagrams that only include the salient components of the deployment model. There are going to be other network devices that you need to take into account, like bandwidth shapers, Network IDS devices, layer 3 switches that might do more than layer 3, and other devices. While you’ll need to take those into account in your overall design, they don’t impact the basic designs discussed in this article.
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.
If you choose to deploy ISATAP to support your DirectAccess deployment, one of the things you need to do is remove the name ISATAP from the DNS block list if you’re using a Windows DNS server running Windows Server 2003 SP2 or above. By default, these DNS servers will not resolve queries for the names WPAD and ISATAP. Even if there is a resource record for WPAD or ISATAP in DNS, the DNS server will not return a response for those names if they are on the DNS query block list.
The reason for this is that it’s possible for a rogue device to dynamically register these names in DNS. If that happens, there is the possibility that client systems will auto-configure themselves to use the rogue device as their web proxy, or configure their ISATAP adapters to use the rogue device as their ISATAP gateway. Both of these scenarios are enabled by the fact that Internet Explorer uses auto-discovery by default to configure the web proxy, and the ISATAP adapter is enabled by default if the name ISATAP can be resolved and the client can contact an ISATAP router.
If you check this link you will find a document that contains the following statement:
“By default, the DNS Server service in Windows Server 2008 and later blocks name resolution for the name ISATAP through the DNS Global Query Block List. To use ISATAP on your intranet, you must remove the ISATAP name from the list for all DNS servers running Windows Server 2008 and later. For more information, see Remove ISATAP from the DNS Global Query Block List in the DirectAccess Deployment Guide..”
The question then is “if ISATAP responses from the DNS server is considered unsecure, then isn’t deploying ISATAP on the network considered unsecure?”
The answer is “no”. The reason for this is that when you deploy ISATAP on your network and enable the DNS server to answer queries for ISATAP, you will enter a static Host (A) record for ISATAP. When you configure the static DNS resource record, it will not be overwritten by dynamic registrations by potential rogue hosts. Therefore, the security implications of removing ISATAP from the DNS block list are mitigated since no one can dynamically overwrite the static ISATAP record you created.
However, if you decide that you don’t want to use ISATAP, or at least don’t want to use DNS to inform ISATAP hosts of the ISATAP router, then you should put ISATAP back into the DNS block list and remove the ISATAP resource record from your DNS server.
You can find out more about the DNS query block list HERE.