mega-merge from 2.2

(This used to be commit c76bf8ed3275e217d1b691879153fe9137bcbe38)

13 files changed, 1851 insertions, 194 deletions

diff --git a/docs/docbook/projdoc/CVS-Access.sgml b/docs/docbook/projdoc/CVS-Access.sgml
index aea146b66a..98ef925f20 100644
--- a/docs/docbook/projdoc/CVS-Access.sgml
+++ b/docs/docbook/projdoc/CVS-Access.sgml
@@ -1,4 +1,4 @@
-<chapter>
+<chapter id="cvs-access">
 
 
 <chapterinfo>
@@ -18,10 +18,10 @@
 <title>Introduction</title>
 
 <para>
-Samba is developed in an open environnment.  Developers use CVS
+Samba is developed in an open environment.  Developers use CVS
 (Concurrent Versioning System) to "checkin" (also known as 
 "commit") new source code.  Samba's various CVS branches can
-be accessed via anonymouns CVS using the instructions
+be accessed via anonymous CVS using the instructions
 detailed in this chapter.
 </para>
 
@@ -67,7 +67,7 @@ url="http://samba.org/cgi-bin/cvsweb">http://samba.org/cgi-bin/cvsweb</ulink>
 You can also access the source code via a 
 normal cvs client.  This gives you much more control over you can 
 do with the repository and allows you to checkout whole source trees 
-and keep them uptodate via normal cvs commands. This is the 
+and keep them up to date via normal cvs commands. This is the 
 preferred method of access if you are a developer and not
 just a casual browser.
 </para>
diff --git a/docs/docbook/projdoc/DOMAIN_MEMBER.sgml b/docs/docbook/projdoc/DOMAIN_MEMBER.sgml
index c6dbda15a3..0b1db84b20 100644
--- a/docs/docbook/projdoc/DOMAIN_MEMBER.sgml
+++ b/docs/docbook/projdoc/DOMAIN_MEMBER.sgml
@@ -1,4 +1,4 @@
-<chapter>
+<chapter id="domain-security">
 
 <chapterinfo>
 	<author>
diff --git a/docs/docbook/projdoc/ENCRYPTION.sgml b/docs/docbook/projdoc/ENCRYPTION.sgml
index 8b624bad1a..6a26dbeffa 100644
--- a/docs/docbook/projdoc/ENCRYPTION.sgml
+++ b/docs/docbook/projdoc/ENCRYPTION.sgml
@@ -1,4 +1,4 @@
-<chapter>
+<chapter id="pwencrypt">
 
 
 <chapterinfo>
@@ -96,7 +96,7 @@
 	
 	<para>The unix and SMB password encryption techniques seem similar 
 	on the surface. This similarity is, however, only skin deep. The unix 
-	scheme typically sends clear text passwords over the nextwork when 
+	scheme typically sends clear text passwords over the network when 
 	logging in. This is bad. The SMB encryption scheme never sends the 
 	cleartext password over the network but it does store the 16 byte 
 	hashed values on disk. This is also bad. Why? Because the 16 byte hashed 
@@ -141,7 +141,7 @@
 		Microsoft SMB/CIFS clients support authentication via the
 		SMB Challenge/Response mechanism described here.  Enabling
 		clear text authentication does not disable the ability
-		of the client to particpate in encrypted authentication.</para>
+		of the client to participate in encrypted authentication.</para>
 	</warning>
 
 	<sect2>
