Updating 3.0.0 from HEAD branch.

(This used to be commit 25ab036160ca922eec7797b0b30c621bdd7d8bcd)

19 files changed, 1084 insertions, 1457 deletions

diff --git a/docs/docbook/projdoc/ADS-HOWTO.sgml b/docs/docbook/projdoc/ADS-HOWTO.sgml
index 887ecd74c2..a98fe14e31 100644
--- a/docs/docbook/projdoc/ADS-HOWTO.sgml
+++ b/docs/docbook/projdoc/ADS-HOWTO.sgml
@@ -14,67 +14,10 @@ This is a rough guide to setting up Samba 3.0 with kerberos authentication again
 Windows2000 KDC. 
 </para>
 
-<para>Pieces you need before you begin:</para>
-<para>
-<simplelist>
-<member>a Windows 2000 server.</member>
-<member>samba 3.0 or higher.</member>
-<member>the MIT kerberos development libraries (either install from the above sources or use a package). The heimdal libraries will not work.</member>
-<member>the OpenLDAP development libraries.</member>
-</simplelist>
-</para>
-
-<sect1>
-<title>Installing the required packages for Debian</title>
-
-<para>On Debian you need to install the following packages:</para>
-<para>
-<simplelist>
-<member>libkrb5-dev</member>
-<member>krb5-user</member>
-</simplelist>
-</para>
-</sect1>
-
-<sect1>
-<title>Installing the required packages for RedHat</title>
-
-<para>On RedHat this means you should have at least: </para>
-<para>
-<simplelist>
-<member>krb5-workstation (for kinit)</member>
-<member>krb5-libs (for linking with)</member>
-<member>krb5-devel (because you are compiling from source)</member>
-</simplelist>
-</para>
-
-<para>in addition to the standard development environment.</para>
-
-<para>Note that these are not standard on a RedHat install, and you may need 
-to get them off CD2.</para>
-
-</sect1>
-
 <sect1>
-<title>Compile Samba</title>
-<para>If your kerberos libraries are in a non-standard location then
-  remember to add the configure option --with-krb5=DIR.</para>
+<title>Setup your <filename>smb.conf</filename></title>
 
-<para>After you run configure make sure that include/config.h it
-  generates contains 
-  lines like this:</para>
-
-<para><programlisting>
-#define HAVE_KRB5 1
-#define HAVE_LDAP 1
-</programlisting></para>
-
-<para>If it doesn't then configure did not find your krb5 libraries or
-  your ldap libraries. Look in config.log to figure out why and fix
-  it.</para>
-
-<para>Then compile and install Samba as usual. You must use at least the
-  following 3 options in smb.conf:</para>
+<para>You must use at least the following 3 options in smb.conf:</para>
 
 <para><programlisting>
   realm = YOUR.KERBEROS.REALM
@@ -93,13 +36,13 @@ In case samba can't figure out your ads server using your realm name, use the
 <para>You do *not* need a smbpasswd file, and older clients will
   be authenticated as if "security = domain", although it won't do any harm
   and allows you to have local users not in the domain.
-  I expect that the above
-  required options will change soon when we get better active
-  directory integration.</para>
-</sect1>
+  I expect that the above required options will change soon when we get better
+  active directory integration.</para>
 
+</sect1>
+  
 <sect1>
-<title>Setup your /etc/krb5.conf</title>
+<title>Setup your <filename>/etc/krb5.conf</filename></title>
 
 <para>The minimal configuration for krb5.conf is:</para>
 
@@ -187,12 +130,11 @@ specify the -k option to choose kerberos authentication.
 <sect1>
 <title>Notes</title>
 
-<para>You must change administrator password at least once after DC install,
- to create the right encoding types</para>
+<para>You must change administrator password at least once after DC 
+install, to create the right encoding types</para>
 
 <para>w2k doesn't seem to create the _kerberos._udp and _ldap._tcp in
    their defaults DNS setup. Maybe fixed in service packs?</para>
-
 </sect1>
 
 </chapter>
diff --git a/docs/docbook/projdoc/Browsing-Quickguide.sgml b/docs/docbook/projdoc/Browsing-Quickguide.sgml
index 0a5cf72038..adf20b7386 100644
--- a/docs/docbook/projdoc/Browsing-Quickguide.sgml
+++ b/docs/docbook/projdoc/Browsing-Quickguide.sgml
@@ -85,6 +85,81 @@ minutes to stabilise, particularly across network segments.
 </sect1>
 
 <sect1>
+<title>How browsing functions and how to deploy stable and 
+dependable browsing using Samba</title>
+
+
+<para>
+As stated above, MS Windows machines register their NetBIOS names 
+(i.e.: the machine name for each service type in operation) on start 
+up. Also, as stated above, the exact method by which this name registration 
+takes place is determined by whether or not the MS Windows client/server 
+has been given a WINS server address, whether or not LMHOSTS lookup 
+is enabled, or if DNS for NetBIOS name resolution is enabled, etc.
+</para>
+
+<para>
+In the case where there is no WINS server all name registrations as 
+well as name lookups are done by UDP broadcast. This isolates name 
+resolution to the local subnet, unless LMHOSTS is used to list all 
+names and IP addresses. In such situations Samba provides a means by 
+which the samba server name may be forcibly injected into the browse 
+list of a remote MS Windows network (using the "remote announce" parameter).
+</para>
+
+<para>
+Where a WINS server is used, the MS Windows client will use UDP 
+unicast to register with the WINS server. Such packets can be routed 
+and thus WINS allows name resolution to function across routed networks.
+</para>
+
+<para>
+During the startup process an election will take place to create a 
+local master browser if one does not already exist. On each NetBIOS network 
+one machine will be elected to function as the domain master browser. This 
+domain browsing has nothing to do with MS security domain control. 
+Instead, the domain master browser serves the role of contacting each local 
+master browser (found by asking WINS or from LMHOSTS) and exchanging browse 
+list contents. This way every master browser will eventually obtain a complete 
+list of all machines that are on the network. Every 11-15 minutes an election 
+is held to determine which machine will be the master browser. By the nature of 
+the election criteria used, the machine with the highest uptime, or the 
+most senior protocol version, or other criteria, will win the election 
+as domain master browser.
+</para>
+
+<para>
+Clients wishing to browse the network make use of this list, but also depend 
+on the availability of correct name resolution to the respective IP 
+address/addresses. 
+</para>
+
+<para>
+Any configuration that breaks name resolution and/or browsing intrinsics 
+will annoy users because they will have to put up with protracted 
+inability to use the network services.
+</para>
+
+<para>
+Samba supports a feature that allows forced synchonisation 
+of browse lists across routed networks using the "remote 
+browse sync" parameter in the smb.conf file. This causes Samba 
+to contact the local master browser on a remote network and 
+to request browse list synchronisation. This effectively bridges 
+two networks that are separated by routers. The two remote 
+networks may use either broadcast based name resolution or WINS 
+based name resolution, but it should be noted that the "remote 
+browse sync" parameter provides browse list synchronisation - and 
+that is distinct from name to address resolution, in other 
+words, for cross subnet browsing to function correctly it is 
+essential that a name to address resolution mechanism be provided. 
+This mechanism could be via DNS, <filename>/etc/hosts</filename>, 
+and so on.
+</para>
+
+</sect1>
+
+<sect1>
 <title>Use of the "Remote Announce" parameter</title>
 <para>
 The "remote announce" parameter of smb.conf can be used to forcibly ensure
diff --git a/docs/docbook/projdoc/Browsing.sgml b/docs/docbook/projdoc/Browsing.sgml
index aeb3b477c5..60512c3cd1 100644
--- a/docs/docbook/projdoc/Browsing.sgml
+++ b/docs/docbook/projdoc/Browsing.sgml
@@ -534,10 +534,10 @@ options in the [global] section of the smb.conf file :
 
 <para>
 <programlisting>
-        domain master = yes
-        local master = yes
-        preferred master = yes
-        os level = 65
+domain master = yes
+local master = yes
+preferred master = yes
+os level = 65
 </programlisting>
 </para>
 
@@ -559,10 +559,10 @@ smb.conf file :
 
 <para>
 <programlisting>
-        domain master = no
-        local master = yes
-        preferred master = yes
-        os level = 65
+domain master = no
+local master = yes
+preferred master = yes
+os level = 65
 </programlisting>
 </para>
 
@@ -588,10 +588,10 @@ options in the [global] section of the smb.conf file :
 
 <para>
 <programlisting>
-        domain master = no
-        local master = no
-        preferred master = no
-        os level = 0
+domain master = no
+local master = no
+preferred master = no
+os level = 0
 </programlisting>
 </para>
 
@@ -619,10 +619,10 @@ file :
 
 <para>
 <programlisting>
-        domain master = no
-        local master = yes
-        preferred master = yes
-        os level = 65
+domain master = no
+local master = yes
+preferred master = yes
+os level = 65
 </programlisting>
 </para>
 
diff --git a/docs/docbook/projdoc/CUPS-printing.sgml b/docs/docbook/projdoc/CUPS-printing.sgml
index a932127d94..65f18dc385 100644
--- a/docs/docbook/projdoc/CUPS-printing.sgml
+++ b/docs/docbook/projdoc/CUPS-printing.sgml
@@ -49,10 +49,65 @@ In any case, let us now move on to explore how one may configure CUPS for interf
 with MS Windows print clients via Samba.
 </para>
 
+<para>
+<ulink url="http://www.cups.org/">CUPS</ulink> is a newcomer in the UNIX printing scene,
+which has convinced many people upon first trial already. However, it has quite a few
+new features, which make it different from other, more traditional printing systems.
+</para>
+
 </sect1>
 
 <sect1>
-<title>CUPS - RAW Print Through  Mode</title>
+<title>Configuring <filename>smb.conf</filename> for CUPS</title>
+
+<para>
+Printing with CUPS in the most basic <filename>smb.conf</filename>
+setup in Samba-3  only needs two settings: <command>printing = cups</command> and
+<command>printcap = cups</command>. While CUPS itself doesn't need a printcap
+anymore, the <filename>cupsd.conf</filename> configuration file knows two directives
+(example: <command>Printcap /etc/printcap</command> and <command>PrintcapFormat
+BSD</command>), which control if such a file should be created for the
+convenience of third party applications. Make sure it is set! For details see
+<command>man cupsd.conf</command> and other CUPS-related documentation.
+</para>
+
+<para>
+If SAMBA is compiled against libcups, then <command>printcap = cups</command> uses the
+CUPS API to list printers, submit jobs, etc. Otherwise it maps to the System V commands
+with an additional <parameter>-oraw</parameter> option for printing. On a Linux system,
+you can use the <command>ldd</command> command to find out details (ldd may not be
+present on other OS platforms, or its function may be embodied by a different command):
+</para>
+
+<para>
+<programlisting>transmeta:/home/kurt # ldd `which smbd`
+        libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4002d000)
+        libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4005a000)
+        libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000)
+        libdl.so.2 => /lib/libdl.so.2 (0x401e8000)
+        libnsl.so.1 => /lib/libnsl.so.1 (0x401ec000)
+        libpam.so.0 => /lib/libpam.so.0 (0x40202000)
+        libc.so.6 => /lib/libc.so.6 (0x4020b000)
+        /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x40000000)
+</programlisting></para>
+
+<para>
+The line "libcups.so.2 =&gt; /usr/lib/libcups.so.2
+(0x40123000)" shows there is CUPS support compiled into this version of
+Samba. If this is the case, and <command>printing = cups</command> is set, then any
+otherwise manually set print command in smb.conf is ignored.
+</para>
+</sect1>
+
+<sect1>
+<title>CUPS - RAW Print Through Mode</title>
+
+<note>
+<para>
+When used in raw print through mode is will be necessary to use the printer
+vendor's drivers in each Windows client PC.
+</para>
+</note>
 
 <para>
 When CUPS printers are configured for RAW print-through mode operation it is the
@@ -246,6 +301,380 @@ for the mailing, etc.).
 </sect1>
 
 <sect1>
