A customer presented the DirectAccess team with an interesting problem that brought together many pieces of how a DirectAccess works, and how things might not work in certain circumstances. Because the problem was an interesting one, and because it highlights how some features of DirectAccess work, we thought it might be a good idea to share our experiences.
The customer was using a UAG DirectAccess solution that included only the “manage out” capabilities. By “manage out” I mean that they’re currently only interested in the ability to manage the DirectAccess clients, regardless of where those DirectAccess clients are located. At this time they aren’t allowing their users to connect to the corpnet using what we call the “intranet tunnel”. While this isn’t a solution we’ve documented, it is possible to configure things to support a “manage out only” solution. For more information on the manage out (always managed) option, please see Deep dive into UAG DirectAccess (Tweaking the GPOs) at http://blogs.technet.com/edgeaccessblog/archive/2010/02/18/deep-dive-into-uag-directaccess-tweaking-the-gpos.aspx
There were no problems with remote management of the DirectAccess clients and in fact they found this ability to keep remote clients in the same security state as on-network clients a fantastic advantage. In addition, they found that their “manage out only” solution enabled users to change this passwords using the same methods that on-network clients use – CTRL-ALT-DEL and click “Change Password”. If you’ve had to deal with password changes using a VPN or other solution, you’ll quickly appreciate just how nice it is that the users can change their passwords in the same why they always do, without having to fire up a VPN connection.
Prior to deploying DirectAccess, external Outlook users used RPC/HTTPS (Outlook Anywhere) to connect to Exchange when they were outside the internal network. When the users were on the internal network, they connected over MAPI/RPC. When the users connected from an external location using RPC/HTTPS, Outlook would ask the users for user name and password, but when on the internal network, Outlook did not ask. This is typical behavior and the solution was working well for them.
The problem seemed to come after they deployed DirectAccess. For some reason, Outlook users were being asked for their passwords when they were on the internal network. This wasn’t normal behavior for Outlook and led the customer to ask if the Outlook problem might be related to DirectAccess.
During the information gathering process it was discovered that:
The answer to that question came quickly. The reason why the internal network users were being asked for passwords was that the Outlook client was no longer using MAPI/RPC to connect to the Exchange Server; it was using RPC/HTTPS.
What didn’t make sense about this is that the Outlook clients were configured to RPC/HTTPS if a slow link is detected. That is to say, the option On slow networks, connect using HTTP first, then connect using TCP/IP (figure 1) is selected. For some reason, the Outlook client detected that it was on a slow network.
Figure 1
At this point you might wonder why the RPC/HTTPS (Outlook Anywhere) connection was being established, even if the a slow link was detected, since in most cases, the name of the publicly accessible proxy used to publish RPC/HTTPS wouldn’t be available to hosts on the internal network. As it turns out, the name was resolvable to both internal and external clients and a path was available for the internal Outlook clients so that they could loop out through the Internet and back into the internal network to access Exchange. Not very efficient, but it did explain why the Outlook clients didn’t try to use MAPI/RPC.
But the team still couldn’t figure out why Outlook determined that there was a slow link between itself and the Exchange Server. There was no significant network congestion, so a fast link should have been detected and MAPI/RPC should have been used.
This got the team wondering if the DirectAccess client assumed it was on the Internet. That didn’t seem to be the case. When they ran
netsh namespace show effectivepolicy
it indicated that the DirectAccess client was on the internal network and that the Name Resolution Policy Table (NRPT) wasn’t being used to resolve names. The fact that clients appeared to have normal corporate connectivity (with the exception of the Outlook issue) confirmed that the DirectAccess clients didn’t think they were on the Internet.
However, the team did notice that the IP-HTTPS adapter on the DirectAccess clients was still active. That shouldn’t have been the case since DirectAccess clients use Corporate Connectivity detection to determine when to enable the IP-HTTPS adapter, and corporate connectivity should be successful.
The status of the IP-HTTPS adapter is a function of:
The IP-HTTPS adapter on the DirectAccess client initializes (also known as entering the Enabled state) if any of the following conditions are met:
Corporate Connectivity detection is a little more complex. There are two possible states for Corporate Connectivity:
The DirectAccess client uses active and passive analyses to determine Corporate Connectivity.
There are two methods used for active probing:
There are also two methods used for the passive probing:
As you can see, passive reachability monitoring is performed continuously in the background. Also note that active probing takes place only after path reachability monitoring indicates Corporate Connectivity failure.
The Corporate DNS Probe Host Name is configured automatically by the UAG DirectAccess wizard and registered in DNS. This is registered in DNS as a quad-A (AAAA) record with the host name UAGDirectAccess-corpConnectivityHost and the IPv6 address ::1 (which is the local host address in IPv6). Note that the DirectAccess client only needs to resolve the name, not connect to the address mapping to the name, hence the reason why we use the local host address.
The UAG DirectAccess Wizard does not configure a URL for the Web probe active probe.
Whether or not the IP-HTTPS adapter is enabled depends on IP-HTTPS adapter initialization and the results of Corporate Connectivity detection:
To understand how Corporate Connectivity for the DirectAccess client works, it helps to think about the adapters used by the DirectAccess client to connect to the DirectAccess server:
What happens if the DirectAccess client tries to use 6to4 or Teredo to perform Corporate Connectivity detection? If the client is able to connect using either the 6to4 or Teredo adapter, and confirm Corporate Connectivity, the IP-HTTPS adapter is deactivated.
What happens if the DirectAccess client fails to confirm Corporate Connectivity using either the 6to4 or Teredo adapter? Then the IP-HTTPS adapter remains activated.
Note that IP-HTTPS activation may take place before Corporate Connectivity detection is complete. That explains why you will sometimes see both 6to4 and IP-HTTPS or Teredo and IP-HTTPS activated at the same time.
Let’s summarize what we know so far:
Now it’s clear why the IP-HTTPS adapter was still active – the customer was running an IPv4 only network. In order to deactivate the IP-HTTPS adapter, we need to confirm Corporate Connectivity and have an adapter other than the IP-HTTPS adapter assigned an IPv6 address.
Now that the team solved the IP-HTTPS problem, the next step was to determine if there was a relationship between the active IP-HTTPS adapter and Outlook’s slow link detection. Maybe the DirectAccess client on the internal network was using the DirectAccess IPsec infrastructure tunnel to connect to the DirectAccess server and “loop back” into the corpnet over the DirectAccess IPsec infrastructure tunnel connection – maybe that’s why there was a slow link detected?
This turned out to not be the case because in order to establish the DirectAccess IPsec infrastructure tunnel from the DirectAccess client on the corpnet and the external interface of the DirectAccess server, you would need:
The second and third bullet points made it clear to the team that there was no traffic moving over a DirectAccess IPsec tunnel. The reason for this is that in order to establish the IPsec tunnels to the DirectAccess server, the DirectAccess client needs to enable either the Public or Private Profile in Windows Firewall with Advanced Security. When the Domain Profile is enabled, the firewall rules and Connection Security Rules required to establish the DirectAccess connection aren’t available – hence, even though the DirectAccess client could potentially connect to the IP-HTTPS listener on the DirectAccess server because there was an existing path, the IPsec tunnels could not be created – with the result that no data could move through the IP-HTTPS adapter.
The team confirmed that the Domain Profile was enabled on the DirectAccess clients on the internal network, which is consistent with the fact that the clients were able to connect to the Network Location Server and a domain controller. The reason why I say that this is consistent with being able to connect to the Network Location Server and a Domain Controller, is that these are these are the two requirements for activating the Domain Profile.
So, what was causing the slow link detection and causing the Outlook clients to use RPC/HTTPS instead of MAPI/RPC? From further investigations, it turned out that the IP-HTTPS adapter was reporting a link speed of around 100Kbps, slow enough for Outlook to decide that there is a slow link. At this point in time, we don’t have an answer for why Outlook decided to use this link speed value instead of the value provided by the NIC.
Let’s finish up with a summary of the technical issues that were encountered:
There were a few reasons why we decided to share these experiences with troubleshooting the Outlook problem this customer encountered after deploying DirectAccess. The problem was solved by changing their DNS configuration so that internal network clients were not able to resolve the name of the RPC/HTTPS proxy –which made the initially observed problem with users needing to enter credentials go away. However, we still haven’t figured out why Outlook was using the link speed reported by the IP-HTTPS adapter, so that’s not the reason why I wanted to tell this story.
Instead, in the process of trying to solve this problem, the team ended up with a better understanding how the IP-HTTPS adapter works, and how it’s treated as the “IPv6 adapter of last resort” for DirectAccess clients. It also helped the team understand the importance of Corporate Connectivity detection, how the IPv6 transition technology interfaces are activated and deactivated, as well as the importance of Network Location Awareness and how that controls the Profile used by Windows Firewall with Advanced Security.
While all the lessons learned were good and valuable, this scenario called out a potential issue we might have with IPv4 only networks. Since we now know that DirectAccess clients on IPv4 only networks will not disable their IP-HTTPS adapter, the result is always going to be that the IP-HTTPS adapter is always be enabled on machines configured as DirectAccess clients on these IPv4 only networks.
What are the implications of having the IP-HTTPS adapter always enabled? It depends on how the network is configured. The team saw with the customer discussed in this article that the result was no traffic could flow out the IP-HTTPS adapter because Network Location Awareness determined that the DirectAccess client was on the corporate network because connectivity to the Network Location Server and a domain controller could be established. Therefore, the Domain Profile was enabled in Windows Firewall with Advanced Security and no IPsec DirectAccess tunnels could be established.
But what if we had the following scenario:
While it appears that it would take an unholy confluence of events to enable the DirectAccess client on the internal network to actually loop back through the UAG DirectAccess server to reach internal network resources, it’s likely that you’ve seen similarly unlikely events take place in the past.
This brings up the question as to whether or not you should enable this kind of scenario on purpose. For example, it’s possible that your Network Location Servers might become unavailable at some point in time, even if you have configured them to be highly available. If you enable the scenario described above, your computers configured as DirectAccess clients will still be able to connect to internal network resources, even though it will be through a very inefficient link. If you don’t enable the above scenario, then the DirectAccess client will not be able to establish DirectAccess tunnels to the UAG DirectAccess server, the NRPT will still be active, and the DNS queries sent to the UAG DirectAccess server’s DNS proxy will fail. The end result is that the DirectAccess clients will not have network connectivity if they need to access a resource by name.
The answer to that question is based on what scenario you prefer. Would it be better to bring your Internet connection to its knees for the period of time it takes to get the Network Location Servers up again? Or would it be better to “brick” your DirectAccess client computers until you can get the Network Location Servers going again?
To help you plan for such an eventuality, you can use the blog post When Good Network Location Servers Go Bad – Preparing Against NLS Failure at http://blogs.technet.com/tomshinder/archive/2010/04/06/when-good-network-location-servers-go-bad-preparing-against-nls-failure.aspx
Deep dive into UAG DirectAccess (Tweaking the GPOs) http://blogs.technet.com/edgeaccessblog/archive/2010/02/18/deep-dive-into-uag-directaccess-tweaking-the-gpos.aspx
When Good Network Location Servers Go Bad – Preparing Against NLS Failure
http://blogs.technet.com/tomshinder/archive/2010/04/06/when-good-network-location-servers-go-bad-preparing-against-nls-failure.aspx
Designing a DNS Infrastructure for Forefront UAG DirectAccess
http://technet.microsoft.com/en-us/library/ee428856.aspx
Designing Your Intranet for Corporate Connectivity Detection
http://technet.microsoft.com/en-us/library/ee809088.aspx
Network Location Awareness
http://technet.microsoft.com/en-us/library/cc753545(WS.10).aspx
This article was originally posted on the Unified Access Gateway Team Blog 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