diff --git a/docs/docbook/projdoc/Integrating-with-Windows.sgml b/docs/docbook/projdoc/Integrating-with-Windows.sgml
new file mode 100644
index 0000000000..0b6abaf80f
--- /dev/null
+++ b/docs/docbook/projdoc/Integrating-with-Windows.sgml
@@ -0,0 +1,935 @@
+<chapter id="integrate-ms-networks">
+ 
+ 
+<chapterinfo>
+        <author>
+		<firstname>John</firstname><surname>Terpstra</surname>
+                <affiliation>
+                        <orgname>Samba Team</orgname>
+			<address>
+			<email>jht@samba.org</email>
+			</address>
+                </affiliation>
+        </author>
+ 
+ 
+        <pubdate> (Jan 01 2001) </pubdate>
+</chapterinfo>
+ 
+<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.
+</para>
+
+<para>
+We will examine:
+</para>
+
+<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>
+
+	<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>
+
+</sect1>
+
+
+<sect1>
+<title>Name Resolution in a pure Unix/Linux world</title>
+
+<para>
+The key configuration files covered in this section are:
+</para>
+
+<itemizedlist>
+	<listitem><para><filename>/etc/hosts</filename></para></listitem>
+	<listitem><para><filename>/etc/resolv.conf</filename></para></listitem>
+	<listitem><para><filename>/etc/host.conf</filename></para></listitem>
+	<listitem><para><filename>/etc/nsswitch.conf</filename></para></listitem>
+</itemizedlist>
+
+<sect2>
+<title><filename>/etc/hosts</filename></title>
+
+<para>
+Contains a static list of IP Addresses and names.
+eg:
+</para>
+<para><programlisting>
+	127.0.0.1	localhost localhost.localdomain
+	192.168.1.1	bigbox.caldera.com	bigbox	alias4box
+</programlisting></para>
+
+<para>
+The purpose of <filename>/etc/hosts</filename> is to provide a 
+name resolution mechanism so that uses do not need to remember 
+IP addresses.
+</para>
+
+
+<para>
+Network packets that are sent over the physical network transport 
+layer communicate not via IP addresses but rather using the Media 
+Access Control address, or MAC address. IP Addresses are currently 
+32 bits in length and are typically presented as four (4) decimal 
+numbers that are separated by a dot (or period). eg: 168.192.1.1
+</para>
+
+<para>
+MAC Addresses use 48 bits (or 6 bytes) and are typically represented 
+as two digit hexadecimal numbers separated by colons. eg: 
+40:8e:0a:12:34:56
+</para>
+
+<para>
+Every network interfrace must have an MAC address. Associated with 
+a MAC address there may be one or more IP addresses. There is NO 
+relationship between an IP address and a MAC address, all such assignments 
+are arbitary or discretionary in nature. At the most basic level all 
+network communications takes place using MAC addressing. Since MAC 
+addresses must be globally unique, and generally remains fixed for 
+any particular interface, the assignment of an IP address makes sense 
+from a network management perspective. More than one IP address can 
+be assigned per MAC address. One address must be the primary IP address, 
+this is the address that will be returned in the ARP reply.
+</para>
+
+<para>
+When a user or a process wants to communicate with another machine 
+the protocol implementation ensures that the "machine name" or "host 
+name" is resolved to an IP address in a manner that is controlled 
+by the TCP/IP configuration control files. The file 
+<filename>/etc/hosts</filename> is one such file.
+</para>
+
+<para>
+When the IP address of the destination interface has been 
+determined a protocol called ARP/RARP isused to identify 
+the MAC address of the target interface. ARP stands for Address 
+Resolution Protocol, and is a broadcast oriented method that 
+uses UDP (User Datagram Protocol) to send a request to all 
+interfaces on the local network segment using the all 1's MAC 
+address. Network interfaces are programmed to respond to two 
+MAC addresses only; their own unique address and the address 
+ff:ff:ff:ff:ff:ff. The reply packet from an ARP request will 
+contain the MAC address and the primary IP address for each 
+interface.
+</para>
+
+<para>
+The <filename>/etc/hosts</filename> file is foundational to all 
+Unix/Linux TCP/IP installations and as a minumum will contain 
+the localhost and local network interface IP addresses and the 
+primary names by which they are known within the local machine. 
+This file helps to prime the pump so that a basic level of name 
+resolution can exist before any other method of name resolution 
+becomes available.
+</para>
+
+</sect2>
+
+
+<sect2>
+<title><filename>/etc/resolv.conf</filename></title>
+
+<para>
+This file tells the name resolution libraries:
+</para>
+
+<itemizedlist>
+	<listitem><para>The name of the domain to which the machine 
+	belongs
+	</para></listitem>
+	
+	<listitem><para>The name(s) of any domains that should be 
+	automatically searched when trying to resolve unqualified 
+	host names to their IP address
+	</para></listitem>
+	
+	<listitem><para>The name or IP address of available Domain 
+	Name Servers that may be asked to perform name to address 
+	translation lookups
+	</para></listitem>
+</itemizedlist>
+
+</sect2>
+
+
+<sect2>
+<title><filename>/etc/host.conf</filename></title>
+
+
+<para>
+<filename>/etc/host.conf</filename> is the primary means by 
+which the setting in /etc/resolv.conf may be affected. It is a 
+critical configuration file.  This file controls the order by 
+which name resolution may procede. The typical structure is:
+</para>
+
+<para><programlisting>
+	order hosts,bind
+	multi on
+</programlisting></para>
+
+<para>
+then both addresses should be returned. Please refer to the 
+man page for host.conf for further details.
+</para>
+
+
+</sect2>
+
+
+
+<sect2>
+<title><filename>/etc/nsswitch.conf</filename></title>
+
+<para>
+This file controls the actual name resolution targets. The 
+file typically has resolver object specifications as follows:
+</para>
+
+
+<para><programlisting>
+	# /etc/nsswitch.conf
+	#
+	# Name Service Switch configuration file.
+	#
+
+	passwd:		compat
+	# Alternative entries for password authentication are:
+	# passwd:	compat files nis ldap winbind
+	shadow:		compat
+	group:		compat
+
+	hosts:		files nis dns
+	# Alternative entries for host name resolution are:
+	# hosts:	files dns nis nis+ hesoid db compat ldap wins
+	networks:	nis files dns
+
+	ethers:		nis files
+	protocols:	nis files
+	rpc:		nis files
+	services:	nis files
+</programlisting></para>
+
+<para>
+Of course, each of these mechanisms requires that the appropriate 
+facilities and/or services are correctly configured.
+</para>
+
+<para>
+It should be noted that unless a network request/message must be 
+sent, TCP/IP networks are silent. All TCP/IP communications assumes a 
+principal of speaking only when necessary.
+</para>
+
+<para>
+Samba version 2.2.0 will add Linux support for extensions to 
+the name service switch infrastructure so that linux clients will 
+be able to obtain resolution of MS Windows NetBIOS names to IP 
+Addresses. To gain this functionality Samba needs to be compiled 
+with appropriate arguments to the make command (ie: <command>make 
+nsswitch/libnss_wins.so</command>). The resulting library should 
+then be installed in the <filename>/lib</filename> directory and 
+the "wins" parameter needs to be added to the "hosts:" line in 
+the <filename>/etc/nsswitch.conf</filename> file. At this point it 
+will be possible to ping any MS Windows machine by it's NetBIOS 
+machine name, so long as that machine is within the workgroup to 
+which both the samba machine and the MS Windows machine belong.
+</para>
+
+</sect2>
+</sect1>
+
+
+<sect1>
+<title>Name resolution as used within MS Windows networking</title>
+
+<para>
+MS Windows networking is predicated about the name each machine 
+is given. This name is known variously (and inconsistently) as 
+the "computer name", "machine name", "networking name", "netbios name", 
+"SMB name". All terms mean the same thing with the exception of 
+"netbios name" which can apply also to the name of the workgroup or the 
+domain name. The terms "workgroup" and "domain" are really just a 
+simply name with which the machine is associated. All NetBIOS names 
+are exactly 16 characters in length. The 16th character is reserved. 
+It is used to store a one byte value that indicates service level 
+information for the NetBIOS name that is registered. A NetBIOS machine 
+name is therefore registered for each service type that is provided by 
+the client/server.
+</para>
+
+<para>
+The following are typical NetBIOS name/service type registrations:
+</para>
+
+<para><programlisting>
+	Unique NetBIOS Names:
+		MACHINENAME<00>	= Server Service is running on MACHINENAME
+		MACHINENAME<03> = Generic Machine Name (NetBIOS name)
+		MACHINENAME<20> = LanMan Server service is running on MACHINENAME
+		WORKGROUP<1b> = Domain Master Browser
+
+	Group Names:
+		WORKGROUP<03> = Generic Name registered by all members of WORKGROUP
+		WORKGROUP<1c> = Domain Controllers / Netlogon Servers
+		WORKGROUP<1d> = Local Master Browsers
+		WORKGROUP<1e> = Internet Name Resolvers
+</programlisting></para>
+
+<para>
+It should be noted that all NetBIOS machines register their own 
+names as per the above. This is in vast contrast to TCP/IP 
+installations where traditionally the system administrator will 
+determine in the /etc/hosts or in the DNS database what names 
+are associated with each IP address.
+</para>
+
+<para>
+One further point of clarification should be noted, the <filename>/etc/hosts</filename> 
+file and the DNS records do not provide the NetBIOS name type information 
+that MS Windows clients depend on to locate the type of service that may 
+be needed. An example of this is what happens when an MS Windows client 
+wants to locate a domain logon server. It find this service and the IP 
+address of a server that provides it by performing a lookup (via a 
+NetBIOS broadcast) for enumeration of all machines that have 
+registered the name type *<1c>. A logon request is then sent to each 
+IP address that is returned in the enumerated list of IP addresses. Which 
+ever machine first replies then ends up providing the logon services.
+</para>
+
+<para>
+The name "workgroup" or "domain" really can be confusing since these 
+have the added significance of indicating what is the security 
+architecture of the MS Windows network. The term "workgroup" indicates 
+that the primary nature of the network environment is that of a 
+peer-to-peer design. In a WORKGROUP all machines are responsible for 
+their own security, and generally such security is limited to use of 
+just a password (known as SHARE MORE security). In most situations 
+with peer-to-peer networking the users who control their own machines 
+will simply opt to have no security at all. It is possible to have 
+USER MODE security in a WORKGROUP environment, thus requiring use 
+of a user name and a matching password.
+</para>
+
+<para>
+MS Windows networking is thus predetermined to use machine names 
+for all local and remote machine message passing. The protocol used is 
+called Server Message Block (SMB) and this is implemented using 
+the NetBIOS protocol (Network Basic Input Output System). NetBIOS can 
+be encapsulated using LLC (Logical Link Control) protocol - in which case 
+the resulting protocol is called NetBEUI (Network Basic Extended User 
+Interface). NetBIOS can also be run over IPX (Internetworking Packet 
+Exchange) protocol as used by Novell NetWare, and it can be run 
+over TCP/IP protocols - in which case the resulting protocol is called 
+NBT or NetBT, the NetBIOS over TCP/IP.
+</para>
+
+<para>
+MS Windows machines use a complex array of name resolution mechanisms. 
+Since we are primarily concerned with TCP/IP this demonstration is 
+limited to this area.
+</para>
+
+<sect2>
+<title>The NetBIOS Name Cache</title>
+
+<para>
+All MS Windows machines employ an in memory buffer in which is 
+stored the NetBIOS names and their IP addresses for all external 
+machines that that the local machine has communicated with over the 
+past 10-15 minutes. It is more efficient to obtain an IP address 
+for a machine from the local cache than it is to go through all the 
+configured name resolution mechanisms.
+</para>
+
+<para>
+If a machine whose name is in the local name cache has been shut 
+down before the name had been expired and flushed from the cache, then 
+an attempt to exchange a message with that machine will be subject 
+to time-out delays. ie: It's name is in the cache, so a name resolution 
+lookup will succeed, but the machine can not respond. This can be 
+frustrating for users - but it is a characteristic of the protocol.
+</para>
+
+<para>
+The MS Windows utility that allows examination of the NetBIOS 
+name cache is called "nbtstat". The Samba equivalent of this 
+is called "nmblookup".
+</para>
+
+</sect2>
+
+<sect2>
+<title>The LMHOSTS file</title>
+
+<para>
+This file is usually located in MS Windows NT 4.0 or 
+2000 in <filename>C:\WINNT\SYSTEM32\DRIVERS\ETC</filename> and contains 
+the IP Address and the machine name in matched pairs. The 
+<filename>LMHOSTS</filename> file performs NetBIOS name 
+to IP address mapping oriented.
+</para>
+
+<para>
+It typically looks like:
+</para>
+
+<para><programlisting>
+	# Copyright (c) 1998 Microsoft Corp.
+	#
+	# This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS
+	# over TCP/IP) stack for Windows98
+	#
+	# This file contains the mappings of IP addresses to NT computernames
+	# (NetBIOS) names.  Each entry should be kept on an individual line.
+	# The IP address should be placed in the first column followed by the
+	# corresponding computername. The address and the comptername
+	# should be separated by at least one space or tab. The "#" character
+	# is generally used to denote the start of a comment (see the exceptions
+	# below).
+	#
+	# This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts
+	# files and offers the following extensions:
+	#
+	#      #PRE
+	#      #DOM:&lt;domain&gt;
+	#      #INCLUDE &lt;filename&gt;
+	#      #BEGIN_ALTERNATE
+	#      #END_ALTERNATE
+	#      \0xnn (non-printing character support)
+	#
+	# Following any entry in the file with the characters "#PRE" will cause
+	# the entry to be preloaded into the name cache. By default, entries are
+	# not preloaded, but are parsed only after dynamic name resolution fails.
+	#
+	# Following an entry with the "#DOM:&lt;domain&gt;" tag will associate the
+	# entry with the domain specified by &lt;domain&gt;. This affects how the
+	# browser and logon services behave in TCP/IP environments. To preload
+	# the host name associated with #DOM entry, it is necessary to also add a
+	# #PRE to the line. The &lt;domain&gt; is always preloaded although it will not
+	# be shown when the name cache is viewed.
+	#
+	# Specifying "#INCLUDE &lt;filename&gt;" will force the RFC NetBIOS (NBT)
+	# software to seek the specified &lt;filename&gt; and parse it as if it were
+	# local. &lt;filename&gt; is generally a UNC-based name, allowing a
+	# centralized lmhosts file to be maintained on a server.
+	# It is ALWAYS necessary to provide a mapping for the IP address of the
+	# server prior to the #INCLUDE. This mapping must use the #PRE directive.
+	# In addtion the share "public" in the example below must be in the
+	# LanManServer list of "NullSessionShares" in order for client machines to
+	# be able to read the lmhosts file successfully. This key is under
+	# \machine\system\currentcontrolset\services\lanmanserver\parameters\nullsessionshares
+	# in the registry. Simply add "public" to the list found there.
+	#
+	# The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE
+	# statements to be grouped together. Any single successful include
+	# will cause the group to succeed.
+	#
+	# Finally, non-printing characters can be embedded in mappings by
+	# first surrounding the NetBIOS name in quotations, then using the
+	# \0xnn notation to specify a hex value for a non-printing character.
+	#
+	# The following example illustrates all of these extensions:
+	#
+	# 102.54.94.97     rhino         #PRE #DOM:networking  #net group's DC
+	# 102.54.94.102    "appname  \0x14"                    #special app server
+	# 102.54.94.123    popular            #PRE             #source server
+	# 102.54.94.117    localsrv           #PRE             #needed for the include
+	#
+	# #BEGIN_ALTERNATE
+	# #INCLUDE \\localsrv\public\lmhosts
+	# #INCLUDE \\rhino\public\lmhosts
+	# #END_ALTERNATE
+	#
+	# In the above example, the "appname" server contains a special
+	# character in its name, the "popular" and "localsrv" server names are
+	# preloaded, and the "rhino" server name is specified so it can be used
+	# to later #INCLUDE a centrally maintained lmhosts file if the "localsrv"
+	# system is unavailable.
+	#
+	# Note that the whole file is parsed including comments on each lookup,
+	# 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>
+
+</sect2>
+
+<sect2>
+<title>HOSTS file</title>
+
+<para>
+This file is usually located in MS Windows NT 4.0 or 2000 in 
+<filename>C:\WINNT\SYSTEM32\DRIVERS\ETC</filename> and contains 
+the IP Address and the IP hostname in matched pairs. It can be 
+used by the name resolution infrastructure in MS Windows, depending 
+on how the TCP/IP environment is configured. This file is in 
+every way the equivalent of the Unix/Linux <filename>/etc/hosts</filename> file.
+</para>
+</sect2>
+
+
+<sect2>
+<title>DNS Lookup</title>
+
+<para>
+This capability is configured in the TCP/IP setup area in the network 
+configuration facility. If enabled an elaborate name resolution sequence 
+is followed the precise nature of which isdependant on what the NetBIOS 
+Node Type parameter is configured to. A Node Type of 0 means use 
+NetBIOS broadcast (over UDP broadcast) is first used if the name 
+that is the subject of a name lookup is not found in the NetBIOS name 
+cache. If that fails then DNS, HOSTS and LMHOSTS are checked. If set to 
+Node Type 8, then a NetBIOS Unicast (over UDP Unicast) is sent to the 
+WINS Server to obtain a lookup before DNS, HOSTS, LMHOSTS, or broadcast 
+lookup is used.
+</para>
+
+</sect2>
+
+<sect2>
+<title>WINS Lookup</title>
+
+<para>
+A WINS (Windows Internet Name Server) service is the equivaent of the 
+rfc1001/1002 specified NBNS (NetBIOS Name Server). A WINS server stores 
+the names and IP addresses that are registered by a Windows client 
+if the TCP/IP setup has been given at least one WINS Server IP Address.
+</para>
+
+<para>
+To configure Samba to be a WINS server the following parameter needs 
+to be added to the <filename>smb.conf</filename> file:
+</para>
+
+<para><programlisting>
+	wins support = Yes
+</programlisting></para>
+
+<para>
+To configure Samba to use a WINS server the following parameters are 
+needed in the smb.conf file:
+</para>
+
+<para><programlisting>
+	wins support = No
+	wins server = xxx.xxx.xxx.xxx
+</programlisting></para>
+
+<para>
+where <replaceable>xxx.xxx.xxx.xxx</replaceable> is the IP address 
+of the WINS server.
+</para>
+
+</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 
+(ie: 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 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 SMB protocol 
+has a mechanism by which the connection can be re-established 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 and 
+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>
diff --git a/docs/docbook/projdoc/NT_Security.sgml b/docs/docbook/projdoc/NT_Security.sgml
index 28dcb5160d..2259dae029 100644
--- a/docs/docbook/projdoc/NT_Security.sgml
+++ b/docs/docbook/projdoc/NT_Security.sgml
@@ -1,4 +1,4 @@
-<chapter>
+<chapter id="unix-permissions">
 
 <chapterinfo>
 	<author>
@@ -16,7 +16,7 @@
 </chapterinfo>
 
 
-<title>UNIX Permission Bits and WIndows NT Access Control Lists</title>
+<title>UNIX Permission Bits and Windows NT Access Control Lists</title>
 
 <sect1>
 	<title>Viewing and changing UNIX permissions using the NT 
@@ -75,7 +75,7 @@
 	<para>Where <replaceable>SERVER</replaceable> is the NetBIOS name of 
 	the Samba server, <replaceable>user</replaceable> is the user name of 
 	the UNIX user who owns the file, and <replaceable>(Long name)</replaceable>
-	is the discriptive string identifying the user (normally found in the
+	is the descriptive string identifying the user (normally found in the
 	GECOS field of the UNIX password database). Click on the <command>Close
 	</command> button to remove this dialog.</para>
 
@@ -87,14 +87,14 @@
 	you to change the ownership of this file to yourself (clicking on 
 	it will display a dialog box complaining that the user you are 
 	currently logged onto the NT client cannot be found). The reason 
-	for this is that changing the ownership of a file is a privilaged 
+	for this is that changing the ownership of a file is a privileged 
 	operation in UNIX, available only to the <emphasis>root</emphasis> 
 	user. As clicking on this button causes NT to attempt to change 
 	the ownership of a file to the current user logged into the NT 
 	client this will not work with Samba at this time.</para>
 
 	<para>There is an NT chown command that will work with Samba 
-	and allow a user with Administrator privillage connected 
+	and allow a user with Administrator privilege connected 
 	to a Samba 2.0.4 server as root to change the ownership of 
 	files on both a local NTFS filesystem or remote mounted NTFS 
 	or Samba drive. This is available as part of the <emphasis>Seclib
@@ -116,7 +116,7 @@
 	<para>Where <replaceable>SERVER</replaceable> is the NetBIOS name of 
 	the Samba server, <replaceable>user</replaceable> is the user name of 
 	the UNIX user who owns the file, and <replaceable>(Long name)</replaceable>
-	is the discriptive string identifying the user (normally found in the
+	is the descriptive string identifying the user (normally found in the
 	GECOS field of the UNIX password database).</para>
 
 	<para>If the parameter <parameter>nt acl support</parameter>
@@ -133,7 +133,7 @@
 		<title>File Permissions</title>
 
 		<para>The standard UNIX user/group/world triple and 
-		the correspinding "read", "write", "execute" permissions 
+		the corresponding "read", "write", "execute" permissions 
 		triples are mapped by Samba into a three element NT ACL 
 		with the 'r', 'w', and 'x' bits mapped into the corresponding 
 		NT permissions. The UNIX world permissions are mapped into 
@@ -200,7 +200,7 @@
 
 	<para>The first thing to note is that the <command>"Add"</command> 
 	button will not return a list of users in Samba 2.0.4 (it will give 
-	an error message of <command>"The remote proceedure call failed 
+	an error message of <command>"The remote procedure call failed 
 	and did not execute"</command>). This means that you can only 
 	manipulate the current user/group/world permissions listed in 
 	the dialog box. This actually works quite well as these are the 
@@ -231,7 +231,7 @@
 	user/group/world  component then you may either highlight the 
 	component and click the <command>"Remove"</command> button, 
 	or set the component to only have the special <command>"Take
-	Ownership"</command> permission (dsplayed as <command>"O"
+	Ownership"</command> permission (displayed as <command>"O"
 	</command>) highlighted.</para>
 </sect1>
 
@@ -281,7 +281,7 @@
 	as the <ulink url="smb.conf.5.html#FORCECREATEMODE"><parameter>force 
 	create mode</parameter></ulink> parameter to provide compatibility
 	with Samba 2.0.4 where the permission change facility was introduced.
-	To allow a user to modify all the user/group/world permissions on a file,
+	To allow a user to modify all the user/group/world permissions on a file
 	with no restrictions set this parameter to 000.</para>
 
 	<para>The <parameter>security mask</parameter> and <parameter>force 
diff --git a/docs/docbook/projdoc/OS2-Client-HOWTO.sgml b/docs/docbook/projdoc/OS2-Client-HOWTO.sgml
index 5db80cda3d..ca7ad6a754 100644
--- a/docs/docbook/projdoc/OS2-Client-HOWTO.sgml
+++ b/docs/docbook/projdoc/OS2-Client-HOWTO.sgml
@@ -1,4 +1,4 @@
-<chapter>
+<chapter id="os2">
 
 
 <chapterinfo>
@@ -116,7 +116,7 @@
 		driver from an OS/2 system.</para>
 		
 		<para>Install the NT driver first for that printer.  Then, 
-		add to your smb.conf a paramater, "os2 driver map = 
+		add to your smb.conf a parameter, "os2 driver map = 
 		<replaceable>filename</replaceable>".  Then, in the file 
 		specified by <replaceable>filename</replaceable>, map the 
 		name of the NT driver name to the OS/2 driver name as 
diff --git a/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml b/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml
new file mode 100644
index 0000000000..6c866acecd
--- /dev/null
+++ b/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml
@@ -0,0 +1,212 @@
+<chapter id="pam">
+ 
+ 
+<chapterinfo>
+        <author>
+		<firstname>John</firstname><surname>Terpstra</surname>
+                <affiliation>
+                        <orgname>Samba Team</orgname>
+			<address>
+			<email>jht@samba.org</email>
+			</address>
+                </affiliation>
+        </author>
+ 
+ 
+        <pubdate> (Jun 21 2001) </pubdate>
+</chapterinfo>
+ 
+<title>Configuring PAM for distributed but centrally 
+managed authentication</title>
+
+<sect1>
+<title>Samba and PAM</title>
+
+<para>
+A number of Unix systems (eg: Sun Solaris), as well as the 
+xxxxBSD family and Linux, now utilize the Pluggable Authentication 
+Modules (PAM) facility to provide all authentication, 
+authorization and resource control services. Prior to the 
+introduction of PAM, a decision to use an alternative to 
+the system password database (<filename>/etc/passwd</filename>) 
+would require the provision of alternatives for all programs that provide 
+security services. Such a choice would involve provision of 
+alternatives to such programs as: <command>login</command>, 
+<command>passwd</command>, <command>chown</command>, etc.
+</para>
+
+<para>
+PAM provides a mechanism that disconnects these security programs 
+from the underlying authentication/authorization infrastructure.
+PAM is configured either through one file <filename>/etc/pam.conf</filename> (Solaris), 
+or by editing individual files that are located in <filename>/etc/pam.d</filename>.
+</para>
+
+<para>
+The following is an example <filename>/etc/pam.d/login</filename> configuration file. 
+This example had all options been uncommented is probably not usable 
+as it stacks many conditions before allowing successful completion 
+of the login process. Essentially all conditions can be disabled 
+by commenting them out except the calls to <filename>pam_pwdb.so</filename>.
+</para>
+
+<para><programlisting>
+#%PAM-1.0
+# The PAM configuration file for the `login' service
+#
+auth 		required	pam_securetty.so
+auth 		required	pam_nologin.so
+# auth 		required	pam_dialup.so
+# auth 		optional	pam_mail.so
+auth		required	pam_pwdb.so shadow md5
+# account    	requisite  	pam_time.so
+account		required	pam_pwdb.so
+session		required	pam_pwdb.so
+# session 	optional	pam_lastlog.so
+# password   	required   	pam_cracklib.so retry=3
+password	required	pam_pwdb.so shadow md5
+</programlisting></para>
+
+<para>
+PAM allows use of replacable modules. Those available on a 
+sample system include:
+</para>
+
+<para><programlisting>
+$ /bin/ls /lib/security
+pam_access.so    pam_ftp.so          pam_limits.so     
+pam_ncp_auth.so  pam_rhosts_auth.so  pam_stress.so     
+pam_cracklib.so  pam_group.so        pam_listfile.so   
+pam_nologin.so   pam_rootok.so       pam_tally.so      
+pam_deny.so      pam_issue.so        pam_mail.so       
+pam_permit.so    pam_securetty.so    pam_time.so       
+pam_dialup.so    pam_lastlog.so      pam_mkhomedir.so  
+pam_pwdb.so      pam_shells.so       pam_unix.so       
+pam_env.so       pam_ldap.so         pam_motd.so       
+pam_radius.so    pam_smbpass.so      pam_unix_acct.so  
+pam_wheel.so     pam_unix_auth.so    pam_unix_passwd.so
+pam_userdb.so    pam_warn.so         pam_unix_session.so
+</programlisting></para>
+
+<para>
+The following example for the login program replaces the use of 
+the <filename>pam_pwdb.so</filename> module which uses the system 
+password database (<filename>/etc/passwd</filename>,
+<filename>/etc/shadow</filename>, <filename>/etc/group</filename>) with 
+the module <filename>pam_smbpass.so</filename> which uses the Samba 
+database which contains the Microsoft MD4 encrypted password 
+hashes. This database is stored in either 
+<filename>/usr/local/samba/private/smbpasswd</filename>, 
+<filename>/etc/samba/smbpasswd</filename>, or in 
+<filename>/etc/samba.d/smbpasswd</filename>, depending on the 
+Samba implementation for your Unix/Linux system. The 
+<filename>pam_smbpass.so</filename> module is provided by 
+Samba version 2.2.1 or later. It can be compiled only if the 
+<constant>--with-pam --with-pam_smbpass</constant> options are both 
+provided to the Samba <command>configure</command> program.
+</para>
+
+<para><programlisting>
+#%PAM-1.0
+# The PAM configuration file for the `login' service
+#
+auth		required	pam_smbpass.so nodelay
+account		required	pam_smbpass.so nodelay
+session		required	pam_smbpass.so nodelay
+password	required	pam_smbpass.so nodelay
+</programlisting></para>
+
+<para>
+The following is the PAM configuration file for a particular 
+Linux system. The default condition uses <filename>pam_pwdb.so</filename>.
+</para>
+
+<para><programlisting>
+#%PAM-1.0
+# The PAM configuration file for the `samba' service
+#
+auth       required     /lib/security/pam_pwdb.so nullok nodelay shadow audit
+account    required     /lib/security/pam_pwdb.so audit nodelay
+session    required     /lib/security/pam_pwdb.so nodelay
+password   required     /lib/security/pam_pwdb.so shadow md5
+</programlisting></para>
+
+<para>
+In the following example the decision has been made to use the 
+smbpasswd database even for basic samba authentication. Such a 
+decision could also be made for the passwd program and would 
+thus allow the smbpasswd passwords to be changed using the passwd 
+program.
+</para>
+
+<para><programlisting>
+#%PAM-1.0
+# The PAM configuration file for the `samba' service
+#
+auth       required     /lib/security/pam_smbpass.so nodelay
+account    required     /lib/security/pam_pwdb.so audit nodelay
+session    required     /lib/security/pam_pwdb.so nodelay
+password   required     /lib/security/pam_smbpass.so nodelay smbconf=/etc/samba.d/smb.conf
+</programlisting></para>
+
+<para>
+Note: PAM allows stacking of authentication mechanisms. It is 
+also possible to pass information obtained within on PAM module through 
+to the next module in the PAM stack. Please refer to the documentation for 
+your particular system implementation for details regarding the specific 
+capabilities of PAM in this environment. Some Linux implmentations also 
+provide the <filename>pam_stack.so</filename> module that allows all 
+authentication to be configured in a single central file. The 
+<filename>pam_stack.so</filename> method has some very devoted followers 
+on the basis that it allows for easier administration. As with all issues in 
+life though, every decision makes trade-offs, so you may want examine the 
+PAM documentation for further helpful information.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Distributed Authentication</title>
+
+<para>
+The astute administrator will realize from this that the 
+combination of <filename>pam_smbpass.so</filename>, 
+<command>winbindd</command>, and <command>rsync</command> (see
+<ulink url="http://rsync.samba.org/">http://rsync.samba.org/</ulink>)
+will allow the establishment of a centrally managed, distributed 
+user/password database that can also be used by all 
+PAM (eg: Linux) aware programs and applications. This arrangement 
+can have particularly potent advantages compared with the 
+use of Microsoft Active Directory Service (ADS) in so far as 
+reduction of wide area network authentication traffic.
+</para>
+
+</sect1>
+
+<sect1>
+<title>PAM Configuration in smb.conf</title>
+
+<para>
+There is an option in smb.conf called <ulink 
+url="smb.conf.5.html#OBEYPAMRESTRICTIONS">obey pam restrictions</ulink>. 
+The following is from the on-line help for this option in SWAT;
+</para>
+
+<para>
+When Samba 2.2 is configure to enable PAM support (i.e. 
+<constant>--with-pam</constant>), this parameter will 
+control whether or not Samba should obey PAM's account 
+and session management directives. The default behavior 
+is to use PAM for clear text authentication only and to 
+ignore any account or session management. Note that Samba always 
+ignores PAM for authentication in the case of 
+<ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">encrypt passwords = yes</ulink>. 
+The reason is that PAM modules cannot support the challenge/response 
+authentication mechanism needed in the presence of SMB 
+password encryption. 
+</para>
+
+<para>Default: <command>obey pam restrictions = no</command></para>
+
+</sect1>
+</chapter>
diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml b/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml
index 0b86bcba63..b980b99e22 100644
--- a/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml
+++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml
@@ -1,4 +1,4 @@
-<chapter>
+<chapter id="samba-pdc">
 
 
 <chapterinfo>
@@ -32,12 +32,12 @@ How to Configure Samba 2.2 as a Primary Domain Controller
 <title>Prerequisite Reading</title>
 
 <para>
-Before you continue readingin this chapter, please make sure 
+Before you continue reading in this chapter, please make sure 
 that you are comfortable with configuring basic files services
-in smb.conf and how to enable and administrate password 
+in smb.conf and how to enable and administer password 
 encryption in Samba.  Theses two topics are covered in the
 <ulink url="smb.conf.5.html"><filename>smb.conf(5)</filename></ulink> 
-manpage and the <ulink url="EMCRYPTION.html">Encryption chapter</ulink> 
+manpage and the <ulink url="ENCRYPTION.html">Encryption chapter</ulink> 
 of this HOWTO Collection.
 </para>
 
@@ -60,13 +60,14 @@ Background
 <para>
 <emphasis>Author's Note :</emphasis> This document is a combination 
 of David Bannon's Samba 2.2 PDC HOWTO and the Samba NT Domain FAQ. 
-Both documents are superceeded by this one.
+Both documents are superseded by this one.
 </para>
 </note>
 
 <para>
 Version of Samba prior to release 2.2 had marginal capabilities to
-act as a Windows NT 4.0 Primary Domain Controller (PDC).  Beginning with 
+act as a Windows NT 4.0 Primary DOmain Controller <indexterm><primary>Primary 
+Domain Controller</primary></indexterm> (PDC).  Beginning with 
 Samba 2.2.0, we are proud to announce official support for Windows NT 4.0 
 style domain logons from Windows NT 4.0 (through SP6) and Windows 2000 (through 
 SP1) clients.  This article outlines the steps necessary for configuring Samba 
@@ -264,9 +265,8 @@ There are a couple of points to emphasize in the above configuration.
 <para>
 As Samba 2.2 does not offer a complete implementation of group mapping between 
 Windows NT groups and UNIX groups (this is really quite complicated to explain 
-in a short space), you should refer to the <ulink url="smb.conf.5.html#DOMAINADMINUSERS">domain 
-admin users</ulink> and <ulink url="smb.conf.5.html#DOMAINADMINGROUP">domain 
-admin group</ulink> smb.conf parameters for information of creating a Domain Admins 
+in a short space), you should refer to the <ulink url="smb.conf.5.html#DOMAINADMINGROUP">domain 
+admin group</ulink> smb.conf parameter for information of creating "Domain Admins"
 style accounts.
 </para>
 
@@ -281,7 +281,7 @@ to the Domain</title>
 A machine trust account is a samba user account owned by a computer.  
 The account password acts as the shared secret for secure 
 communication with the Domain Controller.  This is a security feature
-to prevent an unauthorized machine with the same netbios name from 
+to prevent an unauthorized machine with the same NetBIOS name from 
 joining the domain and gaining access to domain user/group accounts.  
 Hence a Windows 9x host is never a true member of a domain because it does 
 not posses a machine trust account, and thus has no shared secret with the DC.
@@ -310,7 +310,7 @@ There are two means of creating machine trust accounts.
 	<listitem><para>
 	Manual creation before joining the client to the domain.  In this case, 
 	the password is set to a known value -- the lower case of the 
-	machine's netbios name.
+	machine's NetBIOS name.
 	</para></listitem>
 	
 	<listitem><para>
@@ -333,8 +333,11 @@ based Samba server:
 </para>
 
 <para>
-<prompt>root# </prompt>/usr/sbin/useradd -g 100 -d /dev/null -c <replaceable>
-machine_nickname</replaceable> -m -s /bin/false <replaceable>machine_name</replaceable>$
+<prompt>root# </prompt>/usr/sbin/useradd -g 100 -d /dev/null -c <replaceable>"machine 
+nickname"</replaceable> -s /bin/false <replaceable>machine_name</replaceable>$ 
+</para>
+<para>
+<prompt>root# </prompt>passwd -l <replaceable>machine_name</replaceable>$
 </para>
 
 <para>
@@ -351,7 +354,7 @@ doppy$:x:505:501:<replaceable>machine_nickname</replaceable>:/dev/null:/bin/fals
 <para>
 Above, <replaceable>machine_nickname</replaceable> can be any descriptive name for the
 pc i.e. BasementComputer. The <replaceable>machine_name</replaceable> absolutely must be 
-the netbios name of the pc to be added to the domain.  The "$" must append the netbios
+the NetBIOS name of the pc to be added to the domain.  The "$" must append the NetBIOS
 name of the pc or samba will not recognize this as a machine account
 </para>
 
@@ -369,7 +372,7 @@ as shown here:
 </para>
 
 <para>
-where <replaceable>machine_name</replaceable> is the machine's netbios
+where <replaceable>machine_name</replaceable> is the machine's NetBIOS
 name. 
 </para>
 
@@ -382,7 +385,7 @@ name.
 	the "Server Manager".  From the time at which the account is created
 	to the time which th client joins the domain and changes the password,
 	your domain is vulnerable to an intruder joining your domain using a
-	a machine with the same netbios name.  A PDC inherently trusts
+	a machine with the same NetBIOS name.  A PDC inherently trusts
 	members of the domain and will serve out a large degree of user 
 	information to such clients.  You have been warned!
 	</para>
@@ -409,7 +412,7 @@ add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u
 In Samba 2.2.1, <emphasis>only the root account</emphasis> can be used to create
 machine accounts like this.  Therefore, it is required to create 
 an entry in smbpasswd for <emphasis>root</emphasis>.  The password 
-<emphasis>SHOULD</emphasis> be set to s different password that the 
+<emphasis>SHOULD</emphasis> be set to a different password that the 
 associated <filename>/etc/passwd</filename> entry for security reasons.
 </para>
 </sect2>
@@ -519,8 +522,8 @@ associated <filename>/etc/passwd</filename> entry for security reasons.
 	have not been created correctly. Make sure that you have the entry 
 	correct for the machine account in smbpasswd file on the Samba PDC. 
 	If you added the account using an editor rather than using the smbpasswd 
-	utility, make sure that the account name is the machine netbios name 
-	with a '$' appended to it ( ie. computer_name$ ). There must be an entry 
+	utility, make sure that the account name is the machine NetBIOS name 
+	with a '$' appended to it ( i.e. computer_name$ ). There must be an entry 
 	in both /etc/passwd and the smbpasswd file. Some people have reported 
 	that inconsistent subnet masks between the Samba server and the NT 
 	client have caused this problem.   Make sure that these are consistent 
@@ -543,7 +546,7 @@ associated <filename>/etc/passwd</filename> entry for security reasons.
  
 	<para>
 	At first be ensure to enable the useraccounts with <command>smbpasswd -e 
-	%user%</command>, this is normaly done, when you create an account.
+	%user%</command>, this is normally done, when you create an account.
 	</para>
 
 	<para>
@@ -619,7 +622,7 @@ Here are some additional details:
 	<para>
 	The Windows NT policy editor is also included with the Service Pack 3 (and 
 	later) for Windows NT 4.0. Extract the files using <command>servicepackname /x</command>, 
-	ie thats <command>Nt4sp6ai.exe /x</command> for service pack 6a.  The policy editor, 
+	i.e. that's <command>Nt4sp6ai.exe /x</command> for service pack 6a.  The policy editor, 
 	<command>poledit.exe</command> and the associated template files (*.adm) should
 	be extracted as well.  It is also possible to downloaded the policy template 
 	files for Office97 and get a copy of the policy editor.  Another possible 
@@ -715,7 +718,7 @@ general SMB topics such as browsing.</para>
 
    <para>
 	One of the best diagnostic tools for debugging problems is Samba itself.  
-	You can use the -d option for both smbd and nmbd to specifiy what 
+	You can use the -d option for both smbd and nmbd to specify what 
 	'debug level' at which to run.  See the man pages on smbd, nmbd  and 
 	smb.conf for more information on debugging options.  The debug 
 	level can range from 1 (the default) to 10 (100 for debugging passwords).
@@ -758,7 +761,7 @@ general SMB topics such as browsing.</para>
 	(aka. netmon) is available on the Microsoft Developer Network CD's, 
 	the Windows NT Server install CD and the SMS CD's.  The version of 
 	netmon that ships with SMS allows for dumping packets between any two 
-	computers (ie. placing the network interface in promiscuous mode).  
+	computers (i.e. placing the network interface in promiscuous mode).  
 	The version on the NT Server install CD will only allow monitoring 
 	of network traffic directed to the local NT box and broadcasts on the 
 	local subnet.  Be aware that Ethereal can read and write netmon 
@@ -934,7 +937,7 @@ general SMB topics such as browsing.</para>
 		</para></listitem> 
 
 	<listitem><para> Don't cross post. Work out which is the best list to post to 
-		and see what happens, ie don't post to both samba-ntdom and samba-technical.
+		and see what happens, i.e. don't post to both samba-ntdom and samba-technical.
         Many people active on the lists subscribe to more 
 		than one list and get annoyed to see the same message two or more times. 
 		Often someone will see a message and thinking it would be better dealt 
@@ -1026,7 +1029,7 @@ When an SMB client in a domain wishes to logon it broadcast requests for a
 logon server.  The first one to reply gets the job, and validates its
 password using whatever mechanism the Samba administrator has installed.
 It is possible (but very stupid) to create a domain where the user
-database is not shared between servers, ie they are effectively workgroup
+database is not shared between servers, i.e. they are effectively workgroup
 servers advertising themselves as participating in a domain.  This
 demonstrates how authentication is quite different from but closely
 involved with domains.
@@ -1124,7 +1127,7 @@ at how a Win9X client performs a logon:
 <listitem>
 	<para>
 	The client then connects to the user's home share and searches for the 
-	user's profile. As it turns out, you can specify the users home share as
+	user's profile. As it turns out, you can specify the user's home share as
 	a sharename and path. For example, \\server\fred\.profile.
 	If the profiles are found, they are implemented.
 	</para>
@@ -1229,7 +1232,7 @@ logon script = scripts\%U.bat
 
 <listitem>
 	<para>
-	you will probabaly find that your clients automatically mount the
+	you will probably find that your clients automatically mount the
 	\\SERVER\NETLOGON share as drive z: while logging in. You can put
 	some useful programs there to execute from the batch files.
 	</para>
@@ -1255,7 +1258,7 @@ or not Samba must be the domain master browser for its workgroup
 when operating as a DC.  While it may technically be possible
 to configure a server as such (after all, browsing and domain logons
 are two distinctly different functions), it is not a good idea to
-so.  You should remember that the DC must register the DOMAIN#1b netbios 
+so.  You should remember that the DC must register the DOMAIN#1b NetBIOS 
 name.  This is the name used by Windows clients to locate the DC.
 Windows clients do not distinguish between the DC and the DMB.
 For this reason, it is very wise to configure the Samba DC as the DMB.
@@ -1302,7 +1305,7 @@ Win9X and WinNT clients implement these features.
 <para>
 Win9X clients send a NetUserGetInfo request to the server to get the user's
 profiles location. However, the response does not have room for a separate 
-profiles location field, only the users home share. This means that Win9X 
+profiles location field, only the user's home share. This means that Win9X 
 profiles are restricted to being in the user's home directory.
 </para>
 
@@ -1414,7 +1417,7 @@ as are folders "Start Menu", "Desktop", "Programs" and "Nethood".
 These directories and their contents will be merged with the local
 versions stored in c:\windows\profiles\username on subsequent logins,
 taking the most recent from each.  You will need to use the [global]
-options "preserve case = yes", "short case preserve = yes" and
+options "preserve case = yes", "short preserve case = yes" and
 "case sensitive = no" in order to maintain capital letters in shortcuts
 in any of the profile folders.
 </para>
@@ -1551,7 +1554,7 @@ they will be told that they are logging in "for the first time".
 
 <listitem>
 	<para>
-	search for the user's .PWL password-cacheing file in the c:\windows
+	search for the user's .PWL password-caching file in the c:\windows
 	directory, and delete it.
 	</para>
 </listitem>
@@ -1654,11 +1657,11 @@ matter to be resolved].
 </para>
 
 <para>
-[lkcl 20aug97 - after samba digest correspondance, one user found, and
+[lkcl 20aug97 - after samba digest correspondence, one user found, and
 another confirmed, that profiles cannot be loaded from a samba server
 unless "security = user" and "encrypt passwords = yes" (see the file
 ENCRYPTION.txt) or "security = server" and "password server = ip.address.
-of.yourNTserver" are used.  either of these options will allow the NT
+of.yourNTserver" are used.  Either of these options will allow the NT
 workstation to access the samba server using LAN manager encrypted
 passwords, without the user intervention normally required by NT
 workstation for clear-text passwords].
@@ -1843,7 +1846,7 @@ plain Servers.
 <para>
 The User database is called the SAM (Security Access Manager) database and
 is used for all user authentication as well as for authentication of inter-
-process authentication (ie: to ensure that the service action a user has
+process authentication (i.e. to ensure that the service action a user has
 requested is permitted within the limits of that user's privileges).
 </para>
 
@@ -1858,7 +1861,7 @@ to Samba systems.
 <para>
 Windows for Workgroups, Windows 95, and Windows NT Workstations and Servers
 can participate in a Domain security system that is controlled by Windows NT
-servers that have been correctly configured. At most every domain will have
+servers that have been correctly configured. Almost every domain will have
 ONE Primary Domain Controller (PDC). It is desirable that each domain will
 have at least one Backup Domain Controller (BDC).
 </para>
diff --git a/docs/docbook/projdoc/UNIX_INSTALL.sgml b/docs/docbook/projdoc/UNIX_INSTALL.sgml
index 0e4d8a5d03..ee91f6e07a 100644
--- a/docs/docbook/projdoc/UNIX_INSTALL.sgml
+++ b/docs/docbook/projdoc/UNIX_INSTALL.sgml
@@ -1,4 +1,4 @@
-<chapter>
+<chapter id="install">
 
 <title>How to Install and Test SAMBA</title>
 
@@ -30,7 +30,7 @@
 	</userinput></para>
 	
 	<para>first to see what special options you can enable.
-	Then exectuting</para>
+	Then executing</para>
 	
 	<para><prompt>root# </prompt><userinput>make</userinput></para>
 	
@@ -96,7 +96,7 @@
 	<para>which would allow connections by anyone with an 
 	account on the server, using either their login name or 
 	"homes" as the service name. (Note that I also set the 
-	workgroup that Samba is part of. See BROWSING.txt for defails)</para>
+	workgroup that Samba is part of. See BROWSING.txt for details)</para>
 	
 	<para>Note that <command>make install</command> will not install 
 	a <filename>smb.conf</filename> file. You need to create it 
@@ -120,7 +120,7 @@
 	not it will give an error message.</para>
 
 	<para>Make sure it runs OK and that the services look 
-	resonable before proceeding. </para>
+	reasonable before proceeding. </para>
 
 </sect1>
 
@@ -174,14 +174,14 @@
 		<para>NOTE: Some unixes already have entries like netbios_ns 
 		(note the underscore) in <filename>/etc/services</filename>. 
 		You must either edit <filename>/etc/services</filename> or
-		<filename>/etc/inetd.conf</filename> to make them consistant.</para>
+		<filename>/etc/inetd.conf</filename> to make them consistent.</para>
 
 		<para>NOTE: On many systems you may need to use the 
 		"interfaces" option in smb.conf to specify the IP address 
 		and netmask of your interfaces. Run <command>ifconfig</command> 
 		as root if you don't know what the broadcast is for your
 		net. <command>nmbd</command> tries to determine it at run 
-		time, but fails on somunixes. See the section on "testing nmbd" 
+		time, but fails on some unixes. See the section on "testing nmbd" 
 		for a method of finding if you need to do this.</para>
 
 		<para>!!!WARNING!!! Many unixes only accept around 5 
@@ -305,7 +305,7 @@
 	<sect2>
 		<title>Diagnosing Problems</title>
 
-		<para>If you have instalation problems then go to 
+		<para>If you have installation problems then go to 
 		<filename>DIAGNOSIS.txt</filename> to try to find the 
 		problem.</para>
 	</sect2>
@@ -419,7 +419,7 @@
 		are set by an application when it opens a file to determine 
 		what types of access should be allowed simultaneously with 
 		its open. A client may ask for DENY_NONE, DENY_READ, DENY_WRITE 
-		or DENY_ALL. There are also special compatability modes called 
+		or DENY_ALL. There are also special compatibility modes called 
 		DENY_FCB and  DENY_DOS.</para>
 
 		<para>You can disable share modes using "share modes = no". 
@@ -442,7 +442,7 @@
 
 		<para>If you have problems using filenames with accented 
 		characters in them (like the German, French or Scandinavian 
-		character sets) then I recommmend you look at the "valid chars" 
+		character sets) then I recommend you look at the "valid chars" 
 		option in smb.conf and also take a look at the validchars 
 		package in the examples directory.</para>
 	</sect2>
diff --git a/docs/docbook/projdoc/msdfs_setup.sgml b/docs/docbook/projdoc/msdfs_setup.sgml
index 5853049d79..35c9d40840 100644
--- a/docs/docbook/projdoc/msdfs_setup.sgml
+++ b/docs/docbook/projdoc/msdfs_setup.sgml
@@ -1,4 +1,4 @@
-<chapter>
+<chapter id="msdfs">
 
 <chapterinfo>
 	<author>
diff --git a/docs/docbook/projdoc/printer_driver2.sgml b/docs/docbook/projdoc/printer_driver2.sgml
index 51471ae690..4377303ffb 100644
--- a/docs/docbook/projdoc/printer_driver2.sgml
+++ b/docs/docbook/projdoc/printer_driver2.sgml
@@ -1,4 +1,4 @@
-<chapter>
+<chapter id="printing">
 
 
 <chapterinfo>
@@ -126,12 +126,19 @@ Windows NT print servers to provide support for printer driver
 download).
 </para>
 
-<para>You should modify the server's smb.conf file to create the 
+<para>You should modify the server's smb.conf file to add the global
+parameters and to create the 
 following file share (of course, some of the parameter values,
 such as 'path' are arbitrary and should be replaced with
 appropriate values for your site):</para>
 
 <para><programlisting>
+[global]
+    ; members of the ntadmin group should be able
+    ; to add drivers and set printer properties
+    ; root is implicitly a 'printer admin'
+    printer admin = @ntadmin
+
 [print$]
     path = /usr/local/samba/printers
     guest ok = yes
@@ -142,13 +149,13 @@ appropriate values for your site):</para>
     ; sure this account can copy files to the share.  If this
     ; is setup to a non-root account, then it should also exist
     ; as a 'printer admin'
-    write list = ntadmin
+    write list = @ntadmin,root
 </programlisting></para>
 	
 <para>The <ulink url="smb.conf.5.html#WRITELIST"><parameter>
 write list</parameter></ulink> is used to allow administrative 
 level user accounts to have write access in order to update files 
-on the share.  See the <ulink url="smb./conf.5.html">smb.conf(5) 
+on the share.  See the <ulink url="smb.conf.5.html">smb.conf(5) 
 man page</ulink> for more information on configuring file shares.</para>
 	
 <para>The requirement for <ulink url="smb.conf.5.html#GUESTOK"><command>guest 
@@ -345,7 +352,7 @@ Add Printer Wizard icon.  The APW will be show only if
 <itemizedlist>
 	<listitem><para>The connected user is able to successfully
 	execute an OpenPrinterEx(\\server) with administrative
-	priviledges (i.e. root or <parameter>printer admin</parameter>).
+	privileges (i.e. root or <parameter>printer admin</parameter>).
 	</para></listitem>
 	
 	<listitem><para><ulink url="smb.conf.5.html#SHOWADDPRINTERWIZARD"><parameter>show 
@@ -513,7 +520,7 @@ foreach (supported architecture for a given driver)
 		the Imprints tool set was the name space issues between 
 		various supported client architectures.  For example, Windows 
 		NT includes a driver named "Apple LaserWriter II NTX v51.8" 
-		and Windows 95 callsits version of this driver "Apple 
+		and Windows 95 calls its version of this driver "Apple 
 		LaserWriter II NTX"</para>
 		
 		<para>The problem is how to know what client drivers have 
@@ -547,71 +554,10 @@ foreach (supported architecture for a given driver)
 <para>
 Given that printer driver management has changed (we hope improved) in 
 2.2 over prior releases, migration from an existing setup to 2.2 can 
-follow several paths.
+follow several paths. Here are the possible scenarios for 
+migration:
 </para>
 
-<para>
-Windows clients have a tendency to remember things for quite a while.
-For example, if a Windows NT client has attached to a Samba 2.0 server,
-it will remember the server as a LanMan printer server.  Upgrading 
-the Samba host to 2.2 makes support for MSRPC printing possible, but 
-the NT client will still remember the previous setting.
-</para>
-
-<para>
-In order to give an NT client printing "amesia" (only necessary if you 
-want to use the newer MSRPC printing functionality in Samba), delete 
-the registry keys associated with the print server contained in 
-<constant>[HKLM\SYSTEM\CurrentControlSet\Control\Print]</constant>.  The 
-spooler service on the client should be stopped prior to doing this:
-</para>
-
-<para>
-<prompt>C:\WINNT\ ></prompt> <userinput>net stop spooler</userinput>
-</para>
-
-<para>
-<emphasis>All the normal disclaimers about editing the registry go 
-here.</emphasis>  Be careful, and know what you are doing.
-</para>
-
-<para>
-The spooler service should be restarted after you have finished 
-removing the appropriate registry entries by replacing the 
-<command>stop</command> command above with <command>start</command>.
-</para>
-
-<para>
-Windows 9x clients will continue to use LanMan printing calls
-with a 2.2 Samba server so there is no need to perform any of these
-modifications on non-NT clients.
-</para>
-	
-<warning>
-<title>Achtung!</title>
-
-<para>
-The following smb.conf parameters are considered to be depreciated and will 
-be removed soon.  Do not use them in new installations
-</para>
-		
-<itemizedlist>
-	<listitem><para><parameter>printer driver file (G)</parameter>
-	</para></listitem>
-			
-	<listitem><para><parameter>printer driver (S)</parameter>
-	</para></listitem>
-			
-	<listitem><para><parameter>printer driver location (S)</parameter>
-	</para></listitem>
-</itemizedlist>
-</warning>
-
-
-<para>
-Here are the possible scenarios for supporting migration:
-</para>
-	
 <itemizedlist>
 	<listitem><para>If you do not desire the new Windows NT 
 	print driver support, nothing needs to be done.  
@@ -620,13 +566,13 @@ Here are the possible scenarios for supporting migration:
 	<listitem><para>If you want to take advantage of NT printer 
 	driver support but do not want to migrate the 
 	9x drivers to the new setup, the leave the existing 
-	printers.def file.  When smbd attempts to locate a 
+	<filename>printers.def</filename> file.  When smbd attempts 
+	to locate a 
 	9x driver for the printer in the TDB and fails it 
 	will drop down to using the printers.def (and all 
 	associated parameters).  The <command>make_printerdef</command> 
 	tool will also remain for backwards compatibility but will 
-	be moved to the "this tool is the old way of doing it" 
-	pile.</para></listitem>
+	be removed in the next major release.</para></listitem>
 
 	<listitem><para>If you install a Windows 9x driver for a printer 
 	on your Samba host (in the printing TDB), this information will 
@@ -643,6 +589,39 @@ Here are the possible scenarios for supporting migration:
 	</para></listitem>
 </itemizedlist>
 
+
+<warning>
+<title>Achtung!</title>
+
+<para>
+The following <filename>smb.conf</filename> parameters are considered to 
+be deprecated and will be removed soon.  Do not use them in new 
+installations
+</para>
+		
+<itemizedlist>
+	<listitem><para><parameter>printer driver file (G)</parameter>
+	</para></listitem>
+			
+	<listitem><para><parameter>printer driver (S)</parameter>
+	</para></listitem>
+			
+	<listitem><para><parameter>printer driver location (S)</parameter>
+	</para></listitem>
+</itemizedlist>
+</warning>
+
+
+<para>
+The have been two new parameters add in Samba 2.2.2 to for 
+better support of Samba 2.0.x backwards capability (<parameter>disable
+spoolss</parameter>) and for using local printers drivers on Windows 
+NT/2000 clients (<parameter>use client driver</parameter>). Both of 
+these options are described in the smb.coinf(5) man page and are 
+disabled by default.
+</para>
+
+
 </sect1>
 
 
@@ -686,8 +665,8 @@ Here are the possible scenarios for supporting migration:
                  * NT4:
                  * 
                  * On NT4, you only have a global devicemode. This global devicemode can be changed
-                 * by the administrator (or by a user with enough privs). Everytime a user
-                 * wants to print, the devicemode is resetted to the default. In Word, everytime
+                 * by the administrator (or by a user with enough privs). Every time a user
+                 * wants to print, the devicemode is reset to the default. In Word, every time
                  * you print, the printer's characteristics are always reset to the global devicemode.
                  *
                  * NT 2000:
@@ -695,7 +674,7 @@ Here are the possible scenarios for supporting migration:
                  * In W2K, there is the notion of per-user devicemode. The first time you use
                  * a printer, a per-user devicemode is build from the global devicemode.
                  * If you change your per-user devicemode, it is saved in the registry, under the
-                 * H_KEY_CURRENT_KEY sub_tree. So that everytime you print, you have your default
+                 * H_KEY_CURRENT_KEY sub_tree. So that every time you print, you have your default
                  * printer preferences available.
                  *
                  * To change the per-user devicemode: it's the "Printing Preferences ..." button
diff --git a/docs/docbook/projdoc/samba-doc.sgml b/docs/docbook/projdoc/samba-doc.sgml
index 7f3f09f1f3..f1211c0ac6 100644
--- a/docs/docbook/projdoc/samba-doc.sgml
+++ b/docs/docbook/projdoc/samba-doc.sgml
@@ -10,6 +10,8 @@
 <!ENTITY Samba-PDC-HOWTO SYSTEM "Samba-PDC-HOWTO.sgml">
 <!ENTITY CVS-Access SYSTEM "CVS-Access.sgml">
 <!ENTITY IntegratingWithWindows SYSTEM "Integrating-with-Windows.sgml">
+<!ENTITY Samba-PAM SYSTEM "PAM-Authentication-And-Samba.sgml">
+<!ENTITY INDEX-FILE SYSTEM "index.sgml">
 ]>
 
 <book id="Samba-Project-Documentation">
