When a DirectAccess (DA) client connects to the DA server over the Internet, the client establishes two tunnels:

  • Infrastructure Tunnel. The infrastructure tunnel is used to obtain core network services required to log into the domain and option configuration information, such as authentication services, Group Policy objects, and connectivity to management servers, such as System Center Configuration Servers. This tunnel is established before the user logs on. Authentication consists of computer certificate authentication and NTLMv2 authentication using the machine's domain computer account
  • Intranet Tunnel. This tunnel is established after the user logs on to the computer. This tunnel allows the user access to all authorized resources on the intranet. The tunnel is similar to a network connection made directly to the intranet when connected directly to corporate wired or wireless network. It is unlike a VPN connection because most VPN gateways can perform some level of access control at the VPN gateway. The DA server acts as an IPv6 router only and does not perform any access control or protocol validation for communications moving through the DA server. The second tunnel is established using a combination of computer certificate authentication and Kerberos authentication based on the user account.

Users often find that they are able to ping resources on the intranet after logging onto the computer but are unable to connect to any resources using other protocols such as HTTP or SMB. If you find this to be the case, it could be that you have not successfully established your intranet tunnel. One way to determine this is to look at the results of main mode negotiations. In the figure below (when the wiki supports copy/paste like Windows Live Workspaces I'll paste the image) you see that the second authentication method includes both NTLMv2 and Kerberos. NTLMv2 is used to authentication the infrastructure tunnel, and Kerberos is used to authenticate the intranet tunnel. If you see Kerberos missing, that means you are unable to authenticate using Kerberos.

Symptoms of such a failure include:

  • Being able to ping both management and non-management servers
  • Being able to use other protocols such as HTTP and SMB to management server
  • Not being able to use other protocols such as HTTP and SMB to non-management servers

If you find that you are unable to establish the second tunnel, you know that there is most likely a problem with Kerberos authentication, and you would start troubleshooting with the knowledge.

For troubleshooting information for DA client connections, please see:

http://technet.microsoft.com/en-us/library/ee624058(WS.10).aspx

HTH,

Tom

Microsoft ISDUA
UAG DirectAccess
Anywhere Access Team
tomsh@microsoft.com