More updates.

(This used to be commit bcabb1a1b53e950940ba0c597be9cc861e2a0fa6)

3 files changed, 355 insertions, 172 deletions

diff --git a/docs/docbook/projdoc/Integrating-with-Windows.xml b/docs/docbook/projdoc/Integrating-with-Windows.xml
index 9c397172dd..eae51295df 100644
--- a/docs/docbook/projdoc/Integrating-with-Windows.xml
+++ b/docs/docbook/projdoc/Integrating-with-Windows.xml
@@ -24,6 +24,26 @@ NetBIOS over TCP/IP then this section may help you to resolve networking problem
 </para>
 </note>
 
+<sect1>
+<title>Features and Benefits</title>
+
+<para>
+Many MS Windows network administrators have never been exposed to basic TCP/IP
+networking as it is implemented in a Unix/Linux operating system. Likewise, many Unix and
+Linux adminsitrators have not been exposed to the intricacies of MS Windows TCP/IP based
+networking (and may have no desire to be either).
+</para>
+
+<para>
+This chapter gives a short introduction to the basics of how a name can be resolved to 
+it's IP address for each operating system environment.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Background Information</title>
+
 <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
@@ -48,6 +68,7 @@ Use of DHCP with ADS is recommended as a further means of maintaining central co
 over client workstation network configuration.
 </para>
 
+</sect1>
 
 <sect1>
 <title>Name Resolution in a pure Unix/Linux world</title>
@@ -70,10 +91,10 @@ The key configuration files covered in this section are:
 Contains a static list of IP Addresses and names.
 eg:
 </para>
-<para><programlisting>
+<para><screen>
 	127.0.0.1	localhost localhost.localdomain
 	192.168.1.1	bigbox.caldera.com	bigbox	alias4box
-</programlisting></para>
+</screen></para>
 
 <para>
 The purpose of <filename>/etc/hosts</filename> is to provide a 
@@ -181,10 +202,10 @@ critical configuration file.  This file controls the order by
 which name resolution may procede. The typical structure is:
 </para>
 
-<para><programlisting>
+<para><screen>
 	order hosts,bind
 	multi on
-</programlisting></para>
+</screen></para>
 
 <para>
 then both addresses should be returned. Please refer to the 
@@ -205,7 +226,7 @@ file typically has resolver object specifications as follows:
 </para>
 
 
-<para><programlisting>
+<para><screen>
 	# /etc/nsswitch.conf
 	#
 	# Name Service Switch configuration file.
@@ -226,7 +247,7 @@ file typically has resolver object specifications as follows:
 	protocols:	nis files
 	rpc:		nis files
 	services:	nis files
-</programlisting></para>
+</screen></para>
 
 <para>
 Of course, each of these mechanisms requires that the appropriate 
@@ -280,7 +301,7 @@ the client/server.
 The following are typical NetBIOS name/service type registrations:
 </para>
 
-<para><programlisting>
+<para><screen>
 	Unique NetBIOS Names:
 		MACHINENAME&lt;00&gt;	= Server Service is running on MACHINENAME
 		MACHINENAME&lt;03&gt; = Generic Machine Name (NetBIOS name)
@@ -292,7 +313,7 @@ The following are typical NetBIOS name/service type registrations:
 		WORKGROUP&lt;1c&gt; = Domain Controllers / Netlogon Servers
 		WORKGROUP&lt;1d&gt; = Local Master Browsers
 		WORKGROUP&lt;1e&gt; = Internet Name Resolvers
-</programlisting></para>
+</screen></para>
 
 <para>
 It should be noted that all NetBIOS machines register their own 
@@ -392,7 +413,7 @@ to IP address mapping.
 It typically looks like:
 </para>
 
-<para><programlisting>
+<para><screen>
 	# Copyright (c) 1998 Microsoft Corp.
 	#
 	# This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS
