clean up to make the HOWTO-Collection compile again.

The DOMAIN.txt file has been included in the Samba PDC chapter.

1 files changed, 941 insertions, 72 deletions

diff --git a/docs/htmldocs/Samba-HOWTO-Collection.html b/docs/htmldocs/Samba-HOWTO-Collection.html
index 90e890c60b3..acfb1a7a3c1 100644
--- a/docs/htmldocs/Samba-HOWTO-Collection.html
+++ b/docs/htmldocs/Samba-HOWTO-Collection.html
@@ -426,148 +426,206 @@ HREF="#AEN1015"
 ><DT
 >6.8. <A
 HREF="#AEN1129"
+>Domain Control for Windows 9x/ME</A
+></DT
+><DD
+><DL
+><DT
+>6.8.1. <A
+HREF="#AEN1159"
+>Configuration Instructions:	Network Logons</A
+></DT
+><DT
+>6.8.2. <A
+HREF="#AEN1193"
+>Configuration Instructions:	Setting up Roaming User Profiles</A
+></DT
+><DD
+><DL
+><DT
+>6.8.2.1. <A
+HREF="#AEN1201"
+>Windows NT Configuration</A
+></DT
+><DT
+>6.8.2.2. <A
+HREF="#AEN1209"
+>Windows 9X Configuration</A
+></DT
+><DT
+>6.8.2.3. <A
+HREF="#AEN1217"
+>Win9X and WinNT Configuration</A
+></DT
+><DT
+>6.8.2.4. <A
+HREF="#AEN1224"
+>Windows 9X Profile Setup</A
+></DT
+><DT
+>6.8.2.5. <A
+HREF="#AEN1260"
+>Windows NT Workstation 4.0</A
+></DT
+><DT
+>6.8.2.6. <A
+HREF="#AEN1273"
+>Windows NT Server</A
+></DT
+><DT
+>6.8.2.7. <A
+HREF="#AEN1276"
+>Sharing Profiles between W95 and NT Workstation 4.0</A
+></DT
+></DL
+></DD
+></DL
+></DD
+><DT
+>6.9. <A
+HREF="#AEN1286"
 >DOMAIN_CONTROL.txt : Windows NT Domain Control &#38; Samba</A
 ></DT
 ></DL
 ></DD
 ><DT
 >7. <A
-HREF="#AEN1154"
+HREF="#AEN1311"
 >Unifed Logons between Windows NT and UNIX using Winbind</A
 ></DT
 ><DD
 ><DL
 ><DT
 >7.1. <A
-HREF="#AEN1172"
+HREF="#AEN1329"
 >Abstract</A
 ></DT
 ><DT
 >7.2. <A
-HREF="#AEN1176"
+HREF="#AEN1333"
 >Introduction</A
 ></DT
 ><DT
 >7.3. <A
-HREF="#AEN1189"
+HREF="#AEN1346"
 >What Winbind Provides</A
 ></DT
 ><DD
 ><DL
 ><DT
 >7.3.1. <A
-HREF="#AEN1196"
+HREF="#AEN1353"
 >Target Uses</A
 ></DT
 ></DL
 ></DD
 ><DT
 >7.4. <A
-HREF="#AEN1200"
+HREF="#AEN1357"
 >How Winbind Works</A
 ></DT
 ><DD
 ><DL
 ><DT
 >7.4.1. <A
-HREF="#AEN1205"
+HREF="#AEN1362"
 >Microsoft Remote Procedure Calls</A
 ></DT
 ><DT
 >7.4.2. <A
-HREF="#AEN1209"
+HREF="#AEN1366"
 >Name Service Switch</A
 ></DT
 ><DT
 >7.4.3. <A
-HREF="#AEN1225"
+HREF="#AEN1382"
 >Pluggable Authentication Modules</A
 ></DT
 ><DT
 >7.4.4. <A
-HREF="#AEN1233"
+HREF="#AEN1390"
 >User and Group ID Allocation</A
 ></DT
 ><DT
 >7.4.5. <A
-HREF="#AEN1237"
+HREF="#AEN1394"
 >Result Caching</A
 ></DT
 ></DL
 ></DD
 ><DT
 >7.5. <A