@@ -21,13 +23,16 @@
 		<surname>SAMBA Team</surname>
 	</author>
 	<address><email>samba@samba.org</email></address>
-	<pubdate>$rcsId</pubdate>
 </bookinfo>
 
 <dedication>
 <title>Abstract</title>
 
 <para>
+<emphasis>Last Update</emphasis> : Tue Jul 31 15:58:03 CDT 2001
+</para>
+
+<para>
 This book is a collection of HOWTOs added to Samba documentation over the years.
 I try to ensure that all are current, but sometimes the is a larger job
 than one person can maintain.  The most recent version of this document
@@ -42,16 +47,20 @@ Cheers, jerry
 
 </dedication>
 
+<!-- Chapters -->
 &UNIX-INSTALL;
 &IntegratingWithWindows;
-&ENCRYPTION;
+&Samba-PAM;
 &MS-Dfs-Setup;
+&NT-Security;
 &PRINTER-DRIVER2;
 &DOMAIN-MEMBER;
 &Samba-PDC-HOWTO;
 &WINBIND;
-&NT-Security;
 &OS2-Client;
 &CVS-Access;
 
+<!-- Autogenerated Index -->
+&INDEX-FILE;
+
 </book>
diff --git a/docs/docbook/projdoc/winbind.sgml b/docs/docbook/projdoc/winbind.sgml
index 8a380c206d..b496f30dd7 100644
--- a/docs/docbook/projdoc/winbind.sgml
+++ b/docs/docbook/projdoc/winbind.sgml
@@ -1,4 +1,4 @@
-<chapter>
+<chapter id="winbind">
 
 
 <chapterinfo>
