Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Troubleshooting Networking Problems

Three specific network questions must be asked:

Does basic connectivity exist?

Is DNS working?

Can the client and the user authenticate to the domain? (If the computer and user cannot authenticate to the domain, then the policy will not be downloaded.)

It's probably most efficient to troubleshoot network problems by starting with the last issue first. If the client and user can authenticate to the domain, then basic networking and DNS are working. If the client or the user cannot authenticate to the domain, it may seem logical to test DNS. However, there are many DNS issues that can prevent logon and Group Policy operations. Before launching extensive DNS tests, perform basic connectivity tests. If these are not working, they need to be corrected first. If they work, then begin investigating DNS. Finally, don't ignore the rest of the world. It may be that some other recently conducted test has established that DNS is working correctly, or a user may provide helpful information. While many users are not network-literate, they may say something that provides enough information to indicate a more specific problem.

Troubleshoot Authentication

Another class of network-related problems occurs when the user is currently logged on to the domain. This can happen when cached credentials are used or when the user uses a local computer user account to log on. Cached credentials may be used when a DC cannot be located or when a VPN connection or some other remote connection is used.

When cached credentials are used, the last GPO policy stored locally on that computer will be applied. This may not be the current policy. If cached credentials usage is the result of LAN issues, troubleshoot and fix the LAN issues. If the user uses a VPN to connect to the network and does so after logging on to the computer, the latest GPOs will not be downloaded because the user is already authenticated. The VPN problem, however, can be rectified if the user will use the logon with the option to connect to a remote network from the initial logona choice presented when using Ctrl+Alt+Del.

To determine if cached credentials are being used, check the computer System log for event ID 5719, which states No Windows domain controller is available for domain_name. The following error occurred: There are currently no logon servers available to service the logon required. In some cases, a warning may also appear when the user logs on.

Troubleshoot Basic Network Connectivity

Basic TCP/IP troubleshooting and connectivity is covered extensively in networking tutorials and texts, and simple steps are listed in Knowledge Base articles. If the troubleshooting techniques for DNS return data, basic network connectivity can be assumed. Proper network configuration, however, may be an issue and is discussed within this chapter where relevant. Still, it's useful to remember that some estimate that 80% of all networking issues are a loose or disconnected cable. Before assuming a more complicated problem, check connections via observation of link lights on network ports, look for unplugged or damaged cables, and attempt to ping or pathping known routers, DCs, and other computers on the network. Pathping is a command available with Windows 2000, Windows XP, and Windows Server 2003. While the ping command can determine if packets are reaching the desired destination, pathping performs a trace route and additional tests. Pathping can identify the path to the destination and record packet loss and delays possibly due to network congestion.

In addition to basic network connectivity, the following items are necessary to support Group Policy infrastructure:

TCP/IP must be running on all member and domain controller computers.

ICMP is used to detect a slow link when the client first connects to the domain controller. If a firewall sits between the client and the domain controller, be aware that the firewall must allow ICMP if the connection is not tunneled.

For slow detection to work, a feature that will avoid attempts at downloading GPOs, firewalls, and routers must support the use of a 2048-byte packet because the slow link detection packet is of this length. Group Policy settings determine what happens when a slow link is detected.

Multihomed computers must have the high priority set for the network card that connects the client to the network from which GPOs are obtained.

Troubleshoot DNS

Many authentication issues and problems with replication and Active Directory can be traced back to problems with DNS. DNS must be working for these processes to work. This is why testing DNS before testing replication is a good choice. If DNS is broken, fix it, and many of these problems will go away. There are several ways to verify DNS configuration and functioning, including:

Check client computer configuration.

Use DNSLint.exe.

Use DCDiag.exe.

Use Portqry.exe.

Examine Event Viewer events.

Examine DNS records and make manual tests.

Most of these tools are provided in the support tools folder of the installation CD-ROM but are not installed by default. You can install them by inserting the installation CD-ROM and double-clicking on the support.msi file in the Support folder on the CD-ROM. DNSLint must be obtained via download from the Microsoft site.