@@ -469,7 +490,7 @@ It typically looks like:
 	# so keeping the number of comments to a minimum will improve performance.
 	# Therefore it is not advisable to simply add lmhosts file entries onto the
 	# end of this file.
-</programlisting></para>
+</screen></para>
 
 </sect2>
 
@@ -520,19 +541,19 @@ To configure Samba to be a WINS server the following parameter needs
 to be added to the &smb.conf; file:
 </para>
 
-<para><programlisting>
+<para><screen>
 	wins support = Yes
-</programlisting></para>
+</screen></para>
 
 <para>
 To configure Samba to use a WINS server the following parameters are 
 needed in the &smb.conf; file:
 </para>
 
-<para><programlisting>
+<para><screen>
 	wins support = No
 	wins server = xxx.xxx.xxx.xxx
-</programlisting></para>
+</screen></para>
 
 <para>
 where <replaceable>xxx.xxx.xxx.xxx</replaceable> is the IP address 
@@ -542,4 +563,53 @@ of the WINS server.
 </sect2>
 </sect1>
 
+<sect1>
+<title>Common Errors</title>
+
+<para>
+TCP/IP network configuration problems find every network administrator sooner or later.
+The cause can be anything from keybaord mishaps, forgetfulness, simple mistakes, and
+carelessness. Of course, noone is every deliberately careless!
+</para>
+
+	<sect2>
+	<title>My Boomerang Won't Come Back<title>
+
+	<para>
+	Well, the real complaint said, "I can ping my samba server from Windows, but I can
+	not ping my Windows machine from the samba server."
+	</para>
+
+	<para>
+	The Windows machine was at IP Address 192.168.1.2 with netmask 255.255.255.0, the
+	Samba server (Linux) was at IP Address 192.168.1.130 with netmast 255.255.255.128.
+	The machines were on a local network with no external connections.
+	<para>
+
+	<para>
+	Due to inconsistent netmasks, the Windows machine was on network 192.168.1.0/24, while
+	the Samba server was on network 192.168.1.128/25 - logically a different network.
+	</para>
+
+	</sect2>
+
+	<sect2>
+	<title>Very Slow Network Connections</title>
+
+	<para>
+	A common causes of slow network response includes:
+	</para>
+
+	<itemizedlist>
+		<listitem><para>Client is configured to use DNS and DNS server is down</para></listitem>
+		<listitem><para>Client is configured to use remote DNS server, but remote connection is down</para></listitem>
+		<listitem><para>Client is configured to use a WINS server, but there is no WINS server</para></listitem>
+		<listitem><para>Client is NOT configured to use a WINS server, but there is a WINS server</para></listitem>
+		<listitem><para>Firewall is filtering our DNS or WINS traffic</para></listitem>
+	</itemizedlist>
+
+	</sect2>
+
+</sect1>
+
 </chapter>
diff --git a/docs/docbook/projdoc/InterdomainTrusts.xml b/docs/docbook/projdoc/InterdomainTrusts.xml
index 2c492d4ac0..ae780a4b61 100644
--- a/docs/docbook/projdoc/InterdomainTrusts.xml
+++ b/docs/docbook/projdoc/InterdomainTrusts.xml
@@ -16,6 +16,25 @@ possible for Samba-3 to NT4 trust (and vice versa), as well as Samba3 to Samba3
 </para>
 
 <sect1>
+<title>Features and Benefits</title>
+
+<para>
+Samba-3 can participate in Samba-to-Samba as well as in Samba-to-MS Windows NT4 style
+trust relationships. This imparts to Samba similar scalability as is possible with
+MS Windows NT4.
+</para>
+
+<para>
+Given that Samba-3 has the capability to function with a scalable backend authentication
+database such as LDAP, and given it's ability to run in Primary as well as Backup Domain control
+modes, the administrator would be well advised to consider alternatives to the use of
+Interdomain trusts simplt because by the very nature of how this works it is fragile.
+That was after all a key reason for the development and adoption of Microsoft Active Directory.
+</para>
+
+</sect1>
+
+<sect1>
 <title>Trust Relationship Background</title>
 
 <para>
