3.1 Windows Networking Concepts
| Windows 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 dialog boxes to configure each version of Windows, we need to provide you with a common foundation of networking technologies and concepts that apply to the entire family of Windows operating systems. For each Windows version, these are the main issues we will be dealing with:
In addition, some minor issues involving communication and coordination between Windows and Unix are different among Windows versions. One can go crazy thinking about the ways in which Unix is different from Windows, 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 see if we can find some common ground. 3.1.1 ComponentsUnix systems historically have been monolithic in nature, requiring recompilation or relinking to create a kernel with a customized feature set. However, modern versions have the ability to load or unload device drivers or various other operating-system features as modules while the system is running, without even needing to reboot. Windows allows for configuration by installing or uninstalling components . As far as networking goes, components can be one of three things: [1]
Since Samba works using the TCP/IP protocol, of course we'll want to have that installed. In some cases, we also will want to find protocols to uninstall . For example, if Netware protocol (IPX/SPX) is not required on the network, it might as well be removed. NetBEUI protocol should be removed if possible. Having NetBEUI running at the same time as NetBIOS over TCP/IP causes the system to look for services under two different protocols, only one of which is likely to be in use. When Windows is configured with one or more unused protocols, 30-second delays will result when Windows tries to communicate with the unused protocol. Eventually, it times out and tries another one, until it finds one that works. This fruitless searching results in terrible performance. The other two items in the list, client and service components, are pretty much what you'd expect. Client components perform tasks related to connecting with network servers, and service components are for making the local system into a server of resources on the network. In Chapter 1 we told you that SMB systems can act as both clients and servers, offering resources on the network at the same time they request resources. In accordance with that, it is possible to install a component for SMB client services and, separately, a service component that allows file and printer shares on the local system to be accessible from other systems on the network. 3.1.1.1 BindingsOnce 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. We will want to make sure that your Windows client has both TCP/IP and the client component for SMB networking installed and also that it is bound to the network adapter that connects to our Samba network, which in most cases will be an Ethernet adapter. 3.1.2 IP AddressJust like any Unix system (or any other system that is using TCP/IP), your Windows systems will need an IP address. If you are using DHCP on your network, you can configure Windows to obtain its IP address automatically by using a DHCP server. Otherwise, you will need to assign a static IP address manually along with a netmask. [2]
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: [3]
These address ranges are reserved for private networks not directly connected to the Internet. 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. 3.1.3 Name ResolutionName resolution is the function of translating human-friendly hostnames, such as hopi , or fully qualified domain names (FQDNs), such as mixtec.metran.cx , into IP addresses, such as 172.16.1.11 or 172.16.1.7. Unix systems can perform name resolution using an /etc/ hosts file at the minimum, and more commonly can also incorporate services such as DNS (Domain Name System) and NIS (Network Information Service). Thus, name resolution is not necessarily performed by one isolated part of the operating system or one daemon, but is a system that can have a number of dispersed parts (although the name service switch, with its /etc/nsswitch.conf configuration file, helps to tie them together). Although the specific implementation is different, name resolution in Windows is also performed by querying a number of resources, some of which are similar (or even identical) to their Unix counterparts. 3.1.3.1 Broadcast name resolutionOn the other hand, there is one way in which Windows is not at all similar to Unix. If a Windows workstation is set up with no WINS name server, it will use the broadcast method of name resolution, as described in Chapter 1, [4] probably resulting in a very busy network. And even if you provide name servers for your Windows system to use, it might still resort to broadcast name resolution if it is unsuccessful at querying the name servers. For this reason, we recommend that you provide multiple reliable name servers for your Windows computers on the network.
If that weren't enough to get you interested in setting up WINS and DNS servers, broadcast name resolution is usually limited to working on the local subnet because routers are usually configured not to forward broadcast packets to other networks. 3.1.3.2 WINSWe've already told you about WINS in Chapter 1, and we don't have much more to say about it here. WINS can translate simple NetBIOS computer names such as huastec or navajo into IP addresses, as required on an SMB network. Of course, the interesting thing here is that Samba can act as a WINS server if you include the line: wins support = yes in your Samba server's smb.conf file. This can be a good thing, to be sure, and we highly recommend it. Not only will you have a reliable WINS server to reduce the number of broadcast packets, but you won't need to run Windows NT/2000/XP to get it.
3.1.3.3 LMHOSTSAll Windows versions support a backup method of name resolution, in the form of a file called LMHOSTS [5] that contains a lookup table of computer names and IP addresses. This exists for "historical purposes," and is a rather awkward method of name resolution because it requires the administrator (i.e., you!) to keep copies of LMHOSTS up to date on every single Windows system on the network. To be fully effective, LMHOSTS would have to be updated every time a new system were added to (or removed from) the network. Of course, there might be ways to automate that process, but a better option would be simply to run a WINS name server that is intentionally designed to solve that specific problem.
There are perhaps a couple of reasons why you might want to bother with LMHOSTS files. In rare situations, there might be no WINS server on the network. Or maybe a WINS server exists, but it's unreliable. In both cases, if the Windows system has a valid LMHOSTS file, it can help to avoid your network bogging down from those dreaded broadcast name queries. The format of the LMHOSTS file is simple and similar to the /etc/hosts file with which you might be familiar from running Unix systems. Here are the contents of a sample LMHOSTS file: 172.16.1.1 toltec 172.16.1.2 aztec 172.16.1.3 mixtec 172.16.1.4 zapotec 172.16.1.5 huastec 172.16.1.6 maya 172.16.1.7 olmec 172.16.1.8 chichimec 172.16.1.11 hopi 172.16.1.12 zuni 172.16.1.13 dine 172.16.1.14 pima 172.16.1.15 apache 172.16.1.21 inca 172.16.1.22 qero As you can see, the format is like that of /etc/hosts , except that instead of an FQDN (e.g., toltec.metran.cx ), only a NetBIOS computer name ( toltec ) is given. One way to create an LMHOSTS file for your Windows systems is to copy a /etc/hosts file and edit out the parts you don't need. This will work great if your network doesn't have a DNS (or NIS) name server and the Unix system is dependent on /etc/hosts for its own name service. But if your Unix system is querying a DNS server (which is the most frequent case on anything larger than the very smallest networks), you would be better advised to look in the DNS server's configuration files for your source of computer names and IP addresses. If you do not have administrative access to your network's DNS server, you might be able to use tools such as nslookup , nmap , and dig to query the server and obtain the information you need. 3.1.3.4 DNSThe DNS is responsible for translating human-readable , Internet-style hostnames such as pima.metran.cx or sales.oreilly.com into IP addresses. On your first reading of this section, you might be wondering what a section on DNS is doing in a book about NetBIOS and SMB networking. Remember, we told you that Windows can use more than WINS (NetBIOS Name Service) in its strategy for performing name resolution. Because DNS is also able to supply IP addresses for simple hostnames (which are usually the same as NetBIOS computer names), it can be helpful to configure Windows to know about a DNS server on your network. This is slightly more important for newer Windows versions than older ones, and more so for Windows NT/2000/XP than for Windows 95/98/Me, because nowadays Microsoft is focusing more on TCP/IP as the standard protocol and DNS as the primary name service. To find the address of your DNS server, look at the file /etc/resolv.conf on your Samba server or any other Unix system on the local network that is using DNS. It looks like the following: #resolv.conf domain metran.cx nameserver 127.0.0.1 nameserver 172.16.1.53 In this example, the first name server in the list is 127.0.0.1, which indicates that the Samba server is also a DNS server for this LAN. [6] In that case, you would use its network IP address (not 127.0.0.1, its localhost address) for your DNS server when configuring Windows. Otherwise, use the other addresses you find in the lines beginning with nameserver . Try to select ones on your own network. Any name servers listed in /etc/resolv.conf should work, but you'll get better performance by using a server nearby.
All versions of Windows can be configured to know of multiple domain name servers, and you might wish to take advantage of this for increased reliability. If the first domain name server does not respond, Windows can try others in its list. 3.1.3.5 HOSTSSimilar to how the LMHOSTS file can be added to supplement WINS, the HOSTS file on a Windows system can be optionally added to supplement DNS name resolution. Most of our comments regarding LMHOSTS also apply here. This time the format of the file is not just similar to that of /etc/hosts found on Unix ”the format is exactly the same. You can simply copy /etc/hosts from your Samba server or other Unix system to the proper directory on your Windows system. On Windows 95/98/Me, the HOSTS file goes in the Windows installation directory, which is usually C:\Windows . Note that a file called hosts.sam is already there, which is a sample HOSTS file provided by Microsoft. On Windows NT/2000/XP, the HOSTS file goes in the \system32\drivers\etc directory under the Windows installation directory, which is usually C:\WINNT . 3.1.4 PasswordsUnix systems use username and password pairs to authenticate users either on a local system or in an NIS domain. Windows NT/2000/XP are very similar; a user supplies his username and password to log on to the local system or to a Windows domain. When the SMB network is set up as a workgroup, things are different. There is no domain to log on to, although shares on the network can be password-protected. In this case, one password is associated with each password-protected share, rather than with individual users. Samba's default user-level authentication in a workgroup is different from that of Windows. To access shares on the Samba host, users are required to supply a valid username and password for an account on the Samba host. This will be discussed in more detail in Chapter 9. An unfortunate complication arises with passwords. In the first release of Windows 95 and in Windows NT 4.0 with Service Pack 2 (SP2) or less, as well as in all previous versions of Windows, passwords are allowed to be sent over the network in plain text. But in Windows 95 with the network redirector update, [7]
Windows NT 4.0 SP3 or later, and all subsequent releases of Windows, a registry setting must be modified to enable plain-text passwords. These more modern versions of Windows prefer to send encrypted passwords, and if you are working with one of them (and don't want to have to modify the registry), you must have the line: encrypt passwords = yes in the [global] section of your smb.conf file. In addition, you must run the command: # smbpasswd -a username for each user on the Samba host to add their passwords to Samba's collection of encrypted passwords. We showed you how to do this in Chapter 2. If your first attempt to access a Samba share results in a dialog box asking for a password for IPC$ , as shown in Figure 3-1, it is probably because you neglected either or both of these two steps, and the Samba server did not recognize the encrypted password that the Windows system sent to it. Another possible dialog box that might come up is the one shown in Figure 3-2, which was presented by a Windows 2000 client. Figure 3-1. Windows 98 asking for IPC$ password Figure 3-2. Windows 2000 logon error dialog The rest of this chapter is divided into four sections. The first section covers setting up Windows 95/98/Me computers, and the rest of the sections cover Windows NT 4.0, Windows 2000, and Windows XP individually. Each section roughly parallels the order in which we've introduced networking concepts in this section. You need to read only the section that applies to the Windows version with which you are working, and once you have finished reading it, you can continue at the beginning of the next chapter where we will start covering more advanced Samba features and networking issues.
|
EAN: 2147483647
Pages: 475