summaryrefslogtreecommitdiff
path: root/docs/docbook/projdoc/Samba-PDC-HOWTO.xml
diff options
context:
space:
mode:
Diffstat (limited to 'docs/docbook/projdoc/Samba-PDC-HOWTO.xml')
-rw-r--r--docs/docbook/projdoc/Samba-PDC-HOWTO.xml842
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>