@@ -219,4 +238,15 @@ the <filename>secrets.tdb</filename> file.
 </sect2>
 </sect1>
 
+<sect1>
+<title>Common Errors</title>
+
+<para>
+Interdomain trust relationships should NOT be attempted on networks that are unstable
+or that suffer regular outages. Network stability and integrity are key concerns with
+distributed trusted domains.
+</para>
+
+</sect1>
+
 </chapter>
diff --git a/docs/docbook/projdoc/securing-samba.xml b/docs/docbook/projdoc/securing-samba.xml
index 204fceeb4a..58634fba35 100644
--- a/docs/docbook/projdoc/securing-samba.xml
+++ b/docs/docbook/projdoc/securing-samba.xml
@@ -3,7 +3,7 @@
 <chapterinfo>
 	&author.tridge;
 	&author.jht;
-	<pubdate>17 March 2003</pubdate>
+	<pubdate>May 26, 2003</pubdate>
 </chapterinfo>
 
 <title>Securing Samba</title>
@@ -16,209 +16,292 @@ important security fix.  The information contained here applies to Samba
 installations in general.
 </para>
 
-</sect1>
-
-<sect1>
-<title>Using host based protection</title>
-
-<para>
-In many installations of Samba the greatest threat comes for outside
-your immediate network. By default Samba will accept connections from
-any host, which means that if you run an insecure version of Samba on
-a host that is directly connected to the Internet you can be
-especially vulnerable.
-</para>
-
-<para>
-One of the simplest fixes in this case is to use the <command>hosts allow</command> and
-<command>hosts deny</command> options in the Samba &smb.conf; configuration file to only
-allow access to your server from a specific range of hosts. An example
-might be:
-</para>
-
-<para><programlisting>
-	hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24
-	hosts deny = 0.0.0.0/0
-</programlisting></para>
-
-<para>
-The above will only allow SMB connections from 'localhost' (your own
-computer) and from the two private networks 192.168.2 and
-192.168.3. All other connections will be refused as soon
-as the client sends its first packet. The refusal will be marked as a
-'not listening on called name' error.
-</para>
-
-</sect1>
-
-<sect1>
-<title>User based protection</title>
-
 <para>
-If you want to restrict access to your server to valid users only then the following
-method may be of use. In the smb.conf [globals] section put:
+A new apprentice reported for duty to the Chief Engineer of a boiler house. He said, "Here I am,
+if you will show me the boiler I'll start working on it." Then engineer replied, "You're leaning
+on it!"
 </para>
 
-<para><programlisting>
-	valid users = @smbusers, jacko
-</programlisting></para>
-
 <para>
-What this does is, it restricts all server access to either the user <emphasis>jacko</emphasis>
-or to members of the system group <emphasis>smbusers</emphasis>.
+Security concerns are just like that: You need to know a little about the subject to appreciate
+how obvious most of it really is. The challenge for most of us is to discover that first morsel
+of knowledge with which we may unlock the secrets of the masters.
 </para>
 
 </sect1>
 
 <sect1>
-
-<title>Using interface protection</title>
+<title>Features and Benefits</title>
 
 <para>
-By default Samba will accept connections on any network interface that
-it finds on your system. That means if you have a ISDN line or a PPP
-connection to the Internet then Samba will accept connections on those
-links. This may not be what you want.
+There are three level at which security principals must be observed in order to render a site
+at least moderately secure. These are: the perimeter firewall, the configuration of the host
+server that is running Samba, and Samba itself.
 </para>
 
 <para>
-You can change this behaviour using options like the following:
+Samba permits a most flexible approach to network security. As far as possible Samba implements
+the latest protocols to permit more secure MS Windows file and print operations.
 </para>
 
-<para><programlisting>
-	interfaces = eth* lo
-	bind interfaces only = yes
-</programlisting></para>
-
 <para>
