Docbook XML conversion: projdoc

(This used to be commit f7c9df751459da2d4a996d5f0135334fb3f87f69)

1 files changed, 842 insertions, 0 deletions

diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml
new file mode 100644
index 0000000000..6a3bcacf17
--- /dev/null
+++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml
@@ -0,0 +1,842 @@
+<chapter id="samba-pdc">
+
+
+<chapterinfo>
+	&author.jerry;
+	&author.jht;
+	<author>
+		<firstname>David</firstname><surname>Bannon</surname>
+		<affiliation>
+			<orgname>Samba Team</orgname>
+			<address><email>dbannon@samba.org</email></address>
+		</affiliation>
+	</author>
+	<pubdate> (26 Apr 2001) </pubdate>
+</chapterinfo>
+
+<title>
+Samba as an NT4 or Win2k Primary Domain Controller
+</title>
+
+
+<sect1>
+<title>Prerequisite Reading</title>
+
+<para>
+Before you continue reading in this chapter, please make sure 
+that you are comfortable with configuring basic files services
+in smb.conf and how to enable and administer password 
+encryption in Samba.  Theses two topics are covered in the
+&smb.conf; manpage.
+</para>
+
+
+</sect1>
+
+
+
+<sect1>
+<title>
+Background
+</title>
+
+<para>
+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.
+</para>
+
+<itemizedlist>
+	<listitem><para>
+	Domain logons for Windows NT 4.0 / 200x / XP Professional clients.
+	</para></listitem>
+	
+	<listitem><para>
+	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
+	Windows 9x / Me / NT / 200x / XP Professional clients
+	</para></listitem>
+	
+	<listitem><para>
+	Roaming Profiles
+	</para></listitem>
+	
+	<listitem><para>
+	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:
+</para>
+
+<itemizedlist>
+	<listitem><para>
+	Windows NT 4 domain trusts
+	</para></listitem>
+	
+	<listitem><para>
+	Adding users via the User Manager for Domains
+	</para></listitem>
+</itemizedlist>
+
+<para>
+The following functionalities are NOT provided by Samba 3.0:
+</para>
+
+<itemizedlist>
+	<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>
+	Acting as a Windows 2000 Domain Controller (i.e. Kerberos and 
+	Active Directory)
+	</para></listitem>
+</itemizedlist>
+
+<para>
+Please note that Windows 9x / Me / XP Home clients are not true members of a domain
+for reasons outlined in this article.  Therefore the protocol for
+support of Windows 9x-style domain logons is completely different
+from NT4 / Win2k type domain logons and has been officially supported for some 
+time.
+</para>
+
+<para><emphasis>
+MS Windows XP Home edition is NOT able to join a domain and does not permit
+the use of domain logons.</emphasis>
+</para>
+
+
+<para>
+Implementing a Samba PDC can basically be divided into 3 broad
+steps.
+</para>
+
+<orderedlist numeration="arabic">
+	<listitem><para>
+	Configuring the Samba PDC
+	</para></listitem>
+	
+	<listitem><para>
+	Creating machine trust accounts	and joining clients to the domain
+	</para></listitem>
+
+	<listitem><para>
+	Adding and managing domain user accounts
+	</para></listitem>
+</orderedlist>
+
+<para>
+There are other minor details such as user profiles, system
+policies, etc...  However, these are not necessarily specific
+to a Samba PDC as much as they are related to Windows NT networking
+concepts.
+</para>
+
+</sect1>
+
+
+<sect1>
+<title>Configuring the Samba Domain Controller</title>
+
+<para>
+The first step in creating a working Samba PDC is to 
+understand the parameters necessary in smb.conf. Here we
+attempt to explain the parameters that are covered in
+the &smb.conf; man page.
+</para>
+
+<para>
+Here is an example &smb.conf; for acting as a PDC:
+</para>
+
+<para><programlisting>
+[global]
+    ; Basic server settings
+    <ulink url="smb.conf.5.html#NETBIOSNAME">netbios name</ulink> = <replaceable>POGO</replaceable>
+    <ulink url="smb.conf.5.html#WORKGROUP">workgroup</ulink> = <replaceable>NARNIA</replaceable>
+
+    ; User and Machine Account Backends
+    ; Choices are: tdbsam, tdbsam_nua, smbpasswd, smbpasswd_nua, ldapsam, ldapsam_nua, ...
+    ;              mysqlsam, xmlsam, guest
+    <ulink url="smb.conf.5.html#PASSDBBACKEND">passdb backend</ulink> = ldapsam, guest
+
+    ; we should act as the domain and local master browser
+    <ulink url="smb.conf.5.html#OSLEVEL">os level</ulink> = 64
+    <ulink url="smb.conf.5.html#PERFERREDMASTER">preferred master</ulink> = yes
+    <ulink url="smb.conf.5.html#DOMAINMASTER">domain master</ulink> = yes
+    <ulink url="smb.conf.5.html#LOCALMASTER">local master</ulink> = yes
+    
+    ; security settings (must user security = user)
+    <ulink url="smb.conf.5.html#SECURITYEQUALSUSER">security</ulink> = user
+    
+    ; encrypted passwords are a requirement for a PDC
+    <ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">encrypt passwords</ulink> = yes
+    
+    ; support domain logons
+    <ulink url="smb.conf.5.html#DOMAINLOGONS">domain logons</ulink> = yes
+    
+    ; where to store user profiles?
+    <ulink url="smb.conf.5.html#LOGONPATH">logon path</ulink> = \\%N\profiles\%u
+    
+    ; where is a user's home directory and where should it be mounted at?
+    <ulink url="smb.conf.5.html#LOGONDRIVE">logon drive</ulink> = H:
+    <ulink url="smb.conf.5.html#LOGONHOME">logon home</ulink> = \\homeserver\%u
+    
+    ; specify a generic logon script for all users
+    ; 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
+[netlogon]
+    <ulink url="smb.conf.5.html#PATH">path</ulink> = /usr/local/samba/lib/netlogon
+    <ulink url="smb.conf.5.html#READONLY">read only</ulink> = yes
+    <ulink url="smb.conf.5.html#WRITELIST">write list</ulink> = <replaceable>ntadmin</replaceable>
+    
+; share for storing user profiles
+[profiles]
+    <ulink url="smb.conf.5.html#PATH">path</ulink> = /export/smb/ntprofile
+    <ulink url="smb.conf.5.html#READONLY">read only</ulink> = no
+    <ulink url="smb.conf.5.html#CREATEMASK">create mask</ulink> = 0600
+    <ulink url="smb.conf.5.html#DIRECTORYMASK">directory mask</ulink> = 0700
+</programlisting></para>
+
+<note><para>
+The above parameters make for a full set of parameters that may define the server's mode
+of operation. The following parameters are the essentials alone:
+
+<programlisting>
+	workgroup = NARNIA
+	domain logons = Yes
+	security = User
+</programlisting>
+
+The additional parameters shown in the longer listing above just makes for a
+more complete environment.
+</para></note>
+
+<para>
+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 <link linkend="passdb">the User Database chapter</link>.
+	</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.  Please refer to the various 
+	Network Browsing documentation included with this distribution for 
+	details.
+	</para></listitem>
+</itemizedlist>    
+
+<para>
+Samba 3.0 offers a complete implementation of group mapping
+between Windows NT groups and Unix groups (this is really quite
+complicated to explain in a short space).
+</para>
+
+</sect1>
+
+
+<sect1>
+<title>Creating Machine Trust Accounts and Joining Clients to the Domain</title>
+
+<para>
+A machine trust account is a Samba account that is used to
+authenticate a client machine (rather than a user) to the Samba
+server.  In Windows terminology, this is known as a "Computer
+Account."</para>
+
+<para>
+The password of a machine trust account acts as the shared secret for
+secure communication with the Domain Controller.  This is a security
+feature to prevent an unauthorized machine with the same NetBIOS name
+from joining the domain and gaining access to domain user/group
+accounts.  Windows NT, 200x, XP Professional clients use machine trust
+accounts, but Windows 9x / Me / XP Home clients do not.  Hence, a
+Windows 9x / Me / XP Home  client is never a true member of a domain
+because it does not possess a machine trust account, and thus has no
+shared secret with the domain controller.
+</para>
+
+<para>A Windows PDC stores each machine trust account in the Windows
+Registry. A Samba-3 PDC also has to store machine trust account information
+in a suitable backend data store. With Samba-3 there can be multiple back-ends
+for this including:
+</para>
+
+<itemizedlist>
+	<listitem><para>
+	<emphasis>smbpasswd</emphasis> - the plain ascii file stored used by
+	earlier versions of Samba. This file configuration option requires
+	a Unix/Linux system account for EVERY entry (ie: both for user and for
+	machine accounts). This file will be located in the <emphasis>private</emphasis>
+	directory (default is /usr/local/samba/lib/private or on linux /etc/samba).
+	</para></listitem>
+
+	<listitem><para>
+	<emphasis>smbpasswd_nua</emphasis> - This file is independant of the
+	system wide user accounts. The use of this back-end option requires
+	specification of the "non unix account range" option also. It is called
+	smbpasswd and will be located in the <filename>private</filename> directory.
+	</para></listitem>
+
+	<listitem><para>
+	<emphasis>tdbsam</emphasis> - a binary database backend that will be
+	stored in the <emphasis>private</emphasis> directory in a file called
+	<emphasis>passwd.tdb</emphasis>. The key benefit of this binary format
+	file is that it can store binary objects that can not be accomodated
+	in the traditional plain text smbpasswd file.
+	</para></listitem>
+
+	<listitem><para>
+	<emphasis>tdbsam_nua</emphasis> like the smbpasswd_nua option above, this
+	file allows the creation of arbitrary user and machine accounts without
+	requiring that account to be added to the system (/etc/passwd) file. It
+	too requires the specification of the "non unix account range" option
+	in the [globals] section of the &smb.conf; file.
+	</para></listitem>
+
+	<listitem><para>
+	<emphasis>ldapsam</emphasis> - An LDAP based back-end. Permits the
+	LDAP server to be specified. eg: ldap://localhost or ldap://frodo.murphy.com
+	</para></listitem>
+
+	<listitem><para>
+	<emphasis>ldapsam_nua</emphasis> - LDAP based back-end with no unix
+	account requirement, like smbpasswd_nua and tdbsam_nua above.
+	</para></listitem>
+</itemizedlist>
+
+<para>Read the chapter about the <link linkend="passdb">User Database</link> 
+for details.</para>
+
+<note><para>
+The new tdbsam and ldapsam account backends store vastly more information than
+smbpasswd is capable of. The new backend database includes capacity to specify
+per user settings for many parameters, over-riding global settings given in the
+<filename>smb.conf</filename> file. eg: logon drive, logon home, logon path, etc.
+</para></note>
+
+<para>
+A Samba PDC, however, stores each machine trust account in two parts,
+as follows:
+
+<itemizedlist>
+    <listitem><para>A Samba account, stored in the same location as user
+    LanMan and NT password hashes (currently
+    <filename>smbpasswd</filename>). The Samba account 
+    possesses and uses only the NT password hash.</para></listitem>
+
+    <listitem><para>A corresponding Unix account, typically stored in
+    <filename>/etc/passwd</filename>. (Future releases will alleviate the need to
+    create <filename>/etc/passwd</filename> entries.) </para></listitem>
+</itemizedlist>
+</para>
+
+<para>
+There are two ways to create machine trust accounts:
+</para>
+
+<itemizedlist>
+	<listitem><para> Manual creation. Both the Samba and corresponding
+	Unix account are created by hand.</para></listitem>
+	
+	<listitem><para> "On-the-fly" creation. The Samba machine trust
+	account is automatically created by Samba at the time the client
+	is joined to the domain. (For security, this is the
+	recommended method.) The corresponding Unix account may be
+	created automatically or manually. </para>
+	</listitem>
+
+</itemizedlist>
+
+<sect2>
+<title>Manual Creation of Machine Trust Accounts</title>
+
+<para>
+The first step in manually creating a machine trust account is to
+manually create the corresponding Unix account in
+<filename>/etc/passwd</filename>.  This can be done using
+<command>vipw</command> or other 'add user' command that is normally
+used to create new Unix accounts.  The following is an example for a
+Linux based Samba server:
+</para>
+
+<para>
+  <prompt>root# </prompt><command>/usr/sbin/useradd -g 100 -d /dev/null -c <replaceable>"machine 
+nickname"</replaceable> -s /bin/false <replaceable>machine_name</replaceable>$ </command>
+</para>
+<para>
+<prompt>root# </prompt><command>passwd -l <replaceable>machine_name</replaceable>$</command>
+</para>
+
+<para>On *BSD systems, this can be done using the 'chpass' utility:</para>
+
+<para>
+<prompt>root# </prompt><command>chpass -a "<replaceable>machine_name</replaceable>$:*:101:100::0:0:Workstation <replaceable>machine_name</replaceable>:/dev/null:/sbin/nologin"</command>
+</para>
+
+<para>
+The <filename>/etc/passwd</filename> entry will list the machine name 
+with a "$" appended, won't have a password, will have a null shell and no 
+home directory. For example a machine named 'doppy' would have an 
+<filename>/etc/passwd</filename> entry like this:
+</para>
+
+<para><programlisting>
+doppy$:x:505:501:<replaceable>machine_nickname</replaceable>:/dev/null:/bin/false
+</programlisting></para>
+
+<para>
+Above, <replaceable>machine_nickname</replaceable> can be any
+descriptive name for the client, i.e., BasementComputer.
+<replaceable>machine_name</replaceable> absolutely must be the NetBIOS
+name of the client to be joined to the domain.  The "$" must be
+appended to the NetBIOS name of the client or Samba will not recognize
+this as a machine trust account.
+</para>
+
+
+<para>
+Now that the corresponding Unix account has been created, the next step is to create 
+the Samba account for the client containing the well-known initial 
+machine trust account password.  This can be done using the <ulink 
+url="smbpasswd.8.html"><command>smbpasswd(8)</command></ulink> command 
+as shown here:
+</para>
+
+<para>
+<prompt>root# </prompt><userinput>smbpasswd -a -m <replaceable>machine_name</replaceable></userinput>
+</para>
+
+<para>
+where <replaceable>machine_name</replaceable> is the machine's NetBIOS
+name.  The RID of the new machine account is generated from the UID of 
+the corresponding Unix account.
+</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 trust account on a Windows NT PDC using 
+	the "Server Manager".  From the time at which the account is created
+	to the time which the client joins the domain and changes the password,
+	your domain is vulnerable to an intruder joining your domain using
+	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>"On-the-Fly" Creation of Machine Trust Accounts</title>
+
+<para>
+The second (and recommended) way of creating machine trust accounts is
+simply to allow the Samba server to create them as needed when the client
+is joined to the domain. </para>
+
+<para>Since each Samba machine trust account requires a corresponding
+Unix account, a method for automatically creating the
+Unix account is usually supplied; this requires configuration of the
+<ulink url="smb.conf.5.html#ADDUSERSCRIPT">add user script</ulink> 
+option in <filename>smb.conf</filename>.  This
+method is not required, however; corresponding Unix accounts may also
+be created manually.
+</para>
+
+
+<para>Below is an example for a RedHat 6.2 Linux system.
+</para>
+
+<para><programlisting>
+[global]
+   # &lt;...remainder of parameters...&gt;
+   add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u 
+</programlisting></para>
+
+</sect2>
+
+
+<sect2><title>Joining the Client to the Domain</title>
+
+<para>
+The procedure for joining a client to the domain varies with the
+version of Windows.
+</para>
+
+<itemizedlist>
+<listitem><para><emphasis>Windows 2000</emphasis></para>
+
+	<para>
+	When the user elects to join the client to a domain, Windows prompts for
+	an account and password that is privileged to join the domain. A Samba administrative
+	account (i.e., a Samba account that has root privileges on the Samba server) must be
+	entered here; the operation will fail if an ordinary user account is given. 
+	The password for this account should be set to a different password than the associated
+	<filename>/etc/passwd</filename> entry, for security reasons.
+	</para>
+
+	<para>
+	The session key of the Samba administrative account acts as an
+	encryption key for setting the password of the machine trust
+	account. The machine trust account will be created on-the-fly, or
+	updated if it already exists.
+	</para>
+
+</listitem>
+
+<listitem><para><emphasis>Windows NT</emphasis></para>
+
+    <para> If the machine trust account was created manually, on the
+	Identification Changes menu enter the domain name, but do not
+	check the box "Create a Computer Account in the Domain."  In this case,
+	the existing machine trust account is used to join the machine to
+	the domain.</para>
+
+    <para> If the machine trust account is to be created
+	on-the-fly, on the Identification Changes menu enter the domain
+	name, and check the box "Create a Computer Account in the Domain."  In
+	this case, joining the domain proceeds as above for Windows 2000
+	(i.e., you must supply a Samba administrative account when
+	prompted).</para>
+</listitem>
+
+<listitem><para><emphasis>Samba</emphasis></para>
+	<para>Joining a samba client to a domain is documented in 
+	the <link linkend="domain-member">Domain Member</link> chapter.
+</para></listitem>
+</itemizedlist>
+
+</sect2>
+</sect1>
+
+<sect1>
+<title>Common Problems and Errors</title>
+
+<sect2>
+<title>I cannot include a '$' in a machine name</title>
+<para>
+A 'machine name' in (typically) <filename>/etc/passwd</filename> 	
+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.
+Create a user without the '$' using <command>vipw</command> to edit the entry, adding
+the '$'. Or create the whole entry with vipw if you like, make sure you use a unique User ID!
+</para>
+</sect2>
+
+<sect2>
+<title>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 trust account.</title>
+
+<para>
+This happens if you try to create a machine trust 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>
+Further, if the machine is 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>
+</sect2>
+
+<sect2>
+<title>The system can not log you on (C000019B)....</title>
+
+<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 again or consult your 
+system administrator" when attempting to logon.
+</para>
+
+<para>
+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 net or rpcclient utilities.
+</para>
+
+<para>
+The reset or change the domain SID you can use the net command as follows:
+
+<programlisting>
+	net getlocalsid 'OLDNAME'
+	net setlocalsid 'SID'
+</programlisting>
+</para>
+
+</sect2>
+
+<sect2>
+<title>The machine trust account for this computer either does not 
+exist or is not accessible.</title>
+
+<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". What's 
+wrong?
+</para>
+
+<para>
+This problem is caused by the PDC not having a suitable machine trust 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>
+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 trust 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 ( i.e. computer_name$ ). There must be an entry 
+in both /etc/passwd and the smbpasswd file. Some people have reported 
+that inconsistent subnet masks between the Samba server and the NT 
+client have caused this problem.   Make sure that these are consistent 
+for both client and server.
+</para>
+</sect2>
+
+<sect2>
+<title>When I attempt to login to a Samba Domain from a NT4/W2K workstation,
+I get a message about my account being disabled.</title>
+
+<para>
+At first be ensure to enable the useraccounts with <command>smbpasswd -e 
+%user%</command>, this is normally done, when you create an account.
+</para>
+
+</sect2>
+
+</sect1>
+
+<sect1>
+<title>Domain Control for Windows 9x/ME</title>
+
+<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. 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 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 are the focus of this section.
+</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, i.e. they are effectively workgroup
+servers advertising themselves as participating in a domain.  This
+demonstrates how authentication is quite different from but closely
+involved with domains.
+</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 to look at how a Windows 9x/ME 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 name DOMAIN&lt;1c&gt; 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 then	
+	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 user's 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>
+The main difference between a PDC and a Windows 9x logon 
+server configuration is that
+</para>
+
+<itemizedlist>
+
+<listitem><para>
+Password encryption is not required for a Windows 9x logon server.
+</para></listitem>
+
+<listitem><para>
+Windows 9x/ME clients do not possess machine trust accounts.
+</para></listitem>
+
+</itemizedlist>
+
+<para>
+Therefore, a Samba PDC will also act as a Windows 9x logon 
+server.
+</para>
+
+
+<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 closely 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 do
+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 the 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>
+</sect1>
+</chapter>