@@ -21,16 +21,17 @@
 	<pubdate>16 Oct 2000</pubdate>
 </chapterinfo>
 
-<title>Unifed Logons between Windows NT and UNIX using Winbind</title>
+<title>Unified Logons between Windows NT and UNIX using Winbind</title>
 
 <sect1>
 	<title>Abstract</title>
 
 	<para>Integration of UNIX and Microsoft Windows NT through 
 	a unified logon has been considered a "holy grail" in heterogeneous 
-	computing environments for a long time. We present <emphasis>winbind
-	</emphasis>, a component of the Samba suite of programs as a 
-	solution to the unied logon problem. Winbind uses a UNIX implementation 
+	computing environments for a long time. We present 
+	<emphasis>winbind</emphasis>, a component of the Samba suite 
+	of programs as a solution to the unified logon problem. Winbind 
+	uses a UNIX implementation 
 	of Microsoft RPC calls, Pluggable Authentication Modules, and the Name 
 	Service Switch to allow Windows NT domain users to appear and operate 
 	as UNIX users on a UNIX machine. This paper describes the winbind 
@@ -53,11 +54,11 @@
 	and use the Samba suite of programs to provide file and print services 
 	between the two. This solution is far from perfect however, as 
 	adding and deleting users on both sets of machines becomes a chore 
