syncing up with SAMBA_2_2

(This used to be commit 1bc58c21b15fcdb0a504d051f60e20c4e24441e6)

1 files changed, 1220 insertions, 310 deletions

diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml b/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml
index 699ba54a09..0b86bcba63 100644
--- a/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml
+++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml
@@ -8,17 +8,46 @@
 			<orgname>VA Linux Systems/Samba Team</orgname>
 			<address><email>jerry@samba.org</email></address>
 		</affiliation>
+		<firstname>David</firstname><surname>Bannon</surname>
+		<affiliation>
+			<orgname>Samba Team</orgname>
+			<address><email>dbannon@samba.org</email></address>
+		</affiliation>
+		
 	</author>
-	<pubdate> (15 Apr 2001) </pubdate>
+	<pubdate> (26 Apr 2001) </pubdate>
 </chapterinfo>
 
 <title>
-How to Configure Samba 2.2.x as a Primary Domain Controller
+How to Configure Samba 2.2 as a Primary Domain Controller
 </title>
 
 
 <!-- **********************************************************
 
+     Prerequisite Reading
+
+*************************************************************** -->
+<sect1>
+<title>Prerequisite Reading</title>
+
+<para>
+Before you continue readingin this chapter, please make sure 
+that you are comfortable with configuring basic files services
+in smb.conf and how to enable and administrate password 
+encryption in Samba.  Theses two topics are covered in the
+<ulink url="smb.conf.5.html"><filename>smb.conf(5)</filename></ulink> 
+manpage and the <ulink url="EMCRYPTION.html">Encryption chapter</ulink> 
+of this HOWTO Collection.
+</para>
+
+
+</sect1>
+
+
+
+<!-- **********************************************************
+
      Background Information
 
 *************************************************************** -->
@@ -27,44 +56,82 @@ How to Configure Samba 2.2.x as a Primary Domain Controller
 Background
 </title>
 
-<para><emphasis>Author's Note :</emphasis> This document
-is a combination of David Bannon's Samba 2.2 PDC HOWTO
-and the Samba NT Domain FAQ. Both documents are superceeded by this one.
+<note>
+<para>
+<emphasis>Author's Note :</emphasis> This document is a combination 
+of David Bannon's Samba 2.2 PDC HOWTO and the Samba NT Domain FAQ. 
+Both documents are superceeded by this one.
 </para>
+</note>
 
 <para>
 Version of Samba prior to release 2.2 had marginal capabilities to
-act as a Windows NT 4.0 Primary Domain Controller (PDC).  The following 
-functionality should work in 2.2.0:
+act as a Windows NT 4.0 Primary Domain Controller (PDC).  Beginning with 
+Samba 2.2.0, we are proud to announce official support for Windows NT 4.0 
+style domain logons from Windows NT 4.0 (through SP6) and Windows 2000 (through 
+SP1) clients.  This article outlines the steps necessary for configuring Samba 
+as a PDC.  It is necessary to have a working Samba server prior to implementing the 
+PDC functionality.  If you have not followed the steps outlined in 
+<ulink url="UNIX_INSTALL.html"> UNIX_INSTALL.html</ulink>, please make sure 
+that your server is configured correctly before proceeding.  Another good 
+resource in the <ulink url="smb.conf.5.html">smb.conf(5) man 
+page</ulink>. The following  functionality should work in 2.2:
 </para>
 
 <itemizedlist>
-	<listitem><para>domain logons for Windows NT 4.0/2000 clients</para></listitem>
+	<listitem><para>
+	domain logons for Windows NT 4.0/2000 clients.
+	</para></listitem>
 	
-	<listitem><para>placing a Windows 9x client in user level security</para></listitem>
+	<listitem><para>
+	placing a Windows 9x client in user level security
+	</para></listitem>
 	
-	<listitem><para>retrieving a list of users and groups from a Samba PDC to
-	Windows 9x/NT/2000 clients </para></listitem>
+	<listitem><para>
+	retrieving a list of users and groups from a Samba PDC to
+	Windows 9x/NT/2000 clients
+	</para></listitem>
 	
-	<listitem><para>roving user profiles</para></listitem>
+	<listitem><para>
+	roving (roaming) user profiles
+	</para></listitem>
 	
-	<listitem><para>Windows NT 4.0 style system policies</para></listitem>
+	<listitem><para>
+	Windows NT 4.0 style system policies
+	</para></listitem>
 </itemizedlist>
 
+<warning>
+	<title>Windows 2000 Service Pack 2 Clients</title>
+	<para>
+	Samba 2.2.1 is required for PDC functionality when using Windows 2000 
+	SP2 clients. 
+	</para>
+</warning>
+
+
 <para>
 The following pieces of functionality are not included in the 2.2 release:
 </para>
 
 <itemizedlist>
-	<listitem><para>Windows NT 4 domain trusts</para></listitem>
+	<listitem><para>
+	Windows NT 4 domain trusts
+	</para></listitem>
 	
-	<listitem><para>Sam replication with Windows NT 4.0 Domain Controllers
-	(i.e. a Samba PDC and a Windows NT BDC or vice versa) </para></listitem>
+	<listitem><para>
+	SAM replication with Windows NT 4.0 Domain Controllers
+	(i.e. a Samba PDC and a Windows NT BDC or vice versa) 
+	</para></listitem>
 	