-HREF="#AEN1240"
+HREF="#AEN1397"
 >Installation and Configuration</A
 ></DT
 ><DT
 >7.6. <A
-HREF="#AEN1246"
+HREF="#AEN1403"
 >Limitations</A
 ></DT
 ><DT
 >7.7. <A
-HREF="#AEN1258"
+HREF="#AEN1415"
 >Conclusion</A
 ></DT
 ></DL
 ></DD
 ><DT
 >8. <A
-HREF="#AEN1261"
+HREF="#AEN1418"
 >UNIX Permission Bits and WIndows NT Access Control Lists</A
 ></DT
 ><DD
 ><DL
 ><DT
 >8.1. <A
-HREF="#AEN1272"
+HREF="#AEN1429"
 >Viewing and changing UNIX permissions using the NT 
 	security dialogs</A
 ></DT
 ><DT
 >8.2. <A
-HREF="#AEN1281"
+HREF="#AEN1438"
 >How to view file security on a Samba share</A
 ></DT
 ><DT
 >8.3. <A
-HREF="#AEN1292"
+HREF="#AEN1449"
 >Viewing file ownership</A
 ></DT
 ><DT
 >8.4. <A
-HREF="#AEN1312"
+HREF="#AEN1469"
 >Viewing file or directory permissions</A
 ></DT
 ><DD
 ><DL
 ><DT
 >8.4.1. <A
-HREF="#AEN1327"
+HREF="#AEN1484"
 >File Permissions</A
 ></DT
 ><DT
 >8.4.2. <A
-HREF="#AEN1341"
+HREF="#AEN1498"
 >Directory Permissions</A
 ></DT
 ></DL
 ></DD
 ><DT
 >8.5. <A
-HREF="#AEN1348"
+HREF="#AEN1505"
 >Modifying file or directory permissions</A
 ></DT
 ><DT
 >8.6. <A
-HREF="#AEN1370"
+HREF="#AEN1527"
 >Interaction with the standard Samba create mask 
 	parameters</A
 ></DT
 ><DT
 >8.7. <A
-HREF="#AEN1434"
+HREF="#AEN1591"
 >Interaction with the standard Samba file attribute 
 	mapping</A
 ></DT
@@ -575,39 +633,39 @@ HREF="#AEN1434"
 ></DD
 ><DT
 >9. <A
-HREF="#AEN1444"
+HREF="#AEN1601"
 >OS2 Client HOWTO</A
 ></DT
 ><DD
 ><DL
 ><DT
 >9.1. <A
-HREF="#AEN1455"
+HREF="#AEN1612"
 >FAQs</A
 ></DT
 ><DD
 ><DL
 ><DT
 >9.1.1. <A
-HREF="#AEN1457"
+HREF="#AEN1614"
 >How can I configure OS/2 Warp Connect or 
 		OS/2 Warp 4 as a client for Samba?</A
 ></DT
 ><DT
 >9.1.2. <A
-HREF="#AEN1472"
+HREF="#AEN1629"
 >How can I configure OS/2 Warp 3 (not Connect), 
 		OS/2 1.2, 1.3 or 2.x for Samba?</A
 ></DT
 ><DT
 >9.1.3. <A
-HREF="#AEN1481"
+HREF="#AEN1638"
 >Are there any other issues when OS/2 (any version) 
 		is used as a client?</A
 ></DT
 ><DT
 >9.1.4. <A
-HREF="#AEN1485"
+HREF="#AEN1642"
 >How do I get printer driver download working 
 		for OS/2 clients?</A
 ></DT
@@ -617,31 +675,31 @@ HREF="#AEN1485"
 ></DD
 ><DT
 >10. <A
-HREF="#AEN1494"
+HREF="#AEN1651"
 >HOWTO Access Samba source code via CVS</A
 ></DT
 ><DD
 ><DL
 ><DT
 >10.1. <A
-HREF="#AEN1501"
+HREF="#AEN1658"
 >Introduction</A
 ></DT
 ><DT
 >10.2. <A
-HREF="#AEN1506"
+HREF="#AEN1663"
 >CVS Access to samba.org</A
 ></DT
 ><DD
 ><DL
 ><DT
 >10.2.1. <A
