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.

Vulnerability in DirectAccess Could Allow Security Feature Bypass

With the November 2013 security bulletin release, Microsoft advises that DirectAccess includes a vulnerability that could allow security feature bypass. This update affects all supported versions of Microsoft Windows and addresses an issue with how the DirectAccess server authenticates connections with DirectAccess clients. The vulnerability could be leveraged by an attacker to pose as a man-in-the-middle and intercept their communication. For more details, please review Microsoft Security Advisory 2862152.

Configure Windows Server Core to use PowerShell by Default

Beginning with Windows Server 2012, the core installation mode is now the default and preferred installation mode. For workloads that are supported on Windows Server core, which includes the remote access role and DirectAccess, server core should be used to provide the highest levels of security and availability.

When installing Windows Server 2012/R2 core, the operating system defaults to using the old DOS command prompt. I find this particularly annoying since the majority of administration I do on a server core installation is in PowerShell. Also, most DOS commands can be run from the PowerShell console anyway, so why not have PowerShell as the default shell? Well, that’s easy enough to fix. To begin, at the command prompt enter start powershell.

DirectAccess Windows Server Core PowerShell

In the PowerShell window enter the following command:

Set-ItemProperty -Path ‘HKLM:SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon’ -Name Shell -Value PowerShell.exe

DirectAccess Windows Server Core PowerShell

Log off the computer and when you log back in, PowerShell will be the default shell! If you need to execute DOS commands that don’t seem to work in PowerShell, simply enter cmd and you’re good to go.

DirectAccess Windows Server Core PowerShell

DirectAccess Computer Certificate Auto-enrollment

DirectAccess requires computer certificates to be installed on the DirectAccess server and DirectAccess clients. These certificates are used for IPsec, which provides a secure, encrypted communication channel between the DirectAccess client and the DirectAccess server. IPsec ensures the necessary integrity, confidentiality, and non-repudiation required for secure remote access. When using a Public Key Infrastructure (PKI) to issue computer certificates to DirectAccess clients, it can be helpful to automate this process by configuring certificate auto-enrollment using Active Directory group policy.

To begin, open the Group Policy Management Console and expand Domains. Next, expand your domain, right-click Group Policy Objects and choose New. Enter a descriptive name for the new GPO and click Ok. Right-click the GPO you just created and choose Edit. Expand Computer Configuration, Windows Settings, Security Settings, and Public Key Policies. Highlight Public Key Policies, and then double-click Certificate Services Client – Auto-Enrollment. For the Configuration Model choose Enabled. It is recommended that you also choose to Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates.

DirectAccess Certificate Auto-enrollment

Close out of the Group Policy Editor and then link this computer certificate auto-enrollment GPO to your domain. Target only DirectAccess client and server security groups with this GPO instead of all domain computers by configuring Security Filtering to apply this GPO only to DirectAccess client and server machines.

DirectAccess Certificate Auto-enrollment

Finally, on your certificate server, right-click the DirectAccess certificate template, choose Properties, and then choose Security. Make certain the Enroll and Autoenroll permissions are set to Allow for all DirectAccess client and server security groups.

DirectAccess Certificate Auto-enrollment

 

Forefront UAG 2010 Video Training Course Now Available

I’m happy to announce that my latest Trainsignal video training course is now available! This new video training course is on Forefront Unified Access Gateway (UAG) 2010. It is an introductory course on Forefront UAG designed to teach network engineers and security administrators the basic essentials of planning, preparing, installing, configuring, monitoring, and maintain a Forefront UAG 2010 remote access solution. In the course I demonstrate how to publish popular Microsoft on-premises applications like SharePoint and Exchange Outlook Web App (OWA). In addition I cover publishing Remote Desktop Services and VPN remote access. I also provide a high level explanation of endpoint detection and endpoint policy enforcement and demonstrate how to provide high availability for the solution. Here is the entire course outline:

Lesson 1 – Introduction and Course Outline
Lesson 2 – Forefront UAG 2010 Overview
Lesson 3 – Planning to Deploy Forefront UAG 2010
Lesson 4 – Installing and Configuring Forefront UAG 2010
Lesson 5 – Configuring a Portal
Lesson 6 – Publishing Exchange Outlook Web App
Lesson 7 – Publishing SharePoint
Lesson 8 – Publishing Remote Desktop Services
Lesson 9 – Configuring VPN Remote Access
Lesson 10 – Enabling Endpoint Detection
Lesson 11 – Configuring High Availability
Lesson 12 – Web Monitor Overview
Lesson 13 – Forefront UAG Backups