-	<listitem><para>Adding users via the User Manager for Domains</para></listitem>
+	<listitem><para>
+	Adding users via the User Manager for Domains
+	</para></listitem>
 
-	<listitem><para>Acting as a Windows 2000 Domain Controller (i.e. Kerberos
-	and Active Directory)</para></listitem>
+	<listitem><para>
+	Acting as a Windows 2000 Domain Controller (i.e. Kerberos and 
+	Active Directory)
+	</para></listitem>
 </itemizedlist>
 
 <para>
@@ -75,19 +142,6 @@ from NT4 domain logons and has been officially supported for some
 time.
 </para>
 
-<para>
-Beginning with Samba 2.2.0, we are proud to announce official 
-support for Windows NT 4.0 style domain logons from Windows NT
-4.0 and Windows 2000 (including SP1) clients.  This article 
-outlines the steps necessary for configuring Samba as a PDC.
-Note that it is necessary to have a working Samba server
-prior to implementing the PDC functionality.  If you have not 
-followed the steps outlined in <ulink url="UNIX_INSTALL.html">
-UNIX_INSTALL.html</ulink>, please make sure that your server 
-is configured correctly before proceeding.  Another good 
-resource in the <ulink url="smb.conf.5.html">smb.conf(5) man 
-page</ulink>.
-</para>
 
 <para>
 Implementing a Samba PDC can basically be divided into 2 broad
@@ -95,11 +149,14 @@ steps.
 </para>
 
 <orderedlist numeration="Arabic">
-	<listitem><para>Configuring the Samba Domain Controller
+	<listitem><para>
+	Configuring the Samba PDC
 	</para></listitem>
 	
-	<listitem><para>Creating machine trust accounts
-	and joining clients to the domain</para></listitem>
+	<listitem><para>
+	Creating machine trust accounts	and joining clients 
+	to the domain
+	</para></listitem>
 </orderedlist>
 
 <para>
@@ -164,7 +221,7 @@ Here is an example smb.conf for acting as a PDC:
     <ulink url="smb.conf.5.html#LOGONHOME">logon home</ulink> = \\homeserver\%u
     
     ; specify a generic logon script for all users
-    ; this is a relative path to the [netlogon] share
+    ; this is a relative **DOS** path to the [netlogon] share
     <ulink url="smb.conf.5.html#LOGONSCRIPT">logon script</ulink> = logon.cmd
 
 ; necessary share for domain controller
@@ -182,28 +239,32 @@ Here is an example smb.conf for acting as a PDC:
 </programlisting></para>
 
 <para>
-There are a couple of points to emphasize in the above
-configuration.
+There are a couple of points to emphasize in the above configuration.
 </para>
 
 <itemizedlist>
-	<listitem><para>encrypted passwords must be enabled.
-	For more details on how to do this, refer to 
-	<ulink url="ENCRYPTION.html">ENCRYPTION.html</ulink>.
+	<listitem><para>
+	Encrypted passwords must be enabled.  For more details on how 
+	to do this, refer to <ulink url="ENCRYPTION.html">ENCRYPTION.html</ulink>.
 	</para></listitem>
 	
-	<listitem><para>The server must support domain logons
-	and a <filename>[netlogon]</filename> share</para></listitem>
+	<listitem><para>
+	The server must support domain logons and a
+	<filename>[netlogon]</filename> share
+	</para></listitem>
 	
-	<listitem><para>The server must be the domain master browser
-	in order for Windows client to locate the server as a DC.</para>
-	</listitem>
+	<listitem><para>
+	The server must be the domain master browser in order for Windows 
+	client to locate the server as a DC.  Please refer to the various 
+	Network Browsing documentation included with this distribution for 
+	details.
+	</para></listitem>
 </itemizedlist>    
 
 <para>
 As Samba 2.2 does not offer a complete implementation of group mapping between 
 Windows NT groups and UNIX groups (this is really quite complicated to explain 
-in a short space), you should refer to the <ulink url="smb.conf.5.html#DOMAINADMONUSERS">domain 
+in a short space), you should refer to the <ulink url="smb.conf.5.html#DOMAINADMINUSERS">domain 
 admin users</ulink> and <ulink url="smb.conf.5.html#DOMAINADMINGROUP">domain 
 admin group</ulink> smb.conf parameters for information of creating a Domain Admins 
 style accounts.
@@ -217,24 +278,28 @@ style accounts.
 to the Domain</title>
 
 <para>
-First you must understand what a machine trust account is and what 
-it is used for.
-</para>
-
-<para>
-A machine trust account is a user account owned by a computer.  
+A machine trust account is a samba user account owned by a computer.  
 The account password acts as the shared secret for secure 
-communication with the Domain Controller.  Hence the reason that
-a Windows 9x host is never a true member of a domain because
-it does not posses a machine trust account and thus has no shared
-secret with the DC.
+communication with the Domain Controller.  This is a security feature
+to prevent an unauthorized machine with the same netbios name from 
+joining the domain and gaining access to domain user/group accounts.  
+Hence a Windows 9x host is never a true member of a domain because it does 
+not posses a machine trust account, and thus has no shared secret with the DC.
 </para>
 
 <para>
 On a Windows NT PDC, these machine trust account passwords are stored
