Keep off the grass! | ||
| --Suburban yard sign | ||
The houses are painted in cheerful colors, there are flowers in the window boxes, people greet you as you walk down the street, and the dogs never bark after sunset. It seems a lovely place in which to open a small teashop and perhaps, someday, retire. Before you decide to move in, though, there are a few things you probably need to know about the Network Neighborhood.
Behind the picture-postcard facade there lies a complex political and social structure, collectively known as the Browse Service. Many people consider the Browse Service to be mysterious and secretive, perhaps because most of its business is handled discreetly, out of the view of the casual tourists. The Browse Service lurks in the background, gathering, maintaining, and distributing the Browse List—the list of available servers and workgroups.
You can sneak a peek at the Browse List by clicking the Network Neighborhood icon on a Microsoft Windows desktop. If all is working as it should, you will be presented with a neatly organized graphical view of the available SMB filesharing environment. It will look something like the image in Figure 19.1. By selecting icons you can traverse the SMB hierarchy and view workgroups, servers, print queues, shares, directories, and files. In CIFS terms, this is called “browsing” the network.[1]
The original Browse Service staked its claim alongside the LANMAN1.0 dialect, back in the frontier days of OS/2. Its descendants stayed on and prospered through the LM1.2X002 and LANMAN2.1 days, and then quietly faded into legend. There aren’t many systems around today that still earn their keep by running LAN Manager style browsing, as it is known, yet the legacy lives on. Windows systems generally have a server configuration check-box to enable LAN Manager browser announcements, and Samba has an LM ANNOUNCE parameter for the same purpose.
When Windows NT rode into town, it brought along a newfangled Browse Service. Like its predecessor, the new system was built upon the NetBIOS API. It was an improvement over the older version in that it could exchange and combine Browse Lists with remote Browsers on distant LANs, thus bringing the world a little closer together. That version of the Browse Service is the same one most folks still use today, and it is the one we will be studying in detail.
Then came the Information Superhighway, and Windows 2000 arrived in a bright blue limousine with a fancy new Browse Service hanging on its arm. The W2K browsing system is designed to run on naked TCP transport, and it is built on top of Active Directory and the LDAP protocol. As you may have come to expect by now, covering Directory Services is more than this book is trying to achieve so we won’t spend a lot of time on W2K browsing. Besides, Windows 2000 and Windows XP are both backward compatible with previous Windows versions, and can still support the older NetBIOS-based Windows Browse Service.
Another thing that has changed since Windows 2000 arrived is the name of the Network Neighborhood. These days, it is called “My Network Places.” A discussion of the implications of the shift in metaphor from one relating the network environment to a cohesive and open community to one of self-centered virtual oligarchy is also way the heck beyond the scope of this book.
The Browse Service, as was stated earlier, has a social structure. SMB servers and clients are expected to be members of cliques known as “workgroups” or “domains.” The basic difference between a workgroup and a domain is that the latter provides central authentication services via Domain Controllers.
Just to make life more interesting, there are two types of domain to consider:
Windows 2000 Domains
As explained above, Windows 2000 provides a browse system that is based on Directory Services (Active Directory, etc.). W2K Domains are not NBT-based, so they do not use NetBIOS names. Instead, W2K Domains are closely aligned with the Domain Name System (DNS) and rely on Kerberos for authentication. This is Microsoft’s way of grafting their domain architecture onto the Internet Domain Name System.
Windows NT Domains
NT Domains are glorified workgroups, but that’s not a particularly helpful description since we haven’t really explained what a workgroup is yet.
A workgroup, quite simply, is defined by its NetBIOS name. The workgroup name is typically assigned in the node’s configuration, although utilities like smbclient and toolkits like jCIFS allow the workgroup name to be specified at run-time. As with the node’s machine name, the workgroup name is used as the basis for NetBIOS names that are actually registered — just add the appropriate suffix byte. Systems do not need to register any name based on the workgroup unless they are offering services to the workgroup as a whole. Some example workgroup names:
That just scratches the surface, and doesn’t really tell us anything about NT Domains. Fully explaining what workgroups and NT Domains are all about and how the names listed above are used is something of a recursive problem because the sociology of the Browse Service is intertwined with the politics.
On the local level, the Windows Browse Service is a volunteer organization. Nodes that are willing and able to donate some memory and CPU cycles make themselves available to the community by registering a special NetBIOS group name with a suffix byte value of 0x1E, as shown in the table above. That name is then used to hold an election and choose a workgroup leader.[2] The election winner is given the title of “Master Browser,” and it registers a unique NetBIOS name with a suffix byte value of 0x1D. It also registers the strangely-formatted group name “x01x02__MSBROWSE__x02x01” (that last ’x01’ is actually the suffix byte).
As you may recall from the rant in Chapter 7 on page 141, Microsoft’s WINS server provides special handling for unique names with the 0x1D suffix. Though the Master Browser may register this name with the WINS server, WINS will deny knowledge of the name when queried. WINS also returns 255.255.255.255 in response to name queries for group names. Most third-party NBNS implementations behave the same way in order to be WINS-compatible.
Two key things happen as a result:
The NBNS provides no useful information when queried for either the workgroup
<1D>name or theMSBROWSE<01>[3] name, so Master Browsers can only be found using NBT Broadcast Name Queries.Each separate IP subnet may have a Master Browser with the same unique
0x1Dname. Even if there is an NBNS, there will be no name conflict.T
This is highly unusual behavior for NetBIOS names but, on the plus side, each subnet in the Network Neighborhood gets to have its own elected leader. On the minus side, the Master Browsers cannot exchange information because they cannot talk to one another.
Figure 19.2 shows three separate workgroups, all with the same base name: “WORKGROUP”. They are distinct because they cannot exchange and combine Browse Lists. In order to bring these three together, we need yet another special node: the “Domain Master Browser.”
Because they cannot “see” one another, Master Browsers on separate IP subnets register the same unique NBT name without conflict.
Figure 19.2. Isolated Master Browsers
Pedantic Phrasing Alert
Just to make it absolutely clear that the elected Master Browser is LAN-locked, and to distinguish it from the Domain Master Browser, from this point forward we will use the term Local Master Browser (LMB).
The Domain Master Browser (DMB) is the workgroup president. Unlike the democratically elected LMB, the DMB is appointed. The Network Manager (that’s a human being) must select and configure a node to serve as DMB. The DMB will register the unique NetBIOS name workgroup<1B> to identify itself. Since the goal here is to bring together Browse Lists from separate subnets, there must also be an NBNS available so that all of the LMBs on all of the subnets can find the DMB.
Figure 19.3 (which is, admittedly, a bit complex) shows a single, unified workgroup. Node AMOS has been designated to act as the NBNS, and node DENNY has been given the job of Domain Master Browser. Nodes TZUKE and MCSHEE are Local Master Browsers for their own subnets. They will query the NBNS for the name WORKGROUP<1B>, and then contact the DMB in order to exchange Browse Lists. Note that the DMB takes on the role of LMB on its own subnet.
The existence of a Domain Master Browser and an NBNS allows the Local Master Browsers on each subnet to exchange Browse Lists.
Figure 19.3. A unified workgroup
A workgroup is not a workgroup when it is an NT Domain.
The difference between a workgroup and an NT Domain is that the latter has a Domain Controller, which is an authentication server. The Domain Controller keeps track of usernames and passwords, and all of the SMB file servers within the NT Domain are expected to consult with the Domain Controller whenever a client sends a SESSION SETUP REQUEST SMB.
In the Windows world, the DMB service is always offered by a Primary Domain Controller (PDC). The two are considered inseparable, so if you are using Windows, you must set up a PDC in order to offer DMB services, and vice versa. This is probably why the DMB is called a Domain Master Browser.
Samba, on the other hand, lets you set up a DMB without the requirement that you also set up a PDC. Since DMB services do not, in fact, rely upon any NT Domain functionality, the DMB can operate independently. On the other hand, if you do wish to set up a PDC, then the PDC node must also be the DMB — even with Samba. This latter restriction is a bit goofy. The reason for the requirement is that Microsoft’s WINS (and, therefore, any WINS-compatible NBNS) provides special handling for a group name registered by the Domain Controllers. Consider the following table:
Name & Suffix | Service/Description | |
|---|---|---|
unique | This name is registered by the Domain Master Browser. It must be registered with the NBNS in order to be of any real use. | |
Internet group | Registered by all Domain Controllers in the given NT Domain. |
The goofy bit, which has been described elsewhere in this book, is that the WINS server keeps track of up to 25 IPs for the <1C> group name. WINS also ensures that the IP address of the node registering the <1B> name is always the first in the <1C> name’s IP list. That last quirk is the only real linkage between the DMB and PDC names:
Within the NBT namespace, the Primary Domain Controller is distinguished from the Backup Domain Controllers by the fact that it also runs the DMB service and, therefore, registers the
<1B>name.
This all brings up a small nomenclature problem: If there is a DMB running without a PDC (as Samba allows), is the result a workgroup or a domain? That situation was not anticipated by Microsoft, so the terminology doesn’t quite work. (Can you call it a Domain Master Browser if there’s no NT Domain?)
So far, we have described Local Master Browsers and Domain Master Browsers. There are two additional types of browsers to consider.
Now we can explain that a “Browser” is any node that participates in the creation and maintenance of the Browse Service. As we have shown, browsers are categorized as Potential, Backup, Local Master, or Domain Master. Browser roles are cumulative, and the Domain Master is at the top of the heap.
If the socio-political system seems overly complex, keep in mind that:
The Windows Browse Service was developed in the days when 386- and 486-class processors were the top of the line.
The Browse Service is run behind-the-scenes by systems that volunteer CPU time and a bit of memory.
The more nodes there are on the subnet, the more work that must be done by the Local Master Browser.
There may be several nodes on the network that are capable of acting as a Browser.
If the nodes are unstable (frequently rebooted, shut down at the end of the day, etc.) a single copy of the Browse List may be lost.
All of this plays into the design of the Windows Browse Service.
The key thing to remember is that the Local Master Browser (unless it is also the DMB) is a volunteer, and being a Browser is not its primary function. The LMB node is, most likely, running as an SMB server or desktop system, or doing some other work. Allowing the Browse Service to interfere with someone’s word processing or spreadsheet recalculations would be a bad thing.
So, on subnets with a lot of nodes, the LMB may select some of the Potential Browsers to act as Backup Browsers. When a client wants a copy of the Browse List, the LMB may direct the client to one or more Backup Browsers instead. The client will cache the IP addresses of the Backup Browsers, and from that point forward send all Browse List queries to one of those nodes. The Backup Browsers are also the most likely nodes to replace the current LMB if it goes down, and the backup copies of the Browse List that they maintain will ensure stability in the Network Neighborhood.
[1] IBM and Microsoft should not be blamed for any confusion between Network Neighborhood browsing and Web browsing. They started using the term “browse” well before the advent of the web.
[2] Mnemonic: 0x1Election.
[3] From here on out, we use “MSBROWSE<01>” as a shorthand for “x01x02__MSBROWSE__x02x01” because it’s really annoying to have to type all of those hex escapes and underscores every time.