-	and two sets of passwords are required both of which which
+	and two sets of passwords are required both of which
 	can lead to synchronization problems between the UNIX and Windows 
 	systems and confusion for users.</para>
 	
-	<para>We divide the unifed logon problem for UNIX machines into 
+	<para>We divide the unified logon problem for UNIX machines into 
 	three smaller problems:</para>
 	
 	<itemizedlist>
@@ -77,7 +78,7 @@
 	information on the UNIX machines and without creating additional 
 	tasks for the system administrator when maintaining users and 
 	groups on either system. The winbind system provides a simple 
-	and elegant solution to all three components of the unifed logon 
+	and elegant solution to all three components of the unified logon 
 	problem.</para>
 </sect1>
 
@@ -95,7 +96,7 @@
 	<para>The end result is that whenever any 
 	program on the UNIX machine asks the operating system to lookup 
 	a user or group name, the query will be resolved by asking the 
-	NT domain controller for the specied domain to do the lookup.
+	NT domain controller for the specified domain to do the lookup.
 	Because Winbind hooks into the operating system at a low level 
 	(via the NSS name resolution modules in the C library) this 
 	redirection to the NT domain controller is completely 
@@ -112,11 +113,11 @@
 	that redirection to a domain controller is wanted for a particular 
 	lookup and which trusted domain is being referenced.</para>
 	