-in the registry.  A Samba PDC stores these accounts in he same location
+in the registry.  A Samba PDC stores these accounts in the same location
 as user LanMan and NT password hashes (currently <filename>smbpasswd</filename>).
-However, machine trust accounts only possess the NT password hash.
+However, machine trust accounts only possess and use the NT password hash.
+</para>
+
+<para>
+Because Samba requires machine accounts to possess a UNIX uid from
+which an Windows NT SID can be generated, all of these accounts
+must have an entry in <filename>/etc/passwd</filename> and smbpasswd.  
+Future releases will alleviate the need to create 
+<filename>/etc/passwd</filename> entries.  
 </para>
 
 <para>
@@ -242,25 +307,35 @@ There are two means of creating machine trust accounts.
 </para>
 
 <itemizedlist>
-	<listitem><para>Manual creation before joining the client
-	to the domain.  In this case, the password is set to a known
-	value -- the lower case of the machine's netbios name.</para></listitem>
+	<listitem><para>
+	Manual creation before joining the client to the domain.  In this case, 
+	the password is set to a known value -- the lower case of the 
+	machine's netbios name.
+	</para></listitem>
 	
-	<listitem><para>Creation of the account at the time of 
-	joining the domain.  In this case, the session key of the 
-	administrative account used to join the client to the domain acts
-	as an encryption key for setting the password to a random value.</para>
-	</listitem>
+	<listitem><para>
+	Creation of the account at the time of joining the domain.  In 
+	this case, the session key of the administrative account used to join 
+	the client to the domain acts as an encryption key for setting the 
+	password to a random value (This is the recommended method).
+	</para></listitem>
 </itemizedlist>
 
+<sect2>
+<title>Manually creating machine trust accounts</title>
+
 <para>
-Because Samba requires machine accounts to possess a UNIX uid from
-which an Windows NT SID can be generated, all of these accounts
-will have an entry in <filename>/etc/passwd</filename> and smbpasswd.  
-Future releases will alleviate the need to create 
-<filename>/etc/passwd</filename> entries.
+The first step in creating a machine trust account by hand is to 
+create an entry for the machine in /etc/passwd.  This can be done 
+using <command>vipw</command> or any 'add userr' command which is normally 
+used to create new UNIX accounts.  The following is an example for a Linux 
+based Samba server:
 </para>
 
+<para>
+<prompt>root# </prompt>/usr/sbin/useradd -g 100 -d /dev/null -c <replaceable>
+machine_nickname</replaceable> -m -s /bin/false <replaceable>machine_name</replaceable>$
+</para>
 
 <para>
 The <filename>/etc/passwd</filename> entry will list the machine name 
@@ -270,39 +345,60 @@ home directory. For example a machine called 'doppy' would have an
 </para>
 
 <para><programlisting>
-doppy$:x:505:501:NTMachine:/dev/null:/bin/false
+doppy$:x:505:501:<replaceable>machine_nickname</replaceable>:/dev/null:/bin/false
 </programlisting></para>
 
 <para>
-If you are manually creating the machine accounts, it is necessary
-to add the <filename>/etc/passwd</filename> (or NIS passwd
-map) entry prior to adding the <filename>smbpasswd</filename>
-entry.  The following command will create a new machine account
-ready for use.
+Above, <replaceable>machine_nickname</replaceable> can be any descriptive name for the
+pc i.e. BasementComputer. The <replaceable>machine_name</replaceable> absolutely must be 
+the netbios name of the pc to be added to the domain.  The "$" must append the netbios
+name of the pc or samba will not recognize this as a machine account
 </para>
 
+
 <para>
-<prompt>root# </prompt> smbpasswd -a -m <replaceable>machine_name</replaceable>
+Now that the UNIX account has been created, the next step is to create 
+the smbpasswd entry for the machine containing the well known initial 
+trust account password.  This can be done using the <ulink 
+url="smbpasswd.6.html"><command>smbpasswd(8)</command></ulink> command 
+as shown here:
 </para>
 
 <para>
-where <replaceable>machine_name</replaceable> is the machine's netbios
-name.
+<prompt>root# </prompt> smbpasswd -a -m <replaceable>machine_name</replaceable>
 </para>
 
 <para>
-<emphasis>If you manually create a machine account, immediately join
-the client to the domain.</emphasis>  An open account like this
-can allow intruders to gain access to user account information
-in your domain.
+where <replaceable>machine_name</replaceable> is the machine's netbios
+name. 
 </para>
 
+<warning>
+	<title>Join the client to the domain immediately</title>
+
+	<para>
+	Manually creating a machine trust account using this method is the 
+	equivalent of creating a machine account on a Windows NT PDC using 
+	the "Server Manager".  From the time at which the account is created
+	to the time which th client joins the domain and changes the password,
+	your domain is vulnerable to an intruder joining your domain using a
+	a machine with the same netbios name.  A PDC inherently trusts
+	members of the domain and will serve out a large degree of user 
+	information to such clients.  You have been warned!
+	</para>
+</warning>
+</sect2>
+
+
+<sect2>
+<title>Creating machine trust accounts "on the fly"</title>
+
 <para>
