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
|
<!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.77"><LINK
REL="HOME"
TITLE="SAMBA Project Documentation"
HREF="samba-howto-collection.html"><LINK
REL="UP"
TITLE="General installation"
HREF="p18.html"><LINK
REL="PREVIOUS"
TITLE="Oplocks"
HREF="oplocks.html"><LINK
REL="NEXT"
TITLE="LanMan and NT Password Encryption in Samba"
HREF="pwencrypt.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="oplocks.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="pwencrypt.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="BROWSING-QUICK"
></A
>Chapter 4. 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="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN392"
></A
>4.1. Discussion</H1
><P
>Firstly, all MS Windows networking is based on SMB (Server Message
Block) based messaging. SMB messaging is implemented using 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
"remote announce" parameter to smb.conf helps to project browse announcements
to remote network segments via unicast UDP. Similarly, the "remote browse sync"
parameter of smb.conf 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 "remote announce" and
the "remote browse sync" parameters to your smb.conf file.</P
><P
>If only one WINS server is used then the use of the "remote announce" and the
"remote browse sync" parameters should NOT be necessary.</P
><P
>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 "remote browse sync" and "remote announce"
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="AEN400"
></A
>4.2. Use of the "Remote Announce" parameter</H1
><P
>The "remote announce" parameter of smb.conf can be used to forcibly ensure
that all the NetBIOS names on a network get announced to a remote network.
The syntax of the "remote announce" parameter is:
<PRE
CLASS="PROGRAMLISTING"
> remote announce = a.b.c.d [e.f.g.h] ...</PRE
>
_or_
<PRE
CLASS="PROGRAMLISTING"
> remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...</PRE
>
where:
<P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>a.b.c.d and e.f.g.h</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
>WORKGROUP</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="AEN414"
></A
>4.3. Use of the "Remote Browse Sync" parameter</H1
><P
>The "remote browse sync" parameter of smb.conf 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 "remote browse sync" parameter is:
<PRE
CLASS="PROGRAMLISTING"
> remote browse sync = a.b.c.d</PRE
>
where a.b.c.d 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="AEN419"
></A
>4.4. Use of WINS</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
"lmhosts" 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 "wins support = yes" to the
smb.conf 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.</P
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN430"
></A
>4.5. Do NOT use more than one (1) protocol on MS Windows machines</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 take 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
>The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!</P
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN436"
></A
>4.6. Name Resolution Order</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
><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
><P
>Alternative means of name resolution includes:
<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
><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="oplocks.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="pwencrypt.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Oplocks</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="p18.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>LanMan and NT Password Encryption in Samba</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
|