-HREF="#AEN1509"
+HREF="#AEN1666"
 >Access via CVSweb</A
 ></DT
 ><DT
 >10.2.2. <A
-HREF="#AEN1514"
+HREF="#AEN1671"
 >Access via cvs</A
 ></DT
 ></DL
@@ -5091,7 +5149,818 @@ CLASS="SECT1"
 CLASS="SECT1"
 ><A
 NAME="AEN1129"
->6.8. DOMAIN_CONTROL.txt : Windows NT Domain Control &#38; Samba</A
+>6.8. Domain Control for Windows 9x/ME</A
+></H1
+><DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
+><P
+><B
+>Note: </B
+>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)</P
+></BLOCKQUOTE
+></DIV
+><P
+>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).</P
+><P
+>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.</P
+><P
+>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.</P
+><P
+>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.</P
+><P
+>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.</P
+><P
+>Network logon support as discussed in this section is aimed at Window for
+Workgroups, and Windows 9X clients. </P
+><P
+>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.</P
+><P
+>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).</P
+><P
+>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.</P
+><P
+>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.</P
+><P
+>Before launching into the configuration instructions, it is worthwhile looking
+at how a Win9X client performs a logon:</P
+><P
+></P
+><OL
+TYPE="1"
+><LI
+><P
+>	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&#60;00&#62; 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.
+	</P
+></LI
+><LI
+><P
+>	The client then connects to that server, logs on (does an SMBsessetupX) and
+	then connects to the IPC$ share (using an SMBtconX).
+	</P
+></LI
+><LI
+><P
+>	The client then does a NetWkstaUserLogon request, which retrieves the name
+	of the user's logon script. 
+	</P
+></LI
+><LI
+><P
+>	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.
+	</P
+></LI
+><LI
+><P
+>	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.
+	</P
+></LI
+><LI
+><P
+>	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.
+	</P
+></LI
+><LI
+><P
+>	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.
+	</P
+></LI
+></OL
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN1159"
+>6.8.1. Configuration Instructions:	Network Logons</A
+></H2
+><P
+>To use domain logons and profiles you need to do the following:</P
+><P
+></P
+><OL
+TYPE="1"
+><LI
+><P
+>	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).
+	</P
+><P
+>	For example I have used:
+	</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="90%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>[netlogon]
+     path = /data/dos/netlogon
+     writeable = no
+     guest ok = no</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>	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.
+	</P
+></LI
+><LI
+><P
+>	in the [global] section of smb.conf set the following:
+	</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="90%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>domain logons = yes
+logon script = %U.bat
+	</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>	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:
+	</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="90%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>logon script = scripts\%U.bat
+	</PRE
+></TD
+></TR
+></TABLE
+></P
+></LI
+><LI
+><P
+>	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. 
+	</P
+><P
+>	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.
+	</P
+></LI
+><LI
+><P
+>	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.
+	</P
+></LI
+><LI
+><P
+>	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.
+	</P
+></LI
+></OL
+><DIV
+CLASS="WARNING"
+><P
+></P
+><TABLE
+CLASS="WARNING"
+BORDER="1"
+WIDTH="100%"
+><TR
+><TD
+ALIGN="CENTER"
+><B
+>security mode and master browsers</B
+></TD
+></TR
+><TR
+><TD
+ALIGN="LEFT"
+><P
+>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 <TT
+CLASS="CONSTANT"
+>USER</TT
+>.  The only security mode 
+which  will not work due to technical reasons is <TT
+CLASS="CONSTANT"
+>SHARE</TT
+>
+mode security.  <TT
+CLASS="CONSTANT"
+>DOMAIN</TT
+> and <TT
+CLASS="CONSTANT"
+>SERVER</TT
+>
+mode security is really just a variation on SMB user level security.</P
+><P
+>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.</P
+><P
+>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?)</P
+><P
+>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.</P
+></TD
+></TR
+></TABLE
+></DIV
+></DIV
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN1193"
+>6.8.2. Configuration Instructions:	Setting up Roaming User Profiles</A
+></H2
+><DIV
+CLASS="WARNING"
+><P
+></P
+><TABLE
+CLASS="WARNING"
+BORDER="1"
+WIDTH="100%"
+><TR
+><TD
+ALIGN="CENTER"
+><B
+>Warning</B
+></TD
+></TR
+><TR
+><TD
+ALIGN="LEFT"
+><P
+><EM
+>NOTE!</EM
+> Roaming profiles support is different 
+for Win9X and WinNT.</P
+></TD
+></TR
+></TABLE
+></DIV
+><P
+>Before discussing how to configure roaming profiles, it is useful to see how
+Win9X and WinNT clients implement these features.</P
+><P
+>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.</P
+><P
+>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.</P
+><DIV
+CLASS="SECT3"
+><HR><H3
+CLASS="SECT3"
+><A
+NAME="AEN1201"
+>6.8.2.1. Windows NT Configuration</A
+></H3
+><P
+>To support WinNT clients, inn the [global] section of smb.conf set the
+following (for example):</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>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. </P
+><DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
+><P
+><B
+>Note: </B
+>[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.]</P
+></BLOCKQUOTE
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><HR><H3
+CLASS="SECT3"
+><A
+NAME="AEN1209"
+>6.8.2.2. Windows 9X Configuration</A
+></H3
+><P
+>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.</P
+><P
+>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:</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>logon home = \\%L\%U\.profiles</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>then your Win9X clients will dutifully put their clients in a subdirectory
+of your home directory called .profiles (thus making them hidden).</P
+><P
+>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".</P
+></DIV
+><DIV
+CLASS="SECT3"
+><HR><H3
+CLASS="SECT3"
+><A
+NAME="AEN1217"
+>6.8.2.3. Win9X and WinNT Configuration</A
+></H3
+><P
+>You can support profiles for both Win9X and WinNT clients by setting both the
+"logon home" and "logon path" parameters. For example:</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>logon home = \\%L\%U\.profiles
+logon path = \\%L\profiles\%U</PRE
+></TD
+></TR
+></TABLE
+></P
+><DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
+><P
+><B
+>Note: </B
+>I have not checked what 'net use /home' does on NT when "logon home" is
+set as above.</P
+></BLOCKQUOTE
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><HR><H3
+CLASS="SECT3"
+><A
+NAME="AEN1224"
+>6.8.2.4. Windows 9X Profile Setup</A
+></H3
+><P
+>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.</P
+><P
+>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.</P
+><P
+></P
+><OL
+TYPE="1"
+><LI
+><P
+>	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.
+	</P
+></LI
+><LI
+><P
+>	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.
+	</P
+></LI
+></OL
+><P
+>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.</P
+><P
+>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.</P
+><P
+>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'.</P
+><P
+>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.</P
+><P
+>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.</P
+><P
+>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.</P
+><P
+>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".</P
+><P
+></P
+><OL
+TYPE="1"
+><LI
+><P
+>	instead of logging in under the [user, password, domain] dialog,
+	press escape.
+	</P
+></LI
+><LI
+><P
+>	run the regedit.exe program, and look in:
+	</P
+><P
+>	HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList
+	</P
+><P
+>	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.
+	</P
+><P
+>	[Exit the registry editor].
+	</P
+></LI
+><LI
+><P
+>	<EM
+>WARNING</EM
+> - 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).
+	</P
+><P
+>   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.
+	</P
+></LI
+><LI
+><P
+>	search for the user's .PWL password-cacheing file in the c:\windows
+	directory, and delete it.
+	</P
+></LI
+><LI
+><P
+>	log off the windows 95 client.
+	</P
+></LI
+><LI
+><P
+>	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.  
+	</P
+></LI
+></OL
+><P
+>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.</P
+><P
+>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.</P
+></DIV
+><DIV
+CLASS="SECT3"
+><HR><H3
+CLASS="SECT3"
+><A
+NAME="AEN1260"
+>6.8.2.5. Windows NT Workstation 4.0</A
+></H3
+><P
+>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.  </P
+><DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
+><P
+><B
+>Note: </B
+>[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].</P
+></BLOCKQUOTE
+></DIV
+><P
+>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.</P
+><P
+>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].</P
+><P
+>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.</P
+><P
+>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.</P
+><DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
+><P
+><B
+>Note: </B
+>[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].</P
+><P
+>[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].</P
+><P
+>[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].</P
+></BLOCKQUOTE
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><HR><H3
+CLASS="SECT3"
+><A
+NAME="AEN1273"
+>6.8.2.6. Windows NT Server</A
+></H3
+><P
+>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.</P
+></DIV
+><DIV
+CLASS="SECT3"
+><HR><H3
+CLASS="SECT3"
+><A
+NAME="AEN1276"
+>6.8.2.7. Sharing Profiles between W95 and NT Workstation 4.0</A
+></H3
+><DIV
+CLASS="WARNING"
+><P
+></P
+><TABLE
+CLASS="WARNING"
+BORDER="1"
+WIDTH="100%"
+><TR
+><TD
+ALIGN="CENTER"
+><B
+>Potentially outdated or incorrect material follows</B
+></TD
+></TR
+><TR
+><TD
+ALIGN="LEFT"
+><P
+>I think this is all bogus, but have not deleted it. (Richard Sharpe)</P
+></TD
+></TR
+></TABLE
+></DIV
+><P
+>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.</P
+><P
+>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].</P
+><P
+>&#13;If you have this set up correctly, you will find separate user.DAT and
+NTuser.DAT files in the same profile directory.</P
+><DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
+><P
+><B
+>Note: </B
+>[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].</P
+></BLOCKQUOTE
+></DIV
+></DIV
+></DIV
+></DIV
+><DIV
+CLASS="SECT1"
+><HR><H1
+CLASS="SECT1"
+><A
+NAME="AEN1286"
+>6.9. DOMAIN_CONTROL.txt : Windows NT Domain Control &#38; Samba</A
 ></H1
 ><DIV
 CLASS="WARNING"