-The second way of creating machine trust accounts is to add
-them on the fly at the time the client is joined to the domain.
-You will need to include a value for the 
-<ulink url="smb.conf.5.html#ADDUSERSCRIPT">add user script</ulink>
-parameter.  Below is an example I use on a RedHat 6.2 Linux system.
+The second, and most recommended way of creating machine trust accounts 
+is to create them as needed at the time the client is joined to 
+the domain.  You will need to include a value for the <ulink 
+url="smb.conf.5.html#ADDUSERSCRIPT">add user script</ulink>
+parameter.  Below is an example from a RedHat 6.2 Linux system.
 </para>
 
 <para><programlisting>
@@ -310,13 +406,13 @@ add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u
 </programlisting></para>
 
 <para>
-In Samba 2.2.0, <emphasis>only the root account</emphasis> can be used to create
-machine accounts on the fly like this.  Therefore, it is required
-to create an entry in smbpasswd for <emphasis>root</emphasis>.
-The password <emphasis>SHOULD</emphasis> be set to s different
-password that the associated <filename>/etc/passwd</filename>
-entry for security reasons.
+In Samba 2.2.1, <emphasis>only the root account</emphasis> can be used to create
+machine accounts like this.  Therefore, it is required to create 
+an entry in smbpasswd for <emphasis>root</emphasis>.  The password 
+<emphasis>SHOULD</emphasis> be set to s different password that the 
+associated <filename>/etc/passwd</filename> entry for security reasons.
 </para>
+</sect2>
 </sect1>
 
 <!-- **********************************************************
@@ -330,108 +426,145 @@ entry for security reasons.
 
 <para>
 </para>
+<itemizedlist>
+<listitem>
+	<para>
+	<emphasis>I cannot include a '$' in a machine name.</emphasis>
+	</para>
+    
+	<para>
+	A 'machine name' in (typically) <filename>/etc/passwd</> 	
+	of the machine name with a '$' appended. FreeBSD (and other BSD 
+	systems ?) won't create a user with a '$' in their name.
+	</para>
 
-<para>
-<emphasis>I cannot include a '$' in a machine name.</emphasis>
-</para>
-
-<para>
-A 'machine name' in (typically) <filename>/etc/passwd</> 	
-of the machine name with a '$' appended. FreeBSD (and other BSD 
-systems ?) won't create a user with a '$' in their name.
-</para>
+	<para>
+	The problem is only in the program used to make the entry, once 
+	made, it works perfectly. So create a user without the '$' and 
+	use <command>vipw</> to edit the entry, adding the '$'. Or create 
+	the whole entry with vipw if you like, make sure you use a 
+	unique uid !
+	</para>
+</listitem>
+  
+<listitem>
+	<para>
+	<emphasis>I get told "You already have a connection to the Domain...." 
+	or "Cannot join domain, the credentials supplied conflict with an 
+	existing set.." when creating a machine account.</emphasis>
+	</para>
 
-<para>
-The problem is only in the program used to make the entry, once 
-made, it works perfectly. So create a user without the '$' and 
-use <command>vipw</> to edit the entry, adding the '$'. Or create 
-the whole entry with vipw if you like, make sure you use a 
-unique uid !
-</para>
+	<para>
+	This happens if you try to create a machine account from the 
+	machine itself and already have a connection (e.g. mapped drive) 
+	to a share (or IPC$) on the Samba PDC.  The following command
+	will remove all network drive connections:
+	</para>
 
+	<para>
+	<prompt>C:\WINNT\></prompt> <command>net use * /d</command>
+	</para>
 
-<para>
-<emphasis>I get told "You already have a connection to the Domain...." 
-when creating a machine account.</emphasis>
-</para>
+	<para>
+	Further, if the machine is a already a 'member of a workgroup' that 
+	is the same name as the domain you are joining (bad idea) you will 
+	get this message.  Change the workgroup name to something else, it 
+	does not matter what, reboot, and try again.
+	</para>
+</listitem>
 
-<para>
-This happens if you try to create a machine account from the 
-machine itself and use a user name that does not work (for whatever 
-reason) and then try another (possibly valid) user name.
-Exit out of the network applet to close the initial connection 
-and try again.
-</para>
+<listitem>
+	<para>
+	<emphasis>The system can not log you on (C000019B)....</emphasis>
+	</para>
 
-<para>
-Further, if the machine is a already a 'member of a workgroup' that 
-is the same name as the domain you are joining (bad idea) you will 
-get this message.  Change the workgroup name to something else, it 
-does not matter what, reboot, and try again.
-</para>
+	<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 
+	system administrator" when attempting to logon.
+	</para>
 
-<para>
-<emphasis>I get told "Cannot join domain, the credentials supplied 
-conflict with an existing set.."</emphasis>
-</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.
+	</para>
+</listitem>
 
-<para>
-This is the same basic problem as mentioned above, "You already 
-have a connection..."
-</para>
+<listitem>
+	<para>
+	<emphasis>The machine account for this computer either does not 
+	exist or is not accessible.</emphasis>
+	</para>
 
