Troubleshooting Name Resolution Issues on DirectAccess Clients

When troubleshooting name resolution issues on a Windows client, NSlookup is an essential tool. However, it is important to understand that using NSlookup on a DirectAccess client might not always work as you expect. Although using NSlookup on a DirectAccess client will work normally when the client is on the corporate network, it will not provide the correct results to queries for internal hostnames when the DirectAccess client is outside of the corporate network without taking additional steps. This is because when a DirectAccess client is outside the corporate network, the Name Resolution Policy Table (NRPT) is enabled. The NRPT provides policy-based name resolution routing for DirectAccess clients, sending name resolution requests for certain namespaces to specific DNS servers. You can view the NRPT on a Windows 8.x DirectAccess client by issuing the following PowerShell command:

Get-DnsClientNrptPolicy

Troubleshooting Name Resolution Issues on DirectAccess Clients

You can view the NRPT on a Windows 7 DirectAccess client by issuing the following netsh command:

netsh namespace show policy

Troubleshooting Name Resolution Issues on DirectAccess Clients

Here you’ll notice that the namespace .lab.richardhicks.net is configured to use the DNS64 service running on the DirectAccess server at 2002:62bd:d898:3333::1. Notice also that the host nls.lab.richardhicks.net is not configured to use a DNS server. This effectively exempts this host from the NRPT, forcing name resolution requests for this Fully-Qualified Domain Name (FQDN) to be delivered to the DNS servers configured on the network adapter.

A Working Example

With the NRPT enabled, which occurs whenever the DirectAccess client is outside of the corporate network, a name resolution request for app1.lab.richardhicks.net would be sent to the DNS64 service on the DirectAccess server. A name resolution request for technet.microsoft.com would be sent to the DNS servers assigned to the network adapter because the NRPT contains no entry for this namespace. And even though the host nls.lab.richardhicks.net is a part of the internal namespace, a name resolution request for this host would also be sent to the DNS servers assigned to the network adapter because it has been specifically exempted from the NRPT.

NSlookup

The NSlookup utility is unaware of the NRPT. Whenever you use NSlookup it will, by default, automatically send queries directly to the DNS servers configured on the network adapter, regardless of the NRPT. If you wish to use NSlookup to test name resolution for external hostnames, use it as you normally would. However, if you wish to use NSlookup to resolve internal hostnames over the DirectAccess connection, you will need to tell NSlookup to use the DNS64 service running on the DirectAccess server. You can do this by running NSlookup interactively and using the server command to point it to the IPv6 address of the DNS64 service, which you can find in the NRPT.

Troubleshooting Name Resolution Issues on DirectAccess Clients

This also applies to the PowerShell cmdlet Resolve-DNSname. Here you’ll use the -Server switch to specify the DNS64 server’s IPv6 address.

Resolve-DNSName –Server <DNS64_IPv6_Address> app1.lab.richardhicks.net

Troubleshooting Name Resolution Issues on DirectAccess Clients

How to Install and Configure KB2862152 for DirectAccess

Microsoft recently released security advisory 2862152 to address a vulnerability in IPsec that could allow DirectAccess security feature bypass. The associated update addresses an issue with how the DirectAccess client authenticates with a DirectAccess server. Without the update, it is possible for an attacker to launch a man-in-the-middle attack to intercept DirectAccess communication.

The update itself does not resolve the issue directly, however. The update simply allows administrators to configure DirectAccess clients using specific registry settings to enforce more stringent checks during IPsec negotiation after the update is installed. The challenge with this update is that the documentation contained within the knowledge base article is extremely detailed and includes information that pertains to many different remote access scenarios, not just DirectAccess. This has led to much confusion, and many administrators are unclear for which clients and deployment scenarios the registry changes are required.

For DirectAccess deployments, the update needs to be applied to all of your DirectAccess clients. The update does NOT need to be applied to the DirectAccess server. The registry settings required on the client will be dictated based on the configured authentication method for your DirectAccess deployment. If you have configured DirectAccess to use certificate-based authentication by checking selecting the Use computer certificates option as shown below, you’ll only need to make registry settings changes on your Windows 7 clients. Windows 8/8.1 clients DO NOT require any changes be made to the registry when DirectAccess is configured to use certificate-based authentication.

Microsoft Security Update KB2862152 for DirectAccess

If you are NOT using computer certificates for authentication, then you must make registry changes to all of your Windows 8/8.1 clients. For detailed, prescriptive guidance on implementing the client-side registry changes required to support this update and mitigate this vulnerability, Jason Jones has done a wonderful job documenting those steps specifically, so I’ll refer you to his post here.

You can find the update for KB2862152 for all supported clients here.

Forefront UAG Service Pack 4 Now Available for Download

Good news! Service Pack 4 (SP4) for Forefront Unified Access Gateway (UAG) 2010 is now available for download. This latest service pack for UAG includes updates to support Windows 8.1 client devices using Internet Explorer 11, the native mail app, and Remote Desktop Connection (RDC) 8.1 client. In addition, SP4 for Forefront UAG 2010 also includes support for publishing RemoteApps from a Remote Desktop Session Host running on Windows Server 2012 or 2012 R2. The service pack also includes fixes for various reported issues.

KB2907776 – The UserMgrCom service crashes intermittently in Forefront UAG 2010

KB2909151 – Trunk authentication fails when the global catalog server is unavailable in Forefront UAG 2010

KB2909168 – The W3wp.exe process randomly stops and causes all sessions to disconnect in Forefront UAG 2010

KB2909182 – “The URL contains an invalid path” error occurs when you try to access an Exchange 2013 OWA website

KB2909191 – You cannot connect to corporate IPv4 resources by using DirectAccess after Forefront UAG 2010 Service Pack 3 is installed

KB2909350 – An SSL VPN application that has the Socket Forwarding mode set to Disabled uses 100 percent of the CPU’s time in Forefront UAG 2010

KB2909353 – You have to authenticate again to the ADFS server when the published server is configured for single sign-on in Forefront UAG 2010

KB2909356 – A detailed HTTP 403.14 error message occurs when you go to a specific InternalSite URL in a Forefront UAG 2010 environment

KB2909365 – A memory leak in W3wp.exe occurs when Outlook Anywhere is published through a Forefront UAG 2010 trunk

KB2909367 – Intermittent HTTP 500 error codes when you access a Forefront UAG 2010 portal

KB2909376 – File uploads do not occur to SharePoint Server 2013 or SkyDrive Pro through Forefront UAG 2010

KB2910407 – An internal 500 error occurs if a custom URL logoff page is configured in Forefront UAG 2010

KB2910413 – Multiple 4625 event IDs are logged when a user logs on in Forefront UAG 2010

KB2910467 – Configuration activation fails on some servers in a large array in Forefront UAG 2010

KB2910498 – A handle leak occurs in Lsass.exe in Forefront UAG 2010

KB2910506 – An authentication prompt is received even though a user is successfully authenticated in Forefront UAG 2010

KB2910517 – An incorrect domain password policy may be used if Active Directory integrated authentication is configured in Forefront UAG 2010

You must have Forefront UAG 2010 SP3 hotfix rollup 1 installed prior to installing SP4. You can download SP3 rollup 1 here. You can download Forefront UAG 2010 SP4 here. Once the update is installed the new Forefront UAG 2010 build number will be 4.0.4083.10000.