Active Directory Diagnostics, Troubleshooting, and Recovery
Active Directory Diagnostics, Troubleshooting, and Recovery |
|
If you are having problems connecting to Active Directory and you have already successfully verified network connectivity, there might be a name resolution problem. If you cannot find other computers or network resources when you perform queries, this might mean that DNS domain names are not being resolved to IP addresses.
This section discusses diagnostic tools and gives examples of possible name resolution problems, along with suggested solutions. The first step toward identifying and diagnosing Active Directory name resolution problems is to review how a Windows 2000–based computer registers names and locates domain controllers.
To review, whenever you start up a Windows 2000 domain controller, it registers two types of names:
DNS records registered by domain controllers include multiple SRV records, A records, and CNAME records identifying the domain controllers' location in a specific domain and forest.
When a Windows 2000–based computer logs on to a domain, the computer does one of two things:
After the computer finds a domain controller, the information is cached so that a new query is not required for subsequent domain controller discoveries.
For more information about Domain Controller Locator and discovery, see "Name Resolution in Active Directory" in this book.
An answer to the following question can help you determine whether domain controller names are being resolved properly by DNS.
Can you look up names and addresses of network resources by using the Ping tool or the net use command?
Negative responses require further investigation. Begin by verifying your DNS configuration, followed by ensuring that DNS names are properly registered. Also, this section discusses a number of Resource Kit tools that can help you diagnose and repair name resolution problems.
A good practice following the installation of Active Directory is to verify that the DNS resource records for the domain controller are written to the DNS server. This is known as registration.
There are two specific types of registration; registration for the computer A and PTR records and registration for the domain controller SRV records, A records, and CNAME records in the DNS server. It is recommended you check both types of registrations.
Note
If DNS records are not registered in the DNS server, no other computer or user is able to locate the domain controller. If DNS records of a computer are not registered, you see DNS errors in the System log in Event Viewer.
To review, the Net Logon service registers records when the domain controller is restarted and when the Net Logon service starts. The Net Logon service sends DNS dynamic update queries for its SRV records, A records, and CNAME records every hour to ensure that the DNS server always has these records registered. As described in RFC 2136, dynamic update is a recent addition to the DNS standard. It defines a protocol for updating a DNS server with new or changed records dynamically.
All Windows 2000 domain controllers must use DNS as their locator service. Every Windows 2000–based domain controller dynamically registers service (SRV) records in DNS, which allow servers to be located by service type (in this example, LDAP) and protocols (for example, TCP and UDP). In addition to registering LDAP-specific SRV records, Net Logon also registers Kerberos v5 authentication protocol–specific SRV records to enable locating servers that run the Kerberos Key Distribution Center (KDC) service.
For Active Directory–integrated zones, the DNS server stores all the records in the zone in Active Directory. It is possible that a record is updated in Active Directory, but has not replicated to all DNS servers loading the zone. This might cause consistency problems. By default, all DNS servers that load zones from Active Directory, poll Active Directory at a set interval — typically every five minutes — and update the directory for any incremental changes to the zone. In most cases, a DNS update takes no more than 20 minutes to replicate to all DNS servers used in an Active Directory domain environment employing default replication settings and reliable high-speed links. Thus, it is vital to ensure the consistency of directory-integrated zone data. In Windows 2000, DNS consistency plays a similar to the role of WINS in Windows NT 4.0 as the source of logon and trust relationship issues.
The tools discussed in the following sections are useful for troubleshooting DNS problems.
The DNS Server log in the Event Viewer Administrative Tool console is one of the primary tools you can use to identify DNS name resolution problems. To view messages about the DNS server, you need to check the DNS Server folder. To view messages about the DNS client check the System Log folder. For more information about DNS, see "Windows 2000 DNS" in the TCP/IP Core Networking Guide.
Event Viewer logs errors with the Windows 2000 operating system and services such as the DNS service. If you are having problems with DNS, you can check Event Viewer for DNS-related events.
To open Event Viewer
To view messages about the DNS server, click DNS Server.
– Or –
To view messages about the DNS client, click System Log.
For more information about Event Viewer, see Windows 2000 Help.
On a client, if you see DNS event errors in the System log, that is an indication that your client has a problem dynamically updating DNS records. On a domain controller, if you see the Net Logon event error 5781, that usually is an indication that your domain controller has a problem dynamically updating DNS records for the domain controller. Specific methods for troubleshooting these errors are be discussed in this chapter.
You can use Nslookup to perform DNS queries and to examine the contents of zone files on local and remote servers.
To use Nslookup in interactive mode and to verify name resolution, at the command prompt, type the following:
NSLOOKUP
You might receive an error similar to the following:
DNS request timed out.
timeout was 2 seconds.
*** Can't find server name for address 172.16.0.0: Timed out
Default Server: UnKnown
Address: 172.16.0.0
The error " *** Can't find server name for address 172.16.0.0: Timed out" can be ignored. This error usually implies that there is no PTR record corresponding to the DNS server. Hence, if the Nslookup tool can't find a server name for the server's IP address, it uses Unknown as the server name but does not affect your queries.
For more information about the Nslookup tool and configuring a reverse lookup zone, see"Windows 2000 DNS" in the TCP/IP Core Networking Guide.
The Netdiag tool helps to isolate networking and connectivity problems by performing a series of tests. If you are unable to resolve a name, you might be experiencing DNS registration or consistency problems. To confirm this, answer the following questions:
When you run Netdiag, do you receive any DNS error messages? For example:
DNS test . . . . . . . . . . . . . : Failed
[FATAL]: The DNS registration for SERVER1 in reskit.com is incorrect on all DNS servers.
OR
DNS test . . . . . . . . . . . . . : Failed
.....................[FATAL] No DNS servers have our DNS records for this DC registered
If you receive this error refer to the methods used in this section to troubleshoot and resolve DNS registration failures.
Note
To verify the DNS registration for your domain, the best tool to use is netdiag /debug, which must be run on all domain controllers.
To refresh all DHCP leases and re-register DNS names for computers, use the ipconfig /registerdns command. To refresh and re-register DNS names for domain controllers, stop and start the Net Logon service. By default, the Net Logon service automatically re-registers DNS names every hour. For information about DHCP, see "Dynamic Host Configuration Protocol" in the TCP/IP Core Networking Guide.
Dnscmd.exe is a command-line tool that you can use to view the properties of DNS servers, zones, and resource records. To be able to check your DNS server configuration, use the Dnscmd tool or the DNS Manager console to obtain information about the DNS server and obtain statistics about its performance.
Dnscmd is also used to manually modify DNS server properties, to create and delete zones and resource records, and to force replication events between DNS server physical memory and DNS databases and data files.
For more information about Dnscmd.exe, see "Dnscmd.exe: DNS Server Troubleshooting Tool" in Windows 2000 Resource Kit Tools Help on the Resource Kit companion CD.
There are three main scenarios that you might encounter:
Because DNS locates network resources for Active Directory, you need to ensure that it is configured properly. For more information about DNS configuration, see "Name Resolution in Active Directory" in this book. However, begin by answering the following questions:
Before verifying the configuration of the DNS server and the existence of records, verify that your DNS client settings are correct.
To verify DNS client settings
You can use the command-line tool Ipconfig to view your DNS client settings, to view and reset cached information used locally for resolving DNS name queries, and to register the resource records for a dynamic update client. If you use Ipconfig with no parameters, it displays DNS information for each adapter, including the domain name and DNS servers used for that adapter. Table 10.1 shows some command-line options available with Ipconfig.
Table 10.1 Ipconfig Command-Line Options
| Command | Action |
|---|---|
| ipconfig /all | Displays additional information about DNS, including the FQDN and the DNS suffix search list. |
| ipconfig /flushdns | Flushes and resets the DNS resolver cache. |
| ipconfig /displaydns | Displays the contents of the DNS resolver cache. |
| ipconfig /registerdns | Refreshes all DHCP leases and registers any related DNS names. This option is available on Windows 2000–based computers unless the DHCP Client service is stopped. |
| ipconfig /release [adapter] | Releases all DHCP leases. |
| ipconfig /renew [adapter] | Refreshes all DHCP leases and dynamically updates DNS records. This option is available only on computer that are running the DHCP Client service. |
Note
In addition to flushing the cache by using Ipconfig, you can stop and flush the cache by stopping and starting the DNS Client service. For more information about flushing the cache, see "Windows 2000 DNS" in the TCP/IP Core Networking Guide.
After you confirmed that the client properly points to the primary and alternate DNS Servers, if the latter are not authoritative for the names to be resolved, confirm that they can recursively resolve the names that the client attempts to resolve. For more information on recursively resolving names, see Windows 2000 DNS" in the TCP/IP Core Networking Guide.
After you have verified that the client is properly configured and the preferred and alternate DNS servers are capable of the recursive name resolution, you need to verify that the DNS server contains the necessary records.
The following section discusses the list of resource records registered by the Net Logon service running on domain controllers.
Besides A and PTR records that are registered by any Windows 2000 computer, the domain controllers also register additional records that indicate their role. Every time that the Net Logon service starts (including restarting the domain controller) the service attempts to register some or all SRV resource records as shown in the following example.
The SRV resource records are registered by starting the Net Logon service, which enlists the records in the Netlogon.dns file under the
Note
To re-register the SRV resource records, at the command prompt, type net stop netlogon, and then type net start netlogon.
An example of a Netlogon.dns file:
reskit.com. 600 IN A 172.16.128.19
_ldap._tcp.reskit.com. 600 IN SRV 0 100 389 SERVER1.reskit.com.
_ldap._tcp.pdc._msdcs.reskit.com. 600 IN SRV 0 100 389 SERVER1.reskit.com.
_ldap._tcp.gc._msdcs.reskit.com. 600 IN SRV 0 100 3268 SERVER1.reskit.com.
_ldap._tcp.708b2ee5-a806-47c4-b6ee-0dbe0e496b36.domains._msdcs.reskit.com. 600 IN SRV 0 100 389 SERVER1.reskit.com.
gc._msdcs.reskit.com. 600 IN A 172.16.128.19
11992d81-2208-4ff5-8641-b9c6a644064a._msdcs.reskit.com. 600 IN CNAME SERVER1.reskit.com.
_kerberos._tcp.dc._msdcs.reskit.com. 600 IN SRV 0 100 88 SERVER1.reskit.com.
_ldap._tcp.dc._msdcs.reskit.com. 600 IN SRV 0 100 389 SERVER1.reskit.com.
_kerberos._tcp.reskit.com. 600 IN SRV 0 100 88 SERVER1.reskit.com.
_gc._tcp.reskit.com. 600 IN SRV 0 100 3268 SERVER1.reskit.com.
_kerberos._udp.reskit.com. 600 IN SRV 0 100 88 SERVER1.reskit.com.
_kpasswd._tcp.reskit.com. 600 IN SRV 0 100 464 SERVER1.reskit.com.
_kpasswd._udp.reskit.com. 600 IN SRV 0 100 464 SERVER1.reskit.com.
_ldap._tcp.Default-First-Site-Name._sites.reskit.com. 600 IN SRV 0 100 389 SERVER1.reskit.com.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.reskit.com. 600 IN SRV 0 100 3268 SERVER1.reskit.com.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.reskit.com. 600 IN SRV 0 100 88 SERVER1.reskit.com.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.reskit.com. 600 IN SRV 0 100 389 SERVER1.reskit.com.
_kerberos._tcp.Default-First-Site-Name._sites.reskit.com. 600 IN SRV 0 100 88 SERVER1.reskit.com.
_gc._tcp.Default-First-Site-Name._sites.reskit.com. 600 IN SRV 0 100 3268 SERVER1.reskit.com.
_ldap._tcp.dc._msdcs.<existing domain the domain controller is joining>
To join a tree this record is used:
_ldap._tcp.dc._msdcs.<parent domain of the newly created domain in the existing tree>
To join a forest, this record is used:
_ldap._tcp.dc._msdcs.<ForestRoot>
To confirm that appropriate records are registered in DNS, you can use the Nslookup tool or the DNS Management console.
The following example shows how to use an Nslookup query to verify that the generic records for the Reskit.com domain; _ldap._tcp.reskit.com exists in DNS:
C:\>nslookup
Default Server: dc1.reskit.com
Address: 10.0.0.14
> set type=SRV
> _ldap._tcp.reskit.com
Server: dc1.reskit.com
Address: 10.0.0.14
_ldap._tcp.reskit.com SRV service location:
priority = 0
weight = 0
port = 389
svr hostname = dc1.reskit.com
_ldap._tcp.reskit.com SRV service location:
priority = 0
weight = 0
port = 389
svr hostname = dc2.noam.reskit.com
dc1.reskit.com internet address = 10.0.0.14
dc2.reskit.com internet address = 10.0.0.15
Note
Remember that for the Domain Control Locator to be successful, the client must resolve not only domain controller names through target hosts in the SRV resource records, but also the A records corresponding to the target host names. Usually these A records are returned in the additional section in the DNS server's response. If these records are not returned, use the Nslookup tool to verify their existence in DNS.
From the nslookup command prompt, type the host name of the record stored on the DNS server.
Note
The host name that you type must be dot terminated.
Successful and unsuccessful query results might include the following:
> dc1.reskit.com.
Server: my_DNS_servername
Address: 172.16.0.0
Name: dc1.reskit.com
Addresses: 172.31.94.18
This means that DNS contains the A record and the server is responding back with the answer: 172.31.94.18. Next, you need to verify whether this IP address is the actual IP address for your computer, DC1. You can go to computer DC1 and type ipconfig to determine its real IP address, or you can use the Nbtstat tool and run the following command:
nbtstat -A 172.31.94.18.
The Nbstat tool is discussed in more detail later in this chapter.
If you detect that some of the records that must be registered are not registered, you need to troubleshoot your DNS record registrations.
If you have problems with DNS record registration, verify the configuration of the DNS client on the domain controller and configuration of the zone authoritative for the records to be registered.
Use the following steps to diagnose and troubleshoot your problem:
For more information about using the Netdiag tool, see "Network Connectivity" earlier in this chapter.
If all the preceding steps have been verified, the DNS server can receive dynamic updates from the clients, and then follow the troubleshooting steps in the following section.
If dynamic update does not register a resource record properly, use the following process to troubleshoot your problem.
Force the client that is experiencing registration failures to renew its registration by typing the following:
ipconfig /registerdns
Note
You should see at least one DNS server has the DNS entry registered correctly. Other DNS servers still might not have the DNS entry registered because of replication latency from one DNS server to another.
For more information about dynamic updates and secure dynamic updates, see "Windows 2000 DNS" in the TCP/IP Core Networking Guide.
The following suggestions will help you diagnose other problems you might have with DNS:
This is not necessary for dynamic update to work; however, if the client lists a preferred server other than the primary DNS server for the zone, many other problems could cause the failure, such as a network connectivity problem between the two servers or a prolonged recursive lookup for the primary server of the zone. To ascertain the preferred DNS server for the client, check the IP address configured in the TCP/IP properties for the client's network connection, or at the command prompt, type ipconfig /all. If the zone is directory-integrated, any DNS server that hosts a directory-integrated copy of the zone can process the updates.
If the zone is configured for secure dynamic update, the update can fail if zone or record security does not permit this client to make changes to the zone or record, or if the client does not have ownership of the name it is trying to update. To see whether the update failed for one of these reasons, check Event Viewer on the client.
For more information about secure dynamic updates, see "Windows 2000 DNS" in the TCP/IP Core Networking Guide
There are two ways to disable the DNS Caching Resolver:
Caution
Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your computer. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.
For more information about DNS, see "Windows 2000 DNS" in the TCP/IP Core Networking Guide
There might be cases when you question the validity of a returned IP address after you carry out the ipconfig command. For example, you would question an IP address if it was 0.0.0.0, which means that a DHCP server was unavailable and that you didn't assign a static IP address.
Unfortunately, if ping failed to reach a host, it doesn't provide a specific cause for the failure. It might be either name resolution (DNS or WINS) or connectivity problems. Even if Ping succeeds, there is no guarantee that DNS or WINS supplied you with the correct IP address. It is possible that another server is using the same address. For more information about WINS name resolution, see Windows 2000 Server Help.
There are several ways to determine name resolution paths:
For purging the DNS cache, type ipconfig /flushdns at the command prompt and for purging the WINS cache, type nbtstat -R. Then use the ping command to ping a name. For displaying the DNS cache , type ipconfig /displaydns and for displaying the WINS cache, type nbtstat -c.
A simple way to verify that you have the right IP address for a specific NetBIOS name is to use a tool that displays protocol statistics and TCP/IP connections using NBT (NetBIOS over TCP/IP). The tool is called Nbtstat and is mentioned in this section.
Note
Nbtstat arguments are case sensitive. For example, nbtstat -A lists the remote computer name table when given its IP address, and nbtstat -a lists the remote computer name table when given its name.
Following are examples of NetBIOS name resolution problems:
Another useful command is nbtstat -c. This command identifies the IP addresses that are in the NetBIOS/TCP remote cache table and displays the most recent NetBIOS names that were resolved.
To identify IP addresses that are in the NetBIOS/TCP remote cache table by using Nbtstat
nbtstat -c
The -c option lists NetBIOS/TCP's cache of remote computer names and their IP addresses.
Table 10.2 displays the most recent NetBIOS names that have been resolved:
Table 10.2 NetBIOS/TCP Remote Cache Names
| Name | Type | Host Address | Life (sec) |
|---|---|---|---|
| User2 | <20> UNIQUE | 172.31.228.117 | 60 |
| User2 | <00> UNIQUE | 172.31.226.28 | 120 |
| <20> UNIQUE | 172.31.64.42 | 600 | |
| RESKIT | <1C> GROUP | 172.31.128.9 | 480 |
Important
Table 10.2 shows what is in the NetBIOS/TCP remote name cache, not the DNS cache. If name resolution is through WINS then you should purge the cache.
To purge the NetBIOS/TCP remote name cache table by using Nbtstat
nbtstat -R
When validating an IP address for a NetBIOS name, the command you should use is nbtstat -A. This option lists the remote computer name table when given its IP address.
The following procedure assumes that you already ran ping for a domain called RESKIT and received its IP address of 172.16.80.200.)
To validate an IP address for a NetBIOS name by using Nbtstat
nbtstat -A <IP Address> (for example, 172.16.80.200)
The -A subcommand lists the remote computer's name table given its IP address. Table 10.3 lists the NetBIOS remote computer names.
Table 10.3 NetBIOS Remote Computer Names
| Name | Type | Status |
|---|---|---|
| SERVER1 | <00> UNIQUE | Registered |
| RESKIT | <00> GROUP | Registered |
| RESKIT | <1C> GROUP | Registered |
| SERVER1 | <20> UNIQUE | Registered |
| RESKIT | <1B> UNIQUE | Registered |
| RESKIT | <1E> GROUP | Registered |
| SERVER1 | <03> UNIQUE | Registered |
| RESKIT | <1D> UNIQUE | Registered |
| ____MSBROWSE___ | <01> GROUP | Registered |
| INet~Services | <1C> GROUP | Registered |
| IS~ SERVER1 | <00> UNIQUE | Registered |
The nbtstat -A command also resolves the MAC address from the IP address.
MAC Address = 08-00-2B-B9-FE-7C
Note the case of the switch; "-A" lists the remote computer's name table when given its name. As previously mentioned, Ping suggested that RESKIT is at the 172.16.80.200 IP address. Similarly, the Nbtstat -A command also- suggested that the IP address for RESKIT is 172.16.80.200.
Note
The command ping -a <IP address> also results in a call into NetBT to do an IP-to-name lookup similar to what nbtstat -A <IP address> does, except that only one name is printed out.
Table 10.3 provides a key for understanding the NetBIOS types mentioned in Table 10.4.
Table 10.4 Explanations of NetBIOS Types
| Name | Type | Usage |
|---|---|---|
| 00 | Unique | Workstation |
| 00 | Group | Domain |
| 01 | Unique | Messenger Service |
| 01 | Group | Master Browser |
| 03 | Unique | Logon Name/Computer Name /Messenger Service |
| 20 | Unique | Server |
| 2F | Group | Lotus Notes |
| 33 | Group | Lotus Notes |
| 1B | Unique | Domain Master Browser |
| 1C | Group | Domain Controllers |
| 1E | Group | Browser Service Elections |
Note
You can safely ignore the group names (typically domain or workgroup names).
Following are examples of NBT unsuccessful and successful query requests and responses. It is recommended that you monitor these requests and responses to identify name resolution problems by using NetBIOS over TCP/IP. Carry out an NBT query request by running the nbtstat -A <ipaddress> command from the command prompt.
The following is an example of a successful NBT Query request:
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xF421; Proto = UDP; Len: 78
+ UDP: Src Port: NETBIOS Name Service, (137); Dst Port: NETBIOS Name Service (137); Length = 58 (0x3A)
NBT: NS: Query req. for BOGUSNAME <00>
NBT: Transaction ID = 37902 (0x940E)
NBT: Flags Summary = 0x0100 - Req.; Query; Success
NBT: 0............... = Request
NBT: .0000........... = Query
NBT: .....0.......... = Non-authoritative Answer
NBT: ......0......... = Datagram not truncated
NBT: .......1........ = Recursion desired
NBT: ........0....... = Recursion not available
NBT: .........0...... = Reserved
NBT: ..........0..... = Reserved
NBT: ...........0.... = Not a broadcast packet
NBT: ............0000 = Success
NBT: Question Count = 1 (0x1)
NBT: Answer Count = 0 (0x0)
NBT: Name Service Count = 0 (0x0)
NBT: Additional Record Count = 0 (0x0)
NBT: Question Name = BOGUSNAME <00>
NBT: Question Type = General Name Service
NBT: Question Class = Internet Class
The following is an example of an unsuccessful NBT Query response from a Network Monitor sniffer trace:
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xCCFF; Proto = UDP; Len: 84
+ UDP: Src Port: NETBIOS Name Service, (137); Dst Port: NETBIOS Name Service (137); Length = 64 (0x40)
NBT: NS: Query (Node Status) resp. for BOGUSNAME <00>, Requested name doesn't exist
NBT: Transaction ID = 37902 (0x940E)
NBT: Flags Summary = 0x8583 - Resp.; Query; Requested name doesn't exist
NBT: 1............... = Response
NBT: .0000........... = Query
NBT: .....1.......... = Authoritative Answer
NBT: ......0......... = Datagram not truncated
NBT: .......1........ = Recursion desired
NBT: ........1....... = Recursion available
NBT: .........0...... = Reserved
NBT: ..........0..... = Reserved
NBT: ...........0.... = Not a broadcast packet
NBT: ............0011 = Requested name doesn't exist
NBT: Question Count = 0 (0x0)
NBT: Answer Count = 0 (0x0)
NBT: Name Service Count = 0 (0x0)
NBT: Additional Record Count = 0 (0x0)
NBT: Resource Record Name = BOGUSNAME <00>
NBT: Resource Record Type = Null
NBT: Resource Record Class = Internet Class
NBT: Time To Live(Seconds) = 0 (0x0)
NBT: RDATA Length = 0 (0x0)
For more information about NBT, see "Windows 2000 TCP/IP" in the TCP/IP Core Networking Guide.
Following are examples of possible name conflict scenarios received when running the Nbtstat tool.
The following are missing name errors along with suggestions on how to resolve them:
RPC errors generally mean that there is a problem with either networking or name resolution. The two most common causes are either the server is down, or that the name cannot be resolved.
Note
It is important to understand what name is being used for the specific RPC application. For example, Active Directory replication always refers to other domain controllers using the "guid-based name" of the domain controller. This name looks like the following:
<guid>._msdcs.<forest-root-dns-name>
It is recommended that you verify that this name is registered. If the target is a newly promoted domain controller, its name might not have been registered on all DNS servers. The Netdiag tool detects this when run on the target computer.
To determine whether there are name resolution problems, answer the following questions:
Generally, when you receive an "RPC Server not available" error message, this implies a name resolution or registration issue on the domain controller. Run the following Netdiag tool from the command prompt on both the domain controller and then on the client, as follows:
Netdiag /debug /fix
This might show some name conflicts or unregistered or unresolved names for the domain controller.
You can use the /l option to generate a log file. The Netdiag tool is in the Support Directory on the on the Windows 2000 Server operating system CD.
When you perform any of the following server-based tasks, you might receive an error that says the RPC server is unavailable:
The "RPC server unavailable" error can occur for any of the following reasons:
To resolve the "RPC server is unavailable" error
net start rpcss
On the Start menu, point to Programs and Accessories, and then click Command Prompt. At the command prompt, type the following:
ping <servername>
where <servername> is the server, and NetBIOS, DNS, or GUID is the name that you want to test for connectivity. If there is a connection issue with one of these computers, contact your network administrator to resolve the issue. If the error still occurs, continue to the next step.
After you have verified that the network and DNS service are working correctly, you need to identify whether the LDAP interface is working properly.
Note
The most important tool for diagnosing LDAP problems is the Ldp tool and the second most valuable tool is Network Monitor.
A number of tools are available to determine whether the LDAP service is available and whether it can send and receive queries.
Not all object properties stored in Active Directory are displayed by using the graphical tools that are included with the retail version of Windows 2000 Server. You can use Ldp to view these objects and their properties to assist in problem solving. Some object properties contain definitional data, called metadata, that provides information about other data that is managed within an application or environment. Ldp is valuable in that it allows you to see every object property in the directory service. You can also use Ldp to perform extended LDAP operations.
Note
ADSI Edit is better suited to viewing and modifying property values because it displays the objects in a hierarchical view and allows modifications through the object properties pages.
By using Ldp, you can perform the following LDAP functions:
For more information about using Ldp, ADSI Edit, and Repadmin, see Windows 2000 Support Tools Help.
The following sequence provides a logical pattern to diagnose and troubleshoot LDAP protocol issues. Begin by answering the following questions:
If you are having Directory access problems, the first place to check is the Directory Service log in Event Viewer. To identify directory access problems, search for NTDS LDAP error messages.
To connect to a domain controller and view rootDSE attributes by using Ldp
Port 389 is the default port for LDAP; port 3268 is the default port for the Active Directory Global Catalog.
The following is an example of a successful connection by using the Ldp tool:
d = ldap_open("SERVER1", 389);
Established connection to SERVER1.
Retrieving base DSA information...
Result <0>: (null)
Matched DNs:
Getting 1 entries:
>> Dn:
1> currentTime: 10/18/1999 2:45:52 Pacific Standard Time Pacific Daylight Time;
1> subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=reskit,DC=com;
1> dsServiceName: CN=NTDS Settings,CN=SERVER1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=reskit,DC=com;
3> namingContexts: CN=Schema,CN=Configuration,DC=reskit,DC=com; CN=Configuration,DC=reskit,DC=com; DC=reskit,DC=com;
1> defaultNamingContext: DC=reskit,DC=com;
1> schemaNamingContext: CN=Schema,CN=Configuration,DC=reskit,DC=com;
1> configurationNamingContext: CN=Configuration,DC=reskit,DC=com;
1> rootDomainNamingContext: DC=reskit,DC=com;
16> supportedControl: 1.2.840.113556.1.4.319; 1.2.840.113556.1.4.801; 1.2.840.113556.1.4.473; 1.2.840.113556.1.4.528; 1.2.840.113556.1.4.417; 1.2.840.113556.1.4.619; 1.2.840.113556.1.4.841; 1.2.840.113556.1.4.529; 1.2.840.113556.1.4.805; 1.2.840.113556.1.4.521; 1.2.840.113556.1.4.970; 1.2.840.113556.1.4.1338; 1.2.840.113556.1.4.474; 1.2.840.113556.1.4.1339; 1.2.840.113556.1.4.1340; 1.2.840.113556.1.4.1413;
2> supportedLDAPVersion: 3; 2;
11> supportedLDAPPolicies: InitRecvTimeout; MaxConnections; MaxConnIdleTime; MaxActiveQueries; MaxNotificationPerConn; MaxPageSize; MaxQueryDuration; MaxTempTableSize; MaxResultSetSize; MaxPoolThreads; MaxDatagramRecv;
1> highestCommittedUSN: 4696;
2> supportedSASLMechanisms: GSSAPI; GSS-SPNEGO;
1> dnsHostName: SERVER1.reskit.com;
1> ldapServiceName: reskit.com:SERVER1$@RESKIT.COM;
1> serverName: CN=SERVER1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=reskit,DC=com;
1> supportedCapabilities: 1.2.840.113556.1.4.800;
1> isSynchronized: TRUE;
1> isGlobalCatalogReady: TRUE;
-----------
If it fails with the DNS name, try using the IP address that the server reports that it is using, not the one that DNS reports for it.
If a connection can not be established, the next step is to capture a sniffer trace to determine whether the server is responding at all.
If LDAP connections cannot be established at all, the client computer might be registered on the IP-Deny list. The Ntdsutil tool can be used to check this.
It's not necessary to bind in order to check this. Use Ldp to establish a connection to the server. Then perform a synchronous search; leave the Base Dn field blank; set the filter to "(objectclass=*)"; and set the scope to "base." This is a special search of the rootDSE. This returns a list of information including the directory partitions of which this server is aware.
If the search does not return anything, first check the event log, then get a sniffer trace and see whether the server is responding at all.
Because there are many ways to bind, attempt a generic security support provider interface (SSPI) bind. Try one set of credentials; if they don't work, try another set.
If you used administrator credentials, almost all objects in Active Directory should be visible. Other credentials result in some, or possibly most, objects not showing up in searches.
If not, one probable cause is the lack of privileges because of being authenticated in the child domain.
Note
There are two TCP/IP ports that are used for LDAP traffic; the regular port (389) and the Global Catalog port (3268). The Global Catalog port is enabled only when Active Directory has been installed successfully, the server becomes a domain controller, and the Global Catalog option is set. Some data is available on one port, and some on another. For example, read-only copies of data from other domains are available only from the Global Catalog port.
If all of the preceding are successful and the object of interest is still not being returned by LDAP, either the object does not exist or the credentials that are being used are not authorized to view that object. Try another set of credentials — administrator credentials are always a good test.
Confirm that the search is not hitting one of the limits on search time or number of returned objects or attributes. If limits are being hit, a paged search should solve the problem. For more information about LDAP administration limits, see "LDAP Administrative Limits and Query Policy" later in this chapter.
A review of how LDAP messages are sent, the format in which they are sent, and the supported operations can assist you in responding to these questions.
A typical LDAP client application interacts with the LDAP server in the following ways:
When an LDAP client connects to an LDAP server, an LDAP session is established. Options are available to affect the way in which the connection is established, such as setting a time-out value, connecting to a secure LDAP server, and verifying that a server is available.
The bind operation identifies the connecting person, device, or application to the server by providing a distinguished name and some type of authentication credential, such as a password. The exact credentials used depend on the authentication method being used.
Note
LDAPv3 defines an extensible model based on SASL. SASL uses a layered architecture for using different security providers.
LDAPv3 allows the client to negotiate with the LDAP server to determine the best security package available. The Microsoft implementation of the LDAP API allows the NEGOTIATE flag to be used to allow the client to discover the best mechanism available, in which case basic/simple authentication is not used. For example, a SASL mechanism such as Kerberos v5 authentication or NTLM authentication might be used. An Active Directory server can be configured to accept anonymous connections.
The Windows 2000 implementation of LDAP includes these key authentication methods.
Plaintext Password This method (simple bind) authenticates by checking a plaintext password against the account password.
NTLM Authentication NTLM authentication allows clients that are running Windows NT 4.0 and earlier to authenticate themselves to LDAP servers by using NTLM. It also authenticates user logon names in a stand-alone environment.
Kerberos v5 Authentication The Kerberos authentication protocol is the default for network authentication for computers that are running Windows 2000.
Note
Authentication within and between Windows 2000 domains is performed by using either the Kerberos protocol (the default method) or NTLM (for Windows NT). Other methods are available to other clients and external users connecting over the Internet.
Secure Sockets Layer (SSL) SSL is a public-domain protocol for encrypting private communications over the Internet. When a certificate infrastructure is in place, specifying server port 636 causes an SSL session to be set up. Options, methods, and functions are case-sensitive. (For more information about setting up certificates, see "Windows 2000 Certificate Services and Public Key Infrastructure" in this book.)
Simple Protected Negotiation (SPNEGO) SPNEGO enables the client and server to negotiate either through the NTLM or Kerberos v5 depending on the authentication mechanisms available to the particular client and server involved. In this case, both the server and client negotiate on a common secure authentication mechanism (for example, Kerberos authentication or NTLM authentication). This option should be used if the user cares only that the authentication mechanism is secure.
Modifying a Directory Object The LDAP API contains functions to add and delete directory objects and to compare and modify attribute values within existing objects. LDAPv3 provides extensions to the add, delete, and modify functions that enable using controls to perform these operations. Controls are described in RFC 2251 as a mechanism to extend the functionality of LDAP. Windows 2000 supports several extension controls that go beyond those identified by LDAPv3.
Searching the Directory Searching is the most common directory activity, and the LDAP APIs provide a variety of search criteria and result retrieval methods. The client searches the LDAP server by passing it a special set of parameters that describe the information in which the client is interested. These parameters describe where to search in the LDAP directory, how deep to search, and define the search criteria that a client needs. The client uses a search filter to describe the objects it wants. Search filters are defined in RFC 2254. Extensions to the base LDAP API, in the form of LDAPv3 controls, provide the ability to sort results and set various limits on the search operation. Search results can be processed by paging and by sorting. Paging and sorting are supported in Windows 2000 as new LDAPv3 control extensions for processing search results on the server.
Handling Errors All LDAP results return an error code as defined in RFC 2251. In addition, Windows 2000 domain controllers can return additional information in the form of a character string that describes the error, and the error value is translated to the closest Win32 error code.
Unbinding closes the connection and disposes of the session handle. Call the unbind function when an LDAP client has finished communicating with a server. There is no server response to an unbind request.
For the purposes of protocol exchanges, all protocol operations are encapsulated in a common envelope. The LDAPMessage is encapsulated within the Protocol Data Unit(PDU) format. The LDAPMessage consists of protocol operations, such as LDAP Bind Request, LDAP Bind Response, LDAP Search Request, and LDAP Search Response operations. By understanding these operations, you are better able to diagnose and troubleshoot LDAP protocol issues.
LDAPMessage protocol data units are mapped directly to the TCP data stream. The LDAP ports that are used by Active Directory clients are the following:
For more information about LDAP operations, see the Internet Engineering Task Force link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.
According to RFC 2251, the Bind Request has the following parameters:
When receiving a Bind Request, a server authenticates the requesting client, if necessary. The server then returns a Bind Response to the client indicating the status of the authentication.
The following is an example of an LDAP Bind Request as shown by Network Monitor:
LDAP: ProtocolOp: BindRequest (0)
LDAP: MessageID = 11 (0xB)
LDAP: ProtocolOp = BindRequest
LDAP: Version = 3 (0x3)
LDAP: Name =
LDAP: Authentication Type = Sasl
LDAP: Sasl Mechanism = GSS-SPNEGO
LDAP: Sasl Credentials
An LDAP Bind Response is an indication from the server as to the status of a request for authentication of the client. If the bind is successful, the result code is "success." Otherwise, according to RFC 2251, the error is one of the following:
Note
The serverSaslCreds are used as part of a SASL-defined bind mechanism to allow the client to authenticate the server to which it is communicating or to perform "challenge-response" authentication.
The following is an example of an LDAP Bind Response as shown by Network Monitor:
LDAP: ProtocolOp: BindResponse (1)
LDAP: MessageID = 18 (0x12)
LDAP: ProtocolOp = BindResponse
LDAP: Result Code = Success
LDAP: Matched DN =
LDAP: Error Message =
LDAP: Sasl Mechanism = GSSAPI
LDAP: Sasl Credentials
A client uses the LDAP Search operation to request that a search be performed on its behalf by a server. This can be used to read attributes from a single entry, from entries immediately following a particular entry or a whole subtree of entries.
According to RFC 2251, the Search Request has the following parameters:
The following is an example of an LDAP Search Request:
LDAP: ProtocolOp: SearchRequest (3)
LDAP: MessageID = 1 (0x1)
LDAP: ProtocolOp = SearchRequest
LDAP: Base Object =
LDAP: Scope = Base Object
LDAP: Deref Aliases = Never Deref Aliases
LDAP: Size Limit = No Limit
LDAP: Time Limit = No Limit
LDAP: Attrs Only = 0 (0x0)
LDAP: Filter Type = Present
LDAP: Attribute Type = objectClass
The results of an LDAP Search by the server upon receipt of a Search Request are returned in Search Responses, which are LDAP messages containing either SearchResultEntry, SearchResultReference, ExtendedResponse or SearchResultDone data types.
If the LDAP session is running TCP, the server returns to the client a sequence of responses in separate LDAP messages. There might be zero or more responses containing SearchResultEntry, one for each entry found during the search.
As indicated in RFC 2251, each entry returned in a SearchResultEntry contains all attributes, complete with associated values if necessary, as specified in the attributes field of the Search Request. Return of attributes is subject to access control and other administrative policy. Some attributes might be returned in binary format (indicated by the AttributeDescription in the response having the binary option present).
For more information about LDAP Search Result, see the Internet Engineering Task Force link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.
The following is an example of an LDAP Search Response as shown by Network Monitor:
LDAP: ProtocolOp: SearchResponse (4)
LDAP: MessageID = 1 (0x1)
LDAP: ProtocolOp = SearchResponse
LDAP: Object Name =
+ LDAP: Attribute Type = currentTime
+ LDAP: Attribute Type = subschemaSubentry
+ LDAP: Attribute Type = dsServiceName
+ LDAP: Attribute Type = namingContexts
+ LDAP: Attribute Type = defaultNamingContext
+ LDAP: Attribute Type = schemaNamingContext
+ LDAP: Attribute Type = configurationNamingContext
+ LDAP: Attribute Type = rootDomainNamingContext
+ LDAP: Attribute Type = supportedControl
+ LDAP: Attribute Type = supportedLDAPVersion
+ LDAP: Attribute Type = supportedLDAPPolicies
+ LDAP: Attribute Type = highestCommittedUSN
+ LDAP: Attribute Type = supportedSASLMechanisms
LDAP: Attribute Type = dnsHostName
For more information about the LDAP v3 protocol, see the Internet Engineering Task Force link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources
The following is an example of an unsuccessful LDAP Bind Response Sniffer Trace:
LDAP: ProtocolOp: BindResponse (1)
LDAP: MessageID = 8 (0x8)
LDAP: ProtocolOp = BindResponse
LDAP: Result Code = Invalid Credentials
LDAP: Matched DN =
LDAP: Error Message =
The following is an example of a successful LDAP Bind Response Sniffer Trace:
LDAP: ProtocolOp: BindResponse (1)
LDAP: MessageID = 18 (0x12)
LDAP: ProtocolOp = BindResponse
LDAP: Result Code = Success
LDAP: Matched DN =
LDAP: Error Message =
LDAP: Sasl Mechanism = GSSAPI
LDAP: Sasl Credentials
LDAP administrative limits constitute the LDAP query policy, and are stored as a multivalued attribute on query policy objects. LDAP administrative limits allow you to tune working set size and CPU consumption of a particular server or set of servers based on the query workload presented. For example, a "bridgehead" server for a particular domain might disallow sorting and paged results, freeing memory, and CPU cycles to handle the intersite replication workload. A memory-rich server with limited CPU bandwidth might allow for large result sets but a small number of active queries.
Query policy applies to the following LDAP query-related operations:
Because server size and CPU consumption might vary, query policies need to be tested in a laboratory environment, and then managed on an individual server basis.
Configuring parameters for LDAP administrative limits can both restrict and make server resources available to clients for basic queries and queries with paged or sorted results. Also, they determine how many connections are allowed for a server, how long it can be idle, and so on. Finally, they can access to a server through an IP host address or subnet mask.
Support for LDAPv3 extensions for querying, paging, and sorting places demands on the memory and computational resources of the Active Directory server. It is prudent practice to perform load balance testing on LDAP servers before you deploy them. Only then can you develop a set of baseline measurements from which to make adjustments.
Limits can be set on the server resources that are available to clients requesting LDAP queries, paged result sets, and sorted result sets. These limits constitute the LDAP query policy, and are stored as a multivalue attribute on query policy objects. Because workload and resources of a particular server varies, the query policy is configurable at the server level.
The Ntdsutil tool can be used to view or modify the query policy of a domain controller. The Active Directory Sites and Services console can be used to assign query policies to domain controllers but not to sites. Additionally, the Modifyldap.vbs script can be used to create, delete, assign, or modify query policy objects. This script can be installed from the Support\Reskit directory on the Windows® 2000 Resource Kit companion CD.
Query policy objects are stored in the container cn=Query-Policies, cn=Directory Service, cn=Windows NT, cn=Services in the configuration partition.
In the absence of any other assigned policies, all domain controllers use the default query policy. If a site policy is assigned, the domain controller uses this policy. If a specific policy has been assigned to a domain controller, this policy takes precedence over any site policy.
The administrative limits and values can be viewed by using the Ntdsutil command-line tool. Table 10.5 shows the administrative limits that are in effect for the default query policy.
Table 10.5 Default Query Policy Settings
| LDAP Administrative Limits | Default Values | Description/Search Behavior |
|---|---|---|
| InitRecvTimeout | 120 | Initial Receive Timeout. The maximum time in seconds that the server waits for the initial request before the connection closes. If a connection is idle for more than the stated limit, the LDAP server returns a LDAP disconnect notification and closes the connection. |
| MaxConnections | 5000 | Maximum Connections. The maximum number of concurrent LDAP connections allowed on the server. If the stated limit is reached, the LDAP server and closes the connection. |
| MaxConnIdleTime | 900 | Maximum Connection Idle Time. The maximum time in seconds that the client is allowed to be idle before the connection is closed. If a connection is idle for more than the stated limit, the LDAP server closes the connection. |
| MaxActiveQueries | 20 | Maximum Active Queries. The maximum number of concurrent search operations allowed on the server. When the stated limit is reached, the LDAP server returns a busy notification. |
| MaxNotificationPerConn | 5 | Maximum Notifications per Connection. The maximum number of concurrent notification requests allowed per connection on the server. When the stated limit is reached, the server returns a busy notification. |
| MaxReceiveBuffer | 10485760 | Maximum Receive Buffer. The maximum size LDAP request in bytes that the server will attempt to process. If the server receives a request that is larger then this value, it will close the connection. |
| MaxPageSize | 1000 | Maximum Page Size. The largest page size allowed by the server. The server returns the number of rows specified by MaxPageSize. If the paged results were requested, the client can retrieve additional pages until all results are returned. |
| MaxQueryDuration | 120 | Maximum Query Duration. The maximum elapsed time (in seconds) allowed for a query to complete. If paged results are requested, the client can continue the query if the timer expires before the query completes. When the stated limit is reached, the server returns the timeLimitExceeded error. |
| MaxTempTableSize | 10000 | Maximum Temporary Table Size. The upper limit, in candidate objects, on the temporary table. If the temporary table maximum limit is reached by an "OR" query optimization, the optimization is abandoned and replaced with a direct table scan. This limit can also be reached when the server sorts (for example, by the server side sort control,) results for the client. If the server reaches this limit while sorting results it will abandon the sort and return results unsorted. |
| MaxResultSetSize | 262144 | Maximum Result Set Storage. The maximum storage that the server can hold for all paged result sets. If the stated limit is reached, the oldest result sets are discarded. |
| MaxPoolThreads | 4 | The number of threads per processor allocated to answer LDAP requests. This value can be exceeded by the server only under certain circumstances Note: If it takes a long time to bind, increase the count to 6 or 8. |
| MaxDatagramRecv | 1024 | Maximum Datagram Receive. The maximum size of datagrams that can be received by the server. The server pre-allocates datagram buffers and cannot receive datagrams with a size larger than the stated limit. |
For more information about using Ntdsutil, see the Support directory on the Windows 2000 Server operating system CD. For more information about virtual containers, see "Active Directory Data Storage" in this book.