-<para>
-<emphasis>
-"The system can not log you on (C000019B)...."</emphasis>
-</para>
+	<para>
+	When I try to join the domain I get the message "The machine account 
+	for this computer either does not exist or is not accessible". Whats 
+	wrong?
+	</para>
 
-<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 
-system administrator" when attempting to logon.
-</para>
+	<para>
+	This problem is caused by the PDC not having a suitable machine account. 
+	If you are using the <parameter>add user script</parameter> method to create 
+	accounts then this would indicate that it has not worked. Ensure the domain 
+	admin user system is working.
+	</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.
-</para> 
+	<para>
+	Alternatively if you are creating account entries manually then they 
+	have not been created correctly. Make sure that you have the entry 
+	correct for the machine account in smbpasswd file on the Samba PDC. 
+	If you added the account using an editor rather than using the smbpasswd 
+	utility, make sure that the account name is the machine netbios name 
+	with a '$' appended to it ( ie. computer_name$ ). There must be an entry 
+	in both /etc/passwd and the smbpasswd file. Some people have reported 
+	that inconsistent subnet masks between the Samba server and the NT 
+	client have caused this problem.   Make sure that these are consistent 
+	for both client and server.
+	</para>
+</listitem>
 
+<listitem>
+	<para>
+	<emphasis>When I attempt to login to a Samba Domain from a NT4/W2K workstation,
+	I get a message about my account being disabled.</emphasis>
+	</para>
 
-<para>
-<emphasis>"The machine account for this computer either does not 
-exist or is not accessible."</emphasis>
-</para>
+	<para>
+	This problem is caused by a PAM related bug in Samba 2.2.0.  This bug is 
+	fixed in 2.2.1.  Other symptoms could be unaccessible shares on 
+	NT/W2K member servers in the domain or the following error in your smbd.log:
+	passdb/pampass.c:pam_account(268) PAM: UNKNOWN ERROR for User: %user%
+	</para>
+ 
+	<para>
+	At first be ensure to enable the useraccounts with <command>smbpasswd -e 
+	%user%</command>, this is normaly done, when you create an account.
+	</para>
 
-<para>
-When I try to join the domain I get the message "The machine account 
-for this computer either does not exist or is not accessible". Whats 
-wrong ?
-</para>
+	<para>
+	In order to work around this problem in 2.2.0, configure the 
+	<parameter>account</parameter> control flag in 
+	<filename>/etc/pam.d/samba</filename> file as follows:
+	</para> 
 
-<para>
-This problem is caused by the PDC not having a suitable machine account. 
-If you are using the <command>add user script =</> method to create 
-accounts then this would indicate that it has not worked. Ensure the domain 
-admin user system is working.
-</para>
+	<para><programlisting>
+	account required        pam_permit.so
+	</programlisting></para>
 
-<para>
-Alternatively if you are creating account entries manually then they 
-have not been created correctly. Make sure that you have the entry 
-correct for the machine account in smbpasswd file on the Samba PDC. 
-If you added the account using an editor rather than using the smbpasswd 
-utility, make sure that the account name is the machine netbios name 
-with a '$' appended to it ( ie. computer_name$ ). There must be an entry 
-in both /etc/passwd and the smbpasswd file. Some people have reported 
-that inconsistent subnet masks between the Samba server and the NT 
-client have caused this problem.   Make sure that these are consistent 
-for both client and server.
-</para>
+	<para>
+	If you want to remain backward compatibility to samba 2.0.x use
+	<filename>pam_permit.so</filename>, it's also possible to use 
+	<filename>pam_pwdb.so</filename>. There are some bugs if you try to 
+	use <filename>pam_unix.so</filename>, if you need this, be ensure to use
+	the most recent version of this file.
+	</para>
+</listitem>
+</itemizedlist>
 
 </sect1>
 
@@ -460,89 +593,98 @@ Profiles and Policies in Windows NT 4.0</ulink> available from Microsoft.
 Here are some additional details:
 </para>
 
-<para>
-<emphasis>What about Windows NT Policy Editor ?</emphasis>
-</para>
+<itemizedlist>
 
-<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</> and <filename>winnt.adm</>. It is convenient
-to put the two *.adm files in <filename>c:\winnt\inf</> which is where
-the binary will look for them unless told otherwise. Note also that that 
-directory is 'hidden'.
-</para>
+<listitem>
+	<para>
+	<emphasis>What about Windows NT Policy Editor ?</emphasis>
+	</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>, ie thats <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>
+	<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</> and <filename>winnt.adm</>. It is convenient
+	to put the two *.adm files in <filename>c:\winnt\inf</> 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>, 
+	ie thats <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>
 
-<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> 
+<listitem>
+	<para>
+	<emphasis>Can Win95 do Policies ?</emphasis>
+	</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>
+	<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>
-<emphasis>How do I get 'User Manager' and 'Server Manager'</emphasis>
-</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>
 
-<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>
+<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> 
+	<itemizedlist>
+		<listitem><para>Server Manager</para></listitem> 
 		
-	<listitem><para>User Manager for Domains</para></listitem> 
+		<listitem><para>User Manager for Domains</para></listitem> 
 
-	<listitem><para>Event Viewer</para></listitem> 
-</itemizedlist>
+		<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>
+	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>
+	<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>
 