-	<para>Additionally, Winbind provides a authentication service 
+	<para>Additionally, Winbind provides an authentication service 
 	that hooks into the Pluggable Authentication Modules (PAM) system 
 	to provide authentication via a NT domain to any PAM enabled 
 	applications. This capability solves the problem of synchronizing 
-	passwords between systems as all passwords are stored in a single 
+	passwords between systems since all passwords are stored in a single 
 	location (on the domain controller).</para>
 	
 	<sect2>
@@ -126,9 +127,9 @@
 		existing NT based domain infrastructure into which they wish 
 		to put UNIX workstations or servers. Winbind will allow these 
 		organizations to deploy UNIX workstations without having to 
-		maintain a separate account infrastructure. This greatly simplies 
-		the administrative overhead of deploying UNIX workstations into 
-		a NT based organization.</para>
+		maintain a separate account infrastructure. This greatly 
+		simplifies the administrative overhead of deploying UNIX 
+		workstations into a NT based organization.</para>
 		
 		<para>Another interesting way in which we expect Winbind to 
 		be used is as a central part of UNIX based appliances. Appliances 
@@ -179,11 +180,11 @@
 		<para>The Name Service Switch, or NSS, is a feature that is 
 		present in many UNIX operating systems. It allows system 
 		information such as hostnames, mail aliases and user information 
-		to be resolved from dierent sources. For example, a standalone 
+		to be resolved from different sources. For example, a standalone 
 		UNIX workstation may resolve system information from a series of 
