Section 3.1. Windows Networking Concepts
3.1. Windows Networking ConceptsWindows is different from Unix in many ways, including how it supports networking. Before we get into the hands-on task of clicking our way through the configuration dialog boxes, it is best to establish a common foundation of networking technologies and concepts that apply to the entire family of Windows operating systems. These are the main client issues with which we will be dealing:
One can spend a lifetime understanding the ways in which Unix is different from Windows (in fact, Samba developers do just this), or the ways in which members of the Windows family are different from each other in underlying technology, behavior, or appearance. For now let's just focus on their similarities and determine any common ground. 3.1.1. Networking ComponentsUnix systems historically have been monolithic in nature, requiring recompilation or relinking to create a kernel with a customized feature set. Modern versions, however, have the ability to load or unload device drivers or various other operating-system features as modules while the system is running, without requiring a reboot. Windows allows for such configuration by installing or uninstalling components. Networking components can be one of three things:[*]
Figure 3-1 illustrates how these components work in conjunction with each other. The client and server components are distinct pieces that communicate with each other in the same fashion whether both exist on the same machine or reside on different machines in a network. Practically, the distinction is not so clean-cut, but in the abstract, this model still holds. Figure 3-1. An overview of the Microsoft networking puzzle Chapter 1 described how SMB/CIFS rests on top of a set of network services and explained that these services have been historically provided by a variety of protocols, such as NetBEUI, IPX/SPX, and NBT. Samba, however, supports only TCP/IP services, even through it does implement a NetBIOS layer internally. Field experience has proven that Windows clients accessing SMB/CIFS servers perform better when only one network protocol is installed. Older Windows releases such as Windows 95 and Windows NT 4.0 did not install TCP/IP by default, but rather included support for the NetBEUI protocol. Having NetBEUI running at the same time as NetBIOS over TCP/IP caused the system to look for services under two different protocols, only one of which was likely to be in use. Delays of up to 30 seconds resulted as Windows tried to communicate with the unused protocol. Eventually, the client timed out and attempted to use the next protocol in the list. This process continued until the desired service was located. This fruitless searching resulted in terrible performance. The moral of this story is to remove any unnecessary protocols and use only TCP/IP, if at all possible. The other two items in the list, client and service components, are pretty much what their names imply. Client components perform tasks related to connecting with network servers, and service components make the local system into a server of resources on the network. Microsoft has traditionally depended upon the presence of a working server service on Windows NT-based clients to perform management tasks such as remotely adding shares or creating users and groups. Even the MS-RPC-based printing implementation expects to be able to connect back to the client in order to report asynchronous change notification events, such as when a job has finished being printed. Therefore, it is extremely common for both the client and server component to be installed by default. The names for these items has evolved in various Windows releases. Windows NT 4.0 referred to the client component as the Workstation service and creatively named the server component the Server service. Windows 9x and Windows 2000 have standardized on the name Client for Microsoft Networks for the client piece and File and Printer Sharing for Microsoft Networks for the server piece. Once a networking component is installed, it must be bound to a hardware interface, or adapter, to be used on the network. At first this might seem like an odd complication; however, it is a conceptual model that allows the associations between hardware and software to be clearly displayed and easily modified through a graphical interface. Make sure that your Windows client has both TCP/IP and the client component for SMB networking installed, and that it is bound to the network adapter that connects to our Samba network, which in most cases is an Ethernet adapter. Firewalls are beginning to change the Windows landscape. With the default installation of a firewall in Windows XP Service Pack 2, it can no longer be assumed that all remote management tools work as you would expect them to work. For example, after installing SP2, it is probable that you will not even be able to ping the Windows XP host, although from the client's point of view, networking functions are operating correctly. You can view and modify the client's firewall settings by running control firewall.cpl from cmd.exe or the Run . . . option of the Start menu.
3.1.2. IP AddressJust like any Unix system (or any other system that is using TCP/IP), your Windows systems needs an IP address. If you have a DHCP server on your network, you can configure Windows to obtain its IP address automatically. Otherwise, you must assign a static IP address manually, along with a netmask. Make sure to use the same netmask as all other systems on the network. You can determine the netmask in use by checking with Unix or Windows systems that have already been configured. If you are on a private network where you have the authority to assign your own IP addresses, you can select from addresses in one of three ranges:
These address ranges are reserved for private networks that are not directly connected to the Internet. Keep in mind that IP addresses ending in .0 are reserved for network addresses and that ones ending in .255 are for broadcast addresses. These should never be assigned to any system on the network. For more information on using these private network addresses, see RFC 1918. If you're not maintaining your own separate network, see your system administrator for some available addresses on your network, as well as for the proper netmask to use. You should also be prepared to enter the IP address of the default gateway for the network. In some networks, the default gateway is the system or router that connects the LAN to the Internet. In other cases, the default gateway connects a subnet into a larger departmental or enterprise network. In the absence of a DHCP server and manual configuration, many clients support the so-called "dynamic" configuration addresses outlined by RFC 3927. These addresses exist within the 169.254.0.0/255.255.0.0 space and can be used only to communicate with other clients in the same broadcast space (also known as link local space). Dynamic configuration addresses are similar to the private addresses of RFC 1918, except that 169.254.0.0/16 addresses should not be routed at all, even within a private network. Unless a Windows client requires a static IP address, such as for doubling as a database or web server, the simplest solution is to install and configure a DHCP server for your network. The two most popular choices for this service are currently the Internet Systems Consortium's implementation (http://www.isc.org) or the DHCP server that ships with Windows 2000 and Windows Server 2003. Either solution is fine, as both support the basic TCP/IP network parameters and the additional data, such as WINS server addresses, required by Windows clients. 3.1.3. Name ResolutionName resolution is the function of translating human-friendly hostnames, such as lettuce, or fully qualified domain names (FQDNs), such as lettuce.garden.plainjoe.org, into IP addresses, such as 192.168.1.154 or 192.168.1.10. Unix systems perform name resolution using an /etc/hosts file at the minimum, and more commonly rely upon the DNS to perform this function.[*] The name resolution interface on Unix hosts is managed by the Name Service Switch (NSS) layer, which is often implemented as as part of the standard C library. The NSS configuration file, /etc/nsswitch.conf, controls the order in which services (DNS, /etc/hosts, and so on) are queried to resolve a name to an address.
Although the specific implementation is different, name resolution in Windows is also performed by querying a number of resources. For example, when you attempt to ping a host using its name, Windows uses all possible mechanisms at its disposal to resolve the name. Some of these resolution functions are similar (or even identical) to their Unix counterparts, and others are very foreign to Unix systems. In the past, DNS was considered unimportant for functioning Windows networks. Of course, it was still necessary for locating services on the Internet, but DNS was a nonissue in regard to finding and accessing file, print, and authentication services within the internal network. Things changed with the introduction of Windows 2000 and Active Directory. Now most services on a Windows network can be located by querying DNS server resource (SRV) records. (More about AD and DNS is provided in the context of Samba's domain membership capabilities in Chapter 10.) Chances are good that you need DNS for other services besides Windows and Samba and that it is already available on your network. If you don't know the IP addresses of the local DNS servers, check with another administrator or look them up in the /etc/resolv.conf file on one of your Unix servers. For those of us who still have NetBIOS services on our networks, WINS is usually a requirement. The basic operation of WINS was covered in Chapter 1. If you require a WINS server for your network, Samba can happily perform that function if you specify the following line in the [global] section of the server's smb.conf: wins support = yes One caveat about using Samba as a WINS server is that Samba (up to vbooleanersion 3.0.22, at least) cannot synchronize with other WINS servers. So if you specify a Samba server as your Windows system's WINS server, you must be careful not to specify any additional (i.e., secondary) WINS servers. If you do, you are likely to run into problems, because the servers will not be able to synchronize their databases with each other. In Samba's defense, if you are using a Samba WINS server (running on a typically reliable Unix host), you probably have little need for a secondary WINS server anyway. The scarcity of requests for WINS replication could be considerd a testimony to Samba's stability.[*]
If a Windows workstation has NetBIOS support enabled and has no WINS server address defined, it defaults to using the broadcast method of name resolution, as described in Chapter 1, probably resulting in a very busy network. This effect in itself makes Samba's WINS support more attractive. Beyond this however, it is impractical (if not impossible) to configure a working NetBIOS network with client and servers on different subnets without a working WINS infrastructure. 3.1.3.1. Windows' LMHOSTS and HOSTSFlat text files that contain name-to-address mappings are a relic of days gone by, when networks were small and central name services were unnecessary. Today, DNS and WINS services are more common than web or email servers. However, text files such as /etc/hosts are still in use to bootstrap a system before the networking service has been successfully started or as a backup means of locating vital services when name servers are unavailable. All Windows versions support using a pair of local files for name resolution. The two files, HOSTS and LMHOSTS, are stored in %Systemroot%\System32\drivers\etc.[*] As a general rule, it is better to avoid these files, due to the dynamic nature of Windows networks. But creative administrators can always come up with interesting scenarios that require bending the rules a bit.
The Windows HOSTS file is identical in syntax and function to its /etc/hosts cousin. At first glance, the LMHOSTS file appears to be identical as well. However, the scope of the LMHOSTS file is limited to handling NetBIOS name resolution queries from the local machine, and the file's syntax has been extended to handle certain NetBIOS features that were originally outside the scope of DNS, such as defining addresses for domain controllers. In its most basic form, each line in the LMHOSTS file is a single IP address and case-insensitive name: 192.168.1.154 LETTUCE More advanced Windows LMHOSTS files can be written using the following extensions:
For example, we could define the DC for the VALE domain by specifying: 192.168.1.154 LETTUCE #PRE #DOMAIN:VALE We could also use a centralized LMHOSTS file by making use of the #INCLUDE directive and a guest accessible file share name config: 192.168.1.11 MEL #PRE #INCLUDE \\MEL\config\lmhosts But even given this advanced functionality, it is really hard to come up with a good technical reason to use LMHOSTS files when a stable WINS server is easily within your grasp. |
EAN: 2147483647
Pages: 135