@@ -564,12 +706,14 @@ of mailing lists, RFC's and documentation.  The docs that come
 with the samba distribution contain very good explanations of 
 general SMB topics such as browsing.</para> 
 
-<para>
-<emphasis>What are some diagnostics tools I can use to debug the domain logon 
-process and where can I	find them?</emphasis>
-</para>
+<itemizedlist>
+<listitem>
+	<para>
+	<emphasis>What are some diagnostics tools I can use to debug the domain logon 
+	process and where can I	find them?</emphasis>
+	</para>
 
-    <para>
+   <para>
 	One of the best diagnostic tools for debugging problems is Samba itself.  
 	You can use the -d option for both smbd and nmbd to specifiy what 
 	'debug level' at which to run.  See the man pages on smbd, nmbd  and 
@@ -601,9 +745,9 @@ process and where can I	find them?</emphasis>
 		<listitem><para>smbclient -L //{netbios name of server}</para></listitem>
 	</itemizedlist>
     
-    <para>
+	<para>
 	An SMB enabled version of tcpdump is available from 
-    <ulink url="http://www.tcpdump.org/">http://www.tcpdup.org/</ulink>.
+	<ulink url="http://www.tcpdump.org/">http://www.tcpdup.org/</ulink>.
 	Ethereal, another good packet sniffer for UNIX and Win32
 	hosts, can be downloaded from <ulink 
 	url="http://www.ethereal.com/">http://www.ethereal.com</ulink>.
@@ -620,11 +764,15 @@ process and where can I	find them?</emphasis>
 	local subnet.  Be aware that Ethereal can read and write netmon 
 	formatted files.
 	</para>
+</listitem>
+
+
+<listitem>
+	<para>
+	<emphasis>How do I install 'Network Monitor' on an NT Workstation 
+	or a Windows 9x box?</emphasis>
+	</para>
 
-<para>
-<emphasis>How do I install 'Network Monitor' on an NT Workstation 
-or a Windows 9x box?</emphasis>
-</para>
 	<para>
 	Installing netmon on an NT workstation requires a couple 
 	of steps.  The following are for installing Netmon V4.00.349, which comes 
@@ -696,12 +844,17 @@ or a Windows 9x box?</emphasis>
 	information on how to do this.  Copy the files from a working 
 	Netmon installation.
 	</para> 
+</listitem>
 
-<sect2>
-<title>URLs and similar</title>
 
 
-<itemizedlist>
+
+<listitem>
+	<para>
+	The following is a list if helpful URLs and other links:
+	</para>
+
+	<itemizedlist>
 
  	<listitem><para>Home of Samba site <ulink url="http://samba.org">
         http://samba.org</ulink>. We have a mirror near you !</para></listitem>
@@ -728,36 +881,35 @@ or a Windows 9x box?</emphasis>
         <ulink url="ftp://ftp.microsoft.com/developr/drg/CIFS/">
         ftp://ftp.microsoft.com/developr/drg/CIFS/</ulink></para></listitem>
 
+	</itemizedlist>
+</listitem>
 </itemizedlist>
 
-</sect2>
-
-
-<sect2>
-<title>Mailing Lists</title>
 
-<para>
-<emphasis>How do I get help from the mailing lists ?</emphasis>
-</para>
+<itemizedlist>
+<listitem>
+	<para>
+	<emphasis>How do I get help from the mailing lists ?</emphasis>
+	</para>
 
-<para>
-There are a number of Samba related mailing lists. Go to <ulink 
-url="http://samba.org">http://samba.org</ulink>, click on your nearest mirror
-and then click on <command>Support</> and then click on <command>
-Samba related mailing lists</>.
-</para>
+	<para>
+	There are a number of Samba related mailing lists. Go to <ulink 
+	url="http://samba.org">http://samba.org</ulink>, click on your nearest mirror
+	and then click on <command>Support</> and then click on <command>
+	Samba related mailing lists</>.
+	</para>
 
-<para>
-For questions relating to Samba TNG go to
-<ulink url="http://www.samba-tng.org/">http://www.samba-tng.org/</ulink> 
-It has been requested that you don't post questions about Samba-TNG to the
-main stream Samba lists.</para>
+	<para>
+	For questions relating to Samba TNG go to
+	<ulink url="http://www.samba-tng.org/">http://www.samba-tng.org/</ulink> 
+	It has been requested that you don't post questions about Samba-TNG to the
+	main stream Samba lists.</para>
 	 
-<para>
-If you post a message to one of the lists please observe the following guide lines :
-</para>
+	<para>
+	If you post a message to one of the lists please observe the following guide lines :
+	</para>
 
-<itemizedlist>
+	<itemizedlist>
 
 	<listitem><para> Always remember that the developers are volunteers, they are 
 		not paid and they never guarantee to produce a particular feature at 
@@ -801,28 +953,787 @@ If you post a message to one of the lists please observe the following guide lin
         mailing lists go to a huge number of people, do they all need a copy of your 
         smb.conf in their attach directory ?</para></listitem>
 