-		flat files stored on the local lesystem. A networked workstation 
+		flat files stored on the local filesystem. A networked workstation 
 		may first attempt to resolve system information from local files, 
-		then consult a NIS database for user information or a DNS server 
+		and then consult a NIS database for user information or a DNS server 
 		for hostname information.</para>
 		
 		<para>The NSS application programming interface allows winbind 
@@ -196,13 +197,14 @@
 		a NT domain plus any trusted domain as though they were local 
 		users and groups.</para>
 		
-		<para>The primary control le for NSS is <filename>/etc/nsswitch.conf
-		</filename>. When a UNIX application makes a request to do a lookup 
+		<para>The primary control file for NSS is 
+		<filename>/etc/nsswitch.conf</filename>. 
+		When a UNIX application makes a request to do a lookup 
 		the C library looks in <filename>/etc/nsswitch.conf</filename> 
 		for a line which matches the service type being requested, for 
 		example the "passwd" service type is used when user or group names 
 		are looked up. This	config line species which implementations 
-		of that service should be tried andin what order. If the passwd 
+		of that service should be tried and in what order. If the passwd 
 		config line is:</para>
 
 		<para><command>passwd: files example</command></para>
@@ -229,7 +231,7 @@
 		<para>Pluggable Authentication Modules, also known as PAM, 
 		is a system for abstracting authentication and authorization 
 		technologies. With a PAM module it is possible to specify different 
-		authentication methods for dierent system applications without 
+		authentication methods for different system applications without 
 		having to recompile these applications. PAM is also useful
 		for implementing a particular policy for authorization. For example, 
 		a system administrator may only allow console logins from users 
@@ -241,10 +243,10 @@
 		UNIX system. This allows Windows NT users to log in to a UNIX 
 		machine and be authenticated against a suitable Primary Domain 
 		Controller. These users can also change their passwords and have 
-		this change take eect directly on the Primary Domain Controller.
+		this change take effect directly on the Primary Domain Controller.
 		</para>
 		
-		<para>PAM is congured by providing control files in the directory 
+		<para>PAM is configured by providing control files in the directory 
 		<filename>/etc/pam.d/</filename> for each of the services that 
 		require authentication. When an authentication request is made 
 		by an application the PAM code in the C library looks up this
@@ -252,7 +254,7 @@
 		authentication check and in what order. This interface makes adding 
 		a new authentication service for Winbind very easy, all that needs 
 		to be done is that the <filename>pam_winbind.so</filename> module 
-		is copied to <filename>/lib/security/</filename> and the pam 
+		is copied to <filename>/lib/security/</filename> and the PAM 
 		control files for relevant services are updated to allow 
 		authentication via winbind. See the PAM documentation
 		for more details.</para>
@@ -263,11 +265,11 @@
 		<title>User and Group ID Allocation</title>
 		
 		<para>When a user or group is created under Windows NT 
-		is it allocated a numerical relative identier (RID). This is 
-		slightly dierent to UNIX which has a range of numbers which are 
+		is it allocated a numerical relative identifier (RID). This is 
+		slightly different to UNIX which has a range of numbers that are 
 		used to identify users, and the same range in which to identify 
 		groups. It is winbind's job to convert RIDs to UNIX id numbers and
-		vice versa.  When winbind is congured it is given part of the UNIX 
+		vice versa.  When winbind is configured it is given part of the UNIX 
 		user id space and a part of the UNIX group id space in which to 
 		store Windows NT users and groups. If a Windows NT user is 
 		resolved for the first time, it is allocated the next UNIX id from 
@@ -276,7 +278,7 @@
 		to UNIX user ids and group ids.</para>
 
 		<para>The results of this mapping are stored persistently in 
-		a ID mapping database held in a tdb database). This ensures that 
+		an ID mapping database held in a tdb database). This ensures that 
 		RIDs are mapped to UNIX IDs in a consistent way.</para>
 	</sect2>
 	
@@ -290,7 +292,7 @@
 		by NT domain controllers.  User or group information returned 
 		by a PDC is cached by winbind along with a sequence number also 
 		returned by the PDC. This sequence number is incremented by 
-		Windows NT whenever any user or group information is modied. If 
+		Windows NT whenever any user or group information is modified. If 
 		a cached entry has expired, the sequence number is requested from 
 		the PDC and compared against the sequence number of the cached entry. 
 		If the sequence numbers do not match, then the cached information 
@@ -302,29 +304,553 @@
 
 <sect1>
 	<title>Installation and Configuration</title>