Use caution when installing support tools. These tools can provide an attacker with much information and power over servers and your domains should he obtain the proper privileges to run them and find them loaded on the compromised server. While these tools are readily available for free download, an attacker would have to obtain them, install them, and then load them on the server (hopefully you've made that hard to do). While an attacker who has obtained the appropriate privileges will not have difficulty finding the tools and installing or using them, every extra step you burden the attacker with is one more reason that many of them will move on to easier targets. It may also provide you with the time to discover that you are under attack so that you can respond. Leaving excess tools lying about on every server is not a good security practice.

Check Client Computer Configuration

The most obvious problem is often the most frequently overlooked. Never assume that the client computer is correctly configured. A quick manual inspection of network properties may alert you to a necessary change. Use the ipconfig /all command or open the computer's network configuration, as shown in Figure 9-14.

Using DNSLint

The DNSLint tool can be used to determine if problems exist with DNS. DNSLint is a Windows Server 2003 support tool, but it can also be used with Windows 2000 DNS. (DNSLint can be downloaded by following the link in the Knowledge Base Artile 321045 "Description of the DNSLint Utility," http://support.microsoft.com/default.aspx?scid=kb;en-us;321045#kb1.) DNSLint can also report on issues with AD Replication.

DNSLint produces an HTML report or a text file that lists problems with DNS, such as:

Lame delegation
Lame delegation is the situation in which a DNS server delegates authority over a subdomain to another DNS server, but the server that the subdomain is delegated to cannot be reached or is not configured to be authoritative for that domain. It's analogous to the requirement that you obtain a badge from the security office, but when you get to the security office, it cannot issue that type of badge. If lame delegation exists within your environment, client systems will seek an authoritative DNS server for their domain but will never find one. Therefore, the client will not be able to locate a domain controller to authenticate to. Access to resources will be more difficult, if not impossible, and changes to security policy (GPOs) cannot be downloaded.

Missing CNAME or host (glue or A) records for domain controllers
Clients search for a domain controller in their site by finding the GUID for the domain, resolving the associated CNAME, and then obtaining an IP address from the associated glue record. The glue record is the DNS record that ties, or glues, the computer or host name with the IP address that is assigned to it. The CNAME record is a record that identifies a device but does not provide an IP address. It may provide another associated name for the host, in this case the GUID. If either the CNAME or glue record is missing, the client may not locate a DC to authenticate to.

Improperly configured TCP/IP
It is possible that the DNS location configured is not authoritative for the client's domain. In this case, the primary or alternative DNS server identified in the TCP/IP configuration of the computer is the wrong DNS server. When the computer boots, it cannot find the DNS server authoritative for its domain. If it cannot find this DNS server, it cannot determine the location of a DC in its domain. Without a DC, the computer and user cannot authenticate to the domain or download the latest security policy.

Missing Server Locator (SRV) records
_ldap, _kerberos, _gc, and _msdts SRV records must be available for domains and global catalog servers. If these SRV records are missing, authentication cannot occur.

If these problems exist, then clients cannot access domain controllers, and replication between domain controllers may also be affected. The impact of these problems depends on the number of domain controllers and the number of problems there are. DNSLint does not just identify these problems, but many times it will also offer a possible solution. Using DNSLint to produce a report is simple. In the following sections, techniques for obtaining help with DNS are explained. Help using DNSLint to discover Active Directory replication problems is in the later section "Active Directory Replication Problems."

Basic DNS Configuration Check

Obtaining useful information is quite simple. To produce a report, use the following command at the command line:

Dnslint /d domain-name

This command will check for lame delegation and related DNS problems. The domain-name stands for the name of the domain to be checked. The /s switch is used to specify the IP address; otherwise, DNSLint will use the Internet to do an Internic Whois. This command will attempt to find all DNS servers that are authoritative for the domain and test all of them. If your DNS domain is not registered, use the /s switch.

Entering the following command produced the report displayed in Figure 9-15:

Dnslint /d tailspintoys.com

In the figure, an Internic Whois generates a list of servers that are authoritative for the domain and some warning messages. The domains do not seem to have domain records on the servers, or that information may not be available.

To test the DNS server established for the local Chicago.local domain, the /s switch can be used, followed by the IP address of the local DNS server. Using the /s switch prevents DNSLint from doing an Internic whois. The following command is used and produces the report shown in Figure 9-16:

Dnslint /d Chicago.local /s 192.168.5.10

In both cases, the information that DNSLint attempts to report is as follows:

Is each DNS server responding?

What is the SOA data for zone?

Are there additional authoritative DNS servers?

What are the Host (A) records for name?

What are the Mail Exchange (MX) and glue records for name?

Are all records the same on every authoritative DNS server? (If not, intermittent name resolution problems may result.)

Is a summary of errors and warnings, including Non-authoritative, missing glue records, and unresponsive servers shown?

Additional Switches and Special Considerations

The DNSLint switch /ql:inputfile_path will allow you to verify user-defined sets of DNS records on multiple DNS servers. You identify the DNS servers in a text file and use the command dsnlint /ql:inputfile_path, where inputfile_path specifies the path and filename of a text file that lists the IP addresses of the DNS servers you want to test.

Additional switches are as follows:

/v
Reports additional information about the process while the report is begin generated.

/t
Enables the production of a text file in addition to an HTML report.

/r
Is used to specify the path of the report file.

/no_open
Prevents the default file, dnslint, from opening.

/c SMTP
Checks for SMTP server records and tests connections for Pop, SMTP, and NNTP.

/test_tcp
Checks if DNS responds on TCP port 53.

How does DNSLint work? By default, DNSLint uses a Whois command to check with the Internic to find the name of the authoritative DNS server for the domain and to obtain this DNS server's IP address. Next, it uses nslookup to query the returned IP address for a name and an MX record name server and attempts to discover other authoritative DNS servers for the domain. DNSLint queries these servers and compares records on all authoritative servers. The records should reflect the correct information, and all of them should be the same. If the information is incorrect, DNSLint will report it, and then it needs to be corrected. That step, however, DNSLint cannot do for you.

Use DCDIAG and NetDiag to Find DNS Problems

DCDiag is a multipurpose domain controller troubleshooting tool. NetDiag is used to troubleshoot client domain/DNS issues. Simply issuing the dcdiag.exe command on a domain controller will perform most of its diagnostic tests. Because they test DC-specific functions, many of which rely on proper DNS functioning, a pass on these tests can mean that there are no DNS issues. To run a specific test, enter the following:

Dcdiag /test:testname

Some DCDiag tests that are helpful in troubleshooting DNS include:

ForestDNSZones and DomainDNSzones, two tests that check for proper domain records.

Connectivity checks for basic network connectivity.

Figure 9-17 is a screen capture of part of a DCDiag report. DCDiag provides extensive information. If desired, you can redirect the results to a text file to make it easier to study.

The Knowledge Base article 265706, "DCDiag and NetDiag in Windows 2000 Facilitate Domain Join and DC Creation" (http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b265706) provides more in-depth information on DCDiag and NetDiag.

NetDiag is similar to DCDiag, but because it tests client-to-DC/DNS connectivity, it has fewer tests. Run NetDiag from the client. To see if a client can access a domain controller in its domain, use the following command:

NetDiag /d:domainname

To use NetDiag with specific tests, use the following command:

NetDiag /test:testname

An example test command and its results are displayed in Figure 9-18.

NetDiag /l /test:dsgetdc

The /l switch outputs data to the NetDiag log file. The dsgetdc test tests the network card, computer domain membership, and access to the DC. Useful tests for testing connectivity to domain controllers include the following:

DcList
The domain controller list test

DNS
DNS tests

DsGetDC
The domain controller discovery test

Kerberos
The Kerberos test

Use Portqry

Portqry.exe is a simple tool that can be used to determine if specific ports are listening on specific computers. To verify that DNS is listening on the DC1, enter the following command, as shown in Figure 9-19:

Portqry n regalinn.chicago.local p udp e 53

Manually Examine DNS Records Looking for Problems

Although it is a potentially more difficult and less desirable way to troubleshoot DNS problems, you can examine the DNS records manually. There are common problems that occur, and the experienced DNS administrator can spot them quickly without the use of diagnostic tools.

Use nslookup to Test DNS

Nslookup is used by DNSLint, but it may be used on its own to look for DNS issues. Nslookup can be used to locate DNS servers, check for specific records, and test name resolution. Two modes are possible. In interactive mode, if nslookup is entered without parameters, it can be used to examine many parameters. In noninteractive mode, nslookup with specific parameters can be used to find specific data and move on.

Entering nslookup at a command prompt will produce the name and IP address of the default name server (the one identified in the network TCP/IP configuration for the local computer). If entering the command does not produce this information, this is the first sign of a problem. After a successful return, a caret ">" prompt allows entry of other requests. A good check is to use the ls command to list specific types of records on the server. Use the /t switch to limit the record type. Entering ls t a Chicago.local will list the host records for the Chicago.local domain. If the command does not return the expected results, further examination should be done to determine and then fix the problem.

If the servers that can obtain a zone transfer from the DNS server are restricted, make sure to issue the ls command from one of the servers identified as allowed to request and receive a zone transfer. Ls works by doing a zone transfer. Allowing zone transfer by only a limited number of servers is a sound security practice. Information about the records in your DNS server should be restricted.

Examine Event Viewer Records

Check the DNS event log for DNS errors. Any DNS error can mean potential trouble for Group Policy because the error may mean interference with the logon process. Some of the errors that should be resolved are listed in Table 9-4, but this is not meant to be an exhaustive list. Two warnings are also frequently seen. Warning 2630 will be recorded when there are multiple namespaces as the result of a multihomed DNS server for which the DNS server has not been correctly configured. An interface on which DNS should listen must be established in the DNS properties. Warning 414 indicates that there is no DNS domain name for the host. This often is registered when a server is being dcpromoed and DNS is being installed at the same time. If the DNS name is not preconfigured before the dcpromo, the warning is recorded, but later the DNS name is configured and recorded for the host automatically. If this is the reason for the warning, then it can safely be ignored.