+<title>CUPS as a network PostScript RIP -- CUPS drivers working on server, Adobe
+PostScript driver with CUPS-PPDs downloaded to clients</title>
+
+
+<para>
+CUPS is perfectly able to use PPD files (PostScript
+Printer Descriptions). PPDs can control all print device options. They
+are usually provided by the manufacturer -- if you own a PostSript printer,
+that is. PPD files are always a component of PostScript printer drivers on MS
+Windows or Apple Mac OS systems. They are ASCII files containing
+user-selectable print options, mapped to appropriate PostScript, PCL or PJL
+commands for the target printer. Printer driver GUI dialogs translate these
+options "on-the-fly" into buttons and drop-down lists for the user to
+select.
+</para>
+
+<para>
+CUPS can load, without any conversions, the PPD file from
+any Windows (NT is recommended) PostScript driver and handle the options.
+There is a web browser interface to the print options (select
+http://localhost:631/printers/ and click on one "Configure Printer" button
+to see it), a commandline interface (see <command>man lpoptions</command> or
+try if you have <command>lphelp</command> on your system) plus some different GUI frontends on Linux
+UNIX, which can present PPD options to the users. PPD options are normally
+meant to become evaluated by the PostScript RIP on the real PostScript
+printer.
+</para>
+
+<para>
+CUPS doesn't stop at "real" PostScript printers in its
+usage of PPDs. The CUPS developers have extended the PPD concept, to also
+describe available device and driver options for non-PostScript printers
+through  CUPS-PPDs.
+</para>
+
+<para>
+This is logical, as CUPS includes a fully featured
+PostScript interpreter (RIP). This RIP is based on Ghostscript. It can
+process all received PostScript (and additionally many other file formats)
+from clients. All CUPS-PPDs geared to non-PostScript printers contain an
+additional line, starting with the keyword <parameter>*cupsFilter</parameter>.
+This line
+tells the CUPS print system which printer-specific filter to use for the
+interpretation of the accompanying PostScript. Thus CUPS lets all its
+printers appear as PostScript devices to its clients, because it can act as a
+PostScript RIP for those printers, processing the received PostScript code
+into a proper raster print format.
+</para>
+
+<para>
+CUPS-PPDs can also be used on Windows-Clients, on top of a
+PostScript driver (recommended is the Adobe one).
+</para>
+
+<para>
+This feature enables CUPS to do a few tricks no other
+spooler can do:
+</para>
+
+<itemizedlist>
+  <listitem><para>act as a networked PostScript RIP (Raster Image Processor), handling
+    printfiles from all client platforms in a uniform way;</para></listitem>
+  <listitem><para>act as a central accounting and billing server, as all files are passed
+    through the <command>pstops</command> Filter and are therefor logged in
+    the CUPS <filename>page&lowbar;log</filename>. - <emphasis>NOTE: </emphasis>this
+    can not happen with "raw" print jobs, which always remain unfiltered
+    per definition;</para></listitem>
+  <listitem><para>enable clients to consolidate on a single PostScript driver, even for
+    many different target printers.</para></listitem>
+</itemizedlist>
+</sect1>
+
+<sect1>
+<title>Windows Terminal Servers (WTS) as CUPS clients</title>
+
+<para>
+This setup may be of special interest to people
+experiencing major problems in WTS environments. WTS need often a multitude
+of non-PostScript drivers installed to run their clients' variety of
+different printer models. This often imposes the price of much increased
+instability. In many cases, in an attempt to overcome this problem, site
+administrators have resorted to restrict the allowed drivers installed on
+their WTS to one generic PCL- and one PostScript driver. This however
+restricts the clients in the amount of printer options available for them --
+often they can't get out more then simplex prints from one standard paper
+tray, while their devices could do much better, if driven by a different
+driver!
+</para>
+
+<para>
+Using an Adobe PostScript driver, enabled with a CUPS-PPD,
+seems to be a very elegant way to overcome all these shortcomings. The
+PostScript driver is not known to cause major stability problems on WTS (even
+if used with many different PPDs). The clients will be able to (again) chose
+paper trays, duplex printing and other settings. However, there is a certain
+price for this too: a  CUPS server acting as a PostScript RIP for its clients
+requires more CPU and RAM than just to act as  a "raw spooling" device. Plus,
+this setup is not yet widely tested, although the first feedbacks look very
+promising...
+</para>
+</sect1>
+
+
+<sect1>
+<title>Setting up CUPS for driver download</title>
+
+<para>
+The <command>cupsadsmb</command> utility (shipped with all current
+CUPS versions) makes the sharing of any (or all) installed CUPS printers very
+easy. Prior to using it, you need the following settings in smb.conf:
+</para>
+
+	<para><programlisting>[global]
+		 load printers = yes
+		 printing = cups
+		 printcap name = cups
+
+	[printers]
+		 comment = All Printers
+		 path = /var/spool/samba
+		 browseable = no
+		 public = yes
+		 guest ok = yes
+		 writable = no
+		 printable = yes
+		 printer admin = root
+
+	[print$]
+		 comment = Printer Drivers
+		 path = /etc/samba/drivers
+		 browseable = yes
+		 guest ok = no
+		 read only = yes
+		 write list = root
+	</programlisting></para>
+
+<para>
+For licensing reasons the necessary files of the Adobe
+Postscript driver can not be distributed with either Samba or CUPS. You need
+to download them yourself from the Adobe website. Once extracted, create a
+<filename>drivers</filename> directory in the CUPS data directory (usually
+<filename>/usr/share/cups/</filename>). Copy the Adobe files using
+UPPERCASE filenames, to this directory as follows:
+</para>
+
+	<para><programlisting>
+		ADFONTS.MFM
+		ADOBEPS4.DRV
+		ADOBEPS4.HLP
+		ADOBEPS5.DLL
+		ADOBEPSU.DLL
+		ADOBEPSU.HLP
+		DEFPRTR2.PPD
+		ICONLIB.DLL
+	</programlisting></para>
+
+<para>
+Users of the ESP Print Pro software are able to install
+their "Samba Drivers" package for this purpose with no problem.
+</para>
+</sect1>
+
+
+
+<sect1>
+<title>Sources of CUPS drivers / PPDs</title>
+
+<para>
+On the internet you can find now many thousand CUPS-PPD
+files (with their companion filters), in many national languages,
+supporting more than 1.000 non-PostScript models.
+</para>
+
+<itemizedlist>
+  <listitem><para><ulink url="http://wwwl.easysw.com/printpro/">ESP PrintPro
+    (http://wwwl.easysw.com/printpro/)</ulink>
+    (commercial, non-Free) is packaged with more than 3.000 PPDs, ready for
+    successful usage "out of the box" on Linux, IBM-AIX, HP-UX, Sun-Solaris,
+    SGI-IRIX, Compaq Tru64, Digital Unix and some more commercial Unices (it
+    is written by the CUPS developers themselves and its sales help finance
+    the further development of CUPS, as they feed their creators)</para></listitem>
+  <listitem><para>the <ulink
+    url="http://gimp-print.sourceforge.net/">Gimp-Print-Project
+    (http://gimp-print.sourceforge.net/)</ulink>
+    (GPL, Free Software) provides around 120 PPDs (supporting nearly 300
+    printers, many driven to photo quality output), to be used alongside the
+    Gimp-Print CUPS filters;</para></listitem>
+  <listitem><para><ulink url="http://www.turboprint.com/">TurboPrint
+    (http://www.turboprint.com/)</ulink>
+    (Shareware, non-Freee) supports roughly the same amount of printers in
+    excellent quality;</para></listitem>
+  <listitem><para><ulink
+    url="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/">OMNI
+    (http://www-124.ibm.com/developerworks/oss/linux/projects/omni/)</ulink>
+    (LPGL, Free) is a package made by IBM, now containing support for more
+    than 400 printers, stemming from the inheritance of IBM OS/2 KnowHow
+    ported over to Linux (CUPS support is in a Beta-stage at present);</para></listitem>
+  <listitem><para><ulink url="http://hpinkjet.sourceforge.net/">HPIJS
+    (http://hpinkjet.sourceforge.net/)</ulink>
+    (BSD-style licnes, Free) supports around 120 of HP's own printers and is
+    also providing excellent print quality now;</para></listitem>
+  <listitem><para><ulink
+    url="http://www.linuxprinting.org/">Foomatic/cupsomatic (http://www.linuxprinting.org/)</ulink>
+    (LPGL, Free) from Linuxprinting.org are providing PPDs for practically every
+    Ghostscript filter known to the world, now usable with CUPS.</para></listitem>
+</itemizedlist>
+
+<para>
+<emphasis>NOTE: </emphasis>the cupsomatic trick from Linuxprinting.org is
+working different from the other drivers. While the other drivers take the
+generic CUPS raster (produced by CUPS' own pstoraster PostScript RIP) as
+their input, cupsomatic "kidnaps" the PostScript inside CUPS, before
+RIP-ping, deviates it to an external Ghostscript installation (which now
+becomes the RIP) and gives it back to a CUPS backend once Ghostscript is
+finished. -- CUPS versions from 1.1.15 and later will provide their pstoraster
+PostScript RIP function again inside a system-wide Ghostscript
+installation rather than in "their own" pstoraster filter. (This
+CUPS-enabling Ghostscript version may be installed either as a
+patch to GNU or AFPL Ghostscript, or as a complete ESP Ghostscript package).
+However, this will not change the cupsomatic approach of guiding the printjob
+along a different path through the filtering system than the standard CUPS
+way...
+</para>
+
+<para>
+Once you installed a printer inside CUPS with one of the
+recommended methods (the lpadmin command, the web browser interface or one of
+the available GUI wizards), you can use <command>cupsaddsmb</command> to share the
+printer via Samba. <command>cupsaddsmb</command> prepares the driver files for
+comfortable client download and installation upon their first contact with
+this printer share.
+</para>
+
+
+
+<sect2>
+<title><command>cupsaddsmb</command></title>
+
+
+<para>
+The <command>cupsaddsmb</command> command copies the needed files
+for convenient Windows client installations from the previously prepared CUPS
+data directory to your [print$] share. Additionally, the PPD
+associated with this printer is copied from <filename>/etc/cups/ppd/</filename> to
+[print$].
+</para>
+
+<para><programlisting>
+<prompt>root# </prompt> <command>cupsaddsmb -U root infotec_IS2027</command>
+Password for root required to access localhost via SAMBA: <userinput>[type in password 'secret']</userinput>
+</programlisting></para>
+
+<para>
+To share all printers and drivers, use the <parameter>-a</parameter>
+parameter instead of a printer name.
+</para>
+
+
+<para>
+Probably you want to see what's going on. Use the
+<parameter>-v</parameter> parameter to get a more verbose output:
+</para>
+
+<para>
+Probably you want to see what's going on. Use the
+<parameter>-v</parameter> parameter to get a more verbose output:
+</para>
+
+<para><programlisting>
+Note: The following line shave been wrapped so that information is not lost.
+ 
+<prompt>root# </prompt> cupsaddsmb -v -U root infotec_IS2027
+    Password for root required to access localhost via SAMBA:
+    Running command: smbclient //localhost/print\$ -N -U'root%secret' -c 'mkdir W32X86;put
+       /var/spool/cups/tmp/3cd1cc66376c0 W32X86/infotec_IS2027.PPD;put /usr/share/cups/drivers/
+       ADOBEPS5.DLL W32X86/ADOBEPS5.DLL;put /usr/share/cups/drivers/ADOBEPSU.DLLr
+       W32X86/ADOBEPSU.DLL;put /usr/share/cups/drivers/ADOBEPSU.HLP W32X86/ADOBEPSU.HLP'
+    added interface ip=10.160.16.45 bcast=10.160.31.255 nmask=255.255.240.0
+    added interface ip=192.168.182.1 bcast=192.168.182.255 nmask=255.255.255.0
+    added interface ip=172.16.200.1 bcast=172.16.200.255 nmask=255.255.255.0
+    Domain=[TUX-NET] OS=[Unix] Server=[Samba 2.2.3a.200204262025cvs]
+    NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86
+    putting file /var/spool/cups/tmp/3cd1cc66376c0 as \W32X86/infotec_IS2027.PPD (17394.6 kb/s)
+      (average 17395.2 kb/s)
+    putting file /usr/share/cups/drivers/ADOBEPS5.DLL as \W32X86/ADOBEPS5.DLL (10877.4 kb/s)
+      (average 11343.0 kb/s)
+    putting file /usr/share/cups/drivers/ADOBEPSU.DLL as \W32X86/ADOBEPSU.DLL (5095.2 kb/s)
+      (average 9260.4 kb/s)
+    putting file /usr/share/cups/drivers/ADOBEPSU.HLP as \W32X86/ADOBEPSU.HLP (8828.7 kb/s)
+      (average 9247.1 kb/s)
+
+    Running command: smbclient //localhost/print\$ -N -U'root%secret' -c 'mkdir WIN40;put
+      /var/spool/cups/tmp/3cd1cc66376c0 WIN40/infotec_IS2027.PPD;put
+      /usr/share/cups/drivers/ADFONTS.MFM WIN40/ADFONTS.MFM;put
+      /usr/share/cups/drivers/ADOBEPS4.DRV WIN40/ADOBEPS4.DRV;put
+      /usr/share/cups/drivers/ADOBEPS4.HLP WIN40/ADOBEPS4.HLP;put
+      /usr/share/cups/drivers/DEFPRTR2.PPD WIN40/DEFPRTR2.PPD;put
+      /usr/share/cups/drivers/ICONLIB.DLL WIN40/ICONLIB.DLL;put
+      /usr/share/cups/drivers/PSMON.DLL WIN40/PSMON.DLL;'
+    added interface ip=10.160.16.45 bcast=10.160.31.255 nmask=255.255.240.0
+    added interface ip=192.168.182.1 bcast=192.168.182.255 nmask=255.255.255.0
+    added interface ip=172.16.200.1 bcast=172.16.200.255 nmask=255.255.255.0
+    Domain=[TUX-NET] OS=[Unix] Server=[Samba 2.2.3a.200204262025cvs]
+    NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40
+    putting file /var/spool/cups/tmp/3cd1cc66376c0 as \WIN40/infotec_IS2027.PPD (26091.5 kb/s)
+      (average 26092.8 kb/s)
+    putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM (11241.6 kb/s)
+      (average 11812.9 kb/s)
+    putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DRV (16640.6 kb/s)
+      (average 14679.3 kb/s)
+    putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HLP (11285.6 kb/s)
+      (average 14281.5 kb/s)
+    putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PPD (823.5 kb/s)
+      (average 12944.0 kb/s)
+    putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL (19226.2 kb/s)
+      (average 13169.7 kb/s)
+    putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL (18666.1 kb/s)
+      (average 13266.7 kb/s)
+
+    Running command: rpcclient localhost -N -U'root%secret' -c 'adddriver "Windows NT x86"
+       "infotec_IS2027:ADOBEPS5.DLL:infotec_IS2027.PPD:ADOBEPSU.DLL:ADOBEPSU.HLP:NULL:RAW:NULL"'
+    cmd = adddriver "Windows NT x86" "infotec_IS2027:ADOBEPS5.DLL:infotec_IS2027.PPD:ADOBEPSU.DLL:
+       ADOBEPSU.HLP:NULL:RAW:NULL"
+    Printer Driver infotec_IS2027 successfully installed.
+
+    Running command: rpcclient localhost -N -U'root%secret' -c 'adddriver "Windows 4.0"
+       "infotec_IS2027:ADOBEPS4.DRV:infotec_IS2027.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:
+       ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"'
+    cmd = adddriver "Windows 4.0" "infotec_IS2027:ADOBEPS4.DRV:infotec_IS2027.PPD:NULL:
+       ADOBEPS4.HLP:PSMON.DLL:RAW:ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"
+    Printer Driver infotec_IS2027 successfully installed.
+
+    Running command: rpcclient localhost -N -U'root%secret'
+       -c 'setdriver infotec_IS2027 infotec_IS2027'
+    cmd = setdriver infotec_IS2027 infotec_IS2027
+    Succesfully set infotec_IS2027 to driver infotec_IS2027.
+
+    <prompt>root# </prompt>
+</programlisting></para>
+
+<para>
+If you look closely, you'll discover your root password was transfered unencrypted over
+the wire, so beware! Also, if you look further her, you'll discover error messages like
+<constant>NT_STATUS_OBJECT_NAME_COLLISION</constant> in between. They occur, because
+the directories <filename>WIN40</filename> and <filename>W32X86</filename> already
+existed in the [print$] driver download share (from a previous driver
+installation). They are harmless here.
+</para>
+
+<para>
+Now your printer is prepared for the clients to use. From
+a client, browse to the CUPS/Samba server, open the "Printers"
+share, right-click on this printer and select "Install..." or
+"Connect..." (depending on the Windows version you use). Now their
+should be a new printer in your client's local "Printers" folder,
+named (in my case) "infotec_IS2027 on kdebitshop"
+</para>
+
+<para>
+<emphasis>NOTE: </emphasis>
+<command>cupsaddsmb</command> will only reliably work i
+with CUPS version 1.1.15 or higher
+and Samba from 2.2.4. If it doesn't work, or if the automatic printer
+driver download to the clients doesn't succeed, you can still manually
+install the CUPS printer PPD on top of the Adobe PostScript driver on
+clients and then point the client's printer queue to the Samba printer
+share for connection, should you desire to use the CUPS networked
+PostScript RIP functions.
+</para>
+</sect2>
+</sect1>
+
+
+<sect1>
 <title>The CUPS Filter Chains</title>
 
 <para>
@@ -674,7 +1103,8 @@ at "/some/path/on/your/filesystem/somewhere/my-name-for-my-printer.ppd"
 Then install the printer:
 </para>
 <para><programlisting>
-    "lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -P /some/path/on/your/filesystem/somewhere/my-name-for-my-printer.ppd"
+    "lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E \
+          -P /some/path/on/your/filesystem/somewhere/my-name-for-my-printer.ppd"
 </programlisting></para>
 
 <para>
@@ -833,7 +1263,8 @@ assuming an existing printer named "quotaprinter":
 </para>
 
 <programlisting>
-  lpadmin -p quotaprinter -o job-quota-period=604800 -o job-k-limit=1024 -o job-page-limit=100
+  lpadmin -p quotaprinter -o job-quota-period=604800 -o job-k-limit=1024 \
+       -o job-page-limit=100
 </programlisting>
 
 <para>
@@ -989,15 +1420,15 @@ download is "cups-samba-1.1.16.tar.gz". Upon untar-/unzip-ping it will reveal
 the files:
 </para>
 
-<para>
-<programlisting>
-   cups-samba.install
-   cups-samba.license
-   cups-samba.readme
-   cups-samba.remove
-   cups-samba.ss
-</programlisting>
-</para>
+	<para>
+	<programlisting>
+	   cups-samba.install
+	   cups-samba.license
+	   cups-samba.readme
+	   cups-samba.remove
+	   cups-samba.ss
+	</programlisting>
+	</para>
 
 <para>
 These have been packaged with the ESP meta packager software "EPM". The
@@ -1006,13 +1437,13 @@ These have been packaged with the ESP meta packager software "EPM". The
 into <filename>/usr/share/cups/drivers/</filename>. Its contents are 3 files:
 </para>
 
-<para>
-<programlisting>
-   cupsdrvr.dll
-   cupsui.dll
-   cups.hlp
-</programlisting>
-</para>
+	<para>
+	<programlisting>
+	   cupsdrvr.dll
+	   cupsui.dll
+	   cups.hlp
+	</programlisting>
+	</para>
 
 <note><para>
 ATTENTION: due to a bug one CUPS release puts the <filename>cups.hlp</filename>
@@ -1021,11 +1452,11 @@ into <filename>/usr/share/drivers/</filename> instead of
 the file after running the "./cups-samba.install" script manually to the right place:
 </para>
 
-<para>
-<programlisting>
-      cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/
-</programlisting>
-</para>
+	<para>
+	<programlisting>
+	      cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/
+	</programlisting>
+	</para>
 </note>
 
 <note>
@@ -1053,45 +1484,45 @@ Win NT/2k/XP clients.
 </para></note>
 
 
-<note><para>
-NOTE 1: Win 9x/ME clients won't work with this driver. For these you'd
-still need to use the ADOBE*.* drivers as previously.
-</para></note>
+	<note><para>
+	NOTE 1: Win 9x/ME clients won't work with this driver. For these you'd
+	still need to use the ADOBE*.* drivers as previously.
+	</para></note>
 
-<note><para>
-NOTE 2: It is not harming if you've still the ADOBE*.* driver files from
-previous installations in the "/usr/share/cups/drivers/" directory.
-The new cupsaddsmb (from 1.1.16) will automatically use the
-"newest" installed driver (which here then is the CUPS drivers).
-</para></note>
+	<note><para>
+	NOTE 2: It is not harming if you've still the ADOBE*.* driver files from
+	previous installations in the "/usr/share/cups/drivers/" directory.
+	The new cupsaddsmb (from 1.1.16) will automatically use the
+	"newest" installed driver (which here then is the CUPS drivers).
+	</para></note>
 
-<note><para>
-NOTE 3: Should your Win clients have had the old ADOBE*.* files and the
-Adobe PostScript drivers installed, the download and installation
-of the new CUPS PostScript driver for Windows NT/2k/XP will fail
-at first.
-</para>
-<para>
-It is not enough to "delete" the printer (as the driver files
-will still be kept by the clients and re-used if you try to
-re-install the printer). To really get rid of the Adobe driver
-files on the clients, open the "Printers" folder (possibly via
-"Start --> Settings --> Control Panel --> Printers"), right-click
-onto the folder background and select "Server Properties". A
-new dialog opens; select the "Drivers" tab; on the list select
-the driver you want to delete and click on the "Delete" button.
-(This will only work if there is no single printer left which
-uses that particular driver -- you need to "delete" all printers
-using this driver in the "Printers" folder first.)
-</para>
-</note>
-
-<note><para>
-Once you have successfully downloaded the CUPS PostScript driver
-to a client, you can easily switch all printers to this one
-by proceeding as described elsewhere in the "Samba HOWTO
-Collection" to change a driver for an existing printer.
-</para></note>
+	<note><para>
+	NOTE 3: Should your Win clients have had the old ADOBE*.* files and the
+	Adobe PostScript drivers installed, the download and installation
+	of the new CUPS PostScript driver for Windows NT/2k/XP will fail
+	at first.
+	</para>
+	<para>
+	It is not enough to "delete" the printer (as the driver files
+	will still be kept by the clients and re-used if you try to
+	re-install the printer). To really get rid of the Adobe driver
+	files on the clients, open the "Printers" folder (possibly via
+	"Start --> Settings --> Control Panel --> Printers"), right-click
+	onto the folder background and select "Server Properties". A
+	new dialog opens; select the "Drivers" tab; on the list select
+	the driver you want to delete and click on the "Delete" button.
+	(This will only work if there is no single printer left which
+	uses that particular driver -- you need to "delete" all printers
+	using this driver in the "Printers" folder first.)
+	</para>
+	</note>
+
+	<note><para>
+	Once you have successfully downloaded the CUPS PostScript driver
+	to a client, you can easily switch all printers to this one
+	by proceeding as described elsewhere in the "Samba HOWTO
+	Collection" to change a driver for an existing printer.
+	</para></note>
 
 <para>
 What are the benefits with the "CUPS PostScript driver for Windows NT/2k/XP"
diff --git a/docs/docbook/projdoc/Compiling.sgml b/docs/docbook/projdoc/Compiling.sgml
index 49aafebec0..ac98f34a32 100644
--- a/docs/docbook/projdoc/Compiling.sgml
+++ b/docs/docbook/projdoc/Compiling.sgml
@@ -217,6 +217,64 @@ on this system just substitute the correct package name
 	</userinput></para>
 	
 	<para>if you find this version a disaster!</para>
+
+	<sect2>
+	<title>Compiling samba with Active Directory support</title>
+	
+	<para>In order to compile samba with ADS support, you need to have installed
+	on your system: 
+	<simplelist>
+	<member>the MIT kerberos development libraries (either install from the sources or use a package). The heimdal libraries will not work.</member>
+	<member>the OpenLDAP development libraries.</member>
+	</simplelist>
+
+	<para>If your kerberos libraries are in a non-standard location then
+	  remember to add the configure option --with-krb5=DIR.</para>
+
+    <para>After you run configure make sure that <filename>include/config.h</filename> it generates contains lines like this:</para>
+
+		  <para><programlisting>
+#define HAVE_KRB5 1
+#define HAVE_LDAP 1
+		  </programlisting></para>
+
+	  <para>If it doesn't then configure did not find your krb5 libraries or
+	    your ldap libraries. Look in config.log to figure out why and fix
+		  it.</para>
+
+	<sect3>
+	<title>Installing the required packages for Debian</title>
+
+	<para>On Debian you need to install the following packages:</para>
+	<para>
+	<simplelist>
+	<member>libkrb5-dev</member>
+	<member>krb5-user</member>
+	</simplelist>
+	</para>
+	</sect3>
+
+	<sect3>
+	<title>Installing the required packages for RedHat</title>
+
+	<para>On RedHat this means you should have at least: </para>
+	<para>
+	<simplelist>
+	<member>krb5-workstation (for kinit)</member>
+	<member>krb5-libs (for linking with)</member>
+	<member>krb5-devel (because you are compiling from source)</member>
+	</simplelist>
+	</para>
+
+	<para>in addition to the standard development environment.</para>
+
+	<para>Note that these are not standard on a RedHat install, and you may need
+	to get them off CD2.</para>
+
+	</sect3>
+	
+	</sect2>
+			  
 </sect1>
 
 <sect1>
diff --git a/docs/docbook/projdoc/DOMAIN_MEMBER.sgml b/docs/docbook/projdoc/DOMAIN_MEMBER.sgml
index b178bfd2c2..8ac3520384 100644
--- a/docs/docbook/projdoc/DOMAIN_MEMBER.sgml
+++ b/docs/docbook/projdoc/DOMAIN_MEMBER.sgml
@@ -45,9 +45,7 @@
 	<parameter>security =</parameter></ulink> line in the [global] section 
 	of your smb.conf to read:</para>
 
-	<para><command>security = domain</command> or
-	<command>security = ads</command> depending on if the PDC is
-	NT4 or running Active Directory respectivly.</para>
+	<para><command>security = domain</command></para>
 
 	<para>Next change the <ulink url="smb.conf.5.html#WORKGROUP"><parameter>
 	workgroup =</parameter></ulink> line in the [global] section to read: </para>
@@ -86,7 +84,7 @@
 	<para>In order to actually join the domain, you must run this
         command:</para>
 
-	<para><prompt>root# </prompt><userinput>net join -S DOMPDC
+	<para><prompt>root# </prompt><userinput>net rpc join -S DOMPDC
 	-U<replaceable>Administrator%password</replaceable></userinput></para>
 
 	<para>as we are joining the domain DOM and the PDC for that domain 
@@ -124,19 +122,6 @@
 </sect1>
 
 <sect1>
-<title>Samba and Windows 2000 Domains</title>
-<!-- FIXME: this section is partly obsoleted - jelmer@samba.org -->
-
-<para>
-Many people have asked regarding the state of Samba's ability to participate in
-a Windows 2000 Domain.  Samba 3.0 is able to act as a member server of a Windows
-2000 domain operating in mixed or native mode.  The steps above apply
-to both NT4 and Windows 2000.
-</para>
-
-</sect1>
-
-<sect1>
 	<title>Why is this better than security = server?</title>
 
 	<para>Currently, domain security in Samba doesn't free you from 
@@ -178,11 +163,11 @@ to both NT4 and Windows 2000.
 	reply, the Samba server gets the user identification information such 
 	as the user SID, the list of NT groups the user belongs to, etc. </para>
 
-	<para><emphasis>NOTE:</emphasis> Much of the text of this document 
+	<note><para> Much of the text of this document 
 	was first published in the Web magazine <ulink url="http://www.linuxworld.com"> 	
 	LinuxWorld</ulink> as the article <ulink
 	url="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html">Doing 
-	the NIS/NT Samba</ulink>.</para>
+	the NIS/NT Samba</ulink>.</para></note>
 
 </sect1>
 
diff --git a/docs/docbook/projdoc/GROUP-MAPPING-HOWTO.sgml b/docs/docbook/projdoc/GROUP-MAPPING-HOWTO.sgml
index 06c1d3a87e..a2d16541ef 100644
--- a/docs/docbook/projdoc/GROUP-MAPPING-HOWTO.sgml
+++ b/docs/docbook/projdoc/GROUP-MAPPING-HOWTO.sgml
@@ -6,7 +6,7 @@
 	</author>
 </chapterinfo>
 
-<title>Group mapping HOWTO</title>
+<title>Configuring Group Mapping</title>
 
 <para> 
 Starting with Samba 3.0 alpha 2, a new group mapping function is available. The
diff --git a/docs/docbook/projdoc/Integrating-with-Windows.sgml b/docs/docbook/projdoc/Integrating-with-Windows.sgml
index a4e79fd42b..8a5c0c40f2 100644
--- a/docs/docbook/projdoc/Integrating-with-Windows.sgml
+++ b/docs/docbook/projdoc/Integrating-with-Windows.sgml
@@ -18,48 +18,46 @@
  
 <title>Integrating MS Windows networks with Samba</title>
  
-<sect1>
-<title>Agenda</title>
-
 <para>
-To identify the key functional mechanisms of MS Windows networking 
-to enable the deployment of Samba as a means of extending and/or 
-replacing MS Windows NT/2000 technology.
+This section deals with NetBIOS over TCP/IP name to IP address resolution. If you
+your MS Windows clients are NOT configured to use NetBIOS over TCP/IP then this
+section does not apply to your installation. If your installation involves use of
+NetBIOS over TCP/IP then this section may help you to resolve networking problems.
 </para>
 
+<note>
 <para>
-We will examine:
+	NetBIOS over TCP/IP has nothing to do with NetBEUI. NetBEUI is NetBIOS
+	over Logical Link Control (LLC). On modern networks it is highly advised
+	to NOT run NetBEUI at all. Note also that there is NO such thing as
+	NetBEUI over TCP/IP - the existence of such a protocol is a complete
+	and utter mis-apprehension.
 </para>
+</note>
 
-<orderedlist>
-	<listitem><para>Name resolution in a pure Unix/Linux TCP/IP 
-	environment
-	</para></listitem>
-
-	<listitem><para>Name resolution as used within MS Windows 
-	networking
-	</para></listitem>
-
-	<listitem><para>How browsing functions and how to deploy stable 
-	and dependable browsing using Samba
-	</para></listitem>
-	
-	<listitem><para>MS Windows security options and how to 
-	configure Samba for seemless integration
-	</para></listitem>
+<para>
+Since the introduction of MS Windows 2000 it is possible to run MS Windows networking
+without the use of NetBIOS over TCP/IP. NetBIOS over TCP/IP uses UDP port 137 for NetBIOS
+name resolution and uses TCP port 139 for NetBIOS session services. When NetBIOS over
+TCP/IP is disabled on MS Windows 2000 and later clients then only TCP port 445 will be
+used and UDP port 137 and TCP port 139 will not.
+</para>
 
-	<listitem><para>Configuration of Samba as:</para>
-		<orderedlist>
-		<listitem><para>A stand-alone server</para></listitem>
-		<listitem><para>An MS Windows NT 3.x/4.0 security domain member
-		</para></listitem>
-		<listitem><para>An alternative to an MS Windows NT 3.x/4.0 Domain Controller
-		</para></listitem>
-		</orderedlist>
-	</listitem>
-</orderedlist>
+<note>
+<para>
+When using Windows 2000 or later clients, if NetBIOS over TCP/IP is NOT disabled, then
+the client will use UDP port 137 (NetBIOS Name Service, also known as the Windows Internet
+Name Service or WINS), TCP port 139 AND TCP port 445 (for actual file and print traffic).
+</para>
+</note>
 
-</sect1>
+<para>
+When NetBIOS over TCP/IP is disabled the use of DNS is essential. Most installations that
+disable NetBIOS over TCP/IP today use MS Active Directory Service (ADS). ADS requires
+Dynamic DNS with Service Resource Records (SRV RR) and with Incremental Zone Transfers (IXFR).
+Use of DHCP with ADS is recommended as a further means of maintaining central control
+over client workstation network configuration.
+</para>
 
 
 <sect1>
@@ -555,381 +553,4 @@ of the WINS server.
 </sect2>
 </sect1>
 
-
-<sect1>
-<title>How browsing functions and how to deploy stable and 
-dependable browsing using Samba</title>
-
-
-<para>
-As stated above, MS Windows machines register their NetBIOS names 
-(i.e.: the machine name for each service type in operation) on start 
-up. Also, as stated above, the exact method by which this name registration 
-takes place is determined by whether or not the MS Windows client/server 
-has been given a WINS server address, whether or not LMHOSTS lookup 
-is enabled, or if DNS for NetBIOS name resolution is enabled, etc.
-</para>
-
-<para>
-In the case where there is no WINS server all name registrations as 
-well as name lookups are done by UDP broadcast. This isolates name 
-resolution to the local subnet, unless LMHOSTS is used to list all 
-names and IP addresses. In such situations Samba provides a means by 
-which the samba server name may be forcibly injected into the browse 
-list of a remote MS Windows network (using the "remote announce" parameter).
-</para>
-
-<para>
-Where a WINS server is used, the MS Windows client will use UDP 
-unicast to register with the WINS server. Such packets can be routed 
-and thus WINS allows name resolution to function across routed networks.
-</para>
-
-<para>
-During the startup process an election will take place to create a 
-local master browser if one does not already exist. On each NetBIOS network 
-one machine will be elected to function as the domain master browser. This 
-domain browsing has nothing to do with MS security domain control. 
-Instead, the domain master browser serves the role of contacting each local 
-master browser (found by asking WINS or from LMHOSTS) and exchanging browse 
-list contents. This way every master browser will eventually obtain a complete 
-list of all machines that are on the network. Every 11-15 minutes an election 
-is held to determine which machine will be the master browser. By the nature of 
-the election criteria used, the machine with the highest uptime, or the 
-most senior protocol version, or other criteria, will win the election 
-as domain master browser.
-</para>
-
-<para>
-Clients wishing to browse the network make use of this list, but also depend 
-on the availability of correct name resolution to the respective IP 
-address/addresses. 
-</para>
-
-<para>
-Any configuration that breaks name resolution and/or browsing intrinsics 
-will annoy users because they will have to put up with protracted 
-inability to use the network services.
-</para>
-
-<para>
-Samba supports a feature that allows forced synchonisation 
-of browse lists across routed networks using the "remote 
-browse sync" parameter in the smb.conf file. This causes Samba 
-to contact the local master browser on a remote network and 
-to request browse list synchronisation. This effectively bridges 
-two networks that are separated by routers. The two remote 
-networks may use either broadcast based name resolution or WINS 
-based name resolution, but it should be noted that the "remote 
-browse sync" parameter provides browse list synchronisation - and 
-that is distinct from name to address resolution, in other 
-words, for cross subnet browsing to function correctly it is 
-essential that a name to address resolution mechanism be provided. 
-This mechanism could be via DNS, <filename>/etc/hosts</filename>, 
-and so on.
-</para>
-
-</sect1>
-
-<sect1>
-<title>MS Windows security options and how to configure 
-Samba for seemless integration</title>
-
-<para>
-MS Windows clients may use encrypted passwords as part of a 
-challenege/response authentication model (a.k.a. NTLMv1) or 
-alone, or clear text strings for simple password based 
-authentication. It should be realized that with the SMB 
-protocol the password is passed over the network either 
-in plain text or encrypted, but not both in the same 
-authentication requets.
-</para>
-
-<para>
-When encrypted passwords are used a password that has been 
-entered by the user is encrypted in two ways:
-</para>
-
-<itemizedlist>
-	<listitem><para>An MD4 hash of the UNICODE of the password
-	string.  This is known as the NT hash.
-	</para></listitem>
-
-	<listitem><para>The password is converted to upper case,
-	and then padded or trucated to 14 bytes.  This string is 
-	then appended with 5 bytes of NULL characters and split to
-	form two 56 bit DES keys to encrypt a "magic" 8 byte value.
-	The resulting 16 bytes for the LanMan hash.
-	</para></listitem>	
-</itemizedlist>
-
-<para>
-You should refer to the <ulink url="ENCRYPTION.html">
-Password Encryption</ulink> chapter in this HOWTO collection
-for more details on the inner workings
-</para>
-
-<para>
-MS Windows 95 pre-service pack 1, MS Windows NT versions 3.x 
-and version 4.0 pre-service pack 3 will use either mode of 
-password authentication. All versions of MS Windows that follow 
-these versions no longer support plain text passwords by default.
-</para>
-
-<para>
-MS Windows clients have a habit of dropping network mappings that 
-have been idle for 10 minutes or longer. When the user attempts to 
-use the mapped drive connection that has been dropped, the client
-re-establishes the connection using 
-a cached copy of the password.
-</para>
-
-<para>
-When Microsoft changed the default password mode, they dropped support for 
-caching of the plain text password. This means that when the registry 
-parameter is changed to re-enable use of plain text passwords it appears to 
-work, but when a dropped mapping attempts to revalidate it will fail if 
-the remote authentication server does not support encrypted passwords. 
-This means that it is definitely not a good idea to re-enable plain text 
-password support in such clients.
-</para>
-
-<para>
-The following parameters can be used to work around the 
-issue of Windows 9x client upper casing usernames and
-password before transmitting them to the SMB server
-when using clear text authentication.
-</para>
-
-<para><programlisting>
-	<ulink url="smb.conf.5.html#PASSWORDLEVEL">passsword level</ulink> = <replaceable>integer</replaceable>
-	<ulink url="smb.conf.5.html#USERNAMELEVEL">username level</ulink> = <replaceable>integer</replaceable>
-</programlisting></para>
-
-<para>
-By default Samba will lower case the username before attempting
-to lookup the user in the database of local system accounts.
-Because UNIX usernames conventionally only contain lower case
-character, the <parameter>username level</parameter> parameter
-is rarely even needed.
-</para>
-
-<para>
-However, password on UNIX systems often make use of mixed case
-characters.  This means that in order for a user on a Windows 9x
-client to connect to a Samba server using clear text authentication,
-the <parameter>password level</parameter> must be set to the maximum
-number of upper case letter which <emphasis>could</emphasis> appear
-is a password.  Note that is the server OS uses the traditional
-DES version of crypt(), then a <parameter>password level</parameter>
-of 8 will result in case insensitive passwords as seen from Windows
-users.  This will also result in longer login times as Samba
-hash to compute the permutations of the password string and 
-try them one by one until a match is located (or all combinations fail).
-</para>
-
-<para>
-The best option to adopt is to enable support for encrypted passwords 
-where ever Samba is used. There are three configuration possibilities 
-for support of encrypted passwords:
-</para>
-
-
-<sect2>
-<title>Use MS Windows NT as an authentication server</title>
-
-<para>
-This method involves the additions of the following parameters 
-in the smb.conf file:
-</para>
-
-<para><programlisting>
-	encrypt passwords = Yes
-	security = server
-	password server = "NetBIOS_name_of_PDC"
-</programlisting></para>
-
-
-<para>
-There are two ways of identifying whether or not a username and 
-password pair was valid or not. One uses the reply information provided 
-as part of the authentication messaging process, the other uses 
-just and error code.
-</para>
-
-<para>
-The down-side of this mode of configuration is the fact that 
-for security reasons Samba will send the password server a bogus 
-username and a bogus password and if the remote server fails to 
-reject the username and password pair then an alternative mode 
-of identification of validation is used. Where a site uses password 
-lock out after a certain number of failed authentication attempts 
-this will result in user lockouts.
-</para>
-
-<para>
-Use of this mode of authentication does require there to be 
-a standard Unix account for the user, this account can be blocked 
-to prevent logons by other than MS Windows clients.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Make Samba a member of an MS Windows NT security domain</title>
-
-<para>
-This method involves additon of the following paramters in the smb.conf file:
-</para>
-
-<para><programlisting>
-	encrypt passwords = Yes
-	security = domain
-	workgroup = "name of NT domain"
-	password server = *
-</programlisting></para>
-
-<para>
-The use of the "*" argument to "password server" will cause samba 
-to locate the domain controller in a way analogous to the way 
-this is done within MS Windows NT.
-</para>
-
-<para>
-In order for this method to work the Samba server needs to join the 
-MS Windows NT security domain. This is done as follows:
-</para>
-
-<itemizedlist>
-	<listitem><para>On the MS Windows NT domain controller using 
-	the Server Manager add a machine account for the Samba server.
-	</para></listitem>
-	
-	<listitem><para>Next, on the Linux system execute: 
-	<command>smbpasswd -r PDC_NAME -j DOMAIN_NAME</command>
-	</para></listitem>
-</itemizedlist>
-
-<para>
-Use of this mode of authentication does require there to be 
-a standard Unix account for the user in order to assign
-a uid once the account has been authenticated by the remote
-Windows DC.  This account can be blocked to prevent logons by 
-other than MS Windows clients by things such as setting an invalid
-shell in the <filename>/etc/passwd</filename> entry.
-</para>
-
-<para>
-An alternative to assigning UIDs to Windows users on a 
-Samba member server is presented in the <ulink
-url="winbind.html">Winbind Overview</ulink> chapter in
-this HOWTO collection.
-</para>
-
-
-</sect2>
-
-
-<sect2>
-<title>Configure Samba as an authentication server</title>
-
-<para>
-This mode of authentication demands that there be on the 
-Unix/Linux system both a Unix style account as well as an 
-smbpasswd entry for the user. The Unix system account can be 
-locked if required as only the encrypted password will be 
-used for SMB client authentication.
-</para>
-
-<para>
-This method involves addition of the following parameters to 
-the smb.conf file:
-</para>
-
-<para><programlisting>
-## please refer to the Samba PDC HOWTO chapter later in 
-## this collection for more details
-[global]
-	encrypt passwords = Yes
-	security = user
-	domain logons = Yes
-	; an OS level of 33 or more is recommended
-	os level = 33
-
-[NETLOGON]
-	path = /somewhare/in/file/system
-	read only = yes
-</programlisting></para>
-
-<para>
-in order for this method to work a Unix system account needs 
-to be created for each user, as well as for each MS Windows NT/2000 
-machine. The following structure is required.
-</para>
-
-<sect3>
-<title>Users</title>
-
-<para>
-A user account that may provide a home directory should be 
-created. The following Linux system commands are typical of 
-the procedure for creating an account.
-</para>
-
-<para><programlisting>
-	# useradd -s /bin/bash -d /home/"userid" -m "userid"
-	# passwd "userid"
-	  Enter Password: &lt;pw&gt;
-	  
-	# smbpasswd -a "userid"
-	  Enter Password: &lt;pw&gt;
-</programlisting></para>
-</sect3>
-
-<sect3>
-<title>MS Windows NT Machine Accounts</title>
-
-<para>
-These are required only when Samba is used as a domain 
-controller.  Refer to the Samba-PDC-HOWTO for more details.
-</para>
-
-<para><programlisting>
-	# useradd -s /bin/false -d /dev/null "machine_name"\$
-	# passwd -l "machine_name"\$
-	# smbpasswd -a -m "machine_name"
-</programlisting></para>
-</sect3>
-</sect2>
-</sect1>
-
-
-<sect1>
-<title>Conclusions</title>
-
-<para>
-Samba provides a flexible means to operate as...
-</para>
-
-<itemizedlist>
-	<listitem><para>A Stand-alone server - No special action is needed 
-	other than to create user accounts. Stand-alone servers do NOT 
-	provide network logon services, meaning that machines that use this 
-	server do NOT perform a domain logon but instead make use only of 
-	the MS Windows logon which is local to the MS Windows 
-	workstation/server.
-	</para></listitem>
-	
-	<listitem><para>An MS Windows NT 3.x/4.0 security domain member.
-	</para></listitem>
-	
-
-	<listitem><para>An alternative to an MS Windows NT 3.x/4.0 
-	Domain Controller.
-	</para></listitem>
-
-</itemizedlist>
-
-</sect1>
-
 </chapter>
diff --git a/docs/docbook/projdoc/NT_Security.sgml b/docs/docbook/projdoc/NT_Security.sgml
index 2843331519..c5e3b9b9f9 100644
--- a/docs/docbook/projdoc/NT_Security.sgml
+++ b/docs/docbook/projdoc/NT_Security.sgml
@@ -1,5 +1,4 @@
 <chapter id="unix-permissions">
-
 <chapterinfo>
 	<author>
 		<firstname>Jeremy</firstname><surname>Allison</surname>
@@ -10,39 +9,44 @@
 			</address>
 		</affiliation>
 	</author>
-	
-		
 	<pubdate>12 Apr 1999</pubdate>
 </chapterinfo>
 
-
 <title>UNIX Permission Bits and Windows NT Access Control Lists</title>
 
 <sect1>
 	<title>Viewing and changing UNIX permissions using the NT 
 	security dialogs</title>
 
-
-	<para>New in the Samba 2.0.4 release is the ability for Windows 
-	NT clients to use their native security settings dialog box to 
-	view and modify the underlying UNIX permissions.</para>
+	<para>Windows NT clients can use their native security settings 
+	dialog box to view and modify the underlying UNIX permissions.</para>
 
 	<para>Note that this ability is careful not to compromise 
 	the security of the UNIX host Samba is running on, and 
 	still obeys all the file permission rules that a Samba 
 	administrator can set.</para>
+
+	<note>
+	<para>
+	All access to Unix/Linux system file via Samba is controlled at
+	the operating system file access control level. When trying to
+	figure out file access problems it is vitally important to identify
+	the identity of the Windows user as it is presented by Samba at
+	the point of file access. This can best be determined from the
+	Samba log files.
+	</para>
+	</note>
 </sect1>
 
 <sect1>
 	<title>How to view file security on a Samba share</title>
 
-	<para>From an NT 4.0 client, single-click with the right 
+	<para>From an NT4/2000/XP client, single-click with the right 
 	mouse button on any file or directory in a Samba mounted 
 	drive letter or UNC path. When the menu pops-up, click 
 	on the <emphasis>Properties</emphasis> entry at the bottom of 
-	the menu. This brings up the normal file properties dialog
-	box, but with Samba 2.0.4 this will have a new tab along the top
-	marked <emphasis>Security</emphasis>. Click on this tab and you 
+	the menu. This brings up the file properties dialog
+	box. Click on the tab <emphasis>Security</emphasis> and you 
 	will see three buttons, <emphasis>Permissions</emphasis>, 	
 	<emphasis>Auditing</emphasis>, and <emphasis>Ownership</emphasis>. 
 	The <emphasis>Auditing</emphasis> button will cause either 
@@ -89,7 +93,7 @@
 
 	<para>There is an NT chown command that will work with Samba 
 	and allow a user with Administrator privilege connected 
-	to a Samba 2.0.4 server as root to change the ownership of 
+	to a Samba 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
 	</emphasis> NT security library written by Jeremy Allison of 
@@ -193,7 +197,7 @@
 	</command> message.</para>
 
 	<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 
+	button will not return a list of users in Samba (it will give 
 	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 
@@ -233,8 +237,9 @@
 	<title>Interaction with the standard Samba create mask 
 	parameters</title>
 
-	<para>Note that with Samba 2.0.5 there are four new parameters 
-	to control this interaction.  These are :</para>
+	<para>There are four parameters 
+	to control interaction with the standard Samba create mask parameters.
+	These are :</para>
 
 	<para><parameter>security mask</parameter></para>
 	<para><parameter>force security mode</parameter></para>
@@ -256,9 +261,8 @@
 
 	<para>If not set explicitly this parameter is set to the same value as 
 	the <ulink url="smb.conf.5.html#CREATEMASK"><parameter>create mask
-	</parameter></ulink> parameter to provide compatibility with Samba 2.0.4 
-	where this permission change facility was introduced. To allow a user to 
-	modify all the user/group/world permissions on a file, set this parameter 
+	</parameter></ulink> parameter. To allow a user to modify all the
+	user/group/world permissions on a file, set this parameter 
 	to 0777.</para>
 
 	<para>Next Samba checks the changed permissions for a file against 
@@ -273,8 +277,7 @@
 
 	<para>If not set explicitly this parameter is set to the same value 
 	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.
+	create mode</parameter></ulink> parameter.
 	To allow a user to modify all the user/group/world permissions on a file
 	with no restrictions set this parameter to 000.</para>
 
@@ -293,9 +296,7 @@
 	by default is set to the same value as the <parameter>directory mask
 	</parameter> parameter and the <parameter>force directory security 
 	mode</parameter> parameter by default is set to the same value as 
- 	the <parameter>force directory mode</parameter> parameter to provide 
-	compatibility with Samba 2.0.4 where the permission change facility 
-	was introduced.</para>
+ 	the <parameter>force directory mode</parameter> parameter. </para>
 
 	<para>In this way Samba enforces the permission restrictions that 
 	an administrator can set on a Samba share, whilst still allowing users 
@@ -311,15 +312,6 @@
 	<para><parameter>force security mode = 0</parameter></para>
 	<para><parameter>directory security mask = 0777</parameter></para>
 	<para><parameter>force directory security mode = 0</parameter></para>
-
-	<para>As described, in Samba 2.0.4 the parameters :</para>
-
-	<para><parameter>create mask</parameter></para>
-	<para><parameter>force create mode</parameter></para>
-	<para><parameter>directory mask</parameter></para>
-	<para><parameter>force directory mode</parameter></para>
-
-	<para>were used instead of the parameters discussed here.</para>
 </sect1>
 
 <sect1>
diff --git a/docs/docbook/projdoc/Other-Clients.sgml b/docs/docbook/projdoc/Other-Clients.sgml
index 6ba04b01d3..e4d7e34185 100644
--- a/docs/docbook/projdoc/Other-Clients.sgml
+++ b/docs/docbook/projdoc/Other-Clients.sgml
@@ -339,4 +339,14 @@ create accounts on the Samba host for Domain users.</emphasis></para>
 
 </sect1>
 
+<sect1>
+<title>Windows NT 3.1</title>
+
+<para>If you have problems communicating across routers with Windows 
+NT 3.1 workstations, read <ulink url="http://support.microsoft.com/default.aspx?scid=kb;[LN];Q103765">this Microsoft Knowledge Base article</ulink>.
+
+</para>
+
+</sect1>
+
 </chapter>
diff --git a/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml b/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml
index adcd059bc2..f2a6fc06ac 100644
--- a/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml
+++ b/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml
@@ -1,6 +1,4 @@
 <chapter id="pam">
- 
- 
 <chapterinfo>
         <author>
 		<firstname>John</firstname><surname>Terpstra</surname>
@@ -11,13 +9,10 @@
 			</address>
                 </affiliation>
         </author>
- 
- 
         <pubdate> (Jun 21 2001) </pubdate>
 </chapterinfo>
  
-<title>Configuring PAM for distributed but centrally 
-managed authentication</title>
+<title>PAM Configuration for Centrally Managed Authentication</title>
 
 <sect1>
 <title>Samba and PAM</title>
@@ -42,6 +37,19 @@ PAM is configured either through one file <filename>/etc/pam.conf</filename> (So
 or by editing individual files that are located in <filename>/etc/pam.d</filename>.
 </para>
 
+<note>
+	<para>
+	If the PAM authentication module (loadable link library file) is located in the
+	default location then it is not necessary to specify the path. In the case of
+	Linux, the default location is <filename>/lib/security</filename>. If the module
+	is located other than default then the path may be specified as:
+	
+	<programlisting>
+	eg: "auth       required      /other_path/pam_strange_module.so"
+	</programlisting>
+	</para>
+</note>
+
 <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 
@@ -51,20 +59,20 @@ 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
+	#%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>
@@ -73,19 +81,19 @@ 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
+	$ /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>
@@ -110,13 +118,13 @@ source distribution.
 </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
+	#%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>
@@ -125,13 +133,13 @@ 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
+	#%PAM-1.0
+	# The PAM configuration file for the `samba' service
+	#
+	auth       required     pam_pwdb.so nullok nodelay shadow audit
+	account    required     pam_pwdb.so audit nodelay
+	session    required     pam_pwdb.so nodelay
+	password   required     pam_pwdb.so shadow md5
 </programlisting></para>
 
 <para>
@@ -143,17 +151,16 @@ 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
+	#%PAM-1.0
+	# The PAM configuration file for the `samba' service
+	#
+	auth       required     pam_smbpass.so nodelay
+	account    required     pam_pwdb.so audit nodelay
+	session    required     pam_pwdb.so nodelay
+	password   required     pam_smbpass.so nodelay smbconf=/etc/samba.d/smb.conf
 </programlisting></para>
 
-<para>
-Note: PAM allows stacking of authentication mechanisms. It is 
+<note><para>PAM allows stacking of authentication mechanisms. It is 
 also possible to pass information obtained within one 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 
@@ -164,7 +171,7 @@ authentication to be configured in a single central file. The
 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>
+</para></note>
 
 </sect1>
 
@@ -174,9 +181,9 @@ PAM documentation for further helpful information.
 <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 
+<command>winbindd</command>, and a distributed 
+passdb backend, such as ldap, 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 
@@ -196,7 +203,7 @@ 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. 
+When Samba is configured 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 
diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml b/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml
index e3bee32db0..46e69e4ba9 100644
--- a/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml
+++ b/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml
@@ -13,7 +13,7 @@
 </chapterinfo>
 
 <title>
-How to Act as a Backup Domain Controller in a Purely Samba Controlled Domain
+Samba Backup Domain Controller to Samba Domain Control
 </title>
 
 <sect1>
diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml b/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml
index 53dae21775..7aabca948f 100644
--- a/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml
+++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml
@@ -68,27 +68,33 @@ PDC functionality.
 
 <itemizedlist>
 	<listitem><para>
-	domain logons for Windows NT 4.0 / 200x / XP Professional clients.
+	Domain logons for Windows NT 4.0 / 200x / XP Professional clients.
 	</para></listitem>
 	
 	<listitem><para>
-	placing Windows 9x / Me clients in user level security
+	Placing Windows 9x / Me clients in user level security
 	</para></listitem>
 	
 	<listitem><para>
-	retrieving a list of users and groups from a Samba PDC to
+	Retrieving a list of users and groups from a Samba PDC to
 	Windows 9x / Me / NT / 200x / XP Professional clients
 	</para></listitem>
 	
 	<listitem><para>
-	roaming user profiles
+	Roaming Profiles
 	</para></listitem>
 	
 	<listitem><para>
-	Windows NT 4.0-style system policies
+	Network/System Policies
 	</para></listitem>
 </itemizedlist>
 
+<note>
+<para>
+Roaming Profiles and System/Network policies are advanced network administration topics
+that are covered separately in this document.
+</para>
+</note>
 
 <para>
 The following functionalities are new to the Samba 3.0 release:
@@ -587,18 +593,17 @@ version of Windows.
 
 	<para>I joined the domain successfully but after upgrading 
 	to a newer version of the Samba code I get the message, "The system 
-	can not log you on (C000019B), Please try a gain or consult your 
+	can not log you on (C000019B), Please try again or consult your 
 	system administrator" when attempting to logon.
 	</para>
 
 	<para>
-	This occurs when the domain SID stored in 
-	<filename>private/WORKGROUP.SID</filename> is 
-	changed.  For example, you remove the file and <command>smbd</command> automatically 
-	creates a new one.  Or you are swapping back and forth between 
-	versions 2.0.7, TNG and the HEAD branch code (not recommended).  The 
-	only way to correct the problem is to restore the original domain 
-	SID or remove the domain client from the domain and rejoin.
+	This occurs when the domain SID stored in the secrets.tdb database
+	is changed. The most common cause of a change in domain SID is when
+	the domain name and/or the server name (netbios name) is changed.
+ 	The only way to correct the problem is to restore the original domain 
+	SID or remove the domain client from the domain and rejoin. The domain
+	SID may be reset using either the smbpasswd or rpcclient utilities.
 	</para>
 </listitem>
 
@@ -675,128 +680,6 @@ version of Windows.
 
 </sect1>
 
-
-
-<!-- **********************************************************
-
-     Policies and Profiles
-
-*************************************************************** -->
-
-<sect1>
-<title>
-System Policies and Profiles
-</title>
-
-<para>
-Much of the information necessary to implement System Policies and
-Roving User Profiles in a Samba domain is the same as that for 
-implementing these same items in a Windows NT 4.0 domain. 
-You should read the white paper <ulink url="http://www.microsoft.com/ntserver/management/deployment/planguide/prof_policies.asp">Implementing
-Profiles and Policies in Windows NT 4.0</ulink> available from Microsoft.
-</para>
-
-<para>
-Here are some additional details:
-</para>
-
-<itemizedlist>
-
-<listitem>
-	<para>
-	<emphasis>What about Windows NT Policy Editor?</emphasis>
-	</para>
-
-	<para>
-	To create or edit <filename>ntconfig.pol</filename> you must use 
-	the NT Server Policy Editor, <command>poledit.exe</command>	which 
-	is included with NT Server but <emphasis>not NT Workstation</emphasis>. 
-	There is a Policy Editor on a NTws 
-	but it is not suitable for creating <emphasis>Domain Policies</emphasis>. 
-	Further, although the Windows 95 
-	Policy Editor can be installed on an NT Workstation/Server, it will not
-	work with NT policies because the registry key that are set by the policy templates. 
-	However, the files from the NT Server will run happily enough on an NTws. 	
-	You need <filename>poledit.exe, common.adm</filename> and <filename>winnt.adm</filename>. It is convenient
-	to put the two *.adm files in <filename>c:\winnt\inf</filename> which is where
-	the binary will look for them unless told otherwise. Note also that that 
-	directory is 'hidden'.
-	</para>
-
-	<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>, 
-	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 
-	location is with the Zero Administration Kit available for download from Microsoft.
-	</para>
-</listitem>
-
-
-<listitem>
-	<para>
-	<emphasis>Can Win95 do Policies?</emphasis>
-	</para>
-
-	<para>
-	Install the group policy handler for Win9x to pick up group 
-	policies.   Look on the Win98 CD in <filename>\tools\reskit\netadmin\poledit</filename>. 
-	Install group policies on a Win9x client by double-clicking 
-	<filename>grouppol.inf</filename>. Log off and on again a couple of 
-	times and see if Win98 picks up group policies.  Unfortunately this needs 
-	to be done on every Win9x machine that uses group policies....
-	</para> 
-
-	<para>
-	If group policies don't work one reports suggests getting the updated 
-	(read: working) grouppol.dll for Windows 9x. The group list is grabbed 
-	from /etc/group.
-	</para>
-</listitem>
-
-
-<listitem>
-	<para>
-	<emphasis>How do I get 'User Manager' and 'Server Manager'</emphasis>
-	</para>
-
-	<para>
-	Since I don't need to buy an NT Server CD now, how do I get 
-	the 'User Manager for Domains', the 'Server Manager'?
-	</para>
-
-	<para>
-	Microsoft distributes a version of these tools called nexus for 
-	installation on Windows 95 systems.  The tools set includes
-	</para>
-	
-	<itemizedlist>
-		<listitem><para>Server Manager</para></listitem> 
-		
-		<listitem><para>User Manager for Domains</para></listitem> 
-
-		<listitem><para>Event Viewer</para></listitem> 
-	</itemizedlist>
-
-	<para>
-	Click here to download the archived file <ulink 
-	url="ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE">ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE</ulink>
-	</para>
-
-	<para>
-	The Windows NT 4.0 version of the 'User Manager for 
-	Domains' and 'Server Manager' are available from Microsoft via ftp 
-	from <ulink url="ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE">ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE</ulink>
-	</para>
-</listitem>
-</itemizedlist>
-
-</sect1>
-
-
-
 <!-- **********************************************************
 
      Getting Help
@@ -1095,37 +978,28 @@ general SMB topics such as browsing.</para>
 <sect1>
 <title>Domain Control for Windows 9x/ME</title>
 
-<note>
-<para>
-The following section contains much of the original 
-DOMAIN.txt file previously included with Samba.  Much of 
-the material is based on what went into the book <emphasis>Special 
-Edition, Using Samba</emphasis>, by Richard Sharpe.
-</para>
-</note>
-
 <para>
 A domain and a workgroup are exactly the same thing in terms of network
 browsing.  The difference is that a distributable authentication
 database is associated with a domain, for secure login access to a
 network.  Also, different access rights can be granted to users if they
-successfully authenticate against a domain logon server (NT server and 
-other systems based on NT server support this, as does at least Samba TNG now).
+successfully authenticate against a domain logon server. Samba-3 does this
+now in the same way that MS Windows NT/2K.
 </para>
 
 <para>
 The SMB client logging on to a domain has an expectation that every other
 server in the domain should accept the same authentication information.
-Network browsing functionality of domains and workgroups is
-identical and is explained in BROWSING.txt. It should be noted, that browsing
-is totally orthogonal to logon support.
+Network browsing functionality of domains and workgroups is identical and
+is explained in this documentation under the browsing discussions.
+It should be noted, that browsing is totally orthogonal to logon support.
 </para>
 
 <para>
 Issues related to the single-logon network model are discussed in this
 section.  Samba supports domain logons, network logon scripts, and user
 profiles for MS Windows for workgroups and MS Windows 9X/ME clients
-which will be the focus of this section.
+which are the focus of this section.
 </para>
 
 
@@ -1286,593 +1160,5 @@ for its domain.
 </warning>
 
 </sect2>
-
-
-<sect2>
-<title>Configuration Instructions:	Setting up Roaming User Profiles</title>
-
-<warning>
-<para>
-<emphasis>NOTE!</emphasis> Roaming profiles support is different 
-for Win9X and WinNT.
-</para>
-</warning>
-
-<para>
-Before discussing how to configure roaming profiles, it is useful to see how
-Win9X and WinNT clients implement these features.
-</para>
-
-<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 user's home share. This means that Win9X 
-profiles are restricted to being in the user's home directory.
-</para>
-
-
-<para>
-WinNT clients send a NetSAMLogon RPC request, which contains many fields, 
-including a separate field for the location of the user's profiles. 
-This means that support for profiles is different for Win9X and WinNT.
-</para>
-
-
-
-<sect3>
-<title>Windows NT Configuration</title>
-
-<para>
-To support WinNT clients, in the [global] section of smb.conf set the
-following (for example):
-</para>
-
-<para><programlisting>
-logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath
-</programlisting></para>
-
-<para>
-The default for this option is \\%N\%U\profile, namely
-\\sambaserver\username\profile.  The \\N%\%U service is created
-automatically by the [homes] service.
-If you are using a samba server for the profiles, you _must_ make the
-share specified in the logon path browseable. 
-</para>
-
-<note>
-<para>
-[lkcl 26aug96 - we have discovered a problem where Windows clients can
-maintain a connection to the [homes] share in between logins.  The
-[homes] share must NOT therefore be used in a profile path.]
-</para>
-</note>
-
-</sect3>
-
-
-<sect3>
-<title>Windows 9X Configuration</title>
-
-<para>
-To support Win9X clients, you must use the "logon home" parameter. Samba has
-now been fixed so that "net use/home" now works as well, and it, too, relies
-on the "logon home" parameter.
-</para>
-
-<para>
-By using the logon home parameter, you are restricted to putting Win9X 
-profiles in the user's home directory.   But wait! There is a trick you 
-can use. If you set the following in the [global] section of your 
-smb.conf file:
-</para>
-
-<para><programlisting>
-logon home = \\%L\%U\.profiles
-</programlisting></para>
-
-<para>
-then your Win9X clients will dutifully put their clients in a subdirectory
-of your home directory called .profiles (thus making them hidden).
-</para>
-
-<para>
-Not only that, but 'net use/home' will also work, because of a feature in 
-Win9X. It removes any directory stuff off the end of the home directory area
-and only uses the server and share portion. That is, it looks like you
-specified \\%L\%U for "logon home".
-</para>
-
-
-</sect3>
-
-
-<sect3>
-<title>Win9X and WinNT Configuration</title>
-
-<para>
-You can support profiles for both Win9X and WinNT clients by setting both the
-"logon home" and "logon path" parameters. For example:
-</para>
-
-<para><programlisting>
-logon home = \\%L\%U\.profiles
-logon path = \\%L\profiles\%U
-</programlisting></para>
-
-<note>
-<para>
-I have not checked what 'net use /home' does on NT when "logon home" is
-set as above.
-</para>
-</note>
-</sect3>
-
-
-
-<sect3>
-<title>Windows 9X Profile Setup</title>
-
-<para>
-When a user first logs in on Windows 9X, the file user.DAT is created,
-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 preserve case = yes" and
-"case sensitive = no" in order to maintain capital letters in shortcuts
-in any of the profile folders.
-</para>
-
-
-<para>
-The user.DAT file contains all the user's preferences.  If you wish to
-enforce a set of preferences, rename their user.DAT file to user.MAN,
-and deny them write access to this file.
-</para>
-
-<orderedlist>
-<listitem>
-	<para>
-	On the Windows 95 machine, go to Control Panel | Passwords and
-	select the User Profiles tab.  Select the required level of
-	roaming preferences.  Press OK, but do _not_ allow the computer
-	to reboot.
-	</para>
-</listitem>
-
-
-<listitem>
-	<para>
-	On the Windows 95 machine, go to Control Panel | Network |
-	Client for Microsoft Networks | Preferences.  Select 'Log on to
-	NT Domain'.  Then, ensure that the Primary Logon is 'Client for
-	Microsoft Networks'.  Press OK, and this time allow the computer
-	to reboot.
-	</para>
-</listitem>
-
-</orderedlist>
-
-<para>
-Under Windows 95, Profiles are downloaded from the Primary Logon.
-If you have the Primary Logon as 'Client for Novell Networks', then
-the profiles and logon script will be downloaded from your Novell
-Server.  If you have the Primary Logon as 'Windows Logon', then the
-profiles will be loaded from the local machine - a bit against the
-concept of roaming profiles, if you ask me.
-</para>
-
-<para>
-You will now find that the Microsoft Networks Login box contains
-[user, password, domain] instead of just [user, password].  Type in
-the samba server's domain name (or any other domain known to exist,
-but bear in mind that the user will be authenticated against this
-domain and profiles downloaded from it, if that domain logon server
-supports it), user name and user's password.
-</para>
-
-<para>
-Once the user has been successfully validated, the Windows 95 machine
-will inform you that 'The user has not logged on before' and asks you
-if you wish to save the user's preferences?  Select 'yes'.
-</para>
-
-<para>
-Once the Windows 95 client comes up with the desktop, you should be able
-to examine the contents of the directory specified in the "logon path"
-on the samba server and verify that the "Desktop", "Start Menu",
-"Programs" and "Nethood" folders have been created.
-</para>
-
-<para>
-These folders will be cached locally on the client, and updated when
-the user logs off (if you haven't made them read-only by then :-).
-You will find that if the user creates further folders or short-cuts,
-that the client will merge the profile contents downloaded with the
-contents of the profile directory already on the local client, taking
-the newest folders and short-cuts from each set.
-</para>
-
-<para>
-If you have made the folders / files read-only on the samba server,
-then you will get errors from the w95 machine on logon and logout, as
-it attempts to merge the local and the remote profile.  Basically, if
-you have any errors reported by the w95 machine, check the Unix file
-permissions and ownership rights on the profile directory contents,
-on the samba server.
-</para>
-
-<para>
-If you have problems creating user profiles, you can reset the user's
-local desktop cache, as shown below.  When this user then next logs in,
-they will be told that they are logging in "for the first time".
-</para>
-
-<orderedlist>
-<listitem>
-	<para>
-	instead of logging in under the [user, password, domain] dialog,
-	press escape.
-	</para>
-</listitem>
-
-<listitem>
-	<para>
-	run the regedit.exe program, and look in:
-	</para>
-	
-	<para>
-	HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList
-	</para>
-
-	<para>
-	you will find an entry, for each user, of ProfilePath.  Note the
-	contents of this key (likely to be c:\windows\profiles\username),
-	then delete the key ProfilePath for the required user.
-	</para>
-
-	<para>
-	[Exit the registry editor].
-	</para>
-</listitem>
-
-<listitem>
-	<para>
-	<emphasis>WARNING</emphasis> - before deleting the contents of the 
-	directory listed in
-   the ProfilePath (this is likely to be c:\windows\profiles\username),
-   ask them if they have any important files stored on their desktop
-   or in their start menu.  delete the contents of the directory
-   ProfilePath (making a backup if any of the files are needed).
-	</para>
-
-	<para>
-   This will have the effect of removing the local (read-only hidden
-   system file) user.DAT in their profile directory, as well as the
-   local "desktop", "nethood", "start menu" and "programs" folders.
-	</para>
-</listitem>
-
-<listitem>
-	<para>
-	search for the user's .PWL password-caching file in the c:\windows
-	directory, and delete it.
-	</para>
-</listitem>
-
-
-<listitem>
-	<para>
-	log off the windows 95 client.
-	</para>
-</listitem>
-
-<listitem>
-	<para>
-	check the contents of the profile path (see "logon path" described
-	above), and delete the user.DAT or user.MAN file for the user,
-	making a backup if required.  
-	</para>
-</listitem>
-
-</orderedlist>
-
-<para>
-If all else fails, increase samba's debug log levels to between 3 and 10,
-and / or run a packet trace program such as tcpdump or netmon.exe, and
-look for any error reports.
-</para>
-
-<para>
-If you have access to an NT server, then first set up roaming profiles
-and / or netlogons on the NT server.  Make a packet trace, or examine
-the example packet traces provided with NT server, and see what the
-differences are with the equivalent samba trace.
-</para>
-
-</sect3>
-
-
-<sect3>
-<title>Windows NT Workstation 4.0</title>
-
-<para>
-When a user first logs in to a Windows NT Workstation, the profile
-NTuser.DAT is created.  The profile location can be now specified
-through the "logon path" parameter.  
-</para>
-
-<note>
-<para>
-[lkcl 10aug97 - i tried setting the path to
-\\samba-server\homes\profile, and discovered that this fails because
-a background process maintains the connection to the [homes] share
-which does _not_ close down in between user logins.  you have to
-have \\samba-server\%L\profile, where user is the username created
-from the [homes] share].
-</para>
-</note>
-
-<para>
-There is a parameter that is now available for use with NT Profiles:
-"logon drive".  This should be set to "h:" or any other drive, and
-should be used in conjunction with the new "logon home" parameter.
-</para>
-
-<para>
-The entry for the NT 4.0 profile is a _directory_ not a file.  The NT
-help on profiles mentions that a directory is also created with a .PDS
-extension.  The user, while logging in, must have write permission to
-create the full profile path (and the folder with the .PDS extension)
-[lkcl 10aug97 - i found that the creation of the .PDS directory failed,
-and had to create these manually for each user, with a shell script.
-also, i presume, but have not tested, that the full profile path must
-be browseable just as it is for w95, due to the manner in which they
-attempt to create the full profile path: test existence of each path
-component; create path component].
-</para>
-
-<para>
-In the profile directory, NT creates more folders than 95.  It creates
-"Application Data" and others, as well as "Desktop", "Nethood",
-"Start Menu" and "Programs".  The profile itself is stored in a file
-NTuser.DAT.  Nothing appears to be stored in the .PDS directory, and
-its purpose is currently unknown.
-</para>
-
-<para>
-You can use the System Control Panel to copy a local profile onto
-a samba server (see NT Help on profiles: it is also capable of firing
-up the correct location in the System Control Panel for you).  The
-NT Help file also mentions that renaming NTuser.DAT to NTuser.MAN
-turns a profile into a mandatory one.
-</para>
-
-<note>
-<para>
-[lkcl 10aug97 - i notice that NT Workstation tells me that it is
-downloading a profile from a slow link.  whether this is actually the
-case, or whether there is some configuration issue, as yet unknown,
-that makes NT Workstation _think_ that the link is a slow one is a
-matter to be resolved].
-</para>
-
-<para>
-[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
-workstation to access the samba server using LAN manager encrypted
-passwords, without the user intervention normally required by NT
-workstation for clear-text passwords].
-</para>
-
-<para>
-[lkcl 25aug97 - more comments received about NT profiles: the case of
-the profile _matters_.  the file _must_ be called NTuser.DAT or, for
-a mandatory profile, NTuser.MAN].
-</para>
-</note>
-
-</sect3>
-
-
-<sect3>
-<title>Windows NT Server</title>
-
-<para>
-There is nothing to stop you specifying any path that you like for the
-location of users' profiles.  Therefore, you could specify that the
-profile be stored on a samba server, or any other SMB server, as long as
-that SMB server supports encrypted passwords.
-</para>
-
-</sect3>
-
-
-<sect3>
-<title>Sharing Profiles between W95 and NT Workstation 4.0</title>
-
-<warning>
-<title>Potentially outdated or incorrect material follows</title>
-<para>
-I think this is all bogus, but have not deleted it. (Richard Sharpe)
-</para>
-</warning>
-
-<para>
-The default logon path is \\%N\%U.  NT Workstation will attempt to create
-a directory "\\samba-server\username.PDS" if you specify the logon path
-as "\\samba-server\username" with the NT User Manager.  Therefore, you
-will need to specify (for example) "\\samba-server\username\profile".
-NT 4.0 will attempt to create "\\samba-server\username\profile.PDS", which
-is more likely to succeed.
-</para>
-
-<para>
-If you then want to share the same Start Menu / Desktop with W95, you will
-need to specify "logon path = \\samba-server\username\profile" [lkcl 10aug97
-this has its drawbacks: i created a shortcut to telnet.exe, which attempts
-to run from the c:\winnt\system32 directory.  this directory is obviously
-unlikely to exist on a Win95-only host].
-</para>
-
-<para>
-
-If you have this set up correctly, you will find separate user.DAT and
-NTuser.DAT files in the same profile directory.
-</para>
-
-<note>
-<para>
-[lkcl 25aug97 - there are some issues to resolve with downloading of
-NT profiles, probably to do with time/date stamps.  i have found that
-NTuser.DAT is never updated on the workstation after the first time that
-it is copied to the local workstation profile directory.  this is in
-contrast to w95, where it _does_ transfer / update profiles correctly].
-</para>
-</note>
-
-</sect3>
-
-</sect2>
 </sect1>
-
-
-<!-- **********************************************************
-
-     Appendix - DOMAIN_CONTROL.txt
-
-*************************************************************** -->
-
-<sect1>
-<title>
-DOMAIN_CONTROL.txt : Windows NT Domain Control &amp; Samba
-</title>
-
-<warning>
-	<title>Possibly Outdated Material</title>
-
-	<para>
-	This appendix was originally authored by John H Terpstra of 
-	the Samba Team and is included here for posterity.
-	</para>
-</warning>
-
-
-<para>
-<emphasis>NOTE :</emphasis> 
-The term "Domain Controller" and those related to it refer to one specific
-method of authentication that can underly an SMB domain. Domain Controllers
-prior to Windows NT Server 3.1 were sold by various companies and based on 
-private extensions to the LAN Manager 2.1 protocol. Windows NT introduced
-Microsoft-specific ways of distributing the user authentication database.
-See DOMAIN.txt for examples of how Samba can participate in or create
-SMB domains based on shared authentication database schemes other than the 
-Windows NT SAM.
-</para>
-
-<para>
-Windows NT Server can be installed as either a plain file and print server
-(WORKGROUP workstation or server) or as a server that participates in Domain
-Control (DOMAIN member, Primary Domain controller or Backup Domain controller).
-The same is true for OS/2 Warp Server, Digital Pathworks and other similar
-products, all of which can participate in Domain Control along with Windows NT.
-</para>
-
-<para>
-To many people these terms can be confusing, so let's try to clear the air.
-</para>
-
-<para>
-Every Windows NT system (workstation or server) has a registry database.
-The registry contains entries that describe the initialization information
-for all services (the equivalent of Unix Daemons) that run within the Windows
-NT environment. The registry also contains entries that tell application
-software where to find dynamically loadable libraries that they depend upon.
-In fact, the registry contains entries that describes everything that anything
-may need to know to interact with the rest of the system.
-</para>
-
-<para>
-The registry files can be located on any Windows NT machine by opening a
-command prompt and typing:
-</para>
-
-<para>
-<prompt>C:\WINNT\></prompt> dir %SystemRoot%\System32\config
-</para>
-
-<para>
-The environment variable %SystemRoot% value can be obtained by typing:
-</para>
-
-<para>
-<prompt>C:\WINNT></prompt>echo %SystemRoot%
-</para>
-
-<para>
-The active parts of the registry that you may want to be familiar with are
-the files called: default, system, software, sam and security.
-</para>
-
-<para>
-In a domain environment, Microsoft Windows NT domain controllers participate
-in replication of the SAM and SECURITY files so that all controllers within
-the domain have an exactly identical copy of each.
-</para>
-
-<para>
-The Microsoft Windows NT system is structured within a security model that
-says that all applications and services must authenticate themselves before
-they can obtain permission from the security manager to do what they set out
-to do.
-</para>
-
-<para>
-The Windows NT User database also resides within the registry. This part of
-the registry contains the user's security identifier, home directory, group
-memberships, desktop profile, and so on.
-</para>
-
-<para>
-Every Windows NT system (workstation as well as server) will have its own
-registry. Windows NT Servers that participate in Domain Security control
-have a database that they share in common - thus they do NOT own an
-independent full registry database of their own, as do Workstations and
-plain Servers.
-</para>
-
-<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 (i.e. to ensure that the service action a user has
-requested is permitted within the limits of that user's privileges).
-</para>
-
-<para>
-The Samba team have produced a utility that can dump the Windows NT SAM into 
-smbpasswd format: see ENCRYPTION.txt for information on smbpasswd and
-/pub/samba/pwdump on your nearest Samba mirror for the utility. This 
-facility is useful but cannot be easily used to implement SAM replication
-to Samba systems.
-</para>
-
-<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. 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>
-
-<para>
-The PDC and BDCs then participate in replication of the SAM database so that
-each Domain Controlling participant will have an up to date SAM component
-within its registry.
-</para>
-
-</sect1>
-
 </chapter>
diff --git a/docs/docbook/projdoc/ServerType.sgml b/docs/docbook/projdoc/ServerType.sgml
index 41b1c0ed2f..239880160e 100644
--- a/docs/docbook/projdoc/ServerType.sgml
+++ b/docs/docbook/projdoc/ServerType.sgml
@@ -45,6 +45,13 @@ that control security mode are: "security = user" and "security = share".
 </para>
 
 <para>
+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>
+
+<para>
 Samba tends to blur the distinction a little in respect of what is
 a stand alone server. This is because the authentication database may be
 local or on a remote server, even if from the samba protocol perspective
@@ -73,7 +80,7 @@ of a domain security context. This means by definition that all user authenticat
 will be done from a centrally defined authentication regime. The authentication
 regime may come from an NT3/4 style (old domain technology) server, or it may be
 provided from an Active Directory server (ADS) running on MS Windows 2000 or later.
->/para>
+</para>
 
 <para><emphasis>
 Of course it should be clear that the authentication back end itself could be from any
diff --git a/docs/docbook/projdoc/VFS.sgml b/docs/docbook/projdoc/VFS.sgml
index 66b9be1dbd..7aa280f4ef 100644
--- a/docs/docbook/projdoc/VFS.sgml
+++ b/docs/docbook/projdoc/VFS.sgml
@@ -4,6 +4,7 @@
 	<author><firstname>Alexander</firstname><surname>Bokovoy</surname></author>
 	<author><firstname>Tim</firstname><surname>Potter</surname></author>
 	<author><firstname>Simo</firstname><surname>Sorce</surname></author>
+	<author><firstname>John H</firstname><surname>Terpstra</surname></author>
 </chapterinfo>
 <title>Stackable VFS modules</title>
 
@@ -67,6 +68,18 @@ facility.  The following operations are logged:
 </sect2>
 
 <sect2>
+<title>extd_audit</title>
+<para>
+This module is identical with the <emphasis>audit</emphasis> module above except
+that it sends audit logs to both syslog as well as the smbd log file/s. The 
+loglevel for this module is set in the smb.conf file. At loglevel = 0, only file
+and directory deletions and directory and file creations are logged. At loglevel = 1
+file opens are renames and permission changes are logged , while at loglevel = 2 file
+open and close calls are logged also.
+</para>
+</sect2>
+
+<sect2>
 <title>recycle</title>
 <para>
 A recycle-bin like modules. When used any unlink call
diff --git a/docs/docbook/projdoc/passdb.sgml b/docs/docbook/projdoc/passdb.sgml
index fa2d75bd34..7e4b9bcbd0 100644
--- a/docs/docbook/projdoc/passdb.sgml
+++ b/docs/docbook/projdoc/passdb.sgml
@@ -180,7 +180,7 @@
 			only things you can do to stop this is to use SMB encryption.
 			</member>
 
-			<member>Encrypted password support allows auto-matic share
+			<member>Encrypted password support allows automatic share
 			(resource) reconnects.</member>
 		</simplelist>
 	</sect2>
@@ -831,18 +831,6 @@ ntPassword: 878D8014606CDA29677A44EFA1353FC7
 <title>MySQL</title>
 
 <sect2>
-<title>Building</title>
-
-<para>To build the plugin, run <command>make bin/pdb_mysql.so</command>
-in the <filename>source/</filename> directory of samba distribution. 
-</para>
-
-<para>Next, copy pdb_mysql.so to any location you want. I 
-strongly recommend installing it in $PREFIX/lib or /usr/lib/samba/</para>
-
-</sect2>
-
-<sect2>
 <title>Creating the database</title>
 
 <para>
@@ -862,7 +850,7 @@ contains the correct queries to create the required tables. Use the command :
 
 <para>Add a the following to the <command>passdb backend</command> variable in your <filename>smb.conf</filename>:
 <programlisting>
-passdb backend = [other-plugins] plugin:/location/to/pdb_mysql.so:identifier [other-plugins]
+passdb backend = [other-plugins] mysql:identifier [other-plugins]
 </programlisting>
 </para>
 
@@ -978,35 +966,23 @@ Or, set 'identifier:workstations column' to :
 </sect1>
 
 <sect1>
-<title>Passdb XML plugin</title>
-
-<sect2>
-<title>Building</title>
+<title>XML</title>
 
 <para>This module requires libxml2 to be installed.</para>
 
-<para>To build pdb_xml, run: <command>make bin/pdb_xml.so</command> in 
-the directory <filename>source/</filename>. </para>
-
-</sect2>
-
-<sect2>
-<title>Usage</title>
-
 <para>The usage of pdb_xml is pretty straightforward. To export data, use:
 
-<command>pdbedit -e plugin:/usr/lib/samba/pdb_xml.so:filename</command>
+<command>pdbedit -e xml:filename</command>
 
 (where filename is the name of the file to put the data in)
 </para>
 
 <para>
 To import data, use:
-<command>pdbedit -i plugin:/usr/lib/samba/pdb_xml.so:filename -e current-pdb</command>
+<command>pdbedit -i xml:filename -e current-pdb</command>
 
 Where filename is the name to read the data from and current-pdb to put it in.
 </para>
-</sect2>
 </sect1>
 
 </chapter>
diff --git a/docs/docbook/projdoc/samba-doc.sgml b/docs/docbook/projdoc/samba-doc.sgml
index 1a2e285596..7a8c4b6d06 100644
--- a/docs/docbook/projdoc/samba-doc.sgml
+++ b/docs/docbook/projdoc/samba-doc.sgml
@@ -22,11 +22,15 @@
 <!ENTITY ADS-HOWTO SYSTEM "ADS-HOWTO.sgml">
 <!ENTITY Passdb SYSTEM "passdb.sgml">
 <!ENTITY VFS SYSTEM "VFS.sgml">
-<!ENTITY GroupProfiles SYSTEM "GroupProfiles.sgml">
 <!ENTITY SecuringSamba SYSTEM "securing-samba.sgml">
 <!ENTITY Compiling SYSTEM "Compiling.sgml">
 <!ENTITY unicode SYSTEM "unicode.sgml">
 <!ENTITY CUPS SYSTEM "CUPS-printing.sgml">
+<!ENTITY AdvancedNetworkAdmin SYSTEM "AdvancedNetworkAdmin.sgml">
+<!ENTITY PolicyMgmt SYSTEM "PolicyMgmt.sgml">
+<!ENTITY ProfileMgmt SYSTEM "ProfileMgmt.sgml">
+<!ENTITY NT4Migration SYSTEM "NT4Migration.sgml">
+<!ENTITY SWAT SYSTEM "SWAT.sgml">
 ]>
 
 <book id="Samba-HOWTO-Collection">
@@ -102,30 +106,34 @@ for various environments.
 </part>
 
 <part id="optional">
-<title>Optional configuration</title>
+<title>Advanced Configuration</title>
 <partintro>
 <title>Introduction</title>
 <para>Samba has several features that you might want or might not want to use. The chapters in this 
 part each cover one specific feature.</para>
 </partintro>
-&IntegratingWithWindows;
 &NT-Security;
-&Samba-PAM;
-&MS-Dfs-Setup;
+&GROUP-MAPPING-HOWTO;
 &PRINTER-DRIVER2;
 &CUPS;
 &WINBIND;
-&BROWSING;
+&AdvancedNetworkAdmin;
+&PolicyMgmt;
+&ProfileMgmt;
+&Samba-PAM;
 &VFS;
-&GROUP-MAPPING-HOWTO;
-&SPEED;
-&GroupProfiles;
+&MS-Dfs-Setup;
+&IntegratingWithWindows;
+&BROWSING;
 &SecuringSamba;
 &unicode;
 </part>
 
 <part id="Appendixes">
 <title>Appendixes</title>
+&SWAT;
+&NT4Migration;
+&SPEED;
 &Portability;
 &Other-Clients;
 &Compiling;
@@ -133,4 +141,4 @@ part each cover one specific feature.</para>
 &Diagnosis;
 </part>
 
-</book>
+
diff --git a/docs/docbook/projdoc/security_level.sgml b/docs/docbook/projdoc/security_level.sgml
index 00dcc6e83b..e3d7c6ac1f 100644
--- a/docs/docbook/projdoc/security_level.sgml
+++ b/docs/docbook/projdoc/security_level.sgml
@@ -8,8 +8,15 @@
 		</affiliation>
 	</author>
 </chapterinfo>
+<title>Samba as Stand-Alone Server</title
 
-<title>Samba as Stand-Alone server (User and Share security level)</title>
+<para>
+In this section the function and purpose of Samba's <emphasis>security</emphasis>
+modes are described.
+</para>
+
+<sect1>
+<Title>User and Share security level</title>
 
 <para>
 A SMB server tells the client at startup what "security level" it is
@@ -23,6 +30,9 @@ can only tell the client what is available and whether an action is
 allowed. 
 </para>
 
+<sect2>
+<title>User Level Security</title>
+
 <para>
 I'll describe user level security first, as its simpler. In user level
 security the client will send a "session setup" command directly after
@@ -53,6 +63,11 @@ maintain multiple authentication contexts in this way (WinDD is an
 example of an application that does this)
 </para>
 
+</sect2>
+
+<sect2>
+<title>Share Level Security</title>
+
 <para>
 Ok, now for share level security. In share level security the client
 authenticates itself separately for each share. It will send a
@@ -79,6 +94,11 @@ usernames". If a match is found then the client is authenticated as
 that user.
 </para>
 
+</sect2>
+
+<sect2>
+<title>Server Level Security</title>
+
 <para>
 Finally "server level" security. In server level security the samba
 server reports to the client that it is in user level security. The
@@ -113,4 +133,204 @@ That real authentication server can be another Samba server or can be a
 Windows NT server, the later natively capable of encrypted password support.
 </para>
 
+<sect3>
+<title>Configuring Samba for Seemless Windows Network 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 requests.
+</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>
+MS Windows 95 pre-service pack 1, MS Windows NT versions 3.x and version 4.0
+pre-service pack 3 will use either mode of password authentication. All
+versions of MS Windows that follow these versions no longer support plain
+text passwords by default.
+</para>
+
+<para>
+MS Windows clients have a habit of dropping network mappings that have been idle
+for 10 minutes or longer. When the user attempts to use the mapped drive
+connection that has been dropped, the client re-establishes the connection using
+a cached copy of the password.
+</para>
+
+<para>
+When Microsoft changed the default password mode, support was dropped 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
+service connection 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 needed.
+</para>
+
+<para>
+However, passwords 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>
+
+</sect3>
+<sect3>
+<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>
+
+</sect3>
+</sect2>
+
+<sect2>
+<title>Domain Level Security</title>
+
+<para>
+When samba is operating in <emphasis>security = domain</emphasis> mode this means that
+the Samba server has a domain security trust account (a machine account) and will cause
+all authentication requests to be passed through to the domain controllers.
+</para>
+
+<sect3>
+<title>Samba as 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.
+This is the default behaviour.
+</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>
+
+</sect3>
+</sect2>
+
+<sect2>
+<title>ADS Level Security</title>
+
+<para>
+For information about the configuration option please refer to the entire section entitled
+<emphasis>Samba as an ADS Domain Member.</emphasis>
+</para>
+
+</sect2>
+</sect1>
 </chapter>
diff --git a/docs/docbook/projdoc/upgrading-to-3.0.sgml b/docs/docbook/projdoc/upgrading-to-3.0.sgml
index f227556151..cd0ec2064d 100644
--- a/docs/docbook/projdoc/upgrading-to-3.0.sgml
+++ b/docs/docbook/projdoc/upgrading-to-3.0.sgml
@@ -24,16 +24,12 @@ In 3.0, the following configuration options have been removed.
 </para>
 
 <simplelist>
-<member>printer driver</member>
-<member>printer driver file</member>
-<member>printer driver location</member>
+<member>printer driver (replaced by new driver procedures) </member>
+<member>printer driver file (replaced by new driver procedures)</member>
+<member>printer driver location (replaced by new driver procedures)</member>
 <member>use rhosts</member>
 <member>postscript</member>
+<member>client code page (replaced by dos charset)</member>
 </simplelist>
-
-<para>The first three options have been replaced by new driver procedures. 
-Please read the printing documentation.</para>
-
 </sect1>
-
 </chapter>