1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="SAMBA Project Documentation"
HREF="samba-howto-collection.html"><LINK
REL="UP"
TITLE="General installation"
HREF="introduction.html"><LINK
REL="PREVIOUS"
TITLE="How to Install and Test SAMBA"
HREF="install.html"><LINK
REL="NEXT"
TITLE="User information database"
HREF="passdb.html"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>SAMBA Project Documentation</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="install.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="passdb.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="BROWSING-QUICK"
></A
>Chapter 2. Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</H1
><P
>This document should be read in conjunction with Browsing and may
be taken as the fast track guide to implementing browsing across subnets
and / or across workgroups (or domains). WINS is the best tool for resolution
of NetBIOS names to IP addesses. WINS is NOT involved in browse list handling
except by way of name to address mapping.</P
><DIV
CLASS="NOTE"
><P
></P
><TABLE
CLASS="NOTE"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="/usr/share/sgml/docbook/stylesheet/dsssl/modular/images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>MS Windows 2000 and later can be configured to operate with NO NetBIOS
over TCP/IP. Samba-3 and later also supports this mode of operation.</P
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN174"
>2.1. Discussion</A
></H1
><P
>Firstly, all MS Windows networking is based on SMB (Server Message
Block) based messaging. SMB messaging may be implemented using NetBIOS or
without NetBIOS. Samba implements NetBIOS by encapsulating it over TCP/IP.
MS Windows products can do likewise. NetBIOS based networking uses broadcast
messaging to affect browse list management. When running NetBIOS over
TCP/IP this uses UDP based messaging. UDP messages can be broadcast or unicast.</P
><P
>Normally, only unicast UDP messaging can be forwarded by routers. The
<B
CLASS="COMMAND"
>remote announce</B
>
parameter to smb.conf helps to project browse announcements
to remote network segments via unicast UDP. Similarly, the
<B
CLASS="COMMAND"
>remote browse sync</B
> parameter of <TT
CLASS="FILENAME"
>smb.conf</TT
>
implements browse list collation using unicast UDP.</P
><P
>Secondly, in those networks where Samba is the only SMB server technology
wherever possible nmbd should be configured on one (1) machine as the WINS
server. This makes it easy to manage the browsing environment. If each network
segment is configured with it's own Samba WINS server, then the only way to
get cross segment browsing to work is by using the
<B
CLASS="COMMAND"
>remote announce</B
> and the <B
CLASS="COMMAND"
>remote browse sync</B
>
parameters to your <TT
CLASS="FILENAME"
>smb.conf</TT
> file.</P
><P
>If only one WINS server is used for an entire multi-segment network then
the use of the <B
CLASS="COMMAND"
>remote announce</B
> and the
<B
CLASS="COMMAND"
>remote browse sync</B
> parameters should NOT be necessary.</P
><P
>As of Samba 3 WINS replication is being worked on. The bulk of the code has
been committed, but it still needs maturation.</P
><P
>Right now samba WINS does not support MS-WINS replication. This means that
when setting up Samba as a WINS server there must only be one nmbd configured
as a WINS server on the network. Some sites have used multiple Samba WINS
servers for redundancy (one server per subnet) and then used
<B
CLASS="COMMAND"
>remote browse sync</B
> and <B
CLASS="COMMAND"
>remote announce</B
>
to affect browse list collation across all
segments. Note that this means clients will only resolve local names,
and must be configured to use DNS to resolve names on other subnets in
order to resolve the IP addresses of the servers they can see on other
subnets. This setup is not recommended, but is mentioned as a practical
consideration (ie: an 'if all else fails' scenario).</P
><P
>Lastly, take note that browse lists are a collection of unreliable broadcast
messages that are repeated at intervals of not more than 15 minutes. This means
that it will take time to establish a browse list and it can take up to 45
minutes to stabilise, particularly across network segments.</P
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN193"
>2.2. How browsing functions and how to deploy stable and
dependable browsing using Samba</A
></H1
><P
>As stated above, MS Windows machines register their NetBIOS names
(i.e.: the machine name for each service type in operation) on start
up. Also, as stated above, the exact method by which this name registration
takes place is determined by whether or not the MS Windows client/server
has been given a WINS server address, whether or not LMHOSTS lookup
is enabled, or if DNS for NetBIOS name resolution is enabled, etc.</P
><P
>In the case where there is no WINS server all name registrations as
well as name lookups are done by UDP broadcast. This isolates name
resolution to the local subnet, unless LMHOSTS is used to list all
names and IP addresses. In such situations Samba provides a means by
which the samba server name may be forcibly injected into the browse
list of a remote MS Windows network (using the
<B
CLASS="COMMAND"
>remote announce</B
> parameter).</P
><P
>Where a WINS server is used, the MS Windows client will use UDP
unicast to register with the WINS server. Such packets can be routed
and thus WINS allows name resolution to function across routed networks.</P
><P
>During the startup process an election will take place to create a
local master browser if one does not already exist. On each NetBIOS network
one machine will be elected to function as the domain master browser. This
domain browsing has nothing to do with MS security domain control.
Instead, the domain master browser serves the role of contacting each local
master browser (found by asking WINS or from LMHOSTS) and exchanging browse
list contents. This way every master browser will eventually obtain a complete
list of all machines that are on the network. Every 11-15 minutes an election
is held to determine which machine will be the master browser. By the nature of
the election criteria used, the machine with the highest uptime, or the
most senior protocol version, or other criteria, will win the election
as domain master browser.</P
><P
>Clients wishing to browse the network make use of this list, but also depend
on the availability of correct name resolution to the respective IP
address/addresses. </P
><P
>Any configuration that breaks name resolution and/or browsing intrinsics
will annoy users because they will have to put up with protracted
inability to use the network services.</P
><P
>Samba supports a feature that allows forced synchonisation
of browse lists across routed networks using the <B
CLASS="COMMAND"
>remote
browse sync</B
> parameter in the <TT
CLASS="FILENAME"
>smb.conf</TT
> file.
This causes Samba to contact the local master browser on a remote network and
to request browse list synchronisation. This effectively bridges
two networks that are separated by routers. The two remote
networks may use either broadcast based name resolution or WINS
based name resolution, but it should be noted that the <B
CLASS="COMMAND"
>remote
browse sync</B
> parameter provides browse list synchronisation - and
that is distinct from name to address resolution, in other
words, for cross subnet browsing to function correctly it is
essential that a name to address resolution mechanism be provided.
This mechanism could be via DNS, <TT
CLASS="FILENAME"
>/etc/hosts</TT
>,
and so on.</P
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN207"
>2.3. Use of the <B
CLASS="COMMAND"
>Remote Announce</B
> parameter</A
></H1
><P
>The <B
CLASS="COMMAND"
>remote announce</B
> parameter of
<TT
CLASS="FILENAME"
>smb.conf</TT
> can be used to forcibly ensure
that all the NetBIOS names on a network get announced to a remote network.
The syntax of the <B
CLASS="COMMAND"
>remote announce</B
> parameter is:
<PRE
CLASS="PROGRAMLISTING"
> remote announce = <VAR
CLASS="REPLACEABLE"
>a.b.c.d [e.f.g.h]</VAR
> ...</PRE
>
_or_
<PRE
CLASS="PROGRAMLISTING"
> remote announce = <VAR
CLASS="REPLACEABLE"
>a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP]</VAR
> ...</PRE
>
where:
<P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><VAR
CLASS="REPLACEABLE"
>a.b.c.d</VAR
> and
<VAR
CLASS="REPLACEABLE"
>e.f.g.h</VAR
></DT
><DD
><P
>is either the LMB (Local Master Browser) IP address
or the broadcst address of the remote network.
ie: the LMB is at 192.168.1.10, or the address
could be given as 192.168.1.255 where the netmask
is assumed to be 24 bits (255.255.255.0).
When the remote announcement is made to the broadcast
address of the remote network every host will receive
our announcements. This is noisy and therefore
undesirable but may be necessary if we do NOT know
the IP address of the remote LMB.</P
></DD
><DT
><VAR
CLASS="REPLACEABLE"
>WORKGROUP</VAR
></DT
><DD
><P
>is optional and can be either our own workgroup
or that of the remote network. If you use the
workgroup name of the remote network then our
NetBIOS machine names will end up looking like
they belong to that workgroup, this may cause
name resolution problems and should be avoided.</P
></DD
></DL
></DIV
></P
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN230"
>2.4. Use of the <B
CLASS="COMMAND"
>Remote Browse Sync</B
> parameter</A
></H1
><P
>The <B
CLASS="COMMAND"
>remote browse sync</B
> parameter of
<TT
CLASS="FILENAME"
>smb.conf</TT
> is used to announce to
another LMB that it must synchronise it's NetBIOS name list with our
Samba LMB. It works ONLY if the Samba server that has this option is
simultaneously the LMB on it's network segment.</P
><P
>The syntax of the <B
CLASS="COMMAND"
>remote browse sync</B
> parameter is:
<PRE
CLASS="PROGRAMLISTING"
>remote browse sync = <VAR
CLASS="REPLACEABLE"
>a.b.c.d</VAR
></PRE
>
where <VAR
CLASS="REPLACEABLE"
>a.b.c.d</VAR
> is either the IP address of the remote LMB or else is the network broadcast address of the remote segment.</P
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN241"
>2.5. Use of WINS</A
></H1
><P
>Use of WINS (either Samba WINS _or_ MS Windows NT Server WINS) is highly
recommended. Every NetBIOS machine registers it's name together with a
name_type value for each of of several types of service it has available.
eg: It registers it's name directly as a unique (the type 0x03) name.
It also registers it's name if it is running the lanmanager compatible
server service (used to make shares and printers available to other users)
by registering the server (the type 0x20) name.</P
><P
>All NetBIOS names are up to 15 characters in length. The name_type variable
is added to the end of the name - thus creating a 16 character name. Any
name that is shorter than 15 characters is padded with spaces to the 15th
character. ie: All NetBIOS names are 16 characters long (including the
name_type information).</P
><P
>WINS can store these 16 character names as they get registered. A client
that wants to log onto the network can ask the WINS server for a list
of all names that have registered the NetLogon service name_type. This saves
broadcast traffic and greatly expedites logon processing. Since broadcast
name resolution can not be used across network segments this type of
information can only be provided via WINS _or_ via statically configured
<TT
CLASS="FILENAME"
>lmhosts</TT
> files that must reside on all clients in the
absence of WINS.</P
><P
>WINS also serves the purpose of forcing browse list synchronisation by all
LMB's. LMB's must synchronise their browse list with the DMB (domain master
browser) and WINS helps the LMB to identify it's DMB. By definition this
will work only within a single workgroup. Note that the domain master browser
has NOTHING to do with what is referred to as an MS Windows NT Domain. The
later is a reference to a security environment while the DMB refers to the
master controller for browse list information only.</P
><P
>Use of WINS will work correctly only if EVERY client TCP/IP protocol stack
has been configured to use the WINS server/s. Any client that has not been
configured to use the WINS server will continue to use only broadcast based
name registration so that WINS may NEVER get to know about it. In any case,
machines that have not registered with a WINS server will fail name to address
lookup attempts by other clients and will therefore cause workstation access
errors.</P
><P
>To configure Samba as a WINS server just add
<B
CLASS="COMMAND"
>wins support = yes</B
> to the <TT
CLASS="FILENAME"
>smb.conf</TT
>
file [globals] section.</P
><P
>To configure Samba to register with a WINS server just add
"wins server = a.b.c.d" to your smb.conf file [globals] section.</P
><P
><SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>DO NOT EVER</I
></SPAN
> use both "wins support = yes" together
with "wins server = a.b.c.d" particularly not using it's own IP address.
Specifying both will cause nmbd to refuse to start!</P
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN255"
>2.6. Do NOT use more than one (1) protocol on MS Windows machines</A
></H1
><P
>A very common cause of browsing problems results from installing more than
one protocol on an MS Windows machine.</P
><P
>Every NetBIOS machine takes part in a process of electing the LMB (and DMB)
every 15 minutes. A set of election criteria is used to determine the order
of precidence for winning this election process. A machine running Samba or
Windows NT will be biased so that the most suitable machine will predictably
win and thus retain it's role.</P
><P
>The election process is "fought out" so to speak over every NetBIOS network
interface. In the case of a Windows 9x machine that has both TCP/IP and IPX
installed and has NetBIOS enabled over both protocols the election will be
decided over both protocols. As often happens, if the Windows 9x machine is
the only one with both protocols then the LMB may be won on the NetBIOS
interface over the IPX protocol. Samba will then lose the LMB role as Windows
9x will insist it knows who the LMB is. Samba will then cease to function
as an LMB and thus browse list operation on all TCP/IP only machines will
fail.</P
><P
><SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>Windows 95, 98, 98se, Me are referred to generically as Windows 9x.
The Windows NT4, 2000, XP and 2003 use common protocols. These are roughly
referred to as the WinNT family, but it should be recognised that 2000 and
XP/2003 introduce new protocol extensions that cause them to behave
differently from MS Windows NT4. Generally, where a server does NOT support
the newer or extended protocol, these will fall back to the NT4 protocols.</I
></SPAN
></P
><P
>The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!</P
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN263"
>2.7. Name Resolution Order</A
></H1
><P
>Resolution of NetBIOS names to IP addresses can take place using a number
of methods. The only ones that can provide NetBIOS name_type information
are:</P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
>WINS: the best tool!</TD
></TR
><TR
><TD
>LMHOSTS: is static and hard to maintain.</TD
></TR
><TR
><TD
>Broadcast: uses UDP and can not resolve names across remote segments.</TD
></TR
></TBODY
></TABLE
><P
></P
><P
>Alternative means of name resolution includes:</P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
>/etc/hosts: is static, hard to maintain, and lacks name_type info</TD
></TR
><TR
><TD
>DNS: is a good choice but lacks essential name_type info.</TD
></TR
></TBODY
></TABLE
><P
></P
><P
>Many sites want to restrict DNS lookups and want to avoid broadcast name
resolution traffic. The "name resolve order" parameter is of great help here.
The syntax of the "name resolve order" parameter is:
<PRE
CLASS="PROGRAMLISTING"
>name resolve order = wins lmhosts bcast host</PRE
>
_or_
<PRE
CLASS="PROGRAMLISTING"
>name resolve order = wins lmhosts (eliminates bcast and host)</PRE
>
The default is:
<PRE
CLASS="PROGRAMLISTING"
>name resolve order = host lmhost wins bcast</PRE
>.
where "host" refers the the native methods used by the Unix system
to implement the gethostbyname() function call. This is normally
controlled by <TT
CLASS="FILENAME"
>/etc/host.conf</TT
>, <TT
CLASS="FILENAME"
>/etc/nsswitch.conf</TT
> and <TT
CLASS="FILENAME"
>/etc/resolv.conf</TT
>.</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="install.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="samba-howto-collection.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="passdb.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>How to Install and Test SAMBA</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="introduction.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>User information database</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
|