+	</itemizedlist>
+</listitem>
+
+
+<listitem>
+	<para>
+	<emphasis>How do I get off the mailing lists ?</emphasis>
+	</para>
+
+	<para>To have your name removed from a samba mailing list, go to the
+	same place you went to to get on it. Go to <ulink 
+	url="http://lists.samba.org/">http://lists.samba.org</ulink>, 
+	click on your nearest mirror and then click on <command>Support</> and 
+	then click on <command> Samba related mailing lists</>. Or perhaps see 
+	<ulink url="http://lists.samba.org/mailman/roster/samba-ntdom">here</ulink>
+	</para>
+
+	<para>
+	Please don't post messages to the list asking to be removed, you will just
+	be referred to the above address (unless that process failed in some way...)
+	</para>
+</listitem>
 </itemizedlist>
 
+</sect1>
+
+
+<!-- **********************************************************
+
+     Windows 9x domain control
+
+*************************************************************** -->
+<sect1>
+<title>Domain Control for Windows 9x/ME</title>
 
+<note>
 <para>
-<emphasis>How do I get off the mailing lists ?</emphasis>
+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 Special 
+Edition, Using Samba. (Richard Sharpe)
 </para>
+</note>
 
-    <para>To have your name removed from a samba mailing list, go to the
-        same place you went to to get on it. Go to <ulink url=
-        "http://lists.samba.org/">http://lists.samba.org</ulink>, click 
-		on your nearest mirror and then click on <command>Support</> and 
-		then click on <command> Samba related mailing lists</>. Or perhaps see 
-        <ulink url="http://lists.samba.org/mailman/roster/samba-ntdom">here</ulink></para>
+<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).
+</para>
 
-    <para>
-	Please don't post messages to the list asking to be removed, you will just
-        be referred to the above address (unless that process failed in some way...)
-    </para>
-</sect2>      
-</sect1>
+<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 total orthogonal to logon support.
+</para>
+
+<para>
+Issues related to the single-logon network model are discussed in this
+document.  Samba supports domain logons, network logon scripts, and user
+profiles for MS Windows for workgroups and MS Windows 9X clients.
+</para>
+
+
+<para>
+When an SMB client in a domain wishes to logon it broadcast requests for a
+logon server.  The first one to reply gets the job, and validates its
+password using whatever mechanism the Samba administrator has installed.
+It is possible (but very stupid) to create a domain where the user
+database is not shared between servers, ie they are effectively workgroup
+servers advertising themselves as participating in a domain.  This
+demonstrates how authentication is quite different from but closely
+involved with domains.
+</para>
+
+<para>
+Another thing commonly associated with single-logon domains is remote
+administration over the SMB protocol.  Again, there is no reason why this
+cannot be implemented with an underlying username database which is
+different from the Windows NT SAM.  Support for the Remote Administration
+Protocol is planned for a future release of Samba.
+</para>
+
+<para>
+Network logon support as discussed in this section is aimed at Window for
+Workgroups, and Windows 9X clients. 
+</para>
+
+<para>
+Support for profiles is confirmed as working for Win95, NT 4.0 and NT 3.51.
+It is possible to specify: the profile location; script file to be loaded
+on login; the user's home directory; and for NT a kick-off time could also
+now easily be supported. However, there are some differences between Win9X
+profile support and WinNT profile support. These are discussed below.
+</para>
+
+<para>
+With NT Workstations, all this does not require the use or intervention of
+an NT 4.0 or NT 3.51 server: Samba can now replace the logon services
+provided by an NT server, to a limited and experimental degree (for example,
+running "User Manager for Domains" will not provide you with access to
+a domain created by a Samba Server).
+</para>
+
+<para>
+With Win95, the help of an NT server can be enlisted, both for profile storage
+and for user authentication.  For details on user authentication, see
+security_level.txt.  For details on profile storage, see below.
+</para>
+
+<para>
+Using these features you can make your clients verify their logon via
+the Samba server; make clients run a batch file when they logon to
+the network and download their preferences, desktop and start menu.
+</para>
+
+<para>
+Before launching into the configuration instructions, it is worthwhile looking
+at how a Win9X client performs a logon:
+</para>
+
+<orderedlist>
+<listitem>
+	<para>
+	The client broadcasts (to the IP broadcast address of the subnet it is in)
+	a NetLogon request. This is sent to the NetBIOS address DOMAIN<00> at the
+	NetBIOS layer.  The client chooses the first response it receives, which
+	contains the NetBIOS name of the logon server to use in the format of 
+	\\SERVER.
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	The client then connects to that server, logs on (does an SMBsessetupX) and
+	then connects to the IPC$ share (using an SMBtconX).
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	The client then does a NetWkstaUserLogon request, which retrieves the name
+	of the user's logon script. 
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	The client then connects to the NetLogon share and searches for this 	
+	and if it is found and can be read, is retrieved and executed by the client.
+	After this, the client disconnects from the NetLogon share.
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	The client then sends a NetUserGetInfo request to the server, to retrieve
+	the user's home share, which is used to search for profiles. Since the
+	response to the NetUserGetInfo request does not contain much more 	
+	the user's home share, profiles for Win9X clients MUST reside in the user
+	home directory.
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	The client then connects to the user's home share and searches for the 
+	user's profile. As it turns out, you can specify the users home share as
+	a sharename and path. For example, \\server\fred\.profile.
+	If the profiles are found, they are implemented.
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	The client then disconnects from the user's home share, and reconnects to
+	the NetLogon share and looks for CONFIG.POL, the policies file. If this is
+	found, it is read and implemented.
+	</para>
+</listitem>
+</orderedlist>
+
+
+<sect2>
+<title>Configuration Instructions:	Network Logons</title>
+
+<para>
+To use domain logons and profiles you need to do the following:
+</para>
+
+
+<orderedlist>
+<listitem>
+	<para>
+	Create a share called [netlogon] in your smb.conf. This share should
+	be readable by all users, and probably should not be writeable. This
+	share will hold your network logon scripts, and the CONFIG.POL file
+	(Note: for details on the CONFIG.POL file, how to use it, what it is,
+	refer to the Microsoft Windows NT Administration documentation.
+	The format of these files is not known, so you will need to use
+	Microsoft tools).
+	</para>
+
+	<para>
+	For example I have used:
+	</para>
+	
+	<para><programlisting>
+[netlogon]
+     path = /data/dos/netlogon
+     writeable = no
+     guest ok = no
+</programlisting></para>
+
+	<para>
+	Note that it is important that this share is not writeable by ordinary
+	users, in a secure environment: ordinary users should not be allowed
+	to modify or add files that another user's computer would then download
+	when they log in.
+	</para>
+</listitem>
+
+
+
+<listitem>
+	<para>
+	in the [global] section of smb.conf set the following:
+	</para>
+	
+	<para><programlisting>
+domain logons = yes
+logon script = %U.bat
+	</programlisting></para>
+
+	<para>
+	The choice of batch file is, of course, up to you. The above would
+	give each user a separate batch file as the %U will be changed to
+	their username automatically. The other standard % macros may also be
+	used. You can make the batch files come from a subdirectory by using
+	something like:
+	</para>
+
+	<para><programlisting>
+logon script = scripts\%U.bat
+	</programlisting></para>
+</listitem>
+
+<listitem>
+	<para>
+	create the batch files to be run when the user logs in. If the batch
+	file doesn't exist then no batch file will be run. 
+	</para>
+
+	<para>
+	In the batch files you need to be careful to use DOS style cr/lf line
+	endings. If you don't then DOS may get confused. I suggest you use a
+	DOS editor to remotely edit the files if you don't know how to produce
+	DOS style files under unix.
+	</para>
+</listitem>
+
+
+<listitem>
+	<para>
+	Use smbclient with the -U option for some users to make sure that
+	the \\server\NETLOGON share is available, the batch files are
+	visible and they are readable by the users.
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	you will probabaly find that your clients automatically mount the
+	\\SERVER\NETLOGON share as drive z: while logging in. You can put
+	some useful programs there to execute from the batch files.
+	</para>
+</listitem>
+</orderedlist>
 