+	
+<para>
+Many thanks to John Trostel <ulink 
+url="mailto:jtrostel@snapserver.com">jtrostel@snapserver.com</ulink>
+for providing the HOWTO for this section.
+</para>
+
+<para>
+This HOWTO describes how to get winbind services up and running 
+to control access and authenticate users on your Linux box using 
+the winbind services which come with SAMBA 2.2.2.
+</para>
+
+
+<sect2>
+<title>Introduction</title>
+
+<para>
+This HOWTO describes the procedures used to get winbind up and 
+running on my RedHat 7.1 system.  Winbind is capable of providing access 
+and authentication control for Windows Domain users through an NT 
+or Win2K PDC for 'regular' services, such as telnet a nd ftp, as
+well for SAMBA services.
+</para>
+
+<para>
+This HOWTO has been written from a 'RedHat-centric' perspective, so if 
+you are using another distribution, you may have to modify the instructions 
+somewhat to fit the way your distribution works.
+</para>
+
+
+<itemizedlist>
+<listitem>
+	<para>
+	<emphasis>Why should I to this?</emphasis>
+	</para>
+	
+	<para>This allows the SAMBA administrator to rely on the 
+	authentication mechanisms on the NT/Win2K PDC for the authentication 
+	of domain members.  NT/Win2K users no longer need to have separate 
+	accounts on the SAMBA server.
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	<emphasis>Who should be reading this document?</emphasis>
+	</para>
+	
+	<para>
+	This HOWTO is designed for system administrators.  If you are 
+	implementing SAMBA on a file server and wish to (fairly easily) 
+	integrate existing NT/Win2K users from your PDC onto the
+	SAMBA server, this HOWTO is for you.  That said, I am no NT or PAM 
+	expert, so you may find a better or easier way to accomplish 
+	these tasks.
+	</para>
+</listitem>
+</itemizedlist>
+</sect2>
+
+
+<sect2>
+<title>Requirements</title>
+
+<para>
+If you have a samba configuration file that you are currently 
+using... BACK IT UP!  If your system already uses PAM, BACK UP 
+THE <filename>/etc/pam.d</filename> directory contents! If you 
+haven't already made a boot disk, MAKE ON NOW!
+</para>
+
+<para>
+Messing with the pam configuration files can make it nearly impossible 
+to log in to yourmachine. That's why you want to be able to boot back 
+into your machine in single user mode and restore your 
+<filename>/etc/pam.d</filename> back to the original state they were in if 
+you get frustrated with the way things are going.  ;-)
+</para>
+
+<para>
+The newest version of SAMBA (version 2.2.2), available from 
+cvs.samba.org, now include a functioning winbindd daemon.  Please refer 
+to the main SAMBA web page or, better yet, your closest SAMBA mirror 
+site for instructions on downloading the source code.
+</para>
+
+<para>
+To allow Domain users the ability to access SAMBA shares and 
+files, as well as potentially other services provided by your 
+SAMBA machine, PAM (pluggable authentication modules) must
+be setup properly on your machine.  In order to compile the 
+winbind modules, you should have at least the pam libraries resident 
+on your system.  For recent RedHat systems (7.1, for instance), that 
+means 'pam-0.74-22'.  For best results, it is helpful to also
+install the development packages in 'pam-devel-0.74-22'.
+</para>
+
+</sect2>
+
+
+<sect2>
+<title>Testing Things Out</title>
+
+<para>
+Before starting, it is probably best to kill off all the SAMBA 
+related daemons running on your server.  Kill off all <command>smbd</command>, 
+<command>nmbd</command>, and <command>winbindd</command> processes that may 
+be running.  To use PAM, you will want to make sure that you have the 
+standard PAM package (for RedHat) which supplies the <filename>/etc/pam.d</filename> 
+directory structure, including the pam modules are used by pam-aware 
+services, several pam libraries, and the <filename>/usr/doc</filename> 
+and <filename>/usr/man</filename> entries for pam.  Winbind built better 
+in SAMBA if the pam-devel package was also installed.  This package includes 
+the header files needed to compile pam-aware applications. For instance, my RedHat 
+system has both 'pam-0.74-22' and 'pam-devel-0.74-22' RPMs installed.
+</para>
+
+<sect3>
+<title>Configure and compile SAMBA</title>
+
+<para>
+The configuration and compilation of SAMBA is pretty straightforward.
+The first three steps maynot be necessary depending upon
+whether or not you have previously built the Samba binaries.
+</para>
+
+<para><programlisting>
+<prompt>root# </prompt> autoconf
+<prompt>root# </prompt> make clean
+<prompt>root# </prompt> rm config.cache
+<prompt>root# </prompt> ./configure --with-winbind
+<prompt>root# </prompt> make
+<prompt>root# </prompt> make install
+</programlisting></para>
+
+
+<para>
+This will, by default, install SAMBA in /usr/local/samba.  See the 
+main SAMBA documentation if you want to install SAMBA somewhere else.  
+It will also build the winbindd executable and libraries. 
+</para>
+
+</sect3>
+
+<sect3>
+<title>Configure nsswitch.conf and the winbind libraries</title>
+
+<para>
+The libraries needed to run the winbind daemon through nsswitch 
+need to be copied to their proper locations, so
+</para>
+
+<para>
+<prompt>root# </prompt> cp ../samba/source/nsswitch/libnss_winbind.so /lib
+</para>
+
+<para>
+I also found it necessary to make the following symbolic link:
+</para>
+
+<para>
+<prompt>root# </prompt> ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2
+</para>
+
+<para>
+Now, as root you need to edit <filename>/etc/nsswitch.conf</filename> to 
+allow user and group entries to be visible from the <command>winbindd</command> 
+daemon, as well as from your /etc/hosts files and NIS servers.  My 
+<filename>/etc/nsswitch.conf</filename> file look like this after editing:
+</para>
+
+<para><programlisting>
+	passwd:     files winbind
+	shadow:     files winbind
+	group:      files winbind
+</programlisting></para>
+
+<para>	
+The libraries needed by the winbind daemon will be automatically 
+entered into the ldconfig cache the next time your system reboots, but it 
+is faster (and you don't need to reboot) if you do it manually:
+</para>
+
+<para>
+<prompt>root# </prompt> /sbin/ldconfig -v | grep winbind
+</para>
+
+<para>
+This makes <filename>libnss_winbind</filename> available to winbindd 
+and echos back a check to you.
+</para>
+
+</sect3>
+
+
+<sect3>
+<title>Configure smb.conf</title>
+
+<para>
+Several parameters are needed in the smb.conf file to control 
+the behavior of <command>winbindd</command>. Configure 
+<filename>smb.conf</filename> These are described in more detail in 
+the <ulink url="winbindd.8.html">winbindd(8)</ulink> man page.  My 
+<filename>smb.conf</filename> file was modified to
+include the following entries in the [global] section:
+</para>
+
+<para><programlisting>
+[global]
+     <...>
+     # separate domain and username with '+', like DOMAIN+username
+     winbind separator = +
+     # use uids from 10000 to 20000 for domain users
+     winbind uid = 10000-20000
+     # use gids from 10000 to 20000 for domain groups
+     winbind gid = 10000-20000
+     # allow enumeration of winbind users and groups
+     winbind enum users = yes
+     winbind enum groups = yes
+     # give winbind users a real shell (only needed if they have telnet access)
+     template shell = /bin/bash
+</programlisting></para>
+
+</sect3>
+
+
+<sect3>
+<title>Join the SAMBA server to the PDC domain</title>
+
+<para>
+Enter the following command to make the SAMBA server join the 
+PDC domain, where <replaceable>DOMAIN</replaceable> is the name of 
+your Windows domain and <replaceable>Administrator</replaceable> is 
+a domain user who has administrative privileges in the domain.
+</para>
+	
+
+<para>
+<prompt>root# </prompt>/usr/local/samba/bin/smbpasswd -j DOMAIN -r PDC -U Administrator
+</para>
+
+
+<para>
+The proper response to the command should be: "Joined the domain 
+<replaceable>DOMAIN</replaceable>" where <replaceable>DOMAIN</replaceable> 
+is your DOMAIN name.
+</para>
+
+</sect3>
 
-	<para>The easiest way to install winbind is by using the packages 
-	provided in the <filename>pub/samba/appliance/</filename> 
-	directory on your nearest 
-	Samba mirror. These packages provide snapshots of the Samba source 
-	code and binaries already setup to provide the full functionality 
-	of winbind. This setup is a little more complex than a normal Samba 
-	build as winbind needs a small amount of functionality from a 
-	development code branch called SAMBA_TNG.</para>
+
+<sect3>
+<title>Start up the winbindd daemon and test it!</title>
+
+<para>
+Eventually, you will want to modify your smb startup script to 
+automatically invoke the winbindd daemon when the other parts of 
+SAMBA start, but it is possible to test out just the winbind
+portion first.  To start up winbind services, enter the following 
+command as root:
+</para>
+	
+<para>
+<prompt>root# </prompt>/usr/local/samba/bin/winbindd
+</para>
+
+<para>
+I'm always paranoid and like to make sure the daemon 
+is really running...
+</para>
+
+<para>
+<prompt>root# </prompt> ps -ae | grep winbindd 
+3025 ?        00:00:00 winbindd
+</para>
+
+<para>
+Now... for the real test, try to get some information about the 
+users on your PDC
+</para>
+
+<para>
+<prompt>root# </prompt> # /usr/local/samba/bin/wbinfo -u
+</para>
+
+<para>	
+This should echo back a list of users on your Windows users on 
+your PDC.  For example, I get the following response:
+</para>
+
+<para><programlisting>
+CEO+Administrator
+CEO+burdell
+CEO+Guest
+CEO+jt-ad
+CEO+krbtgt
+CEO+TsInternetUser
+</programlisting></para>
+
+<para>
+Obviously, I have named my domain 'CEO' and my winbindd separator is '+'.
+</para>
+
+<para>
+You can do the same sort of thing to get group information from 
+the PDC:
+</para>
+
+<para><programlisting>
+<prompt>root# </prompt>/usr/local/samba/bin/wbinfo -g
+CEO+Domain Admins
+CEO+Domain Users
+CEO+Domain Guests
+CEO+Domain Computers
+CEO+Domain Controllers
+CEO+Cert Publishers
+CEO+Schema Admins
+CEO+Enterprise Admins
+CEO+Group Policy Creator Owners
+</programlisting></para>
+
+<para>
+The function 'getent' can now be used to get unified 
+lists of both local and PDC users and groups.
+Try the following command:
+</para>
+
+<para>
+<prompt>root# </prompt> getent passwd
+</para>
 	
-	<para>Once you have installed the packages you should read 
-	the <command>winbindd(8)</command> man page which will provide you 
-	with conguration information and give you sample conguration files. 
-	You may also wish to update the main Samba daemons smbd and nmbd) 
-	with a more recent development release, such as the recently
-	announced Samba 2.2 alpha release.</para>
+<para>
+You should get a list that looks like your <filename>/etc/passwd</filename> 
+list followed by the domain users with their new uids, gids, home 
+directories and default shells.
+</para>
+
+<para>
+The same thing can be done for groups with the command
+</para>
+
+<para>
+<prompt>root# </prompt> getent group
+</para>
+
+</sect3>
+
+
+<sect3>
+<title>Fix the /etc/rc.d/init.d/smb startup files</title>
+
+<para>
+The <command>winbindd</command> daemon needs to start up after the 
+<command>smbd</command> and <command>nmbd</command> daemons are running.  
+To accomplish this task, you need to modify the <filename>/etc/init.d/smb</filename>
+script to add commands to invoke this daemon in the proper sequence.  My 
+<filename>/etc/init.d/smb</filename> file starts up <command>smbd</command>, 
+<command>nmbd</command>, and <command>winbindd</command> from the 
+<filename>/usr/local/samba/bin</filename> directory directly.  The 'start' 
+function in the script looks like this:
+</para>
+
+<para><programlisting>
+start() {
+        KIND="SMB"
+        echo -n $"Starting $KIND services: "
+        daemon /usr/local/samba/bin/smbd $SMBDOPTIONS
+        RETVAL=$?
+        echo
+        KIND="NMB"
+        echo -n $"Starting $KIND services: "
+        daemon /usr/local/samba/bin/nmbd $NMBDOPTIONS
+        RETVAL2=$?
+        echo
+        KIND="Winbind"
+        echo -n $"Starting $KIND services: "
+        daemon /usr/local/samba/bin/winbindd
+        RETVAL3=$?
+        echo
+        [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && touch /var/lock/subsys/smb || \
+           RETVAL=1
+        return $RETVAL
+}
+</programlisting></para>
+
+<para>
+The 'stop' function has a corresponding entry to shut down the 
+services and look s like this:
+</para>
+
+<para><programlisting>
+stop() {
+        KIND="SMB"
+        echo -n $"Shutting down $KIND services: "
+        killproc smbd
+        RETVAL=$?
+        echo
+        KIND="NMB"
+        echo -n $"Shutting down $KIND services: "
+        killproc nmbd
+        RETVAL2=$?
+        echo
+        KIND="Winbind"
+        echo -n $"Shutting down $KIND services: "
+        killproc winbindd
+        RETVAL3=$?
+        [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && rm -f /var/lock/subsys/smb
+        echo ""
+        return $RETVAL
+}
+</programlisting></para>
+
+</sect3>
+
+
+
+<sect3>
+<title>Configure Winbind and PAM</title>
+
+<para>
+If you have made it this far, you know that winbindd is working.  
+Now it is time to integrate it into the operation of samba and other 
+services.  The pam configuration files need to be altered in
+this step.  (Did you remember to make backups of your original 
+<filename>/etc/pam.d</filename> files? If not, do it now.)
+</para>
+
+<para>
+To get samba to allow domain users and groups, I modified the 
+<filename>/etc/pam.d/samba</filename> file from
+</para>
+
+
+<para><programlisting>
+auth    required        /lib/security/pam_stack.so service=system-auth
+account required        /lib/security/pam_stack.so service=system-auth
+</programlisting></para>
+
+<para>
+to
+</para>
+
+<para><programlisting>
+auth    required        /lib/security/pam_winbind.so
+auth    required        /lib/security/pam_stack.so service=system-auth
+account required        /lib/security/pam_winbind.so
+account required        /lib/security/pam_stack.so service=system-auth
+</programlisting></para>
+
+<para>
+The other services that I modified to allow the use of winbind 
+as an authentication service were the normal login on the console (or a terminal 
+session), telnet logins, and ftp service.  In order to enable these 
+services, you may first need to change the entries in 
+<filename>/etc/xinetd.d</filename> (or <filename>/etc/inetd.conf</filename>).  
+RedHat 7.1 uses the new xinetd.d structure, in this case you need 
+to change the lines in <filename>/etc/xinetd.d/telnet</filename> 
+and <filename>/etc/xinetd.d/wu-ftp</filename> from 
+</para>
+
+<para><programlisting>
+enable = no
+</programlisting></para>
+
+<para>
+to
+</para>
+
+<para><programlisting>
+enable = yes
+</programlisting></para>
+
+<para>	
+For ftp services to work properly, you will also need to either 
+have individual directories for the domain users already present on 
+the server, or change the home directory template to a general
+directory for all domain users.  These can be easily set using 
+the <filename>smb.conf</filename> global entry 
+<command>template homedir</command>.
+</para>
+
+<para>
+The <filename>/etc/pam.d/ftp</filename> file can be changed 
+to allow winbind ftp access in a manner similar to the
+samba file.  My <filename>/etc/pam.d/ftp</filename> file was 
+changed to look like this:
+</para>
+
+<para><programlisting>
+auth       sufficient   /lib/security/pam_winbind.so
+auth       required     /lib/security/pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
+auth       required     /lib/security/pam_stack.so service=system-auth
+auth       required     /lib/security/pam_shells.so
+account    required     /lib/security/pam_stack.so service=system-auth
+session    required     /lib/security/pam_stack.so service=system-auth
+</programlisting></para>
+
+<para>
+The <filename>/etc/pam.d/login</filename> file can be changed nearly the 
+same way.  It now looks like this:
+</para>
+
+<para><programlisting>
+auth       required     /lib/security/pam_securetty.so
+auth       sufficient   /lib/security/pam_winbind.so
+auth       sufficient   /lib/security/pam_unix.so use_first_pass
+auth       required     /lib/security/pam_stack.so service=system-auth
+auth       required     /lib/security/pam_nologin.so
+account    sufficient   /lib/security/pam_winbind.so
+account    required     /lib/security/pam_stack.so service=system-auth
+password   required     /lib/security/pam_stack.so service=system-auth
+session    required     /lib/security/pam_stack.so service=system-auth
+session    optional     /lib/security/pam_console.so
+</programlisting></para>
+
+<para>
+In this case, I added the <command>auth sufficient /lib/security/pam_winbind.so</command> 
+lines as before, but also added the <command>required pam_securetty.so</command> 
+above it, to disallow root logins over the network.  I also added a 
+<command>sufficient /lib/security/pam_unix.so use_first_pass</command>
+line after the <command>winbind.so</command> line to get rid of annoying 
+double prompts for passwords.
+</para>
+
+<para>
+Finally, don't forget to copy the winbind pam modules from 
+the source directory in which you originally compiled the new 
+SAMBA up to the /lib/security directory so that pam can use it:
+</para>
+
+<para>
+<prompt>root# </prompt> cp ../samba/source/nsswitch/pam_winbind.so /lib/security
+</para>
+
+</sect3>
+
+</sect2>
+
 </sect1>
 
 <sect1>
 	<title>Limitations</title>
 	
 	<para>Winbind has a number of limitations in its current 
-	released version which we hope to overcome in future 
+	released version that we hope to overcome in future 
 	releases:</para>
 
 	<itemizedlist>
@@ -346,12 +872,6 @@
 		<listitem><para>Currently the winbind PAM module does not take 
 		into account possible workstation and logon time restrictions 
 		that may be been set for Windows NT users.</para></listitem>
-		
-		<listitem><para>Building winbind from source is currently 
-		quite tedious as it requires combining source code from two Samba 
-		branches. Work is underway to solve this by providing all 
-		the necessary functionality in the main Samba code branch.</para>
-		</listitem>
 	</itemizedlist>
 </sect1>
 
@@ -369,4 +889,3 @@
 </sect1>
 
 </chapter>
-