Jim Harrison recently pointed out to me that there’s a small problem with the UAG DirectAccess Test Lab Guide, which you can find over at http://technet.microsoft.com/en-us/library/ee861167.aspx If you haven’t seen the Test Lab Guide yet, or if you haven’t had a chance to run it, I highly recommend that you do. We recently updated it with new extensions that enable you to see how UAG specific scenarios such as “manage out”, array deployment, NLB configuration, and access to IPv4 only resources works.
However, back to the “small” problem. Part of the Test Lab Guide walks you through how to install and configure the Microsoft Certificate Server so that Certificate Revocation Checks won’t fail when the DirectAccess client tries to connect to the IP-HTTPS listener on the UAG DirectAccess server.
As I point out in the Test Lab Guide, this isn’t something that you would do in a production environment. If you use a commercial certificate for the IP-HTTPS listener, the certificate provider will make sure the CRL is reachable and highly available. If you create your own certificate for the IP-HTTPS listener, then you’ll have to publish your CRL and make sure it’s highly available – a lot of work for some people, not so much for others. The point is, you can do it either way.
If you go to http://technet.microsoft.com/en-us/library/ee861152.aspx#BKMK_O you’ll find that you’re in Section O – Remove CRL Distribution Settings on the Certificate Authority on DC1. In step 3, you’ll read the following:
“3. Click the Extensions tab. In Specify locations for which users can obtain a certificate revocation list, check all locations of the CRL Distribution Point (CDP) Authority Information Access (AIA), and verify that Publish CRLs to this location or Publish Delta CRLs to this location is not selected.”
The problem with these instructions is that they are incomplete and won’t prevent CRL check failure when the DirectAccess client is later configured to connect to the UAG DirectAccess server using its IP-HTTPS adapter. You’ll know that you’re running into this problem when you run the command
netsh interface httpstunnel show interface
you’ll see a Last Error Code of 0x80092013. You might also see an error code of 0x274c on the way to the the interface finally failing. The 0x80092013 code indicates that the CRL check failed.
In the figure below you can see the Properties dialog box for the Certificate Authority we use in the Test Lab Guide. The problem you’re encounter with the Test Lab Guide is related to the ldap:// URI. When you select that option from the Specify location from which users can obtain a certificate revocation list (CRL), you have to make sure that you deselect (uncheck) the option Include in the CDP extension of issued certificates. That step is not called out in the Test Lab Guide. I will add that as soon as I can, but until then, make sure you uncheck that option.
What if you already configured the Test Lab and everything worked except for the IP-HTTPS connection? What you can do is request a new certificate for the IP-HTTPS listener and run the UAG DirectAccess Wizard again so that the new certificate is bound to the IP-HTTPS listener. Here are the general steps
When you see it work, your output will look something like the figure below
HTH,
Tom
Tom Shinder tomsh@microsoft.com Microsoft ISD iX/SCD iX UAG Direct Access/Anywhere Access Team The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
In a recent blog post about an interesting problem we had with understanding Outlook performance issues and the IP-HTTPS adapter, we had the opportunity to review how the various IPv6 transition technology adapters worked in terms of when they were enabled and when they were disabled. If you haven’t seen that post, head on over to The Mystery of the IP-HTTPS Listener, an Outlook Client and an IPv4 Only Network at http://blogs.technet.com/edgeaccessblog/archive/2010/05/09/the-mystery-of-the-ip-https-listener-an-outlook-client-and-an-ipv4-only-network.aspx
One of the things that we got a better understanding of was Teredo adapter behavior. First, Teredo is an IPv6 transition technology that is used by DirectAccess clients when they are located behind a NAT device, and thus are typically assigned a private IP address (RPC 1918). Teredo encapsulates the IPv6 packets in an IPv4 packet with a UDP header. The UAG DirectAccess server listens for connections from Teredo clients on UDP port 3544. Therefore, if the DirectAccess Teredo client has outbound access to the UAG DA server’s UDP port 3544, the Teredo connection can be established.
However, before that Teredo connection can be established, the adapter needs to be configured. When you run the UAG DirectAccess Wizard, one of the many things it does it configure a DirectAccess clients Group Policy Object (GPO). The DA Clients GPO (The actual name of the GPO is UAG DirectAccess: Client [GUID]) contains settings for the IPv6 transition technologies used by the UAG DirectAccess clients, and one of these is the Teredo client configuration.
If you go to the following path: Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies you will find Teredo GPO configuration options, as seen in the figure below.
Figure 1
There are two settings that are of the most interest to us. The first one is the Teredo Default Qualified setting, as seen in the figure below. The UAG DirectAccess Wizard leaves this setting at its default. As you can see in the description, “qualified” means that the Teredo interface is ready to communicate. The default setting is Enabled State, which means that the Teredo adapter will go through the process of trying to connect to the UAG DirectAccess server to obtain information required to communicate. Qualification includes determining what type of NAT device the Teredo client is located behind.
Figure 2
The second setting of interest is the Teredo State setting. The UAG DirectAccess wizard leaves the Teredo State at its default setting. The default setting is to set the Teredo state as Client. With this state enabled, the Teredo adapter will come up only if the DirectAccess client is not on a network that has a domain controller on it. If the DirectAccess client detects that it’s on a network with a domain controller, it will disable the Teredo adapter, and the IP-HTTPS adapter will take over, assuming that the IP-HTTPS adapter can establish a connection with the UAG DirectAccess server’s IP-HTTPS listener.
Figure 3
Now the celebrity question is “how does the DirectAccess client determine is there is a domain controller on the network?” That’s a great question, and it’s not easy to find an answer to it. At least it wasn’t easy, until this article was published.
To determine if the DirectAccess client is on a “managed network”, the client performs a DNS query looking for SRV records in the path _ldap._tcp.dc._msdcs.DnsDomainName, where DnsDomainName is the name of the DNS suffix assigned to the current connection. If SRV records are located, the client assumes it is in a managed network, and Teredo is disabled. If no records are located, the Teredo interface is enabled.
What’s important to know here is that the detected domain can be any domain. It does not need to be the domain that the computer belongs to. Given this to be the case, a DirectAccess client that’s connected to a home network with a domain (a lot of us computer geeks have domains on our home networks) or to a customer’s network that has domain controllers on it, if a DNS query for that SRV record is successful, the Teredo adapter will disable itself when the “Client” state is enabled for the Teredo client. Another important thing to know is that the DA client doesn’t need to connect to the domain controller, it only needs to be able to resolve the name.
As you can imagine, this might cause some problems. For example, suppose you connect to your corporate network from your domain-based home network (that’s my situation – I work from home and connect to the Microsoft corpnet over DirectAccess). Because my corporate laptop is connected to a domain-based network, it will detect a domain, and disable the Teredo adapter. In this situation, my Teredo adapter will be disabled and I’ll be forced to use IP-HTTPS, which is a lower performance adapter. Most users would prefer a higher-performance solution (including me), so is there anything we can do about that?
Yes there is – but you’ll need to customize your Group Policy. In Figure 3 , notice that there is another option for setting the Teredo State – that option is Enterprise Client. When you set the Teredo State to Enterprise Client, the Teredo interface will always be present, even if the host is on a network that includes a domain controller. Now, the Teredo adapter will try to activate even when a domain (managed network) is detected.
MSIT decided to do this, as evidence by the figure below. Here you can see the output of the
netsh interface teredo show state
command. Notice that the State is set as qualified – which means that the adapter was able to determine what type of NAT device it was behind, which involves being about to connect to the UAG DirectAccess server. Also, notice the Network setting, which reports as managed. This combination shows that the Teredo adapter was able to connect to the UAG DirectAccess server, it detected a domain network, but remains activated and functional because the Type is set as enterpriseclient (Group Policy).
Figure 4
I need to point out before moving on that if you make these “hand edits” to the UAG DirectAccess Wizard GPO, that they will be overwritten the next time you use the UAG DirectAccess Wizard to update the DirectAccess Client GPO. So you’ll need to create a change control reminder that you need to manually set the Teredo State to Enterprise Client.
Now, while this is a good thing for those of us who want to connect from managed networks (successful domain detection), it does have the potential to cause problems. One example of this is when NLS (Network Location Server)failure takes place, NLA (Network Location Awareness) isn’t able to succeed at domain detection for setting Windows Firewall with Advanced Security (WFAS), with an end result being the WFAS Profile is set to Public or Private (which enables the DirectAccess Connection Security Rules), and the network firewall allows outbound access to UDP port 3544 to the IP address on the external interface of the UAG DirectAccess server. In this scenario (admittedly uncommon) the Teredo adapter will be enabled and intranet communications will take place through the UAG DirectAccess server.
However, given how common domain networks are, and how uncommon the combination of events noted above are, it makes sense to make the default Teredo State Enterprise Client.
Cannot Reach the DirectAccess Server with Teredo
http://technet.microsoft.com/en-us/library/ee844188(WS.10).aspx
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.
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.
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