A common configuration error is to specify a dif-ferent WINS server to use as an alternate WINS server.The problem with doing this is that during startup of the WINS server, it will try
Trang 1potentially improved by lengthening the amount of time an entry would persist in cache beyond the default 10 minutes
Preventing Split WINS Registrations
A WINS server is also a WINS client to itself A common configuration error is to specify a dif-ferent WINS server to use as an alternate WINS server.The problem with doing this is that during startup of the WINS server, it will try to register its names with the WINS servers configured in the TCP/IP properties Because the WINS server service won’t start until NetBT has initialized, this causes the WINS server to attempt to register with the alternate or secondary WINS However, it will continue to try to register these mappings in the local WINS database Once the local WINS database is available, the WINS server will switch to it to register the remaining mappings.This
results in what is known as a split registration, where name mappings are registered in and owned by
two different WINS servers A split registration for WINS servers can cause intermittent problems with WINS name resolution
Performance Issues
As mentioned earlier in the chapter, a typical WINS server can handle WINS registrations and name resolution requests for up to 10,000 clients, even if the WINS server has only modest amounts of CPU power and RAM WINS traffic for each registration and name resolution request is relatively small However, a number of factors can affect the performance of WINS server.These factors include the presence of other services running on the WINS server, the performance of database maintenance
on the WINS server, various WINS server settings, and the flooding of the network with NetBIOS name registration requests In this section, we’ll look at WINS server performance issues
Hardware Considerations
Even a modestly powered computer can handle a large number of registrations and name resolution requests However, WINS can generate intensive CPU and disk activity WINS server performance
is, therefore, significantly improved by using fast disks and multiple CPUs For mission-critical WINS servers that handle large amounts of data, it is a good idea to use RAID arrays to enhance fault tolerance and performance If you don’t use a RAID array, you should consider placing the WINS database on a separate hard disk from the operating system.You can specify the location of
the database on the Advanced tab of the property pages for the WINS server (see Figure 20.30 in
the next section)
If the organization requires a very high degree of fault tolerance and availability, you should consider using a Windows Server 2003 server cluster for the WINS service.This will require at least two WINS servers configured as cluster nodes to use a shared SCSI or Fibre Channel storage device On large networks, adding more WINS servers to distribute the load will improve response times for WINS queries, but will add more replication traffic and require more administration
Burst Handling
Since Windows NT 4.0 Service Pack 3, WINS servers have been capable of burst handling Burst
handling, which is enabled by default, allows the WINS server to handle a large volume of
Trang 2simulta-neous registration requests.This situation can occur, for example, when power is suddenly returned
to many computers after a power outage With burst handling configured, the WINS server will respond positively to name registration and refresh requests before it writes them to the database
However, it will supply the WINS clients with varied and short TTLs for the name registrations to stagger the load for subsequent WINS client refresh attempts
By default, burst handling occurs when the server has more than 500 requests in its queue
However, you can adjust this setting in the WINS console As shown in Figure 20.30, the
Advanced tab for the properties of the WINS server allows you to select a Low (300 requests), Medium (500), High (1000), or Custom (where you specify the number of requests) If the
WINS server has more than 25,000 requests in its queue, it will start dropping queries
It’s a good idea to ensure that burst handling is enabled for reasons other than improving the performance of the WINS server under peak-load conditions When burst handling is enabled, it writes events to the event log.The presence of burst handling events can provide an indication that the WINS server hardware is not adequate Furthermore, the presence of burst handling events can indicate a possible DoS attack on the WINS server.You can use Network Monitor or some other tool for analyzing network traffic to capture packets and track down the possible causes of the pres-ence of burst handling events
Scavenging of WINS Records
Performance of a WINS server will be affected by the settings that are used to determine how fre-quently clients refresh their registrations, how long it takes for a released or deleted registration to
be removed from the database, and how frequently the database verifies its records to ensure the
integrity of data Scavenging is the process by which WINS records are removed from the database.
More specifically, scavenging is a preset process that periodically runs on the WINS server and either deletes or changes the status of WINS records based on their timestamps and current state.The
set-tings that control these intervals are found in the Intervals tab in the property pages of the WINS
server It might be useful to change these settings to improve the performance of the WINS server:
Figure 20.30 Configuring Burst Handling
Trang 3■ Renewal interval Governs the TTL of the client registration WINS clients will attempt
to renew registrations after half the renewal interval has elapsed Increasing this interval will reduce the frequency of client renewal attempts and reduce the load on the WINS server However, increasing the interval also makes the database less consistent with the network over time when computer names are changed.The renewal interval should be the same for all WINS servers when they are replicating with one another
■ Extinction interval Governs the period that must elapse from when a name is marked
as released and when it is marked as tombstoned
■ Extinction timeout Governs the period that must elapse from when a name marked as tombstoned and is subsequently scavenged (removed) from the database
■ Verification interval Dependent on the previous values and governs when a WINS server must validate active records it does not own; that is, records learned of via replica-tion with other WINS servers
Figure 20.31 shows the Intervals tab with the default settings
Database Compaction
When records are deleted from the WINS database, the space formerly occupied by them should be recovered to ensure optimal performance of the database.The process of recovering this space is
referred to as compaction.The WINS service automatically and periodically performs online
com-paction of the WINS database However, online comcom-paction of the WINS database is not as efficient
as offline compaction It is, therefore, sometimes desirable for the WINS administrator to stop the WINS service (take the database offline) and perform a manual compaction of the database
The WINS administrator can use Jetpack.exe, found in the System32 folder, for manual database compaction.The Jetpack utility works by creating a temporary database in which to compact the records, and then replacing the original database with the compacted one.To manually compact the
Figure 20.31 Interval Settings for Registration Renewal, Removal, and Verification
Trang 4database, the WINS administrator must first stop the WINS service and then issue the jetpack
command, using the following syntax:
jetpack %systemroot%\system32\Wins\Wins.mdb [name_of_temp_database.mdb]
After running the jetpack command, the WINS administrator can start the WINS service again
Using the net stop and net start commands, the WINS administrator can automate offline
compaction in a batch file For example, you can create a simple batch file that contains the fol-lowing three lines:
net stop wins
jetpack %systemroot%\system32\Wins\Wins.mdb [name_of_temp_database.mdb]
net start wins
Once you have created the batch file, you can configure it to run at preconfigured intervals using the Task Scheduler or the AT command-line utility For example, you could configure the batch file to run once a month during off hours to ensure that the database uses space optimally
Scheduling Consistency Checking
In order to maintain database integrity in environments that employ replication, it is recommended that automatic periodic consistency checking be enabled Consistency checking is the process whereby a local WINS server compares local entries that it has acquired by replication with the entries in WINS servers that own the record If a WINS server detects that the records are identical between its locally stored copy and the remote database, it will update the record with a new times-tamp However, if the record has a lower version ID in the local database, it will pull the updated record from its replication partner and mark the original one for deletion
Because consistency checking puts a significant load on the resources of a WINS server, it
should be scheduled to run during off-peak hours Figure 20.32 shows the Database Verification
tab of the property pages of the WINS server, where you can set the schedule for consistency checking
Figure 20.32 Enabling and Scheduling Consistency Checking
Trang 5In Figure 20.32, consistency checking is enabled and scheduled to run every 24 hours at 2:00
A.M Additional settings allow the WINS administrator to specify the maximum number of records
to verify and to select randomly selected replication partners Consistency checking can also be manually initiated from the context menu of the WINS server in the WINS server console
Security Issues
As with any service that you implement on your servers and your network, it is important for you
to understand the service and take measures that mitigate the risk to the service and the network as
a whole.These measures include setting up restricted ACLs, logging, auditing, and monitoring, as well as using VPNs or IPSec to secure WINS replication traffic In the next section, we briefly examine issues related to the security of the WINS service
NetBIOS Security Issues
With regard to NetBIOS in general and the WINS service in particular, administrators need to be aware that NetBIOS is an unauthenticated protocol.That is, users are not required to submit cre-dentials before using the services provided by a WINS server, such as name registration, renewal, release, and queries.This makes WINS susceptible to a number of different kinds of attacks, pri-marily DoS attacks and redirection attacks
In a DoS attack, an attacker attempts to tie up the WINS service with a large number of requests that compromise the WINS server’s ability to process legitimate requests.To mitigate the risk of DoS attacks, you should do the following:
■ Secure the physical network from unauthorized access
■ Enable burst handling When burst handling is enabled, burst handling events are recorded
in Event Viewer, providing an alert to a possible DoS attack (This is set in the Advanced tab for the properties of the WINS server, shown in Figure 20.30 earlier in this chapter.)
■ Enable detailed WINS logging to provide more complete and specific logging of WINS events in the System log (Also set in the Advanced tab for the properties of the WINS server, shown in Figure 20.30)
■ Use a protocol-analysis tool, such as Network Monitor, to analyze traffic in the case of a suspected attack
In a redirection attack, an attacker tries to register a rogue computer that has the same name mappings as a previously registered computer If the previously registered computer is down for maintenance or is otherwise unable to respond to the challenge from the WINS server (for
example, if it is also a victim of a specific DoS attack), the rogue computer will be able to register the name mappings with its own IP address WINS clients will then subsequently be redirected to the rogue computer.To mitigate the risk of redirection attacks, you should do the following:
■ Identify mission-critical systems and assign them static mappings in the WINS database
■ Ensure that the migrate on setting is disabled to prevent the WINS server from
over-writing the static mappings with dynamic mappings (This is controlled by the Overwrite
Trang 6unique static mappings at this server (migrate on) setting in the Replication Partners Properties dialog box, shown in Figure 20.27 earlier in this chapter.)
Protecting the WINS Database and Log Files
The WINS databases and log files contain important information about your network.The informa-tion in these files could be used by attackers to glean confidential informainforma-tion about your company
For example, by an analysis of the number of computers, the attacker could learn the names of those computers, the NetBIOS applications running on the computers, and so on Furthermore, the integrity and availability of the WINS database and the log files are critical to the operation of the network
It is particularly important to note that, if you change the default location of the WINS database files, they will inherit the ACLs of the new destination folder, removing the effective security they inherited by virtue of being located in a subfolder of the System32 folder Also, the WINS backup files inherit the ACL of the folder used to store the backup files.To mitigate the risks to the confi-dentiality, integrity, and availability of WINS databases, you should consider doing the following:
■ Do not store WINS database files on anything except an NTFS formatted partition
■ Ensure that the ACLs for the WINS database, backup, and log files are restricted to allow access to only the Local System Account and the Administrators group
■ Enable file auditing on the WINS files to track attempts of objects that try to access these files
■ Ensure that the WINS server is physically secured from remote access
■ Do not transfer WINS database files over the network using FTP or other unsecured protocols
WINS Users Group
Only members of the Administrators group can modify the settings for WINS servers However, it is desirable, in some situations, to provide read-only access to the configuration and database informa-tion of WINS servers.To provide users with read-only access to the WINS server, you can use the special WINS Users group Users who are members of this group are able to query the WINS server database to find records and to view configuration information
Planning for WINS Database Backup and Restoration
Although it is possible to rely on replicated copies of WINS records to restore a corrupted database, you should only do so as a method of last resort It is far better to back up the WINS database, either manually or automatically, and restore WINS records from the backup, if necessary
By default, the WINS database is not backed up automatically.To back up a WINS database automatically, you need to do the following:
1 Specify a backup directory in the General tab of the WINS server properties (WINS will create a folder called Wins_bak under this folder to store the backups).
Trang 72 Perform a manual backup of the WINS database to the specified location.You can do this
by choosing the Backup Up Database option from context menu of the WINS server
object in the WINS console tree
After you have performed these steps, backups will occur every 24 hours or upon service shut-down (if so configured) In the event that the WINS service detects a corrupt WINS database upon startup, it will automatically restore the backed up version from the location that you specified for the WINS backups.You cannot use a network drive for this location Figure 20.33 shows the set-tings for configuring automatic backups
To restore the WINS database, you can stop the WINS service, delete the original database, and restore the backup If you do not stop the WINS service, the option to restore the WINS database will be grayed out
Troubleshooting Name Resolution Issues
Proper name resolution is critical to the smooth operation of the network When name resolution fails, for whatever reason, users might be inconvenienced, and connectivity to critical systems might
be compromised Usually, a name resolution failure requires immediate action on the part of the administrator, even if the failure is not widespread
Often, problems that appear to be related to name resolution are, in fact, the result of problems that occur further down in the OSI or DoD networking models for TCP/IP For example, if a router fails, and the DNS or WINS servers are on the other side of the router from the client, clients will not be able to resolve names.The failure of a router occurs at Layer 3 (Network layer) of the ISO model
As part of a prudent and successful troubleshooting strategy, it is important to troubleshoot from the bottom of the OSI model up, ensuring the following:
Figure 20.33 WINS Backup Configuration
Trang 8■ The hardware is functioning properly.
■ The computer is configured properly
■ The computer is able to communicate with hosts on the local subnet
■ The computer is able to communicate with the router configured as the default gateway
■ The computer can communicate with remote networks on the far side of the router
Usually, this troubleshooting will rely on tools such as Ipconfig to verify configuration and PING (using IP addresses) to test communication
Name resolution occurs further up in the OSI or DoD model.You need to discover if is the failure specific to NetBIOS or DNS (host name resolution).To make this determination, you can test name resolution using applications that are specific to these interfaces For example, to test NetBIOS name resolution, try to connect to shares using a UNC path or the net commands, invoked from the command line As long as the name you are trying to resolve does not include dots or is less than 15 characters long, Windows clients will default to using NetBIOS resolution first If name resolution is successful, but you encounter a delay, chances are that NetBIOS resolution failed but that the fallback host name resolution was successful.To test host name resolution, you can use WinSock applications, such as NSLookup,Telnet, FTP, HTTP, and so on
You should also consider whether NetBT is enabled, either by means of a DHCP server option
or as a configuration on the client computer Some applications, such as Microsoft Exchange Server, still require that NetBT be enabled to work properly In troubleshooting name resolution problems, you should therefore take into account the applications that may be involved and their dependence
on either the WinSock or NetBT interfaces to work properly
It is sometimes obvious that the problem is specific to either host name or NetBIOS name res-olution In any event, after you have made the determination, you can proceed to troubleshoot according to the interface (WinSock or NetBT) that is involved
Troubleshooting Host Name Resolution
Assuming you have eliminated any antecedent causes that have to do with connectivity and com-munication on the network, troubleshooting host name resolution is easier if you can isolate whether the problem is caused by problems with client configuration or by problems with the DNS server Problems with DNS clients include improperly entered addresses for the primary and sec-ondary DNS server, in addition to improperly configured DNS suffix search list settings Problems with DNS servers include improperly configured delegations; improperly configured restrictions on zone transfers; missing, incorrect, or stale resource records; and so on
Effective troubleshooting of Microsoft DNS issues requires a familiarity with the process of DNS name resolution (for example, recursive versus iterative queries and authoritative versus nonauthoritative responses), dynamic updates, zone transfers, stub zones, forwarding, and so on
A familiarity with DNS-related troubleshooting tools, such as NSLookup, Ipconfig, Dnscmd, and DNSLint, will help to ensure that you can trace the source of the problem effectively Using NSLookup, you can request either an authoritative or nonauthoritative response from the DNS server, which can help you to narrow down the problem further; for example, to determine whether
a stale record is coming from the DNS cache or not Furthermore, with NSLookup, you can use
Trang 9debug mode to provide a great amount of detail in the output of the command.You can use
DNSLint to check all your delegations and verify the correct configuration of well-known services, such as SMTP Issues with dynamic registration can sometimes be resolved by using the command
ipconfig /registerdns Incorrect entries in the client DNS cache can be resolved with the
ipconfig /displaydns and ipconfig /flushdns commands Some tools that are not specific to
DNS, such as Nltest, can help to troubleshoot DNS-related issues with domain controllers
Issues Related to Client Computer Configuration
Many problems with DNS resolution have their origins in the client configuration, so verifying the correct client configuration is a good place to begin.To troubleshoot problems with client
configu-ration, use the ipconfig /all command to verify the DNS configuconfigu-ration, and then use PING and
NSLookup to verify communication with the DNS server If you can ping the DNS servers, but an NSLookup query against them fails, the issue is most likely related to a problem with the DNS servers (This is the kind of situation where troubleshooting from the bottom to the top of the OSI model really pays off in helping to narrow down the problem.)
One of the more common and serious problems with client configuration is an improperly configured FQDN, which is set up in the properties of My Computer on Windows 2000 and Windows XP clients If the FQDN is not present or is incorrectly configured on the client com-puter, name resolution can fail for domains that would otherwise be searched according to a domain suffix search list For example, if the computer is a member of the corp.tacteam.net domain, and the user enters and uses an unqualified name (for example, PServer1) in a DNS query for a host in the tacteam.net domain, the query will fail unless the FQDN of the computer is properly configured (An unqualified name is one that doesn’t have a trailing dot.) By default, the DNS client uses a domain suffix search list based on the FQDN So, if the host name cannot be resolved in the
corp.tacteam.net domain, the suffix will be devolved to tacteam.net to find the host.To troubleshoot problems with domain suffix search lists, try to resolve the name at the client using the FQDN (that
is, include the trailing dot) If this query succeeds, but an unqualified query does not, the problem is related to the domain suffix search list
Clients that have improperly configured FQDNs might also have problems with dynamic registra-tion in the DNS zone.The client registraregistra-tion of a host record in a DNS requires that the primary suffix be properly configured If the domain suffix is improperly configured, the client may be trying
to register in a nonexistent or an unintended domain.To troubleshoot and resolve this problem, verify that the client computer is correctly configured with a primary domain suffix and that it can reach a name server that is authoritative for the domain name (you can simulate this by using NSLookup to perform an SOA RR query type for the authoritative zone) If the client receives its TCP/IP configu-ration from a DHCP server, verify that the DHCP server option for the domain suffix and other set-tings are configured correctly Also, the client needs to be configured with the IP address of a DNS that contains the primary zone in order for the updates to occur Meeting these conditions and then
using the ipconfig /registerdns command to register the host in the domain might solve the
problem However, if the problem is still not resolved, chances are the source of the problem is the DNS server; for example, an ACL on the RR may be preventing the update Using Event Viewer on the client computer can help you determine the nature of the problem
Trang 10If the DNS clients are getting incorrect responses to DNS queries, the problem might be related
to their DNS cache.To clear the cache and force a new query to a DNS server for the host name,
use the command ipconfig /flushdns (Alternatively, you can use NSLookup to request an
author-itative response.) If you have cleared the cache and are still getting incorrect responses to queries, it
is likely the source of the problem has to do with the DNS server; for example, there might be an incorrect entry in the cache of the DNS server, a problem with zone transfers, or a delay in AD replication
Issues Related to DNS Services
If you have determined that the problem you are experiencing is unrelated to DNS client settings
or the client’s ability to communicate with the network, the problem is most likely related to DNS server configuration.To troubleshoot DNS server problems, you need to let the symptoms of the problem guide you to a likely cause and solution Again, using a tool like NSLookup will help you get a clearer picture of the problem, since it can provide more detailed information and be used to get either authoritative or nonauthoritative responses from DNS servers.The following is a brief list
of guidelines to help troubleshoot problems with DNS servers:
■ If clients cannot resolve names on the Internet or in domains for which their DNS servers are not authoritative using recursive queries, the problem might be related to the ability of the DNS server to perform recursion or to forward the query to a server that will perform recursion for it In this case, check to make sure that the root hints file is present and the records are correct If these settings are correct, your DNS server might be experiencing cache pollution In this case, you should enable protection against cache pollution and restart the DNS service
■ If clients do not get correct records or are getting stale records, the cause could be the cache on the DNS client or DNS server Examining and clearing the cache will eliminate the problem However, if the problem is unrelated to cache, the cause could be failed or slow zone transfers to the secondary zones If you are using Active Directory-integrated zones, the cause could be related to problems with AD replication Comparing the RRs in the various zone files and looking at events in Event Viewer will help to confirm zone transfers as being the cause or the problem
■ If some clients cannot get responses to DNS queries from a multihomed DNS server but others can, the problem might be related to the listener settings on the DNS server.These settings can restrict which interfaces the DNS service will use to respond to queries
■ If you are implementing a round-robin configuration to provide load balancing and are not getting the desired results, check the settings for subnet prioritization Round robin is a kind
of load balancing that can be configured using multiple host records that have the same name but different IP addresses When round robin is enabled, the DNS server will rotate responses among all the records However, if subnet prioritization is also enabled, the DNS server will try to respond with a record that is on the same subnet as the DNS client
■ If zone transfers are failing between DNS servers, the cause could be improper restrictions
on DNS servers that are authorized to pull zone information from the primary server By