@@ -5211,7 +6080,7 @@ within its registry.</P
 CLASS="CHAPTER"
 ><HR><H1
 ><A
-NAME="AEN1154"
+NAME="AEN1311"
 >Chapter 7. Unifed Logons between Windows NT and UNIX using Winbind</A
 ></H1
 ><DIV
@@ -5219,7 +6088,7 @@ CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1172"
+NAME="AEN1329"
 >7.1. Abstract</A
 ></H1
 ><P
@@ -5241,7 +6110,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1176"
+NAME="AEN1333"
 >7.2. Introduction</A
 ></H1
 ><P
@@ -5295,7 +6164,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1189"
+NAME="AEN1346"
 >7.3. What Winbind Provides</A
 ></H1
 ><P
@@ -5337,7 +6206,7 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1196"
+NAME="AEN1353"
 >7.3.1. Target Uses</A
 ></H2
 ><P
@@ -5361,7 +6230,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1200"
+NAME="AEN1357"
 >7.4. How Winbind Works</A
 ></H1
 ><P
@@ -5381,7 +6250,7 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1205"
+NAME="AEN1362"
 >7.4.1. Microsoft Remote Procedure Calls</A
 ></H2
 ><P
@@ -5407,7 +6276,7 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1209"
+NAME="AEN1366"
 >7.4.2. Name Service Switch</A
 ></H2
 ><P
