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.
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
(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)
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.
HTH,
Tom
Tom Shinder Microsoft ISDUA Anywhere Access Team/UAG DirectAccess
UAG 2010 (UAG) supports two types of network level SSL VPN:
Network Connector is aimed at legacy clients and SSTP for Windows 7 clients.
Network Connector supports both split and non-split tunneling configurations while SSTP, when accessed through the UAG portal, supports only non-split tunneled connections.
This can be a problematic for firms that want to enable a split tunneled configuration to reduce the bandwidth drain that VPN clients can extract when split tunneling isn’t supported. And with current network security opinions moving away from disabling split tunneling as a security solution (see my articles on split tunneling for more information at http://blogs.technet.com/b/tomshinder/archive/2010/03/02/why-split-tunneling-is-not-a-security-issue-with-directaccess.aspx), it makes sense that admins would want to enable split tunneling for their UAG SSTP clients.
Faisal Hussain provides a solution on his blog and you can find it at:
http://blogs.technet.com/b/fsl/archive/2011/01/26/uag-sstp-split-tunnel.aspx
WARNING: This is an unsupported solution and has not been tested or validated by CSS.
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
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.
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
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
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
While I spend most (all) of my time working with the UAG DirectAccess solution, UAG DirectAccess is functionality essentially represents a superset of Windows DirectAccess functionality. Therefore, I thought it might be interesting to share with you all some questions I received from a fellow who is interested in deploying Windows DirectAccess. Maybe the questions and answers contained here will help you with your own planning for deploying DirectAccess in your SMB environment.
==============================
Question/issue 1: I’m in the process of putting together a DirectAccess solution for a small client of mine that needs the features of DirectAccess but can’t lay down the cash for multiple physical servers or UAG. They don’t need the additional complexities of access to IPv4 only resources as this is basically going to be a new network starting from scratch.
I know this may not be ideal from a performance perspective because of the many shared roles and limited scalability, but this is not going to be a network with many users; rather it will be a network of a dozen or so kiosks that will always be remotely connected. I’m starting to experiment some but haven’t found many resources for the absolute simplest implementation of DirectAccess.
I will certainly be going through the test lab documentation and other papers from Microsoft regarding the set up, but I thought I’d ask just in case anyone knows of some resources I haven't found yet (or just has some good tidbits of info themselves).
My concept is this:
What I’d ultimately really love is a "test lab" document similar to the one already out there from Microsoft but designed to interface with the real internet instead of a fake internet. The document makes several references to "problems" trying to adapt that test environment into a real world scenario, but it doesn’t give a whole lot of information about what "problems" they are referring to.
ANSWER: First off, these are great questions and thanks for sending them my way. Examples of planning for real-world deployments help everyone on their trek to DirectAccess goodness.
Since your customer can’t afford UAG at this time (maybe he will in the future as the company grows), the place to start is with the Windows DirectAccess solution. You are right that you will not have support for IPv4-only resources on the intranet, and your high availability options are somewhat limited. But you recognize these conditions and we can work within these parameters.
We generally recommend that you don’t put the Network Location Server on the domain controller, especially in pure IPv6 scenarios for some reasons regarding interface timings. While I don’t have the details in front of me, I have received information from a DirectAccess PM who strongly recommends that the Network Location Server not be placed on a DC – so if you could create a VM for the NLS, that would be a good way to go.
You can put the DirectAccess server in a virtual machine. However, there are performance implications and therefore we generally recommend that you put the DirectAccess servers on physical machines. With that said, you mention that this is going to be a relatively lightly used configuration, and therefore you might be able to get acceptable performance. You’ll need to monitoring your deployment and see if you are running into processor bottlenecks.
It is good that you’re planning on dedicated NICs for the virtual and physical interfaces. DirectAccess will perform better this way.
It’s also good you recognize that the firewall in front of the DirectAccess server will perform only firewall functionality and not NAT, because DirectAccess is not supported from behind a NAT device (although it can be done with the help of a few routing tricks, but that configuration is not supported by the product group).
Windows 7 Enterprise or Ultimate is required – so you’re good with the OS on your clients. Keep in mind that these must be domain members.
Regarding the problems that we suggest with the Test Lab Guides here are a few things that I can think of:
With those things in mind, you can create a “live” pilot deployment. I’d recommend that you obtain a commercial certificate for the IP-HTTPS listener, and not use the CRL checking disablement steps I deployed in the UAG DirectAccess Test Lab Guides.
-----------------------------------------
Question 2: What are the advantages/disadvantages of using a native IPv6 infrastructure (with a tunnel broker like Hurricane Electric) vs just using ISATAP? Are there any compelling reasons to go ahead and go native (especially if the network is going to be new with no legacy devices)?
ANSWER:
ISATAP is useful if your network infrastructure isn’t IPv6 aware, since you can tunnel your IPv6 traffic over IPv4 and use your current IPv4 routing infrastructure. However, if your routing, DNS and DHCP infrastructure is all IPv6 capable, there’s no need to deploy ISATAP and I’d recommend that you go native IPv6. You will need to configure your routers (and maybe the hosts) on your network so that they know the route back to the DirectAccess clients.
In most cases that will require that you make the DirectAccess server the IPv6 route of last resort since this is the only way to get the messages back to the 6to4 DirectAccess clients – or better, you can disable 6to4 on your DirectAccess clients and they will use Teredo instead – then your routing tables will be a bit “cleaner” and you want need to make the DirectAccess server the IPv6 route of last resort.
Question 3: What are the security implications with opening up inbound IPv6 traffic into your network? Since DirectAccess requires Protocol 41 traffic to be let through the firewall directly to the external NIC on the DirectAccess server, doesn't this open up some potential security issues without an IPv6 firewall in place? Maybe I am missing something, but since Protocol 41 is encapsulating ALL IPv6 traffic in IPv4 packets isn't letting Protocol 41 traffic through essentially the same thing as having a computer directly connected to the IPv6 internet with no firewall at all?
IP Protocol 41 is used to indicate that there is direct encapsulation of IPv6 packets within an IPv4 header to support 6to4. So, we’re not really allowing all IPv6 traffic through the firewall, just 6to4 traffic. Also, keep in mind that both of infrastructure tunnel and the intranet tunnel require authentication – for the infrastructure tunnel, both computer certificate and NTLMv2 authentication is required, and for the intranet tunnel, both computer certificate and Kerberos v5 authentication is required.
While all IPv6 traffic is allowed through the IPv4 tunnel – traffic to the DirectAccess server is allowed only after the client authenticates and establishes a valid IPv6 IPsec connection . We also have some Denial of Service Protection technology built into to take care of malicious users who try to take advantage of this situation, though. However, if you don’t think this is enough – you can take my earlier recommendation and disable 6to4 on the DirectAccess clients and let them use only Teredo or IP-HTTPS. Keep in mind that this is the same situation – the Teredo and IP-HTTPS clients are also encapsulating all IPv6 traffic. But the same protections still apply regarding IPsec and DoSP.
I hope you find these answers helpful and would be happy to carry on the conversation in the comments section.
Thanks!
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
Visit the TechNet forums to discuss all your UAG DirectAccess issues http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads Stay up-to-date with “just in time” UAG DirectAccess information on the TechNet wiki http://social.technet.microsoft.com/wiki/tags/DirectAccess/default.aspx
For companies thinking about deploying DirectAccess, the question of whether or not you need to deploy ISATAP will invariably come up. The answer to this question is “no” and the reasons for why you don’t need ISATAP in a DirectAccess deployment are covered in my article over at http://blogs.technet.com/b/tomshinder/archive/2010/10/01/is-isatap-required-for-uag-directaccess.aspx
However, ISATAP does have a place in a DirectAccess deployment, as I discussed in that article. If you don’t have an existing native IPv6 network infrastructure in place, then you might want to consider enabling ISATAP to fully realize the “manage out” capabilities that are part of a comprehensive DirectAccess solution.
However, in all the coverage of ISATAP, I’ve left out some critical information that can help you decide on how you deploy ISATAP in your organization. It’s at this point I get to tell you that the ole “Edge Man’s” favorite food is crow. When I get to eat crow, it means I said something in public and then find out later I was wrong (or at least not entirely right). I like crow because when I eat it, it means that I’ve learned something new.
Now with that are an introduction, let’s get into what led to this “crow eating” session. If you read this blog on a regular basis, you might remember my article on using a HOSTS file entry to control which systems configure themselves as ISATAP hosts. If you didn’t see it you can check it out at http://blogs.technet.com/b/tomshinder/archive/2011/02/14/use-a-hosts-file-entry-to-control-isatap-host-configuration.aspx
In that article, I said:
“In general, ISATAP is a good thing…”
Now that seems like a pretty benign statement, doesn’t it? I thought so. But if you look at the Intra-site Automatic Tunnel Addressing Protocol Deployment Guide at http://www.microsoft.com/downloads/en/details.aspx?familyid=0F3A8868-E337-43D1-B271-B8C8702344CD&displaylang=en you will find the following statement:
“Appropriate Uses for ISATAP on Intranets ISATAP in Windows is not designed for production networks [italics mine]. On a production network, ISATAP should be used in a limited capacity for testing while you deploy native IPv6 capabilities. Microsoft does not recommend the use of ISATAP across entire production networks. Instead, you should deploy native IPv6 routing capability…”
Ah, well, ahem, er, kaff-kaff, aaaa.., that doesn’t really align with my comment regarding “in general, ISATAP is a good thing”.
Let me explain.
To get a better appreciation for the situation, it’s a good start to think about what ISATAP actually does. For most of us, our introduction to ISATAP is with DirectAccess. In fact, for many of us, our introduction to IPv6 is with DirectAccess. When reading about DirectAccess you see that the DirectAccess server is configured as an ISATAP router, as well as a router or relay for Teredo and IP-HTTPS. This gives you the initial impression that ISATAP must be a required component of the UAG DirectAccess solution, and that perhaps it’s a standard for all IPv6 deployments. In truth, ISATAP has limited utility and is designed to support a very specific scenario.
ISATAP is an IPv6 transition technology and is designed as a temporary solution to help you transition your IPv4 network to an IPv6 network. ISATAP enables ISATAP capable hosts to automatically assign an address to an ISATAP adapter, and to communicate with an ISATAP router to get IPv6 routing table information. The purpose of ISATAP then is to provide ISATAP capable hosts with information that enables them to connect to hosts on an IPv6 only network. That connection is made through an ISATAP router.
The ISATAP router has an interface on the IPv4 only network and a second interface on an IPv6 only network. The ISATAP router will take the IPv6 packets that are encapsulated in an IPv4 header, and forward them to the IPv6 only network by removing the IPv4 header before forwarding them. When hosts on the IPv6 only network want to connect to hosts on the IPv4 network, the ISATAP router will receive the packets, put an IPv4 header on them, and forward them to the ISATAP enabled hosts on the IPv4 only network.
When ISATAP enabled hosts on an IPv4 only network communicate with each other, they will preferentially use their ISATAP adapters to communicate. They will query DNS and if they receive both A and AAAA records, they will use the AAAA record’s address and use IPv6 to communicate with the other ISATAP enabled host on the IPv4 only network. This is done because Windows hosts that are capable of using ISATAP (Vista and above, Windows 2008 and above) use IPv6 preferentially. It doesn’t matter that the IPv6 packets are encapsulated with an IPv4 header. Keep in mind that in order to reach the ISATAP adapter on the destination host, the source host also needs the address in the A record to get the IPv4 address of the destination.
In Figure 1, you can see three networks:
When a host on the IPv4 only network wants to connect to a host on the IPv6 only network, it uses routing table entries that indicate that it should use its ISATAP adapter to send the IPv6 packets to the IPv4 address ISATAP router. The ISATAP router then removes the IPv4 header to expose the IPv6 header and forwards the IPv6 packet to the host on the IPv6 network.
The UAG DirectAccess server is also configured as an ISATAP router, and it advertises IPv6 routes that ISATAP capable hosts on the IPv4 only network can use to connect to DirectAccess clients. The DirectAccess clients network (which includes network prefixes for the Teredo, 6to4 and IP-HTTPS address spaces) is an IPv6 only network. Therefore, when a host on the IPv4 only network wants to connect to a DirectAccess client, it checks its routing table and finds that it should use its ISATAP adapter to send the IPv6 packets to the IPv4 address on the internal interface of the UAG DirectAccess server. The UAG DirectAccess server (acting as an ISATAP router) removes the IPv4 header and forwards the un-encapsulated IPv6 packet to the DirectAccess client.
Figure 1
As you can see, ISATAP is used to enable connections from an IPv4 only network (meaning the routing infrastructure only supports IPv4 routing) to an IPv6 only network (meaning that the routing infrastructure supports IPv6 and the hosts on the network use only IPv6 addressing) by using an ISATAP router. The idea here is that as you transition to an IPv6 network, you will create dedicated segments devoted to IPv6 and that during this transition, you still need to enable connectivity between the “old” IPv4 only network and the “new” IPv6 only network. The transition phase isn’t meant to be indefinite and when the transition phase of the deployment is over, you’ll disable ISATAP in DNS and take down the ISATAP routers.
However, DirectAccess is a special case when it comes to ISATAP and IPv6 enablement. We want you to be able to use DirectAccess now. However, we also realize that very few networks are IPv6-only at this time and that it will take several years before the predominate network protocol is IPv6. To solve this problem, we enabled the UAG DirectAccess server as an ISATAP router. For the UAG DirectAccess server, the purpose is to enable full “manage out” capability, so that management servers on the IPv4 intranet can initiate connections with DirectAccess clients. We don’t need ISATAP to support connections initiated by DirectAccess clients to IPv4 resources on the intranet because we have the NAT64/DNS64 solution.
The “manage out” scenario where management servers on the intranet initiate connections to the DirectAccess clients is a relatively limited one in terms of scope. You won’t have that many management servers that need to be able to do this (although you might want to allow Help Desk to connect to DirectAccess clients over RDP, in which case the number of hosts that need to initiate a “manage out” connection will be larger). Since you know in advance who these machines are, you might want to consider using a HOSTS file entry on these “manage out” machines instead of enabling ISATAP for your entire network using DNS. This gets around problems you might run into if you’ve decided to disable IPv6 on the computers on your network (you can find out the details of this situation in my blog post at http://blogs.technet.com/b/tomshinder/archive/2011/02/14/use-a-hosts-file-entry-to-control-isatap-host-configuration.aspx).
In conclusion, we can reconcile my statement that ISATAP is generally a good thing when we think about the special case of the DirectAccess. However, the purpose of ISATAP in a DirectAccess scenario is a bit different than it is when you’re using ISATAP to transition your intranet to IPv6. Because a limited number of hosts on the intranet need to be IPv6 capable to initiate connections (manage out) DirectAccess clients, there is a good argument for not enabling ISATAP in DNS (it is disabled by default) and only using HOSTS file entries on the machines that require “manage out” capability to DirectAccess clients.
Take a look at the figures below and see if you can guess what device is in the request/response path that you don’t typically see a UAG DirectAccess deployment.
First, the ipconfig output on a DirectAccess client located behind a NAT device:
Now let’s ping DC1:
Figure 2
Now let’s do a tracert from CLIENT1 and DC1:
Figure 3
With this information you should be able to figure out what the “novel” device is in the path between CLIENT1 and DC1. If you know, then consider yourself pretty well-versed with IPv6 addressing. If you don’t know, then here’s a great opportunity to learn something new!
Now take a look at figures 4 and 5 and determine what device was removed from the path:
Figure 4
Figure 5
Think about the solutions and put your answer in the comments section. Give your reasoning. I’ll post the answer and a network diagram of the solution tomorrow.
Have fun!
We’ve received a number of questions recently about UAG DirectAccess support for the IPv6 Internet. When thinking about the IPv6 Internet, you need to think about when the DirectAccess client is on an IPv6 Internet (or on an IPv6 only intranet) and when the UAG DirectAccess server has its external interface connected to an IPv6 Internet connection.
Part of this confusion seems to stem from a TechNet article over at:
http://technet.microsoft.com/en-us/library/ee809074.aspx
Let’s look at some of the sections that might be ambiguous or otherwise difficult to understand and try to clarify a few things.
“The DirectAccess client computer connects to the Forefront UAG DirectAccess server using IPv6 and IPsec. If a native IPv6 network isn’t available (which is most probable when the user is connected to the Internet), the client establishes an IPv6-over-IPv4 tunnel using 6to4 or Teredo. The user does not need to be logged in to complete this step…”
There are two issues that need to be clarified here:
That’s it – not too complicated but an important thing to know – that we don’t support scenarios where the UAG DirectAccess server’s external interface is connected an IPv6 Internet (that is to say, that the UAG DirectAccess server has an IPv6 address assigned to its external interface) and when the DirectAccess client is connected to an IPv6 only network (which prevents the client from being able to set up an IPv6 transition technology based connection to the UAG DirectAccess server.
Several people have asked why we decided to use this approach, and the primary reason is that there are very few scenarios where the UAG DirectAccess server is connected to an IPv6 only Internet connection and where the UAG DirectAccess client is connected to an IPv6 only network. Since these scenarios can be interpreted as “corner cases” at this time, the decision was to not design toward these scenarios and focus on what we see on networks today.
That said, Microsoft is firmly committed to IPv6 and our DirectAccess design and implementation will grow with the increasing availability of native IPv6 Internet and intranet connectivity.
When I’m between doing things that I sort of want to do, but not enough where I want to start on them right away, I’ll do a little ego surfing. If you haven’t heard the term “ego surfing”, it’s the act of going to your favorite search engine (or multiple search engines) and searching for the results returned on your name. I do this from time to time because, well, ahhh – for the same reason anybody else does it!
Today I was doing some ego surfing for someone else. That “someone else” in this case was DirectAccess. I wanted to see what the top search engine results were for DirectAccess using a number of search engines. On more than one search engine, I found an article that left me a little perturbed. The title of the article is Microsoft DirectAccess: The ugly truth. Now, I know that headline writers write outrageous headlines because they get more attention, but I felt that I needed to write a response to show that the ugly really isn’t there and that there is beauty in its place.
In fact, when it comes to UAG DirectAccess, much of the ugliness is swept away and what we see is a real thing of beauty. Hence the name of this article Microsoft UAG DirectAccess: The Beautiful Truth. To find this beautiful truth about UAG DirectAccess, let’s take a look as some quotes from the Network World article.
“The following list of DirectAccess requirements comes directly from Microsoft TechNet: One or more DirectAccess servers running Windows Server 2008 R2 with two network adapters: one connected directly to the Internet, and a second connected to the intranet. On the DirectAccess server, at least two consecutive, public IPv4 addresses assigned to the network adapter that's connected to the Internet. DirectAccess clients running Windows 7. At least one domain controller and DNS server running Windows Server 2008 SP2 or Windows Server 2008 R2. A public key infrastructure (PKI) to issue computer certificates, smart card certificates, and for NAP, health certificates. IPsec policies to specify protection for traffic. IPv6 transition technologies available for use on the DirectAccess server: ISATAP, Teredo, and 6to4. Optionally, a third-party NAT-PT device to provide access to IPv4-only resources for DirectAccess clients”
“The following list of DirectAccess requirements comes directly from Microsoft TechNet:
Let’s look at each one of these:
Now that we’ve debunked many of the issues regarding DirectAccess for UAG, let’s take a look at another quote from the article:
“That is no small list of requirements. What it means is that to implement DirectAccess, I have to change, replace, or upgrade just about everything at my network edge. In addition to maintaining a public-facing firewall for Internet access, I have to add another direct-to-Internet server to act as the DirectAccess termination point. As servers are replaced and updated, I can see the enterprise eventually getting to the point where all of these things are already in place. But for most of us, this set of conditions can be a showstopper.”
Everyone already has a firewall at the edge of their networks. So, there’s nothing to add there. And, firewalls and NAT are not the same thing. All you need to do is create a small block of public addresses for the UAG DirectAccess server and route the connections through the firewall (firewalls still provide firewall protection without NAT) – so there’s nothing to add there when it comes to hardware, and subnetting is pretty easy for the network guys. Yes, it is true that you need to add the DirectAccess server as an Internet facing device – but you already have a lot of those, so what’s one more? Again, this is something most network admins do frequently and it isn’t a odd “one off” situation. There really don’t appear to be any show stoppers here – and with UAG DirectAccess, I think we end up with the “star of the show” when both users and IT tip their hats to you for giving them what they’ve actually wanted since the first PPTP VPN was deployed.
Let’s finish up with another quote that we can easily address:
“Also, because other releases of Windows server operating systems don't support dual-layer IP, DirectAccess can't natively talk to them. If your enterprise has a bank of Windows Server 2003 or older machines that won't be upgraded anytime soon, that data is in a silo that DirectAccess can't directly access.”
With UAG DirectAccess and its built-in NAT64/DNS64 service, the only Windows Server 2008 or above machine you need on your network is the UAG DirectAccess server. Your entire network can be full of Windows Server 2003, Windows 2000 Server, and Windows XP. DirectAccess clients will be able to connect to these network resources just fine. In addition, you can run your domain on Windows Server 2003 domain controllers and DNS servers. Like I said – only the UAG DA server needs to be running Windows Server 2008 R2. That means there is no silo – DirectAccess users can access whatever they need on legacy operating systems.
There you go. Microsoft UAG DirectAccess – The Beautiful Truth. I hope that you’ve had a chance to read this article before you read the ugly truth article, but if you read the ugly truth article first, at least you know what the truth is regarding UAG DirectAccess. And with these truths in mind, I hope that you’ll consider researching a possible DirectAccess deployment for your company. If you have any questions on how to do this, send me a note at the address in the sig line below.
How’s that for a catchy title?
Test Lab Guides (TLGs) are a new method that Joe Davies and I have developed that makes learning complex technologies easier than ever. Using TLGs, you can significantly cut down on the time it takes for you to learn a new technology, product or an entire multi-tier solution by configuring a Test Lab using a TLG.
Now you might be wondering “what’s the difference between a Test Lab Guide and a Step by Step Guide?” In the past, we’ve used the term “step by step guide” to describe a lot of different types of content. It might be a collection of steps you do to issue a certificate, or maybe the steps required to enable and disable the Windows Firewall, or it could be a large collection of steps used in a lab type of environment.
The problem with step by step guides is that they don’t define a standard environment on which you could test out the steps and then validate that the steps actually worked. You could create your own test lab using what you think might be the best settings for a collection of clients and servers, but when you were done with it, you were done. The next time you wanted to go through a different step by step guide, you had to build out another lab, with different settings, clients, servers and services, and go through the steps. Then if you wanted to check out another step by step guide, you had to go through the entire drill all over again.
It was a time consuming process and many of us shied away from the valuable experience the step by step guidance could provide. Test Lab Guides solve this problem by enabling you to create a reusable environment that speeds your lab setups and allows you to get to testing the technology, product or solution faster than ever.
At the heart of the Test Lab Guide concept is the Base Configuration. The Base Configuration is a standard set of servers and clients that are used to simulate a private network and the Internet. The Base Configuration defines the names, IP addressing information and network services used in the Base Configuration setup. After you create the Base Configuration, you take a snapshot – as all subsequent Test Lab Guides will start with the Base Configuration. By creating a snapshot of the Base Configuration, you save a few hours each time you want to try out a new Test Lab Guide. Over the course of a year, this can save you literally days of effort!
The Base Configuration is shown in the figure below:
Now that you have a snapshot of the Base Configuration, what do you do with it? The next step is to build on it using Test Lab Guide modules.
A Test Lab Guide module always builds on the Base Configuration. For example, the figure below shows a Test Lab Guide module named Demonstrate UAG DirectAccess. When you go through the Demonstrate UAG DirectAccess module, the first step is to restore the Base Configuration and you start with the Base Configuration. The module then uses the servers and services already configured in the Base Configuration and adds what’s required to demonstrate DirectAccess.
When you finish the module, you can take a snapshot of the working solution, so that you can return to it later. This is very cool because you don’t have to go through the entire module again to see what the working solution looks like. But if you wanted to do the module all over again, you can restore the Base Configuration and start all over.
See how flexible this approach is?
Now let’s have even more fun. TLG modules build on the Base Configuration. But modules can also build on other modules, so that your TLG actually represents a stack of modules! Check out the figure below. You see three new TLG modules:
These three Test Lab Guides are modules that build on the Demonstrate UAG DirectAccess module. So, if you already did the Demonstrate UAG DirectAccess module and took a snapshot of that module, all you need to do is restore the snapshot of that module, and then go to work on one of the TLGs higher up in the stack. We like to call these “third level modules” since they’re the third module in the stack.
Of course, your stack can get as high as you want, and as long as you take a snapshot after each module, you don’t have to spend time going through all the steps all over again just to begin the new module. Again, a tremendous time saver that allows you to test a greater number of capabilities in the technology, product or solution that you want to learn about.
Virtualization is the key to success with TLGs because it allows you to easily take snapshots of the entire Test Lab and then restore them to proceed to the next module in a Test Lab Guide stack. Before the mainstreaming of virtualization, putting together Test Labs that provide a reasonable facsimile to a production environment would be very difficult. And the time it would take to image the disk drives and restore the images can take quite a while – with virtualization technology, regardless of the virtualization solution you’re interested in, snapshots and restoration is a “snap”.
And it doesn’t stop there. While I’m using DirectAccess as the example technology for Test Lab Guides, the TLG approach can be used for any technology, and we’re expecting that many of the teams at Microsoft will be adopting the Base Configuration and Test Lab Guide module approach so that mixing and matching TLGs will be easy and enable you to build on your collection of TLG snapshots.
For example, maybe the Exchange Team wants to build a TLG on demonstrating Exchange remote access. They could take the Demonstrate UAG Direct Access TLG and build on that, since UAG is part of that TLG and all they need to add is the Exchange configuration and the UAG Exchange publishing configuration. In that way, they don’t need to “reinvent the wheel'” and start from the beginning. Again, a big time saver and a way to get this key information out to you so that you can test it in record time.
What’s even better is that YOU can get into the Test Lab Guide game by creating Test Lab Guide Extensions. A Test Lab Guide Extension is something that you can create that extends the value of a Test Lab Guide. For example, suppose you wanted to create a Test Lab Guide module that built on the Demonstrate UAG DirectAccess and NAP TLG to show how smart cards work with UAG DirectAccess and NAP. What you could do is use the TLG Extension template and create a module that builds on top of the Demonstrate UAG DirectAccess and NAP TLG stack. That way, you don’t have to write out all the steps have already been written – you only need to include the steps required to add the smart card integration.
Of course, you could create your own stack and use the Base Configuration as the start of any technology that you’d like to create a TLG extension for. You start your own stack, beginning with the Base Configuration and then add a stack of TLG extensions. Then others can reuse your stack and create their own extensions. Everyone ends up saving time and learning more because the reusability of the Base Configuration, modules and extensions.
Go Ahead – give it a try – or as we like to say “The Test Lab Guide Base Configuration: Make Something of IT!”
So let’s put it all together.
The figure below shows the components of the Test Lab Guide approach to building out Test Labs using the theoretical example of the solution consisting of UAG DirectAccess, NAP, and SCCM. At the bottom is the core of all Test Lab Guides, which is the Base Configuration. Then modules are built out of the Base Configuration (second level modules). Then modules are built on the second level modules (third level modules) and so forth. You can also see where you can build out your own TLG extensions in the TechNet wiki. Notice on the right side a little icon of a woman taking a snapshot. These are points where you would want to take a snapshot of your configuration so that you can return to it to either redo the steps for a module, or to build a new module or extension.
There’s no doubt about it – you really don’t know how to do something until you actually do it, and that’s what Test Lab Guides are all about. With our reusable TLGs, you’ll be able to get up to speed on simple and more importantly, complex technologies faster than ever. And you’ll be learning the technology, product or solution using a tested and reliable TLG that you know will end up in a working configuration.
You’ll learn all the moving parts, all the tricky areas, and infrastructure requirements that go into making things work. You’ll also have more confidence in the solution, as there isn’t any “smoke and mirrors” configuration in the background – you’ll do every step to configure the front-end and the back-end so that you’ll understand how all the pieces fit together.
Try out some of the Test Lab Guides. You can find the TLG clearinghouse on the TechNet wiki. Right now we have TLGs stacks for Windows DirectAccess and UAG DirectAccess, but we’re expecting many more technologies to be included in the future, and we’ll update the wiki when they become available. Also, remember that anyone can update the wiki, so if you create a Test Lab Guide extension, make sure to update the wiki with your extension. We’re looking forward to some great contributions by the community of original and innovative TLG extensions.
Finally, I want to let you know that I’m here to help. If you have questions about Test Lab Guides let me know. If you want to create a new extension but not sure how to proceed, send me a note and I’ll try to help you. Test Lab Guides speed up all of our knowledge and knowledge is power – let’s go for the power!
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.
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.
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.
Most of you probably know this, but before I joined Microsoft I spent most of my time with ISA Server and Threat Management Gateway (TMG). A big part of my life was ISAserver.org (www.isaserver.org). My affiliation with ISAserver.org started in mid-2000 and continued uninterrupted until I joined Microsoft in December 2009. However, even after joining Microsoft, I’ve continued to post to the web forums on ISAserver.org because the community for ISA and TMG and UAG is so active there.
The web forums were my favorite experience at ISAserver.org. From those forums I got to know many people, and became friends with a lot of them, over the years. ISAserver.org brought together people from all over world to have professional and interesting discussions about our favorite firewall: ISA Server (now TMG). I can honestly say that my life would have been a poorer experience if I hadn’t participated and met so many great people because of my involvement with the ISAserver.org web forums.
So yesterday was a big day for me – I hit my 50,000th post on the web forums!
It took 10 years to do it, which means I averaged something like 5,000 posts per year. Of course, the number of posts per day was significantly higher in the days of ISA 2000 and ISA 2004 – ISA 2000 was a complete remake of Proxy Server 2.0 and somewhat of a challenge to understand and then when ISA 2004 was released, it represented a major remake of the user interface and required a lot of new learning. It was with the introduction of ISA 2004 that ISA became a true enterprise ready network firewall.
Because something like this only happens once, I decided to do a short movie of the event. If you’d like to watch the momentous occasion, then check out the video below.
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.
A couple of good questions were asked on a recent blog post and I figured it was worthwhile to answer them in more detail in a separate post.
====================================
“Can you clarify a couple points related to Certificate Authorities and CRLs? I plan on getting a commercial certificate for the IP-HTTPS listener as you recommended, but how does that affect all of the other certificate related configurations in the test lab guide? The CA created on the domain server is completely separate from this commercial certificate, right?…”
The IP-HTTPS listener needs a web site certificate (intended use is server authentication) so that DirectAccess clients can establish an IP-HTTPS connection to the UAG DirectAccess server before establishing the DirectAccess IPsec tunnels. This requires mutual client and server authentication, something that is the default setting for UAG DirectAccess (the default for Windows DirectAccess is server authentication only).
The primary advantage of using a commercial certificate for the IP-HTTPS listener is that the commercial certificate provider maintains the Certificate Revocation List (CRL) and Distribution Points for you. Not only do they maintain that list for you, they also make sure that the CRL is highly available. While you could use your private PKI for the IP-HTTPS listener, you would then be responsible for maintaining the CRL and making sure that it it highly available.
Now how does this relate to what we did in the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess Test Lab Guide (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=71be4b7b-e0e9-4204-b2b5-ac7f3c23b16d)?
In the Test Lab we actually created a certificate template that removed CRL related information so that the DirectAccess client would not fail its IP-HTTPS connection when the CRL wasn’t published. This simplified the TLG environment because we didn’t need to go through the steps of publishing the CRL. In your production environment, you do want to make sure that the CRL is available for your private PKI; so you wouldn’t use the special configuration we did for the web site certificate template we used in the TLG. However, you don’t need to publish your private CRL because the commercial provider is handling the IP-HTTPS certificate’s CRL Distribution Points.
You still want to use your private PKI to distribute computer certificates to the DirectAccess clients and the UAG DirectAccess server. You also want to distribute computer certificates to any machines that you want end-to-end IPsec transport mode protection. And you want to make sure that the CRL is available so that you can revoke certificates (however, revoking certificates for DirectAccess clients is not an effective way to prevent them from connecting to the DirectAccess server – other methods should be used, such as disabling the computer account for the suspect DirectAccess client and changing the password of the user who lost the DirectAccess enabled computer). And you want to be able to use autoenrollment to make is easy to distribute the certificates.
The commercial certificate and the private certificates have no relationship to each other and don’t need any. The commercial certificate provider should be included in the Enterprise Root Certificate Authorities store on all your DirectAccess enabled machines.
========================================================
“And you mentioned that you wouldn't want to host the CRL on the DirectAccess server in a production environment. Is this only because of performance reasons or because of something else? And is this CRL not related to the IP-HTTPS listener? So, just to make sure I'm getting it, there is one CA and a corresponding CRL for the active directory domain, and then another CA/CRL (in this case commercial) for the DirectAccess connections. Is that right?…”
There are a number of reasons why you wouldn’t want to host the CRL Distribution Point web site on the UAG DirectAccess server, but probably the main one is that every time you reconfigure the DirectAccess settings using the UAG DirectAccess wizard, it will end up resetting your CRL Distribution Point web site. There are also traffic related reasons – since the CRL check requires anonymous access to the CRL Distribution Point web site, you increase both the amount of traffic and the attack surface on the UAG DirectAccess server.
You are correct that there are two CRLs in use in the DirectAccess scenario discussed here:
It’s important to note here that only a “soft” CRL check is done when the DirectAccess client connects to the UAG DirectAccess server. If the DirectAccess client fails the CRL check, it will still be allowed to connect. So whether or not the CRL is available doesn’t determine connectivity for your DirectAccess clients.
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.
DirectAccess is about being “always-on”. When I start my laptop in the morning, I’m ready to get to work. Even though I don’t work on the Microsoft campus, I’m able to connect to anything I want (that I have permissions to connect to) on the Microsoft intranet without thinking about connecting to an SSL VPN portal, some web application gateway, or a traditional network layer VPN connection. I just start the laptop and BAM! I’m connected. And IT is always connected to me too, so my laptop is always up to date and managed by Microsoft IT.
DirectAccess connections consist of two IPsec tunnels that fire up when the Private or Public Windows Firewall with Advanced Profiles are assigned to the machine configured as a DirectAccess client. When the Public or Private Profile is active, the machine configured to be a DirectAccess client will attempt to establish two IPsec tunnels with the DirectAccess server:
The infrastructure tunnel is established after computer certificate authentication and computer account NTLMv2 authentication. The infrastructure tunnel allows the DirectAccess client to connect to key resources on the intranet, such as domain controllers and management servers (WSUS, SCCM, SCOM, etc.). Intranet tunnel connectivity enables you to always manage the DirectAccess client, even if the user isn’t logged on to the computer. In addition, the intranet tunnel provides the connectivity required for the user to log on and establish the intranet tunnel.
The intranet tunnel is established after both computer certificate and user account Kerberos authentication is successful. In order to complete the user account authentication (Kerberos), the user needs access to a domain controller. That’s why you need the infrastructure tunnel to come up before the second tunnel can be established. The intranet tunnel cannot be established by using cached credentials on the client.
So what does this all to do with 3G connectivity? Mobile computers with 3G adapters are becoming increasingly popular. These 3G adapters are tremendously convenient, as you no longer need to depend on being able to connect to whatever local network where you might be physically located . All of us have gone through “the drill” of trying to connect to a customer’s network, a hotel network, or some public Wi-Fi network. Sometimes it’s easy, but more often than not there are some bumps that eat into your productivity. The 3G adapter allows you to get around those time-eating complications.
The problem is that not all 3G adapters and their supporting software are the same. The following describes an interesting issue that came up when a customer was using a particular 3G adapter:
“This morning I tested the “always-on” 3G connection scenario with my Rogers 3G adapter (http://www.rogers.com/web/content/wireless_network) and the built-in 3G GOBI (built-in mobile broadband technology - http://www.gobianywhere.com/) adapter in my HP Tablet and found that when using the Rogers USB 3G adapter an “always-on” connection is not possible, but when using an integrated 3G GOBI module it is possible (it really comes down to the software that is provided). The details of my test methodology and results are below… Rogers Rocket™ Stick – The Rogers Communication Manager software runs in User Mode only (does not run as a Service), so the connection is invoked when a user is logged on and disconnected when the user logs off. There is an “Auto-Connect” checkbox, but it only makes the connection when a user logs on to the device. Therefore the current software provided by Rogers does not support an “always-on” scenario. I verified this by looking at the activity light on the USB stick itself – Red is device is not ready, solid Blue is network detected, blinking Blue is network connected and active. For the duration of the test the activity light remained sold Blue, indicating that a connection to the 3G network was never established. It only began blinking after I logged in to the computer. HP Built-In 3G GOBI Adapter – The HP software is installed as a Service that can be configured to automatically start at boot (in the Services console), and there is also an option to “Auto-Connect” to the 3G broadband. Since the HP Tablet does not have external lights to indicate network activity I had to find another method to determine if the 3G connection was active prior to logon, so I did the following: Disabled the wireless adapter, so that the HP Tablet could only connect using the 3G broadband Installed the Windows Live Mesh software on the HP Tablet, added the HP Tablet to my managed device list and configured it to allow remote connections I completely shut down the HP Tablet, then turned it on (cold boot) and left it alone (did not log on) At my other computer (Lenovo laptop), I logged on to http://mesh.live.com and was able to successfully Remote Desktop to my HP Tablet via the website To verify that only the 3G broadband connection was active, from the Remote Desktop session I checked the active network connections on the HP Tablet, then double-checked by logging on to the HP Tablet locally – and yes, throughout the entire time the only active connection was the 3G broadband. Therefore the HP built-in 3G adapter (with a Rogers SIM), appropriately configured, will allow for an “always-on” 3G connection that could be used for device management prior to user logon. A similar test would have to be run for the any other 3G adapter you will be using to verify if the 3G adapter’s software provides the same capability.”
“This morning I tested the “always-on” 3G connection scenario with my Rogers 3G adapter (http://www.rogers.com/web/content/wireless_network) and the built-in 3G GOBI (built-in mobile broadband technology - http://www.gobianywhere.com/) adapter in my HP Tablet and found that when using the Rogers USB 3G adapter an “always-on” connection is not possible, but when using an integrated 3G GOBI module it is possible (it really comes down to the software that is provided). The details of my test methodology and results are below…
Rogers Rocket™ Stick – The Rogers Communication Manager software runs in User Mode only (does not run as a Service), so the connection is invoked when a user is logged on and disconnected when the user logs off. There is an “Auto-Connect” checkbox, but it only makes the connection when a user logs on to the device. Therefore the current software provided by Rogers does not support an “always-on” scenario. I verified this by looking at the activity light on the USB stick itself – Red is device is not ready, solid Blue is network detected, blinking Blue is network connected and active. For the duration of the test the activity light remained sold Blue, indicating that a connection to the 3G network was never established. It only began blinking after I logged in to the computer.
HP Built-In 3G GOBI Adapter – The HP software is installed as a Service that can be configured to automatically start at boot (in the Services console), and there is also an option to “Auto-Connect” to the 3G broadband. Since the HP Tablet does not have external lights to indicate network activity I had to find another method to determine if the 3G connection was active prior to logon, so I did the following:
Therefore the HP built-in 3G adapter (with a Rogers SIM), appropriately configured, will allow for an “always-on” 3G connection that could be used for device management prior to user logon. A similar test would have to be run for the any other 3G adapter you will be using to verify if the 3G adapter’s software provides the same capability.”
Later another interesting finding was that with the HP GOBI 3G adapter, if the user logged off the computer the 3G adapter shut down and does not start again until the user logs on again or until the machine is restarted.
When considering a 3G solution to work with your DirectAccess capable mobile computer, make sure to check on the adapter software’s connectivity behavior. The adapter should be able to initialize and connect to the 3G network before the user logs on to the DirectAccess client computer. You can use the methods described in this article to determine if the adapter is capable of this behavior.
(Hat tip to Pat Telford for informing me of this issue.)
The question on how to handle DirectAccess clients and Internet security for those clients is always a popular topic. As I’ve mentioned many times in this blog, the overall threat and management profile of the DirectAccess client should be little different than a client that is on the intranet.
However, there is one major difference between the intranet client and the DirectAccess client – and that’s an Internet gateway that protects the client from Internet threats with URL filtering and web antimalware.
With this in mind, the following question is topical and I’ll use it to drive the discussion.
====================================================================
“UAG providing direct access over HTTPS to a large set of demo computers in retail stores. They are a wireless ISP so all the computers in the offices are connected directly to the Internet, rather than a corporate network. We are using DA to manage group policy on the demo boxes to ensure they are tightly locked down. We have a need to also provide some sort of content filtering/web site blocking on these boxes. One thought is to leverage UAG to act as a filtering proxy server for these boxes. The customer is concerned about using UAG “normally” because traffic would then flow across the DA/HTTPs link which would be the slowest option and may impact the performance of these demo boxes. Thus they would like to configure their UAG box to act as a proxy server out on the Internet with some authentication for clients to connect. So my questions to the group are: Is this totally crazy? Can this be done in a supported way? Is there a better way for them to do this”
“UAG providing direct access over HTTPS to a large set of demo computers in retail stores. They are a wireless ISP so all the computers in the offices are connected directly to the Internet, rather than a corporate network. We are using DA to manage group policy on the demo boxes to ensure they are tightly locked down.
We have a need to also provide some sort of content filtering/web site blocking on these boxes. One thought is to leverage UAG to act as a filtering proxy server for these boxes. The customer is concerned about using UAG “normally” because traffic would then flow across the DA/HTTPs link which would be the slowest option and may impact the performance of these demo boxes. Thus they would like to configure their UAG box to act as a proxy server out on the Internet with some authentication for clients to connect.
So my questions to the group are:
First we have to get clear on the scenario. It sounds like these machines are configured as DirectAccess clients and are configured to use IP-HTTPS to connect to the UAG DirectAccess servers. It’s not clear why this is being used instead of 6to4 – maybe there is a device in the path between these DirectAccess clients that blocks IPv4 Protocol 41. What it appears they want to do is provide some gateway based security for these clients. The proposed idea is to use the UAG DirectAccess server as an outbound proxy for the DirectAccess clients. There are two problems with this possible solution:
Given those two facts, we need to think of some other way to enable Internet gateway security for these clients. This is what I’d propose:
The figure below shows what the request path would look like when you configure the DirectAccess clients to use a Web proxy. Note in this scenario that you can have the outbound connection use a different gateway to the Internet than the one used by the DirectAccess server itself.
The figure below shows what it looks like when you configure the DirectAccess clients to “bounce off” the UAG DirectAccess server. The difference in this case is that the web filtering gateway is most likely going to be in a DMZ. You will need to be careful here, because the DirectAccess server can only have a single default gateway, which means that the web filtering gateway is going to need to be in the DirectAccess request/response path between the DirectAccess client and server. In the figure below, you can see that the outbound connections are leaving through the same firewall that they DirectAccess tunnel connections came in through.
If you want to see how this configuration works in a test lab, then check the Force Tunneling Test Lab Guide. You can find a complete list of Test Lab guides at http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx
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
Yuri Diogenes and I have worked together on a number of projects over the years – last year we published three new books on TMG, UAG and Forefront Security for Exchange. You can find more information on these books on Yuri’s blog at http://blogs.technet.com/b/yuridiogenes/archive/2010/07/08/new-forefront-books-by-microsoft-press.aspx
We also worked together on the TMG Firewall Administrator’s Companion which you can find at http://blogs.msdn.com/b/microsoft_press/archive/2009/12/09/forefront-tmg-2010-administrator-s-companion-a-unique-reading-experience-is-coming.aspx
So with four books in the can, where do we go from there? Well, Yuri recently moved from CSS Security to Windows Server iX so we thought “how about we do a security talk show?” Sounded like a good idea to me, and thus Security Talk with Yuri Diogenes and Tom Shinder was born.
Unlike Talk TechNet (http://technet.microsoft.com/en-us/gg558001), Security Talk with Yuri Diogenes and Tom Shinder is like a television talk show – we plan on recording two shows a month and if the thing takes off, we’ll consider doing four shows a month so that you can enjoy the fun once a week.
While the official launch won’t be until after TechEd, we took advantage of the fact that Jim Harrison was in town from Redmond (Yuri and I live in the Dallas/Ft. Worth area in Texas) and did a “practice” session.
Head on over to the Security Talk with Yuri Diogenes and Tom Shinder blog for more information and to view the v0.5 of the program!
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]
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
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.
DirectAccess is a new remote access technology enabled by the combination of Windows Server 2008 R2 and Windows 7. Unlike other remote access technologies such as reverse proxy, reverse NAT, SSL VPN gateways, and network layer VPNs, the goal of DirectAccess is to extend your network to any location in the world, so that your domain member client systems are always connected to the corpnet.
Think about the mix of remote access technologies you use now. Some of them might be in place to support partners, for which you want to provide very limited network access. But what about your employees? If you’re like me, you’ve probably spent most of your professional life trying to figure out how to give employees the information they need, in the most efficient way possible, so as to create the least frustration for both the employee and the Help Desk and IT overall. Most of all, you want to make sure this access is secure and that security doesn’t interfere with productivity.
There have always been two major stumbling points when providing productivity-enabling remote access to employees:
When you think about it, neither you nor your users ever wanted to use VPN. You never really wanted your employees to have to use SSL VPN gateways. You never actually wanted your users to have to gain access to resources over reverse proxies and NAT devices. You never really wanted to use any of the myriad number of remote access “artifices” that you’ve put in place.
But you did, because your goal was to provide your business an advantage by delivering out of office users access to information so that they could get their work done from anywhere.
But these solutions didn’t really didn’t do what they were supposed to do – at least not for you and your employee users:
No, we didn’t want these remote access solutions for our employees, but they were the best we could do.
What we actually wanted all this time was DirectAccess.
I can tell you that as a user, DirectAccess becomes a transformational experience. It completely changes the way I approach my work. In the past, if I left the office, I anticipated the traditional road warrior’s “negotiations with the remote access gods”.
The negotiations went something like this:
You just never knew what the computing experience was going to be. If the network layer VPN worked, then almost everything worked. Of course, I’d have to fire off the VPN client first, and make sure the client was configured correctly (easy for me, not so easy for the average or even above average user). If neither network layer VPN protocol worked, then I spend my time living the second-class life of browser based applications. And file access experiences ranged from problematic to catastrophic.
There were often workarounds, but I could employ them because I’ve been doing networking for a long time. Average users would give up, call the Help Desk or try their best to do what they could with what they had – with the end result being a significant compromise in productivity and a flagging faith in the entire remote access experience and reduced expectations for what could be done when away from the office.
DirectAccess changes the game. Not only the game, but the entire playing field. So many of the problems related to remote access technologies that I’ve described so far are due to the users “location awareness”. While location awareness in the software is a very useful thing (and used by DirectAccess in the background), it’s not something you and your users want to worry about.
It’s the entire “location awareness” issue that creates problems for users:
This “location awareness” creates both conscious and unconscious friction with the surface of user productivity. Energy is wasted and productivity is reduced. With DirectAccess, the entire “location awareness” issue is a non-issue. When you and your users connect with DirectAccess – the experience is the same all of the time.
How is the computing experience the same in each of these scenarios? Because the following describes the computing experience for all five of the scenarios listed above:
Notice there was no “starting the VPN connection” or “connecting to the SSL VPN portal page” or anything else that required the user to be “location aware”.
This is what makes DirectAccess the paradigm shifting, transformational technology it is. And what really proves the point is how quickly you will take it for granted. That is a key component of what I consider to be transformational technology – you take it for granted because it was always supposed to be this way. In fact, you’ll find that the technology, over time, will seem boring to you. And for new computer users who have never experienced DirectAccess , they will find it really boring – or at least not exciting or transformational, because they will assume that is how remote computing should have always been done.
The story on the IT side of the house is just as compelling. Now you have access to the DA clients anytime a DirectAccess client is turned on; the user doesn’t even need to be logged on. You can apply patches, do “just in time” updates, install software, remove software, perform real-time remote management and configuration or assistance over RDP, and many more management tasks because the connection between DA clients and management servers is bidirectional and always available between the management servers and DA clients.
Your DA clients will be in the same state of compliance as machines that never leave the corpnet and they have access to all the management, command and control systems you use to manage any machine on the corpnet.
The reason is that DirectAccess allows you to extend the corpnet and its management infrastructure to the DA client.
I know that you’ve heard about “paradigm shifts” and “transformational technologies” in the past. IPsec server and domain isolation had that potential. But it never caught on. Network Access Protection, something I can remember hearing a number of people at TechEd 2004 demand “I need it now!” But after it was released, sort of “hung in the stretch” (to use a horse racing term). Why? I don’t know if there are any official reasons why, but I suspect that these two fantastic, potentially game changing technologies were just too complex and the expected return on investment for dealing with such a level of complexity ended up being too low.
This can’t and must not happen to DirectAccess – there are two main reasons why I don’t see DA “dying on the vine”:
So there you have it – my reasons why DirectAccess will change the world, and it’s a world that both IT and end-users have always wanted to live in.
It’s also a world that I want to help you get to. In the following months this blog will be dedicated to UAG DirectAccess and provide you hints, tips, tricks, ideas, opinions, workarounds, designs, and experiences that will speed your path to DirectAccess deployment. Because the only way you’ll really know the joy of the DirectAccess experience is to experience it. And after that, you’ll take it for granted – but you’ll be taking for granted an all new world of computing – one that allows you to get more done faster without ever needing to think about where you are.
Thomas W. Shinder MD
Microsoft ISDUA – UAG DirectAccess – Anywhere Access Team (AAT)
tomsh@microsoft.com