20.4. The Windows BrowserThe information that Windows machines display in the Network Neighborhood and in other places where you can pick a computer from a list comes from a server known as the Windows Browser. This is a separate service from name resolution and is not just dependent on name resolution, but also intertwined with it. In particular, machines use special names to locate Browser servers, and those names are sometimes registered and resolved exceptionally. The Browser service is responsible for most of the mysterious broadcast packets to port 138 that you will see on Windows networks, and a significant number of the mysterious headaches suffered by Windows administrators. The headaches are greatly magnified by the fact that very few people understand exactly what Browser service is supposed to do, let alone how it does it.
The Browser service is responsible only for maintaining lists of computers so that human beings can pick them from the list instead of having to be able to type the computer's name. The Browser does not list the resources actually available on the computer; it isn't part of WINS, much less the same thing as WINS; and it isn't involved in any direct interactions between servers and clients. It's not at all unusual for a machine to be visible via the Browser but not actually accessible, and this is not a problem with the Browser. If it is accessible but unintentionally invisible, that's a Browser problem but not a surprise.
Originally, Windows Browser service was entirely broadcast-based. A number of complicated changes have been made to allow it to work across routers, so that in theory if a network stays the same for long enough, and contains enough Windows NT machines, browsing information will stabilize and propagate across the entire network. For a complex network, this process may take a considerable amount of time and in fact will often take longer than the average delay between network changes.
20.4.1. Domains and WorkgroupsEvery machine on a Windows network must be part of some domain or workgroup. A workgroup is simply a collection of machines that share the same workgroup registration; there are no controls over what machines can be in a workgroup. Being a member of a workgroup is like being a sports fan; if you say you're part of the group, then you are.
A domain is an administrative entity where there is a centralized source of information (a domain controller). Joining a domain is like joining an exclusive club; you have to be admitted by the administration. Unfortunately, it is possible to create a workgroup with the same name as a domain.
The Browser service was created before domains, and as a result, it is not fully aware of the distinction between workgroups and domains. It treats them identically and pretends that they are domains (both by calling them domains and by assuming that every group of workstations that it knows about has a contactable domain controller).
20.4.2. Windows Browser RolesA Browser server contains information about a single domain, which it gathers by listening to the registrations broadcast by machines at boot time. Since the Browser is primarily broadcast-based, many things about the Browser apply to the set of machines that are reachable by broadcast. For convenience, we'll call this set of machines a subnet, although depending on how you configure your network it may not technically be a subnet.
ost machines that know about Browser service are capable of being Browser servers, and it is perfectly legitimate for multiple machines on the same subnet to be Browser servers for the same domain or workgroup. These machines will use broadcast to elect a master browser. There will always be exactly one master browser per subnet per domain or workgroup. A single subnet may have multiple master browsers for different domains or workgroups, and a single domain or workgroup may have multiple master browsers on different subnets. Figure 20-7 shows a network with multiple subnets and multiple domains and the resulting browser configuration.
Figure 20-7. Master browsers in a network with multiple domains and multiple subnetsIn general, users don't care about subnet boundaries; they want to know about all the machines in a domain or workgroup, regardless of what subnet they're on. Since Browser servers collect data via broadcast, it requires some mechanism for master browsers on different networks to synchronize information. In a workgroup configuration, there is simply no way for this to occur. Workgroups have no centralized structure. In a domain configuration, however, there is a central source of information (the domain controller), and the master browsers for a domain will all synchronize to it. The domain controller's centralized Browser server is called a domain master browser.
Browser servers do not initiate transactions to individual hosts by their normal names. Instead, the Browser sends out broadcast packets or unicast packets to special hostnames. The Browser does not need to know how to find other servers; it simply tries to send packets to the name that the server would be using if it existed. If no server is there, name resolution will fail (for unicast packets), or the broadcast will be ignored (for broadcast packets). The Browser simplifies things still further by not even attempting name resolution for most group names and simply sending out broadcasts with a destination NetBIOS name set. Hosts that are not part of the group will ignore the broadcasts.
The following sections describe the browser roles and the names associated with them.
188.8.131.52. Domain master browserThe domain master browser registers a unique name with the name of the domain and the type 1B. It is always the primary domain controller. Because it is a domain controller, it also registers a group name with the name of the domain and the type 1C. Aside from registering the name, the domain master browser takes no special actions. Other master browsers will initiate connections to it for synchronization. (This will be true whether or not there is an actual domain master browser, since the Browser assumes that everything is a domain. If there is no domain master browser, or it is unreachable, the amount of name resolution traffic will be significant as master browsers try to resolve the 1B and 1C names.)
184.108.40.206. Master browserA master browser registers a unique name with the name of the domain and the type 1D. This represents a problem for WINS because WINS spans multiple subnets. It's legal for more than one master browser to exist, as long as they're on different subnets, but if they're all talking to the same WINS server, they shouldn't be able to register the name as a unique name. This is dealt with by having WINS treat the type 1D as special. WINS servers will return success for any attempt to register a unique name with type 1D, and failure for any attempt to resolve such a name. This allows the broadcast-based NetBT name service to handle uniqueness and resolution for master browsers.
A master browser also registers the group name _MSBROWSE_, which is used to distribute information among master browsers so that each one has the full list of available domains and workgroups.
aster browsers collect information from broadcasts to build up a list of all hosts in the domain or workgroup that they are responsible for, and to build up a list of other domains and workgroups and their master browsers.
aster browsers initiate four types of communication:
220.127.116.11. Backup browsersBackup browsers have two functions: they take requests from clients and return actual data, and they participate in elections to select a master browser. Backup browsers register a group name with the name of the domain and the type 1E.
18.104.22.168. Potential browsersPotential browsers register a group name with the name of the domain and the type 1E. They participate in elections, but otherwise do nothing unless they are promoted to backup browsers.
22.214.171.124. Browseable serverAny machine that has a service that should show up in the browser sends an announcement every 12 minutes to a group with the name of the domain and the type 1D.
126.96.36.199. Browser clientA client that's in the domain "netherworld" and wants to look up a browse list for the domain "limbo" goes through the following steps:
20.4.3. Browser ElectionsElections are one of the best-documented parts of the Browser protocol; for the details on how they work, consult almost any book on Microsoft networking (for instance, Microsoft's Windows NT Server Networking Guide, mentioned earlier). In outline, the procedure is that a machine that wants an election to occur sends a packet to the IP broadcast address with the NetBT destination of the group with the name of the domain and the type 1E. This packet includes several parameters that indicate the machine's qualifications to be master browser. Each browser that gets the packet compares those qualifications to its own and sends another election packet if it is more qualified. A machine that sends out an election packet without getting a response from a more qualified machine will send out three more; once a machine has sent out four election packets without seeing a response from a more qualified machine, it will consider itself elected and send out a master browser announcement.
Because master browsers are important for the speed with which browsing works, elections are designed to prefer more stable machines. Election qualifications include a parameter that depends on the machine's operating system version (Windows NT Server is better than Windows NT Workstation is better than Windows 95), plus a parameter specific to the browser, which you can think of as an indication of how much the machine wants to win, and a parameter that depends on the machine's uptime (longer uptime wins). Master browser announcements include information about some of these parameters (in particular, the operating system type and part of the browser-specific information).
There are two situations in which machines will decide to call elections:
20.4.4. Security Implications of the Windows BrowserObviously, the Windows Browser gives out security-critical information (valid hostnames). Less obviously, it has many fewer security implications than WINS does. The Browser provides information in bulk, unlike WINS, but it provides only hostname information, while WINS coincidentally provides much more sensitive information about valid usernames and current logins. Various sorts of denial of service and network flooding attacks can be carried out via the Browser, but the Browser has no equivalent of a WINS server that can be used as a magnifier and distributor to carry attacks to networks that the attacker is not connected to. You can spread misinformation via the Browser, but doing so is merely confusing; unless the misinformation is actually in NetBT name service as well, connections will simply fail.
This is all highly theoretical, however, since making the Windows Browser work requires making all of NetBT work. You can't allow the relatively safe Windows Browser without also allowing the highly unsafe NetBT name service. If you do allow all of NetBT, adding the Windows Browser is a relatively small decrease in security. (From a purely practical standpoint, as opposed to a security standpoint, we advise against it; while the security problem is small, the administrative problem is extremely large, and the Browser almost never works well, or even predictably, in complex networks.)
20.4.5. Packet Filtering Characteristics of the Windows BrowserThe Windows Browser depends on NetBT name service at port 137 (UDP and TCP, broadcast and unicast), NetBT datagram service at port 138 (UDP, broadcast, and unicast), and NetBT session service at port 139 (TCP, unicast only). Packet filtering characteristics of NetBT session and datagram service are discussed in Chapter 14, "Intermediary Protocols"; NetBT name service is discussed earlier in this chapter.
20.4.6. Proxying Characteristics of the Windows BrowserBecause the Browser is strongly based on broadcasts, standard proxying systems will not work with it. It is possible to use router configurations to forward broadcasts, but this is not terribly effective with the Browser because of the large amount of traffic involved and the multiple port numbers used.
20.4.7. Network Address Translation Characteristics of the Windows BrowserNot only does the Browser use NetBT (which has embedded IP addresses), it also relies on many-to-many communication via broadcasts. This is not a promising situation for network address translation. In particular, it is not possible to conserve address space using network address translation and the Browser, since all hosts must be able to speak to all other hosts. Furthermore, unlike many NetBT-based protocols, the Browser actually uses the embedded IP addresses in some situations and will need them to be correct.
20.4.8. Summary of Recommendations for the Windows Browser
Copyright © 2002 O'Reilly & Associates. All rights reserved.