@@ -5486,7 +6355,7 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1225"
+NAME="AEN1382"
 >7.4.3. Pluggable Authentication Modules</A
 ></H2
 ><P
@@ -5535,7 +6404,7 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1233"
+NAME="AEN1390"
 >7.4.4. User and Group ID Allocation</A
 ></H2
 ><P
@@ -5561,7 +6430,7 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1237"
+NAME="AEN1394"
 >7.4.5. Result Caching</A
 ></H2
 ><P
@@ -5584,7 +6453,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1240"
+NAME="AEN1397"
 >7.5. Installation and Configuration</A
 ></H1
 ><P
@@ -5615,7 +6484,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1246"
+NAME="AEN1403"
 >7.6. Limitations</A
 ></H1
 ><P
@@ -5663,7 +6532,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1258"
+NAME="AEN1415"
 >7.7. Conclusion</A
 ></H1
 ><P
@@ -5679,7 +6548,7 @@ NAME="AEN1258"
 CLASS="CHAPTER"
 ><HR><H1
 ><A
-NAME="AEN1261"
+NAME="AEN1418"
 >Chapter 8. UNIX Permission Bits and WIndows NT Access Control Lists</A
 ></H1
 ><DIV
@@ -5687,7 +6556,7 @@ CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1272"
+NAME="AEN1429"
 >8.1. Viewing and changing UNIX permissions using the NT 
 	security dialogs</A
 ></H1
