More of the documentation overhaul. More to follow.

(This used to be commit 8333c4709e239a7b8bef6f7a5050a7f8a1ffbe7d)

1 files changed, 32 insertions, 411 deletions

diff --git a/docs/docbook/projdoc/Integrating-with-Windows.sgml b/docs/docbook/projdoc/Integrating-with-Windows.sgml
index a4e79fd42b..8a5c0c40f2 100644
--- a/docs/docbook/projdoc/Integrating-with-Windows.sgml
+++ b/docs/docbook/projdoc/Integrating-with-Windows.sgml
@@ -18,48 +18,46 @@
  
 <title>Integrating MS Windows networks with Samba</title>
  
-<sect1>
-<title>Agenda</title>
-
 <para>
-To identify the key functional mechanisms of MS Windows networking 
-to enable the deployment of Samba as a means of extending and/or 
-replacing MS Windows NT/2000 technology.
+This section deals with NetBIOS over TCP/IP name to IP address resolution. If you
+your MS Windows clients are NOT configured to use NetBIOS over TCP/IP then this
+section does not apply to your installation. If your installation involves use of
+NetBIOS over TCP/IP then this section may help you to resolve networking problems.
 </para>
 
+<note>
 <para>
-We will examine:
+	NetBIOS over TCP/IP has nothing to do with NetBEUI. NetBEUI is NetBIOS
+	over Logical Link Control (LLC). On modern networks it is highly advised
+	to NOT run NetBEUI at all. Note also that there is NO such thing as
+	NetBEUI over TCP/IP - the existence of such a protocol is a complete
+	and utter mis-apprehension.
 </para>
+</note>
 
-<orderedlist>
-	<listitem><para>Name resolution in a pure Unix/Linux TCP/IP 
-	environment
-	</para></listitem>
-
-	<listitem><para>Name resolution as used within MS Windows 
-	networking
-	</para></listitem>
-
-	<listitem><para>How browsing functions and how to deploy stable 
-	and dependable browsing using Samba
-	</para></listitem>
-	
-	<listitem><para>MS Windows security options and how to 
-	configure Samba for seemless integration
-	</para></listitem>
+<para>
+Since the introduction of MS Windows 2000 it is possible to run MS Windows networking
+without the use of NetBIOS over TCP/IP. NetBIOS over TCP/IP uses UDP port 137 for NetBIOS
+name resolution and uses TCP port 139 for NetBIOS session services. When NetBIOS over
+TCP/IP is disabled on MS Windows 2000 and later clients then only TCP port 445 will be
+used and UDP port 137 and TCP port 139 will not.
+</para>
 
-	<listitem><para>Configuration of Samba as:</para>
-		<orderedlist>
-		<listitem><para>A stand-alone server</para></listitem>
-		<listitem><para>An MS Windows NT 3.x/4.0 security domain member
-		</para></listitem>
-		<listitem><para>An alternative to an MS Windows NT 3.x/4.0 Domain Controller
-		</para></listitem>
-		</orderedlist>
-	</listitem>
-</orderedlist>
+<note>
+<para>
+When using Windows 2000 or later clients, if NetBIOS over TCP/IP is NOT disabled, then
+the client will use UDP port 137 (NetBIOS Name Service, also known as the Windows Internet
+Name Service or WINS), TCP port 139 AND TCP port 445 (for actual file and print traffic).
+</para>
+</note>
 
-</sect1>
+<para>
+When NetBIOS over TCP/IP is disabled the use of DNS is essential. Most installations that
+disable NetBIOS over TCP/IP today use MS Active Directory Service (ADS). ADS requires
+Dynamic DNS with Service Resource Records (SRV RR) and with Incremental Zone Transfers (IXFR).
+Use of DHCP with ADS is recommended as a further means of maintaining central control
+over client workstation network configuration.
+</para>
 
 
 <sect1>
@@ -555,381 +553,4 @@ of the WINS server.
 </sect2>
 </sect1>
 