-This tells Samba to only listen for connections on interfaces with a
-name starting with 'eth' such as eth0, eth1, plus on the loopback
-interface called 'lo'. The name you will need to use depends on what
-OS you are using, in the above I used the common name for Ethernet
-adapters on Linux.
+Samba may be secured from connections that originate from outside the local network. This may be
+done using <emphasis>host based protection</emphasis> (using samba's implementation of a technology
+known as "tcpwrappers", or it may be done be using <emphasis>interface based exclusion</emphasis>
+so that <command>smbd</command> will bind only to specifically permitted interfaces. It is also
+possible to set specific share or resource based exclusions, eg: on the <parameter>IPC$</parameter>
+auto-share. The <parameter>IPC$</parameter> share is used for browsing purposes as well as to establish
+TCP/IP connections.
 </para>
 
 <para>
-If you use the above and someone tries to make a SMB connection to
-your host over a PPP interface called 'ppp0' then they will get a TCP
-connection refused reply. In that case no Samba code is run at all as
-the operating system has been told not to pass connections from that
-interface to any samba process.
+Another method by which Samba may be secured is by way of setting Access Control Entries in an Access 
+Control List on the shares themselves. This is discussed in the chapter on File, Directory and Share Access
+Control.
 </para>
 
 </sect1>
 
 <sect1>
-<title>Using a firewall</title>
+<title>Technical Discussion of Protective Measures and Issues</title>
 
 <para>
-Many people use a firewall to deny access to services that they don't
-want exposed outside their network. This can be a very good idea,
-although I would recommend using it in conjunction with the above
-methods so that you are protected even if your firewall is not active
-for some reason.
-</para>
-
-<para>
-If you are setting up a firewall then you need to know what TCP and
-UDP ports to allow and block. Samba uses the following:
-</para>
-
-<para><programlisting>
-	UDP/137    - used by nmbd
-	UDP/138    - used by nmbd
-	TCP/139    - used by smbd
-	TCP/445    - used by smbd
-</programlisting></para>
-
-<para>
-The last one is important as many older firewall setups may not be
-aware of it, given that this port was only added to the protocol in
-recent years. 
+The key challenge of security is the fact that protective measures suffice at best
+only to close the door on known exploits and breach techniques. Never assume that
+because you have followed these few measures that the Samba server is now an impenetrable
+fortress! Given the history of information systems so far, it is only a matter of time
+before someone will find yet another vulnerability.
 </para>
 
+	<sect2>
+	<title>Using host based protection</title>
+
+	<para>
+	In many installations of Samba the greatest threat comes for outside
+	your immediate network. By default Samba will accept connections from
+	any host, which means that if you run an insecure version of Samba on
+	a host that is directly connected to the Internet you can be
+	especially vulnerable.
+	</para>
+
+	<para>
+	One of the simplest fixes in this case is to use the <command>hosts allow</command> and
+	<command>hosts deny</command> options in the Samba &smb.conf; configuration file to only
+	allow access to your server from a specific range of hosts. An example
+	might be:
+	</para>
+
+	<para><screen>
+		hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24
+		hosts deny = 0.0.0.0/0
+	</screen></para>
+
+	<para>
+	The above will only allow SMB connections from 'localhost' (your own
+	computer) and from the two private networks 192.168.2 and
+	192.168.3. All other connections will be refused as soon
+	as the client sends its first packet. The refusal will be marked as a
+	'not listening on called name' error.
+	</para>
+
+	</sect2>
+
+	<sect2>
+	<title>User based protection</title>
+
+	<para>
+	If you want to restrict access to your server to valid users only then the following
+	method may be of use. In the smb.conf [globals] section put:
+	</para>
+
+	<para><screen>
+		valid users = @smbusers, jacko
+	</screen></para>
+
+	<para>
+	What this does is, it restricts all server access to either the user <emphasis>jacko</emphasis>
+	or to members of the system group <emphasis>smbusers</emphasis>.
+	</para>
+
+	</sect2>
+
+	<sect2>
+
+	<title>Using interface protection</title>
+
+	<para>
+	By default Samba will accept connections on any network interface that
+	it finds on your system. That means if you have a ISDN line or a PPP
+	connection to the Internet then Samba will accept connections on those
+	links. This may not be what you want.
+	</para>
+
+	<para>
+	You can change this behaviour using options like the following:
+	</para>
+
+	<para><screen>
+		interfaces = eth* lo
+		bind interfaces only = yes
+	</screen></para>
+
+	<para>
+	This tells Samba to only listen for connections on interfaces with a
+	name starting with 'eth' such as eth0, eth1, plus on the loopback
+	interface called 'lo'. The name you will need to use depends on what
+	OS you are using, in the above I used the common name for Ethernet
+	adapters on Linux.
+	</para>
+
+	<para>
+	If you use the above and someone tries to make a SMB connection to
+	your host over a PPP interface called 'ppp0' then they will get a TCP
+	connection refused reply. In that case no Samba code is run at all as
+	the operating system has been told not to pass connections from that
+	interface to any samba process.
+	</para>
+
+	</sect2>
+
+	<sect2>
+	<title>Using a firewall</title>
+
+	<para>
+	Many people use a firewall to deny access to services that they don't
+	want exposed outside their network. This can be a very good idea,
+	although I would recommend using it in conjunction with the above
+	methods so that you are protected even if your firewall is not active
+	for some reason.
+	</para>
+
+	<para>
+	If you are setting up a firewall then you need to know what TCP and
+	UDP ports to allow and block. Samba uses the following:
+	</para>
+
+	<para><screen>
+		UDP/137    - used by nmbd
+		UDP/138    - used by nmbd
+		TCP/139    - used by smbd
+		TCP/445    - used by smbd
+	</screen></para>
+
+	<para>
+	The last one is important as many older firewall setups may not be
+	aware of it, given that this port was only added to the protocol in
+	recent years. 
+	</para>
+
+	</sect2>
+
+	<sect2>
+	<title>Using a IPC$ share deny</title>
+
+	<para>
+	If the above methods are not suitable, then you could also place a
+	more specific deny on the IPC$ share that is used in the recently
+	discovered security hole. This allows you to offer access to other
+	shares while denying access to IPC$ from potentially untrustworthy
+	hosts.
+	</para>
+
+	<para>
+	To do that you could use:
+	</para>
+
+	<para><screen>
+		[ipc$]
+		     hosts allow = 192.168.115.0/24 127.0.0.1
+		     hosts deny = 0.0.0.0/0
+	</screen></para>
+
+	<para>
+	this would tell Samba that IPC$ connections are not allowed from
+	anywhere but the two listed places (localhost and a local
+	subnet). Connections to other shares would still be allowed. As the
+	IPC$ share is the only share that is always accessible anonymously
+	this provides some level of protection against attackers that do not
+	know a username/password for your host.
+	</para>
+
+	<para>
+	If you use this method then clients will be given a 'access denied'
+	reply when they try to access the IPC$ share. That means that those
+	clients will not be able to browse shares, and may also be unable to
+	access some other resources. 
+	</para>
+
+	<para>
+	This is not recommended unless you cannot use one of the other
+	methods listed above for some reason.
+	</para>
+
+	</sect2>
+
+	<sect2>
+	<title>NTLMv2 Security</title>
+
+	<para>
+	To configure NTLMv2 authentication the following registry keys are worth knowing about:
+	</para>
+
+	<para>
+	<screen>
+		[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
+		"lmcompatibilitylevel"=dword:00000003
+
+		0x3 - Send NTLMv2 response only. Clients will use NTLMv2 authentication,
+		use NTLMv2 session security if the server supports it. Domain
+		controllers accept LM, NTLM and NTLMv2 authentication.
+
+		[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
+		"NtlmMinClientSec"=dword:00080000
+
+		0x80000 - NTLMv2 session security. If either NtlmMinClientSec or
+		NtlmMinServerSec is set to 0x80000, the connection will fail if NTLMv2
+		session security is not negotiated.
+	</screen>
+	</para>
+	</sect2>
 </sect1>
 
 <sect1>
-<title>Using a IPC$ share deny</title>
-
-<para>
-If the above methods are not suitable, then you could also place a
-more specific deny on the IPC$ share that is used in the recently
-discovered security hole. This allows you to offer access to other
-shares while denying access to IPC$ from potentially untrustworthy
-hosts.
-</para>
-
-<para>
-To do that you could use:
-</para>
-
-<para><programlisting>
-	[ipc$]
-	     hosts allow = 192.168.115.0/24 127.0.0.1
-	     hosts deny = 0.0.0.0/0
-</programlisting></para>
-
-<para>
-this would tell Samba that IPC$ connections are not allowed from
-anywhere but the two listed places (localhost and a local
-subnet). Connections to other shares would still be allowed. As the
-IPC$ share is the only share that is always accessible anonymously
-this provides some level of protection against attackers that do not
-know a username/password for your host.
-</para>
-
-<para>
-If you use this method then clients will be given a 'access denied'
-reply when they try to access the IPC$ share. That means that those
-clients will not be able to browse shares, and may also be unable to
-access some other resources. 
-</para>
+<title>Upgrading Samba</title>
 
 <para>
-This is not recommended unless you cannot use one of the other
-methods listed above for some reason.
+Please check regularly on <ulink url="http://www.samba.org/">http://www.samba.org/</ulink> for updates and
+important announcements.  Occasionally security releases are made and 
+it is highly recommended to upgrade Samba when a security vulnerability
+is discovered.
 </para>
 
 </sect1>
 
 <sect1>
-<title>NTLMv2 Security</title>
+<title>Common Errors</title>
 
 <para>
-To configure NTLMv2 authentication the following registry keys are worth knowing about:
+If all of samba and host platform configuration were really as intuitive as one might like then this
+section would not be necessary. Security issues are often vexing for a support person to resolve, not
+because of the complexity of the problem, but for reason that most admininstrators who post what turns
+out to be a security problem request are totally convinced that the problem is with Samba.
 </para>
 
-<para>
-<programlisting>
-	[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
-	"lmcompatibilitylevel"=dword:00000003
-
-	0x3 - Send NTLMv2 response only. Clients will use NTLMv2 authentication,
-	use NTLMv2 session security if the server supports it. Domain
-	controllers accept LM, NTLM and NTLMv2 authentication.
+	<sect2>
+	<title>Smbclient works on localhost, but the network is dead</title>
 
-	[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
-	"NtlmMinClientSec"=dword:00080000
+	<para>
+	This is a very common problem. Red Hat Linux (as do others) will install a default firewall.
+	With the default firewall in place only traffic on the loopback adapter (IP address 127.0.0.1)
+	will be allowed through the firewall.
+	</para>
 
-	0x80000 - NTLMv2 session security. If either NtlmMinClientSec or
-	NtlmMinServerSec is set to 0x80000, the connection will fail if NTLMv2
-	session security is not negotiated.
-</programlisting>
-</para>
-</sect1>
+	<para>
+	The solution is either to remove the firewall (stop it) or to modify the firewall script to
+	allow SMB networking traffic through. See section above in this chapter.
+	</para>
 
-<sect1>
-<title>Upgrading Samba</title>
-
-<para>
-Please check regularly on <ulink url="http://www.samba.org/">http://www.samba.org/</ulink> for updates and
-important announcements.  Occasionally security releases are made and 
-it is highly recommended to upgrade Samba when a security vulnerability
-is discovered.
-</para>
+	</sect2>
 
 </sect1>
-
 </chapter>