다음을 통해 공유

Direct Access Test Lab Troubleshooting Scenario: DA client cannot detect the intranet due to incorrect DNS record

  • 아티클

Introduction

This troubleshooting scenario is for the DirectAccess test lab for Windows Server 2008 R2. For information about test lab troubleshooting scenarios, click here.

When connecting to any network, a DirectAccess client attempts to access its network location server, a Web server that is only available on the intranet. If a DirectAccess client cannot successfully access the network location server when connected to its intranet, depending on its configuration, it cannot resolve intranet DNS names.

In this troubleshooting scenario, you configure the DNS Host (A) record for the network location server name (nls.corp.contoso.com) to use the wrong IP address, and then troubleshoot the results.

Steps to configure Direct Access Test lab

Follow these steps to configure the DirectAccess test lab for this troubleshooting scenario. 

To configure the A record for the network location server to use the wrong IP address

  1. On DC1, click Start, point to Administrative Tools, and then click DNS.
  2.  In the console tree, open Forward Lookup Zones\corp.contoso.com.
  3.  In the details pane, double-click the nls record.
  4.  In nls Properties, change the IP address to 10.0.0.1, and then click OK.
  5.  Connect CLIENT1 to the Corpnet subnet.
  6.  On CLIENT1, from a Command Prompt window, run the ping app1 command. This command should display the Ping request could not find host app1 message.
  7.  From the Command Prompt window, run the ipconfig command. Notice that there are no global IPv6 addresses assigned. CLIENT1 cannot resolve the name ISATAP to reach the intranet ISATAP server and configure the Tunnel adapter isatap.corp.contoso.com interface.

From the previous procedure, it appears that DC1, the intranet DNS server, is not resolving intranet names for CLIENT1 even when it is directly attached to the intranet. The following procedure uses the appropriate steps in DirectAccess Client Determines that it is on the Internet When on the Intranet to determine the root cause of the problem.

To troubleshoot this scenario

  1.  On CLIENT1, from the Command Prompt window, run the netsh namespace show effective command. If intranet detection was successful you would not see the two NRPT rules. However, because intranet detection was not successful, you should see the two NRPT rules.
  2.  From the Command Prompt window, run the reg query HKLM\software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\CorporateConnectivity /v DomainLocationDeterminationUrl command. This command displays the network location URL.
  3.  From the display of the netsh namespace show effective command in step 1, verify that the FQDN in the network location URL appears as an exemption rule in the NRPT (nls.corp.contoso.com).
  4.  From the Command Prompt window, ping the FQDN in the network location URL (nls.corp.contoso.com). This command should be successful.
  5.  Open Internet Explorer, type the network location URL in the address bar, and press ENTER. You should see a “There is a problem with this website’s security certificate.” message. This indicates that CLIENT1 could not perform a successful validation of the SSL certificate used by the application server for HTTPS-based URLs.
  6.  On APP1, run the Internet Information Services (IIS) Manager snap-in.
  7.  In the console tree, open APP1\Sites, and then click NLS.
  8.  In Actions, click Bindings.
  9.  In Site Bindings, click https, and then click Edit.
  10.  In Edit Site Binding, in SSL certificate, notice the name of the selected certificate.
  11.  Click View, click the Details tab, and then click the Subject field. Notice that the Subject field FQDN (nls.corp.contoso.com) matches the FQDN from the network location URL (nls.corp.contoso.com).
  12.  On DC1, from a Command Prompt window, ping app1.corp.contoso.com. Note that the IP address for the name app1.corp.contoso.com (10.0.0.3) is different from the IP address for nls.corp.contoso.com (10.0.0.1, from step 4). Because APP1 is the network location server, the resolved IP address for both of these FQDNs should be 10.0.0.3, the IP address of APP1.

This is the root cause of the problem. Because nls.corp.contoso.com is resolving to the IP address of EDGE1 (rather than APP1), CLIENT1 is attempting to access the default web page of EDGE1 for network location detection. For SSL-based Web connections, the FQDN in the Subject field of the certificate offered by the web server must match the FQDN of the URL that is being used to access the Web site. Because IIS on EDGE1 is configured to offer the IP-HTTPS certificate with the Subject name of edge1.contoso.com, network location detection fails and CLIENT1 determines that it is connected to the Internet, rather than the intranet.

Steps to correct the configuration

Follow these steps to correct the configuration of the DirectAccess test lab for this troubleshooting scenario.

To configure the A records for the network location server use the correct IP address

  1.  On DC1, click Start, point to Administrative Tools, and then click DNS.
  2.  In the console tree, open Forward Lookup Zones\corp.contoso.com.
  3.  In the details pane, double-click the nls record.
  4. In nls Properties, change the IP address to 10.0.0.3, and then click OK.
  5.  Disconnect CLIENT1 from the intranet subnet, wait 30 seconds, and then reconnect it to the intranet subnet.
  6.  From the Command Prompt window, run the ping app1 command. This command should be successful.
  7.   From the Command Prompt window, run the ipconfig command. Notice that there is now a global IPv6 address assigned to the Tunnel adapter isatap.corp.contoso.com that begins with 2002:836b:2.