-
-<sect1>
-<title>How browsing functions and how to deploy stable and 
-dependable browsing using Samba</title>
-
-
-<para>
-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.
-</para>
-
-<para>
-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 "remote announce" parameter).
-</para>
-
-<para>
-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.
-</para>
-
-<para>
-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.
-</para>
-
-<para>
-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. 
-</para>
-
-<para>
-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.
-</para>
-
-<para>
-Samba supports a feature that allows forced synchonisation 
-of browse lists across routed networks using the "remote 
-browse sync" parameter in the smb.conf 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 "remote 
-browse sync" 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, <filename>/etc/hosts</filename>, 
-and so on.
-</para>
-
-</sect1>
-
-<sect1>
-<title>MS Windows security options and how to configure 
-Samba for seemless integration</title>
-
-<para>
-MS Windows clients may use encrypted passwords as part of a 
-challenege/response authentication model (a.k.a. NTLMv1) or 
-alone, or clear text strings for simple password based 
-authentication. It should be realized that with the SMB 
-protocol the password is passed over the network either 
-in plain text or encrypted, but not both in the same 
-authentication requets.
-</para>
-
-<para>
-When encrypted passwords are used a password that has been 
-entered by the user is encrypted in two ways:
-</para>
-
-<itemizedlist>
-	<listitem><para>An MD4 hash of the UNICODE of the password
-	string.  This is known as the NT hash.
-	</para></listitem>
-
-	<listitem><para>The password is converted to upper case,
-	and then padded or trucated to 14 bytes.  This string is 
-	then appended with 5 bytes of NULL characters and split to
-	form two 56 bit DES keys to encrypt a "magic" 8 byte value.
-	The resulting 16 bytes for the LanMan hash.
-	</para></listitem>	
-</itemizedlist>
-
-<para>
-You should refer to the <ulink url="ENCRYPTION.html">
-Password Encryption</ulink> chapter in this HOWTO collection
-for more details on the inner workings
-</para>
-
-<para>
-MS Windows 95 pre-service pack 1, MS Windows NT versions 3.x 
-and version 4.0 pre-service pack 3 will use either mode of 
-password authentication. All versions of MS Windows that follow 
-these versions no longer support plain text passwords by default.
-</para>
-
-<para>
-MS Windows clients have a habit of dropping network mappings that 
-have been idle for 10 minutes or longer. When the user attempts to 
-use the mapped drive connection that has been dropped, the client
-re-establishes the connection using 
-a cached copy of the password.
-</para>
-
-<para>
-When Microsoft changed the default password mode, they dropped support for 
-caching of the plain text password. This means that when the registry 
-parameter is changed to re-enable use of plain text passwords it appears to 
-work, but when a dropped mapping attempts to revalidate it will fail if 
-the remote authentication server does not support encrypted passwords. 
-This means that it is definitely not a good idea to re-enable plain text 
-password support in such clients.
-</para>
-
-<para>
-The following parameters can be used to work around the 
-issue of Windows 9x client upper casing usernames and
-password before transmitting them to the SMB server
-when using clear text authentication.
-</para>
-
-<para><programlisting>
-	<ulink url="smb.conf.5.html#PASSWORDLEVEL">passsword level</ulink> = <replaceable>integer</replaceable>
-	<ulink url="smb.conf.5.html#USERNAMELEVEL">username level</ulink> = <replaceable>integer</replaceable>
-</programlisting></para>
-
-<para>
-By default Samba will lower case the username before attempting
-to lookup the user in the database of local system accounts.
-Because UNIX usernames conventionally only contain lower case
-character, the <parameter>username level</parameter> parameter
-is rarely even needed.
-</para>
-
-<para>
-However, password on UNIX systems often make use of mixed case
-characters.  This means that in order for a user on a Windows 9x
-client to connect to a Samba server using clear text authentication,
-the <parameter>password level</parameter> must be set to the maximum
-number of upper case letter which <emphasis>could</emphasis> appear
-is a password.  Note that is the server OS uses the traditional
-DES version of crypt(), then a <parameter>password level</parameter>
-of 8 will result in case insensitive passwords as seen from Windows
-users.  This will also result in longer login times as Samba
-hash to compute the permutations of the password string and 
-try them one by one until a match is located (or all combinations fail).
-</para>
-
-<para>
-The best option to adopt is to enable support for encrypted passwords 
-where ever Samba is used. There are three configuration possibilities 
-for support of encrypted passwords:
-</para>
-
-
-<sect2>
-<title>Use MS Windows NT as an authentication server</title>
-
-<para>
-This method involves the additions of the following parameters 
-in the smb.conf file:
-</para>
-
-<para><programlisting>
-	encrypt passwords = Yes
-	security = server
-	password server = "NetBIOS_name_of_PDC"
-</programlisting></para>
-
-
-<para>
-There are two ways of identifying whether or not a username and 
-password pair was valid or not. One uses the reply information provided 
-as part of the authentication messaging process, the other uses 
-just and error code.
-</para>
-
-<para>
-The down-side of this mode of configuration is the fact that 
-for security reasons Samba will send the password server a bogus 
-username and a bogus password and if the remote server fails to 
-reject the username and password pair then an alternative mode 
-of identification of validation is used. Where a site uses password 
-lock out after a certain number of failed authentication attempts 
-this will result in user lockouts.
-</para>
-
-<para>
-Use of this mode of authentication does require there to be 
-a standard Unix account for the user, this account can be blocked 
-to prevent logons by other than MS Windows clients.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Make Samba a member of an MS Windows NT security domain</title>
-
-<para>
-This method involves additon of the following paramters in the smb.conf file:
-</para>
-
-<para><programlisting>
-	encrypt passwords = Yes
-	security = domain
-	workgroup = "name of NT domain"
-	password server = *
-</programlisting></para>
-
-<para>
-The use of the "*" argument to "password server" will cause samba 
-to locate the domain controller in a way analogous to the way 
-this is done within MS Windows NT.
-</para>
-
-<para>
-In order for this method to work the Samba server needs to join the 
-MS Windows NT security domain. This is done as follows:
-</para>
-
-<itemizedlist>
-	<listitem><para>On the MS Windows NT domain controller using 
-	the Server Manager add a machine account for the Samba server.
-	</para></listitem>
-	
-	<listitem><para>Next, on the Linux system execute: 
-	<command>smbpasswd -r PDC_NAME -j DOMAIN_NAME</command>
-	</para></listitem>
-</itemizedlist>
-
-<para>
-Use of this mode of authentication does require there to be 
-a standard Unix account for the user in order to assign
-a uid once the account has been authenticated by the remote
-Windows DC.  This account can be blocked to prevent logons by 
-other than MS Windows clients by things such as setting an invalid
-shell in the <filename>/etc/passwd</filename> entry.
-</para>
-
-<para>
-An alternative to assigning UIDs to Windows users on a 
-Samba member server is presented in the <ulink
-url="winbind.html">Winbind Overview</ulink> chapter in
-this HOWTO collection.
-</para>
-
-
-</sect2>
-
-
-<sect2>
-<title>Configure Samba as an authentication server</title>
-
-<para>
-This mode of authentication demands that there be on the 
-Unix/Linux system both a Unix style account as well as an 
-smbpasswd entry for the user. The Unix system account can be 
-locked if required as only the encrypted password will be 
-used for SMB client authentication.
-</para>
-
-<para>
-This method involves addition of the following parameters to 
-the smb.conf file:
-</para>
-
-<para><programlisting>
-## please refer to the Samba PDC HOWTO chapter later in 
-## this collection for more details
-[global]
-	encrypt passwords = Yes
-	security = user
-	domain logons = Yes
-	; an OS level of 33 or more is recommended
-	os level = 33
-
-[NETLOGON]
-	path = /somewhare/in/file/system
-	read only = yes
-</programlisting></para>
-
-<para>
-in order for this method to work a Unix system account needs 
-to be created for each user, as well as for each MS Windows NT/2000 
-machine. The following structure is required.
-</para>
-
-<sect3>
-<title>Users</title>
-
-<para>
-A user account that may provide a home directory should be 
-created. The following Linux system commands are typical of 
-the procedure for creating an account.
-</para>
-
-<para><programlisting>
-	# useradd -s /bin/bash -d /home/"userid" -m "userid"
-	# passwd "userid"
-	  Enter Password: &lt;pw&gt;
-	  
-	# smbpasswd -a "userid"
-	  Enter Password: &lt;pw&gt;
-</programlisting></para>
-</sect3>
-
-<sect3>
-<title>MS Windows NT Machine Accounts</title>
-
-<para>
-These are required only when Samba is used as a domain 
-controller.  Refer to the Samba-PDC-HOWTO for more details.
-</para>
-
-<para><programlisting>
-	# useradd -s /bin/false -d /dev/null "machine_name"\$
-	# passwd -l "machine_name"\$
-	# smbpasswd -a -m "machine_name"
-</programlisting></para>
-</sect3>
-</sect2>
-</sect1>
-
-
-<sect1>
-<title>Conclusions</title>
-
-<para>
-Samba provides a flexible means to operate as...
-</para>
-
-<itemizedlist>
-	<listitem><para>A Stand-alone server - No special action is needed 
-	other than to create user accounts. Stand-alone servers do NOT 
-	provide network logon services, meaning that machines that use this 
-	server do NOT perform a domain logon but instead make use only of 
-	the MS Windows logon which is local to the MS Windows 
-	workstation/server.
-	</para></listitem>
-	
-	<listitem><para>An MS Windows NT 3.x/4.0 security domain member.
-	</para></listitem>
-	
-
-	<listitem><para>An alternative to an MS Windows NT 3.x/4.0 
-	Domain Controller.
-	</para></listitem>
-
-</itemizedlist>
-
-</sect1>
-
 </chapter>