 |  |
20.4. The Windows Browser
The 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 Workgroups
Every 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 Roles
A 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 subnets
In 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.
20.4.2.1. Domain master browser
The 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.)
20.4.2.2. Master browser
A 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:
- They broadcast their lists of hosts and domains to the backup browsers (using the group with the name of the domain and the type 1E).
- They broadcast their domain and name to the other master browsers (using the group _MSBROWSE_).
- They synchronize their lists of hosts and domains with their domain master browser (using the unique name with the name of the domain and the type 1B or, if that fails, the group name with the name of the domain and the type 1C).
- They tell machines that are potential browsers to become backup browsers (using a packet that is an IP unicast but has a NetBT destination of the group name with the name of the domain and the type 1E).
20.4.2.3. Backup browsers
Backup 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.
20.4.2.4. Potential browsers
Potential 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.
20.4.2.5. Browseable server
Any 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.
20.4.2.6. Browser client
A client that's in the domain "netherworld" and wants to look up a browse list for the domain "limbo" goes through the following steps:
- Sends a GetBackupListRequest via a NetBT message at UDP port 138 to the special unique name "netherworld<1d>" (this is sent as an IP broadcast and is processed only by the local master browser).
- Sends a GetBackupListRequest to the unique name "netherworld<1b>" (this is sent as an IP unicast because it's a unique name, and it goes to the domain master browser, which is also the primary domain controller).
- Gets back two lists of servers, which contain computer names.
- Selects three of the servers listed in the browser lists provided to it and saves them for future browsing.
- Asks one of those three servers for a list of domains and workgroups; this comes back with the names of the domains or workgroups and the computer name of the local master browser for each one. This is a NetBT session conversation at TCP port 139.
- Sends a name resolution query for the name "limbo<1d>" via broadcast to UDP port 137 (NetBT name service). This is a special query that is done over broadcast even on a machine that would otherwise try WINS before broadcast.
- If step 6 succeeded, sends a request for a list of members to the machine "limbo<1d>". This is once again a NetBT session conversation at TCP port 139.
- If there was no response to the previous request, resolves the computer name listed as the master browser for domain "limbo" by the machine's standard name resolution procedure and connects to it over NetBT session for a list of members.
20.4.3. Browser Elections
Elections 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:
- A client will call an election if it tries to find a master browser and cannot. In this case, it will send out an election packet that is guaranteed to lose (all the parameters are set to zero). This is called an election force. If the client is also a potential browser server, it will not send out its real election packet unless it gets one from a less-qualified candidate, or it gets no response to repeated election force attempts.
- A browser server will call an election if it receives a master browser announcement from a less qualified machine. This should normally happen only when a more qualified machine boots onto a network (for instance, when a machine running Windows NT Server comes onto a network of machines running Windows 98). However, you may see less qualified machines boot and immediately claim to be master servers, thereby forcing elections on otherwise stable networks.
20.4.4. Security Implications of the Windows Browser
Obviously, 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 Browser
The 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 Browser
Because 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 Browser
Not 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.