@@ -5726,7 +6595,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1281"
+NAME="AEN1438"
 >8.2. How to view file security on a Samba share</A
 ></H1
 ><P
@@ -5772,7 +6641,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1292"
+NAME="AEN1449"
 >8.3. Viewing file ownership</A
 ></H1
 ><P
@@ -5858,7 +6727,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1312"
+NAME="AEN1469"
 >8.4. Viewing file or directory permissions</A
 ></H1
 ><P
@@ -5920,7 +6789,7 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1327"
+NAME="AEN1484"
 >8.4.1. File Permissions</A
 ></H2
 ><P
@@ -5982,7 +6851,7 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1341"
+NAME="AEN1498"
 >8.4.2. Directory Permissions</A
 ></H2
 ><P
@@ -6014,7 +6883,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1348"
+NAME="AEN1505"
 >8.5. Modifying file or directory permissions</A
 ></H1
 ><P
@@ -6112,7 +6981,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1370"
+NAME="AEN1527"
 >8.6. Interaction with the standard Samba create mask 
 	parameters</A
 ></H1
@@ -6385,7 +7254,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1434"
+NAME="AEN1591"
 >8.7. Interaction with the standard Samba file attribute 
 	mapping</A
 ></H1
@@ -6432,7 +7301,7 @@ CLASS="COMMAND"
 CLASS="CHAPTER"
 ><HR><H1
 ><A
-NAME="AEN1444"
+NAME="AEN1601"
 >Chapter 9. OS2 Client HOWTO</A
 ></H1
 ><DIV
@@ -6440,7 +7309,7 @@ CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1455"
+NAME="AEN1612"
 >9.1. FAQs</A
 ></H1
 ><DIV
@@ -6448,7 +7317,7 @@ CLASS="SECT2"
 ><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1457"
+NAME="AEN1614"
 >9.1.1. How can I configure OS/2 Warp Connect or 
 		OS/2 Warp 4 as a client for Samba?</A
 ></H2
@@ -6507,7 +7376,7 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1472"
+NAME="AEN1629"
 >9.1.2. How can I configure OS/2 Warp 3 (not Connect), 
 		OS/2 1.2, 1.3 or 2.x for Samba?</A
 ></H2
@@ -6560,7 +7429,7 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1481"
+NAME="AEN1638"
 >9.1.3. Are there any other issues when OS/2 (any version) 
 		is used as a client?</A
 ></H2
@@ -6582,7 +7451,7 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1485"
+NAME="AEN1642"
 >9.1.4. How do I get printer driver download working 
 		for OS/2 clients?</A
 ></H2
@@ -6630,7 +7499,7 @@ CLASS="REPLACEABLE"
 CLASS="CHAPTER"
 ><HR><H1
 ><A
-NAME="AEN1494"
+NAME="AEN1651"
 >Chapter 10. HOWTO Access Samba source code via CVS</A
 ></H1
 ><DIV
@@ -6638,7 +7507,7 @@ CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1501"
+NAME="AEN1658"
 >10.1. Introduction</A
 ></H1
 ><P
@@ -6660,7 +7529,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1506"
+NAME="AEN1663"
 >10.2. CVS Access to samba.org</A
 ></H1
 ><P
@@ -6673,7 +7542,7 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1509"
+NAME="AEN1666"
 >10.2.1. Access via CVSweb</A
 ></H2
 ><P
@@ -6694,7 +7563,7 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1514"
+NAME="AEN1671"
 >10.2.2. Access via cvs</A
 ></H2
 ><P
@@ -6772,7 +7641,7 @@ CLASS="PARAMETER"
 ></TT
 >
 	and defining a tag name.  A list of branch tag names can be found on the
-	"Development page of the samba web site.  A common request is to obtain the
+	"Development" page of the samba web site.  A common request is to obtain the
 	latest 2.2 release code.  This could be done by using the following command.
 	</P
 ><P