+<warning>
+<title>security mode and master browsers</title>
 
+<para>
+There are a few comments to make in order to tie up some 
+loose ends.  There has been much debate over the issue of whether
+or not it is ok to configure Samba as a Domain Controller in security
+modes other than <constant>USER</constant>.  The only security mode 
+which  will not work due to technical reasons is <constant>SHARE</constant>
+mode security.  <constant>DOMAIN</constant> and <constant>SERVER</constant>
+mode security is really just a variation on SMB user level security.
+</para>
+
+<para>
+Actually, this issue is also closer tied to the debate on whether 
+or not Samba must be the domain master browser for its workgroup
+when operating as a DC.  While it may technically be possible
+to configure a server as such (after all, browsing and domain logons
+are two distinctly different functions), it is not a good idea to
+so.  You should remember that the DC must register the DOMAIN#1b netbios 
+name.  This is the name used by Windows clients to locate the DC.
+Windows clients do not distinguish between the DC and the DMB.
+For this reason, it is very wise to configure the Samba DC as the DMB.
+</para>
+
+<para>
+Now back to the issue of configuring a Samba DC to use a mode other
+than "security = user".  If a Samba host is configured to use 
+another SMB server or DC in order to validate user connection 
+requests, then it is a fact that some other machine on the network 
+(the "password server") knows more about user than the Samba host.
+99% of the time, this other host is a domain controller.  Now 
+in order to operate in domain mode security, the "workgroup" parameter
+must be set to the name of the Windows NT domain (which already 
+has a domain controller, right?)
+</para>
+
+<para>
+Therefore configuring a Samba box as a DC for a domain that 
+already by definition has a PDC is asking for trouble.
+Therefore, you should always configure the Samba DC to be the DMB
+for its domain.
+</para>
+</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 users 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, inn 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 case preserve = 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-cacheing 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 correspondance, 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>
 
 
 <!-- **********************************************************
@@ -836,10 +1747,14 @@ If you post a message to one of the lists please observe the following guide lin
 DOMAIN_CONTROL.txt : Windows NT Domain Control & Samba
 </title>
 
-<para>
-This appendix was originally authored by John H Terpstra of the Samba Team
-and is included here for posterity.
-</para>
+<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>
@@ -858,13 +1773,8 @@ Windows NT SAM.
 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).
-</para>
-
-<para>
 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.
-However only those servers which have licensed Windows NT code in them can be
-a primary Domain Controller (eg Windows NT Server, Advanced Server for Unix.)
 </para>
 
 <para>