diff options
Diffstat (limited to 'docs/htmldocs/browsing-quick.html')
| -rw-r--r-- | docs/htmldocs/browsing-quick.html | 413 |
1 files changed, 74 insertions, 339 deletions
diff --git a/docs/htmldocs/browsing-quick.html b/docs/htmldocs/browsing-quick.html index 95a1ca3504..8c597e001f 100644 --- a/docs/htmldocs/browsing-quick.html +++ b/docs/htmldocs/browsing-quick.html @@ -5,7 +5,8 @@ >Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK +CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+ +"><LINK REL="HOME" TITLE="SAMBA Project Documentation" HREF="samba-howto-collection.html"><LINK @@ -13,11 +14,11 @@ REL="UP" TITLE="General installation" HREF="introduction.html"><LINK REL="PREVIOUS" -TITLE="How to Install and Test SAMBA" -HREF="install.html"><LINK +TITLE="Improved browsing in samba" +HREF="improved-browsing.html"><LINK REL="NEXT" -TITLE="User information database" -HREF="passdb.html"></HEAD +TITLE="LanMan and NT Password Encryption in Samba" +HREF="pwencrypt.html"></HEAD ><BODY CLASS="CHAPTER" BGCOLOR="#FFFFFF" @@ -45,7 +46,7 @@ WIDTH="10%" ALIGN="left" VALIGN="bottom" ><A -HREF="install.html" +HREF="improved-browsing.html" ACCESSKEY="P" >Prev</A ></TD @@ -59,7 +60,7 @@ WIDTH="10%" ALIGN="right" VALIGN="bottom" ><A -HREF="passdb.html" +HREF="pwencrypt.html" ACCESSKEY="N" >Next</A ></TD @@ -72,9 +73,7 @@ WIDTH="100%"></DIV CLASS="CHAPTER" ><H1 ><A -NAME="BROWSING-QUICK" -></A ->Chapter 2. Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</H1 +NAME="BROWSING-QUICK">Chapter 3. 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 @@ -82,117 +81,43 @@ 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="AEN183" ->2.1. Discussion</A -></H1 +NAME="AEN377">3.1. Discussion</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 +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 -<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 +"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 <SPAN -CLASS="APPLICATION" ->nmbd</SPAN -> should be configured on one (1) machine as the WINS +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 <SPAN -CLASS="APPLICATION" ->nmbd</SPAN -> 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 +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 @@ -204,120 +129,19 @@ CLASS="SECT1" ><H1 CLASS="SECT1" ><A -NAME="AEN204" ->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="AEN218" ->2.3. Use of the <B -CLASS="COMMAND" ->Remote Announce</B -> parameter</A -></H1 +NAME="AEN385">3.2. Use of the "Remote Announce" parameter</H1 ><P ->The <B -CLASS="COMMAND" ->remote announce</B -> parameter of -<TT -CLASS="FILENAME" ->smb.conf</TT -> can be used to forcibly ensure +>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 <B -CLASS="COMMAND" ->remote announce</B -> parameter is: +The syntax of the "remote announce" parameter is: <PRE CLASS="PROGRAMLISTING" -> remote announce = <VAR -CLASS="REPLACEABLE" ->a.b.c.d [e.f.g.h]</VAR -> ...</PRE +> remote announce = a.b.c.d [e.f.g.h] ...</PRE > _or_ <PRE CLASS="PROGRAMLISTING" -> remote announce = <VAR -CLASS="REPLACEABLE" ->a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP]</VAR -> ...</PRE +> remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...</PRE > where: @@ -327,14 +151,7 @@ where: CLASS="VARIABLELIST" ><DL ><DT -><VAR -CLASS="REPLACEABLE" ->a.b.c.d</VAR -> and -<VAR -CLASS="REPLACEABLE" ->e.f.g.h</VAR -></DT +>a.b.c.d and e.f.g.h</DT ><DD ><P >is either the LMB (Local Master Browser) IP address @@ -349,10 +166,7 @@ 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 +>WORKGROUP</DT ><DD ><P >is optional and can be either our own workgroup @@ -371,51 +185,27 @@ CLASS="SECT1" ><H1 CLASS="SECT1" ><A -NAME="AEN241" ->2.4. Use of the <B -CLASS="COMMAND" ->Remote Browse Sync</B -> parameter</A -></H1 +NAME="AEN399">3.3. Use of the "Remote Browse Sync" parameter</H1 ><P ->The <B -CLASS="COMMAND" ->remote browse sync</B -> parameter of -<TT -CLASS="FILENAME" ->smb.conf</TT -> is used to announce to +>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 <B -CLASS="COMMAND" ->remote browse sync</B -> parameter is: - +>The syntax of the "remote browse sync" parameter is: <PRE CLASS="PROGRAMLISTING" ->remote browse sync = <VAR -CLASS="REPLACEABLE" ->a.b.c.d</VAR -></PRE +> remote browse sync = a.b.c.d</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 +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="AEN252" ->2.5. Use of WINS</A -></H1 +NAME="AEN404">3.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 @@ -437,11 +227,7 @@ 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 +"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 @@ -459,70 +245,32 @@ 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 +>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 -><DIV -CLASS="IMPORTANT" -><P -></P -><TABLE -CLASS="IMPORTANT" -WIDTH="100%" -BORDER="0" -><TR -><TD -WIDTH="25" -ALIGN="CENTER" -VALIGN="TOP" -><IMG -SRC="/usr/share/sgml/docbook/stylesheet/dsssl/modular/images/important.gif" -HSPACE="5" -ALT="Important"></TD -><TD -ALIGN="LEFT" -VALIGN="TOP" ><P ->Never use both <B -CLASS="COMMAND" ->wins support = yes</B -> together -with <B -CLASS="COMMAND" ->wins server = a.b.c.d</B -> -particularly not using it's own IP address. -Specifying both will cause <SPAN -CLASS="APPLICATION" ->nmbd</SPAN -> to refuse to start!</P -></TD -></TR -></TABLE -></DIV +><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="AEN269" ->2.6. Do NOT use more than one (1) protocol on MS Windows machines</A -></H1 +NAME="AEN415">3.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 takes part in a process of electing the LMB (and DMB) +>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 @@ -538,19 +286,6 @@ interface over the IPX protocol. Samba will then lose the LMB role as Windows 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 @@ -558,14 +293,12 @@ CLASS="SECT1" ><H1 CLASS="SECT1" ><A -NAME="AEN277" ->2.7. Name Resolution Order</A -></H1 +NAME="AEN421">3.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 +are: +<P ></P ><TABLE BORDER="0" @@ -586,9 +319,10 @@ BORDER="0" ></TABLE ><P ></P +></P ><P ->Alternative means of name resolution includes:</P -><P +>Alternative means of name resolution includes: +<P ></P ><TABLE BORDER="0" @@ -605,23 +339,24 @@ BORDER="0" ></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 +> name resolve order = wins lmhosts bcast host</PRE > _or_ <PRE CLASS="PROGRAMLISTING" ->name resolve order = wins lmhosts (eliminates bcast and host)</PRE +> name resolve order = wins lmhosts (eliminates bcast and host)</PRE > The default is: <PRE CLASS="PROGRAMLISTING" ->name resolve order = host lmhost wins bcast</PRE +> 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 @@ -653,7 +388,7 @@ WIDTH="33%" ALIGN="left" VALIGN="top" ><A -HREF="install.html" +HREF="improved-browsing.html" ACCESSKEY="P" >Prev</A ></TD @@ -671,7 +406,7 @@ WIDTH="33%" ALIGN="right" VALIGN="top" ><A -HREF="passdb.html" +HREF="pwencrypt.html" ACCESSKEY="N" >Next</A ></TD @@ -681,7 +416,7 @@ ACCESSKEY="N" WIDTH="33%" ALIGN="left" VALIGN="top" ->How to Install and Test SAMBA</TD +>Improved browsing in samba</TD ><TD WIDTH="34%" ALIGN="center" @@ -695,7 +430,7 @@ ACCESSKEY="U" WIDTH="33%" ALIGN="right" VALIGN="top" ->User information database</TD +>LanMan and NT Password Encryption in Samba</TD ></TR ></TABLE ></DIV |