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:

+ +

+
Making sure required networking components are installed and bound to +the network adapter
+
+
Configuring networking with a valid IP address, netmask and gateway, +and WINS and DNS name servers
+
+
Assigning workgroup and computer names
+
+
Setting the username(s) and password(s)
+

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.

+ + +

+ +

Components

+ +

Unix +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]

+ +

+
Protocols
+
+
Clients
+
+
Services
+

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.

+ + +

+ +

Bindings

+ +

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.

+ +

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.

+ + +

+ +

IP Address

+ +

Just 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]

+ +

+
10.0.0.1 through 10.255.255.254
+
+
172.16.0.1 through 172.31.255.254
+
+
192.168.0.1 through 192.168.255.254
+

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.

+ + +

+ +

Name Resolution

+ +

Name 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.

+ + +

+ +

Broadcast name resolution

+ +

On 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.

+ + +

+ + + +

+ +

WINS

+ +

We'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.

WARNING
+
One caveat about using Samba as a WINS server is that Samba (up to Version +2.2, 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 will probably have little need for a secondary WINS +server anyway.
+

+ + +

+ + + +

+ +

LMHOSTS

+ +

All 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.

+ + +

+ + + +

+ +

DNS

+ +

The 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.

+ + +

+ + + +

+ +

HOSTS

+ +

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.

+ + +

+ +

Passwords

+ +

Unix 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.

+ +

TIP
+
Keep in mind that we are continuing our example from Chapter 2, in which we are setting up a very simple +prototype network using a workgroup that has very lax security. After +you have the basics working, we recommend you continue with later +chapters to learn how to implement both better security and a Samba +domain.
+

+ + +

Chapter 3. Configuring Windows Clients

Windows Networking Concepts

Components

Bindings

IP Address

Name Resolution

Broadcast name resolution

WINS

WARNING

LMHOSTS

DNS

HOSTS

Passwords

TIP

Setting Up Windows 95/98/Me Computers

Setting Up the Network

Adding TCP/IP

Configuring TCP/IP

IP Address tab

WINS Configuration tab

WARNING

DNS Configuration tab

LMHOSTS file

NetBIOS tab

Bindings tab

Setting the Computer Name and Workgroup

Username and Password

Logging in for the first time

Accessing the Samba Server from Windows 95/98

Accessing the Samba Server from Windows Me

Setting Up Windows NT 4.0 Computers

Basic Configuration

Installing the TCP/IP protocol

Installing the Workstation service

Configuring TCP/IP

IP Address tab

WINS Address tab

DNS tab

The LMHOSTS file

Bindings

Computer Name and Workgroup

WARNING

Adding a User

TIP

Connecting to the Samba Server

Setting Up Windows 2000 Computers

Networking Components

Bindings

Configuring TCP/IP

IP address

DNS server

WINS server

The LMHOSTS file

Computer and Workgroup Names

WARNING

Adding a Samba-Enabled User

WARNING

Connecting to the Samba Server

Setting Up Windows XP Computers

Networking Components

Bindings

Configuring TCP/IP

IP address

DNS server

WINS server

The LMHOSTS file

Computer and Workgroup Names

WARNING

Adding a Samba-Enabled User

TIP

Connecting to the Samba Server

Footnotes