Very large number of markup fixes, layout updates, etc.
[samba.git] / docs / docbook / projdoc / Integrating-with-Windows.xml
1 <chapter id="integrate-ms-networks">
2  
3 <chapterinfo>
4         &author.jht;
5         <pubdate> (Jan 01 2001) </pubdate>
6 </chapterinfo>
7  
8 <title>Integrating MS Windows networks with Samba</title>
9  
10 <para>
11 This section deals with NetBIOS over TCP/IP name to IP address resolution. If
12 your MS Windows clients are NOT configured to use NetBIOS over TCP/IP then this
13 section does not apply to your installation. If your installation involves use of
14 NetBIOS over TCP/IP then this section may help you to resolve networking problems.
15 </para>
16
17 <note>
18 <para>
19         NetBIOS over TCP/IP has nothing to do with NetBEUI. NetBEUI is NetBIOS
20         over Logical Link Control (LLC). On modern networks it is highly advised
21         to NOT run NetBEUI at all. Note also that there is NO such thing as
22         NetBEUI over TCP/IP - the existence of such a protocol is a complete
23         and utter mis-apprehension.
24 </para>
25 </note>
26
27 <sect1>
28 <title>Features and Benefits</title>
29
30 <para>
31 Many MS Windows network administrators have never been exposed to basic TCP/IP
32 networking as it is implemented in a Unix/Linux operating system. Likewise, many Unix and
33 Linux adminsitrators have not been exposed to the intricacies of MS Windows TCP/IP based
34 networking (and may have no desire to be either).
35 </para>
36
37 <para>
38 This chapter gives a short introduction to the basics of how a name can be resolved to 
39 it's IP address for each operating system environment.
40 </para>
41
42 </sect1>
43
44 <sect1>
45 <title>Background Information</title>
46
47 <para>
48 Since the introduction of MS Windows 2000 it is possible to run MS Windows networking
49 without the use of NetBIOS over TCP/IP. NetBIOS over TCP/IP uses UDP port 137 for NetBIOS
50 name resolution and uses TCP port 139 for NetBIOS session services. When NetBIOS over
51 TCP/IP is disabled on MS Windows 2000 and later clients then only TCP port 445 will be
52 used and UDP port 137 and TCP port 139 will not.
53 </para>
54
55 <note>
56 <para>
57 When using Windows 2000 or later clients, if NetBIOS over TCP/IP is NOT disabled, then
58 the client will use UDP port 137 (NetBIOS Name Service, also known as the Windows Internet
59 Name Service or WINS), TCP port 139 AND TCP port 445 (for actual file and print traffic).
60 </para>
61 </note>
62
63 <para>
64 When NetBIOS over TCP/IP is disabled the use of DNS is essential. Most installations that
65 disable NetBIOS over TCP/IP today use MS Active Directory Service (ADS). ADS requires
66 Dynamic DNS with Service Resource Records (SRV RR) and with Incremental Zone Transfers (IXFR).
67 Use of DHCP with ADS is recommended as a further means of maintaining central control
68 over client workstation network configuration.
69 </para>
70
71 </sect1>
72
73 <sect1>
74 <title>Name Resolution in a pure Unix/Linux world</title>
75
76 <para>
77 The key configuration files covered in this section are:
78 </para>
79
80 <itemizedlist>
81         <listitem><para><filename>/etc/hosts</filename></para></listitem>
82         <listitem><para><filename>/etc/resolv.conf</filename></para></listitem>
83         <listitem><para><filename>/etc/host.conf</filename></para></listitem>
84         <listitem><para><filename>/etc/nsswitch.conf</filename></para></listitem>
85 </itemizedlist>
86
87 <sect2>
88 <title><filename>/etc/hosts</filename></title>
89
90 <para>
91 Contains a static list of IP Addresses and names.
92 eg:
93 </para>
94 <para><screen>
95         127.0.0.1       localhost localhost.localdomain
96         192.168.1.1     bigbox.caldera.com      bigbox  alias4box
97 </screen></para>
98
99 <para>
100 The purpose of <filename>/etc/hosts</filename> is to provide a 
101 name resolution mechanism so that uses do not need to remember 
102 IP addresses.
103 </para>
104
105
106 <para>
107 Network packets that are sent over the physical network transport 
108 layer communicate not via IP addresses but rather using the Media 
109 Access Control address, or MAC address. IP Addresses are currently 
110 32 bits in length and are typically presented as four (4) decimal 
111 numbers that are separated by a dot (or period). eg: 168.192.1.1.
112 </para>
113
114 <para>
115 MAC Addresses use 48 bits (or 6 bytes) and are typically represented 
116 as two digit hexadecimal numbers separated by colons. eg: 
117 40:8e:0a:12:34:56
118 </para>
119
120 <para>
121 Every network interface must have an MAC address. Associated with 
122 a MAC address there may be one or more IP addresses. There is NO 
123 relationship between an IP address and a MAC address, all such assignments 
124 are arbitary or discretionary in nature. At the most basic level all 
125 network communications takes place using MAC addressing. Since MAC 
126 addresses must be globally unique, and generally remains fixed for 
127 any particular interface, the assignment of an IP address makes sense 
128 from a network management perspective. More than one IP address can 
129 be assigned per MAC address. One address must be the primary IP address, 
130 this is the address that will be returned in the ARP reply.
131 </para>
132
133 <para>
134 When a user or a process wants to communicate with another machine 
135 the protocol implementation ensures that the "machine name" or "host 
136 name" is resolved to an IP address in a manner that is controlled 
137 by the TCP/IP configuration control files. The file 
138 <filename>/etc/hosts</filename> is one such file.
139 </para>
140
141 <para>
142 When the IP address of the destination interface has been 
143 determined a protocol called ARP/RARP is used to identify 
144 the MAC address of the target interface. ARP stands for Address 
145 Resolution Protocol, and is a broadcast oriented method that 
146 uses UDP (User Datagram Protocol) to send a request to all 
147 interfaces on the local network segment using the all 1's MAC 
148 address. Network interfaces are programmed to respond to two 
149 MAC addresses only; their own unique address and the address 
150 ff:ff:ff:ff:ff:ff. The reply packet from an ARP request will 
151 contain the MAC address and the primary IP address for each 
152 interface.
153 </para>
154
155 <para>
156 The <filename>/etc/hosts</filename> file is foundational to all 
157 Unix/Linux TCP/IP installations and as a minumum will contain 
158 the localhost and local network interface IP addresses and the 
159 primary names by which they are known within the local machine. 
160 This file helps to prime the pump so that a basic level of name 
161 resolution can exist before any other method of name resolution 
162 becomes available.
163 </para>
164
165 </sect2>
166
167
168 <sect2>
169 <title><filename>/etc/resolv.conf</filename></title>
170
171 <para>
172 This file tells the name resolution libraries:
173 </para>
174
175 <itemizedlist>
176         <listitem><para>The name of the domain to which the machine 
177         belongs
178         </para></listitem>
179         
180         <listitem><para>The name(s) of any domains that should be 
181         automatically searched when trying to resolve unqualified 
182         host names to their IP address
183         </para></listitem>
184         
185         <listitem><para>The name or IP address of available Domain 
186         Name Servers that may be asked to perform name to address 
187         translation lookups
188         </para></listitem>
189 </itemizedlist>
190
191 </sect2>
192
193
194 <sect2>
195 <title><filename>/etc/host.conf</filename></title>
196
197
198 <para>
199 <filename>/etc/host.conf</filename> is the primary means by 
200 which the setting in /etc/resolv.conf may be affected. It is a 
201 critical configuration file.  This file controls the order by 
202 which name resolution may procede. The typical structure is:
203 </para>
204
205 <para><screen>
206         order hosts,bind
207         multi on
208 </screen></para>
209
210 <para>
211 then both addresses should be returned. Please refer to the 
212 man page for host.conf for further details.
213 </para>
214
215
216 </sect2>
217
218
219
220 <sect2>
221 <title><filename>/etc/nsswitch.conf</filename></title>
222
223 <para>
224 This file controls the actual name resolution targets. The 
225 file typically has resolver object specifications as follows:
226 </para>
227
228
229 <para><screen>
230         # /etc/nsswitch.conf
231         #
232         # Name Service Switch configuration file.
233         #
234
235         passwd:         compat
236         # Alternative entries for password authentication are:
237         # passwd:       compat files nis ldap winbind
238         shadow:         compat
239         group:          compat
240
241         hosts:          files nis dns
242         # Alternative entries for host name resolution are:
243         # hosts:        files dns nis nis+ hesoid db compat ldap wins
244         networks:       nis files dns
245
246         ethers:         nis files
247         protocols:      nis files
248         rpc:            nis files
249         services:       nis files
250 </screen></para>
251
252 <para>
253 Of course, each of these mechanisms requires that the appropriate 
254 facilities and/or services are correctly configured.
255 </para>
256
257 <para>
258 It should be noted that unless a network request/message must be 
259 sent, TCP/IP networks are silent. All TCP/IP communications assumes a 
260 principal of speaking only when necessary.
261 </para>
262
263 <para>
264 Starting with version 2.2.0 samba has Linux support for extensions to 
265 the name service switch infrastructure so that linux clients will 
266 be able to obtain resolution of MS Windows NetBIOS names to IP 
267 Addresses. To gain this functionality Samba needs to be compiled 
268 with appropriate arguments to the make command (ie: <userinput>make 
269 nsswitch/libnss_wins.so</userinput>). The resulting library should 
270 then be installed in the <filename>/lib</filename> directory and 
271 the "wins" parameter needs to be added to the "hosts:" line in 
272 the <filename>/etc/nsswitch.conf</filename> file. At this point it 
273 will be possible to ping any MS Windows machine by it's NetBIOS 
274 machine name, so long as that machine is within the workgroup to 
275 which both the samba machine and the MS Windows machine belong.
276 </para>
277
278 </sect2>
279 </sect1>
280
281
282 <sect1>
283 <title>Name resolution as used within MS Windows networking</title>
284
285 <para>
286 MS Windows networking is predicated about the name each machine 
287 is given. This name is known variously (and inconsistently) as 
288 the "computer name", "machine name", "networking name", "netbios name", 
289 "SMB name". All terms mean the same thing with the exception of 
290 "netbios name" which can apply also to the name of the workgroup or the 
291 domain name. The terms "workgroup" and "domain" are really just a 
292 simply name with which the machine is associated. All NetBIOS names 
293 are exactly 16 characters in length. The 16th character is reserved. 
294 It is used to store a one byte value that indicates service level 
295 information for the NetBIOS name that is registered. A NetBIOS machine 
296 name is therefore registered for each service type that is provided by 
297 the client/server.
298 </para>
299
300 <para>
301 The following are typical NetBIOS name/service type registrations:
302 </para>
303
304 <para><screen>
305         Unique NetBIOS Names:
306                 MACHINENAME&lt;00&gt;   = Server Service is running on MACHINENAME
307                 MACHINENAME&lt;03&gt; = Generic Machine Name (NetBIOS name)
308                 MACHINENAME&lt;20&gt; = LanMan Server service is running on MACHINENAME
309                 WORKGROUP&lt;1b&gt; = Domain Master Browser
310
311         Group Names:
312                 WORKGROUP&lt;03&gt; = Generic Name registered by all members of WORKGROUP
313                 WORKGROUP&lt;1c&gt; = Domain Controllers / Netlogon Servers
314                 WORKGROUP&lt;1d&gt; = Local Master Browsers
315                 WORKGROUP&lt;1e&gt; = Internet Name Resolvers
316 </screen></para>
317
318 <para>
319 It should be noted that all NetBIOS machines register their own 
320 names as per the above. This is in vast contrast to TCP/IP 
321 installations where traditionally the system administrator will 
322 determine in the /etc/hosts or in the DNS database what names 
323 are associated with each IP address.
324 </para>
325
326 <para>
327 One further point of clarification should be noted, the <filename>/etc/hosts</filename> 
328 file and the DNS records do not provide the NetBIOS name type information 
329 that MS Windows clients depend on to locate the type of service that may 
330 be needed. An example of this is what happens when an MS Windows client 
331 wants to locate a domain logon server. It finds this service and the IP 
332 address of a server that provides it by performing a lookup (via a 
333 NetBIOS broadcast) for enumeration of all machines that have 
334 registered the name type *&lt;1c&gt;. A logon request is then sent to each 
335 IP address that is returned in the enumerated list of IP addresses. Which 
336 ever machine first replies then ends up providing the logon services.
337 </para>
338
339 <para>
340 The name "workgroup" or "domain" really can be confusing since these 
341 have the added significance of indicating what is the security 
342 architecture of the MS Windows network. The term "workgroup" indicates 
343 that the primary nature of the network environment is that of a 
344 peer-to-peer design. In a WORKGROUP all machines are responsible for 
345 their own security, and generally such security is limited to use of 
346 just a password (known as SHARE MODE security). In most situations 
347 with peer-to-peer networking the users who control their own machines 
348 will simply opt to have no security at all. It is possible to have 
349 USER MODE security in a WORKGROUP environment, thus requiring use 
350 of a user name and a matching password.
351 </para>
352
353 <para>
354 MS Windows networking is thus predetermined to use machine names 
355 for all local and remote machine message passing. The protocol used is 
356 called Server Message Block (SMB) and this is implemented using 
357 the NetBIOS protocol (Network Basic Input Output System). NetBIOS can 
358 be encapsulated using LLC (Logical Link Control) protocol - in which case 
359 the resulting protocol is called NetBEUI (Network Basic Extended User 
360 Interface). NetBIOS can also be run over IPX (Internetworking Packet 
361 Exchange) protocol as used by Novell NetWare, and it can be run 
362 over TCP/IP protocols - in which case the resulting protocol is called 
363 NBT or NetBT, the NetBIOS over TCP/IP.
364 </para>
365
366 <para>
367 MS Windows machines use a complex array of name resolution mechanisms. 
368 Since we are primarily concerned with TCP/IP this demonstration is 
369 limited to this area.
370 </para>
371
372 <sect2>
373 <title>The NetBIOS Name Cache</title>
374
375 <para>
376 All MS Windows machines employ an in memory buffer in which is 
377 stored the NetBIOS names and IP addresses for all external 
378 machines that that machine has communicated with over the 
379 past 10-15 minutes. It is more efficient to obtain an IP address 
380 for a machine from the local cache than it is to go through all the 
381 configured name resolution mechanisms.
382 </para>
383
384 <para>
385 If a machine whose name is in the local name cache has been shut 
386 down before the name had been expired and flushed from the cache, then 
387 an attempt to exchange a message with that machine will be subject 
388 to time-out delays. i.e.: Its name is in the cache, so a name resolution 
389 lookup will succeed, but the machine can not respond. This can be 
390 frustrating for users - but it is a characteristic of the protocol.
391 </para>
392
393 <para>
394 The MS Windows utility that allows examination of the NetBIOS 
395 name cache is called "nbtstat". The Samba equivalent of this 
396 is called <command>nmblookup</command>.
397 </para>
398
399 </sect2>
400
401 <sect2>
402 <title>The LMHOSTS file</title>
403
404 <para>
405 This file is usually located in MS Windows NT 4.0 or 
406 2000 in <filename>C:\WINNT\SYSTEM32\DRIVERS\ETC</filename> and contains 
407 the IP Address and the machine name in matched pairs. The 
408 <filename>LMHOSTS</filename> file performs NetBIOS name 
409 to IP address mapping.
410 </para>
411
412 <para>
413 It typically looks like:
414 </para>
415
416 <para><screen>
417         # Copyright (c) 1998 Microsoft Corp.
418         #
419         # This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS
420         # over TCP/IP) stack for Windows98
421         #
422         # This file contains the mappings of IP addresses to NT computernames
423         # (NetBIOS) names.  Each entry should be kept on an individual line.
424         # The IP address should be placed in the first column followed by the
425         # corresponding computername. The address and the comptername
426         # should be separated by at least one space or tab. The "#" character
427         # is generally used to denote the start of a comment (see the exceptions
428         # below).
429         #
430         # This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts
431         # files and offers the following extensions:
432         #
433         #      #PRE
434         #      #DOM:&lt;domain&gt;
435         #      #INCLUDE &lt;filename&gt;
436         #      #BEGIN_ALTERNATE
437         #      #END_ALTERNATE
438         #      \0xnn (non-printing character support)
439         #
440         # Following any entry in the file with the characters "#PRE" will cause
441         # the entry to be preloaded into the name cache. By default, entries are
442         # not preloaded, but are parsed only after dynamic name resolution fails.
443         #
444         # Following an entry with the "#DOM:&lt;domain&gt;" tag will associate the
445         # entry with the domain specified by &lt;domain&gt;. This affects how the
446         # browser and logon services behave in TCP/IP environments. To preload
447         # the host name associated with #DOM entry, it is necessary to also add a
448         # #PRE to the line. The &lt;domain&gt; is always preloaded although it will not
449         # be shown when the name cache is viewed.
450         #
451         # Specifying "#INCLUDE &lt;filename&gt;" will force the RFC NetBIOS (NBT)
452         # software to seek the specified &lt;filename&gt; and parse it as if it were
453         # local. &lt;filename&gt; is generally a UNC-based name, allowing a
454         # centralized lmhosts file to be maintained on a server.
455         # It is ALWAYS necessary to provide a mapping for the IP address of the
456         # server prior to the #INCLUDE. This mapping must use the #PRE directive.
457         # In addtion the share "public" in the example below must be in the
458         # LanManServer list of "NullSessionShares" in order for client machines to
459         # be able to read the lmhosts file successfully. This key is under
460         # \machine\system\currentcontrolset\services\lanmanserver\parameters\nullsessionshares
461         # in the registry. Simply add "public" to the list found there.
462         #
463         # The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE
464         # statements to be grouped together. Any single successful include
465         # will cause the group to succeed.
466         #
467         # Finally, non-printing characters can be embedded in mappings by
468         # first surrounding the NetBIOS name in quotations, then using the
469         # \0xnn notation to specify a hex value for a non-printing character.
470         #
471         # The following example illustrates all of these extensions:
472         #
473         # 102.54.94.97     rhino         #PRE #DOM:networking  #net group's DC
474         # 102.54.94.102    "appname  \0x14"                    #special app server
475         # 102.54.94.123    popular            #PRE             #source server
476         # 102.54.94.117    localsrv           #PRE             #needed for the include
477         #
478         # #BEGIN_ALTERNATE
479         # #INCLUDE \\localsrv\public\lmhosts
480         # #INCLUDE \\rhino\public\lmhosts
481         # #END_ALTERNATE
482         #
483         # In the above example, the "appname" server contains a special
484         # character in its name, the "popular" and "localsrv" server names are
485         # preloaded, and the "rhino" server name is specified so it can be used
486         # to later #INCLUDE a centrally maintained lmhosts file if the "localsrv"
487         # system is unavailable.
488         #
489         # Note that the whole file is parsed including comments on each lookup,
490         # so keeping the number of comments to a minimum will improve performance.
491         # Therefore it is not advisable to simply add lmhosts file entries onto the
492         # end of this file.
493 </screen></para>
494
495 </sect2>
496
497 <sect2>
498 <title>HOSTS file</title>
499
500 <para>
501 This file is usually located in MS Windows NT 4.0 or 2000 in 
502 <filename>C:\WINNT\SYSTEM32\DRIVERS\ETC</filename> and contains 
503 the IP Address and the IP hostname in matched pairs. It can be 
504 used by the name resolution infrastructure in MS Windows, depending 
505 on how the TCP/IP environment is configured. This file is in 
506 every way the equivalent of the Unix/Linux <filename>/etc/hosts</filename> file.
507 </para>
508 </sect2>
509
510
511 <sect2>
512 <title>DNS Lookup</title>
513
514 <para>
515 This capability is configured in the TCP/IP setup area in the network 
516 configuration facility. If enabled an elaborate name resolution sequence 
517 is followed the precise nature of which is dependant on what the NetBIOS 
518 Node Type parameter is configured to. A Node Type of 0 means use 
519 NetBIOS broadcast (over UDP broadcast) is first used if the name 
520 that is the subject of a name lookup is not found in the NetBIOS name 
521 cache. If that fails then DNS, HOSTS and LMHOSTS are checked. If set to 
522 Node Type 8, then a NetBIOS Unicast (over UDP Unicast) is sent to the 
523 WINS Server to obtain a lookup before DNS, HOSTS, LMHOSTS, or broadcast 
524 lookup is used.
525 </para>
526
527 </sect2>
528
529 <sect2>
530 <title>WINS Lookup</title>
531
532 <para>
533 A WINS (Windows Internet Name Server) service is the equivaent of the 
534 rfc1001/1002 specified NBNS (NetBIOS Name Server). A WINS server stores 
535 the names and IP addresses that are registered by a Windows client 
536 if the TCP/IP setup has been given at least one WINS Server IP Address.
537 </para>
538
539 <para>
540 To configure Samba to be a WINS server the following parameter needs 
541 to be added to the &smb.conf; file:
542 </para>
543
544 <para><screen>
545         wins support = Yes
546 </screen></para>
547
548 <para>
549 To configure Samba to use a WINS server the following parameters are 
550 needed in the &smb.conf; file:
551 </para>
552
553 <para><screen>
554         wins support = No
555         wins server = xxx.xxx.xxx.xxx
556 </screen></para>
557
558 <para>
559 where <replaceable>xxx.xxx.xxx.xxx</replaceable> is the IP address 
560 of the WINS server.
561 </para>
562
563 </sect2>
564 </sect1>
565
566 <sect1>
567 <title>Common Errors</title>
568
569 <para>
570 TCP/IP network configuration problems find every network administrator sooner or later.
571 The cause can be anything from keybaord mishaps, forgetfulness, simple mistakes, and
572 carelessness. Of course, noone is every deliberately careless!
573 </para>
574
575         <sect2>
576         <title>My Boomerang Won't Come Back</title>
577
578         <para>
579         Well, the real complaint said, "I can ping my samba server from Windows, but I can
580         not ping my Windows machine from the samba server."
581         </para>
582
583         <para>
584         The Windows machine was at IP Address 192.168.1.2 with netmask 255.255.255.0, the
585         Samba server (Linux) was at IP Address 192.168.1.130 with netmast 255.255.255.128.
586         The machines were on a local network with no external connections.
587         </para>
588
589         <para>
590         Due to inconsistent netmasks, the Windows machine was on network 192.168.1.0/24, while
591         the Samba server was on network 192.168.1.128/25 - logically a different network.
592         </para>
593
594         </sect2>
595
596         <sect2>
597         <title>Very Slow Network Connections</title>
598
599         <para>
600         A common causes of slow network response includes:
601         </para>
602
603         <itemizedlist>
604                 <listitem><para>Client is configured to use DNS and DNS server is down</para></listitem>
605                 <listitem><para>Client is configured to use remote DNS server, but remote connection is down</para></listitem>
606                 <listitem><para>Client is configured to use a WINS server, but there is no WINS server</para></listitem>
607                 <listitem><para>Client is NOT configured to use a WINS server, but there is a WINS server</para></listitem>
608                 <listitem><para>Firewall is filtering our DNS or WINS traffic</para></listitem>
609         </itemizedlist>
610
611         </sect2>
612
613         <sect2>
614         <title>Samba server name change problem</title>
615
616         <para>
617         The name of the samba server was changed, samba was restarted, samba server can not be
618         pinged by new name from MS Windows NT4 Workstation, but it does still respond to ping using
619         the old name. Why?
620         </para>
621
622         <para>
623         From this description three (3) things are rather obvious:
624         </para>
625
626         <itemizedlist>
627                 <listitem><para>WINS is NOT in use, only broadcast based name resolution is used</para></listitem>
628                 <listitem><para>The samba server was renamed and restarted within the last 10-15 minutes</para></listitem>
629                 <listitem><para>The old samba server name is still in the NetBIOS name cache on the MS Windows NT4 Workstation</para></listitem>
630         </itemizedlist>
631
632         <para>
633         To find what names are present in the NetBIOS name cache on the MS Windows NT4 machine,
634         open a cmd shell, then:
635         </para>
636
637         <para>
638         <screen>
639         C:\temp\&gt;nbtstat -n
640
641                       NetBIOS Local Name Table
642
643            Name                 Type          Status
644         ------------------------------------------------
645         SLACK            &lt;03&gt;  UNIQUE      Registered
646         ADMININSTRATOR   &lt;03&gt;  UNIQUE      Registered
647         SLACK            &lt;00&gt;  UNIQUE      Registered
648         SARDON           &lt;00&gt;  GROUP       Registered
649         SLACK            &lt;20&gt;  UNIQUE      Registered
650         SLACK            &lt;1F&gt;  UNIQUE      Registered
651
652
653         C:\Temp\&gt;nbtstat -c
654
655                      NetBIOS Remote Cache Name Table
656
657            Name                 Type       Host Address     Life [sec]
658         --------------------------------------------------------------
659         FRODO            &lt;20&gt;  UNIQUE      192.168.1.1          240
660
661         C:\Temp\&gt;
662         </screen>
663         </para>
664
665         <para>
666         In the above example, FRODO is the Samba server and SLACK is the MS Windows NT4 Workstation.
667         The first listing shows the contents of the Local Name Table (ie: Identity information on
668         the MS Windows workstation), the second shows the NetBIOS name in the NetBIOS name cache.
669         The name cache contains the remote machines known to this workstation.
670         </para>
671
672         </sect2>
673
674 </sect1>
675
676 </chapter>