Once again I had the opportunity to work with my good friend and fellow Microsoft MVP Jordan Krause on this course. As he did in my previous Trainsignal video training course on Windows Server 2012 DirectAccess, Jordan served as the technical reviewer and provided valuable insight that ultimately made the course better. If you’re planning to implement Forefront UAG 2010 to provide secure remote access to both managed and non-managed systems and devices, be sure to sign up for a subscription at Trainsignal.com today! Not only will you have access to this video training course on Forefront UAG 2010, you will gain access to the entire Trainsignal library of content, including my course on Windows Server 2012 DirectAccess, all for just $49.00 per month!

TrainSignal Windows Server 2012 DirectAcess Video Training Course

Forefront UAG 2010 DirectAccess Clients and Repeated OTP Prompts

In a very specific DirectAccess deployment scenario it is possible that users may be prompted repeatedly for One-Time Password (OTP) credentials. Specifically this may occur when you have Windows 7 clients accessing a Forefront UAG 2010 DirectAccess server with two-factor authentication enabled with OTP, along with forced tunneling required and the client configured to use a corporate web proxy server. The root cause of the issue has to do with Network Connectivity Status Indicator (NCSI) probes and security permissions on the private key of the certificate used for OTP authentication. To resolve the issue will require creating a custom certificate template for use with two-factor authentication and setting key permissions for the NETWORK SERVICE on the certificate template. You can also workaround this issue by disabling forced tunneling or disabling the 6to4 and Teredo adapters, which will stop the NCSI probes from occurring. For more detailed information read Microsoft KB article 2797301.

DirectAccess and NAT

One of the more common barriers to adoption for DirectAccess in Windows Server 2008 R2 and Forefront Unified Access Gateway (UAG) 2010 is the strict requirement for two consecutive public IPv4 addresses to be assigned to the external network interface of the DirectAccess server. Many small and mid-sized businesses have only a single public IPv4 address, or have a very small range of public IPv4 addresses that are already in use. For large organizations, corporate security policies often dictate that Windows-based systems cannot be internet facing, and many object to having a domain-joined Windows system exposed directly to the Internet. Further complicating matters is the fact that deploying a Window Server 2008 R2 or Forefront UAG 2010 DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is explicitly not supported.

Beginning with Windows Server 2012, deploying the DirectAccess server behind a border router or edge firewall performing NAT is now fully supported. No longer is there a requirement to have public IPv4 addresses assigned to the DirectAccess server’s external network interface. In fact, DirectAccess in Windows Server 2012 can be deployed with a single network adapter, allowing the DirectAccess server to be completely isolated in a perimeter or DMZ network.

Windows Server 2012 DirectAccess Network Topology

Be advised that deploying a Windows Server 2012 DirectAccess server behind a NAT device will result in all DirectAccess client communication being delivered to the server exclusively using the IP-HTTPS IPv6 transition protocol. If you are using Windows 8 clients, there’s nothing to worry about in terms of performance and scalability because Windows 8 clients leverage NULL encryption for IP-HTTPS traffic. However, Windows 7 clients cannot utilize NULL encryption and will instead encrypt all DirectAccess client communication using SSL/TLS. DirectAccess communication is already encrypted using IPsec, so this presents a problem. Double encryption places high demands on the DirectAccess server’s CPU and memory and will significantly impact performance on the client and the server. It will also impede the scalability of the solution by dramatically reducing the number of DirectAccess clients supported on a single DirectAccess server.

So, if you’re planning to deploy a Windows Server 2012 DirectAccess server behind a NAT, and you are also planning to support a lot of Windows 7 clients, please proceed cautiously. Monitor the DirectAccess server performance closely during your pilot and, if at all possible, offload SSL/TLS off box using F5 BIG-IP Local Traffic Manager (LTM) or equivalent device.

DirectAccess Clients and TPM

I’ve been frustrated recently with a number of articles and blog posts I’ve seen indicating Windows 8 DirectAccess clients connecting to a Windows Server 2012 DirectAccess server require a Trusted Platform Module (TPM) and the use of smart cards for authentication. This is a myth, and nothing could be further from the truth. TPM and smart cards are indeed supported (TPM with Windows 8, smart cards with Windows 7 and Windows 8 DirectAccess clients) but they are not explicitly required. For the posts I’ve seen I have asked the authors to correct their statements, and to their credit some of them have. Others, unfortunately, have not. I’m not sure if they are simply misinformed or if they are deliberately misleading their readers to downplay DirectAccess in an effort to sell another VPN solution. Regardless, I am compelled to set the record straight here. So, to be perfectly clear:

TPM is NOT a requirement for DirectAccess clients.

There you have it. Now go out and deploy DirectAccess today!

%d bloggers like this: