missed checking in a couple of files.

2 files changed, 2324 insertions, 339 deletions

diff --git a/docs/htmldocs/Samba-HOWTO-Collection.html b/docs/htmldocs/Samba-HOWTO-Collection.html
index acfb1a7a3c1..086636006e0 100644
--- a/docs/htmldocs/Samba-HOWTO-Collection.html
+++ b/docs/htmldocs/Samba-HOWTO-Collection.html
@@ -181,76 +181,215 @@ HREF="#AEN209"
 ><DT
 >2. <A
 HREF="#AEN212"
->LanMan and NT Password Encryption in Samba 2.x</A
+>Integrating MS Windows networks with Samba</A
 ></DT
 ><DD
 ><DL
 ><DT
 >2.1. <A
 HREF="#AEN223"
->Introduction</A
+>Agenda</A
 ></DT
 ><DT
 >2.2. <A
-HREF="#AEN227"
->How does it work?</A
+HREF="#AEN245"
+>Name Resolution in a pure Unix/Linux world</A
+></DT
+><DD
+><DL
+><DT
+>2.2.1. <A
+HREF="#AEN248"
+><TT
+CLASS="FILENAME"
+>/etc/hosts</TT
+></A
+></DT
+><DT
+>2.2.2. <A
+HREF="#AEN264"
+><TT
+CLASS="FILENAME"
+>/etc/resolv.conf</TT
+></A
+></DT
+><DT
+>2.2.3. <A
+HREF="#AEN275"
+><TT
+CLASS="FILENAME"
+>/etc/host.conf</TT
+></A
+></DT
+><DT
+>2.2.4. <A
+HREF="#AEN283"
+><TT
+CLASS="FILENAME"
+>/etc/nsswitch.conf</TT
+></A
 ></DT
+></DL
+></DD
 ><DT
 >2.3. <A
-HREF="#AEN238"
->Important Notes About Security</A
+HREF="#AEN295"
+>Name resolution as used within MS Windows networking</A
 ></DT
 ><DD
 ><DL
 ><DT
 >2.3.1. <A
-HREF="#AEN257"
->Advantages of SMB Encryption</A
+HREF="#AEN307"
+>The NetBIOS Name Cache</A
 ></DT
 ><DT
 >2.3.2. <A
-HREF="#AEN264"
->Advantages of non-encrypted passwords</A
+HREF="#AEN312"
+>The LMHOSTS file</A
+></DT
+><DT
+>2.3.3. <A
+HREF="#AEN320"
+>HOSTS file</A
+></DT
+><DT
+>2.3.4. <A
+HREF="#AEN325"
+>DNS Lookup</A
+></DT
+><DT
+>2.3.5. <A
+HREF="#AEN328"
+>WINS Lookup</A
 ></DT
 ></DL
 ></DD
 ><DT
 >2.4. <A
-HREF="#AEN273"
+HREF="#AEN341"
+>How browsing functions and how to deploy stable and 
+dependable browsing using Samba</A
+></DT
+><DT
+>2.5. <A
+HREF="#AEN351"
+>MS Windows security options and how to configure 
+Samba for seemless integration</A
+></DT
+><DD
+><DL
+><DT
+>2.5.1. <A
+HREF="#AEN368"
+>Use MS Windows NT as an authentication server</A
+></DT
+><DT
+>2.5.2. <A
+HREF="#AEN376"
+>Make Samba a member of an MS Windows NT security domain</A
+></DT
+><DT
+>2.5.3. <A
+HREF="#AEN390"
+>Configure Samba as an authentication server</A
+></DT
+><DD
+><DL
+><DT
+>2.5.3.1. <A
+HREF="#AEN397"
+>Users</A
+></DT
+><DT
+>2.5.3.2. <A
+HREF="#AEN404"
+>MS Windows NT Machine Accounts</A
+></DT
+></DL
+></DD
+></DL
+></DD
+><DT
+>2.6. <A
+HREF="#AEN409"
+>Configuration of Samba as ...</A
+></DT
+></DL
+></DD
+><DT
+>3. <A
+HREF="#AEN420"
+>LanMan and NT Password Encryption in Samba 2.x</A
+></DT
+><DD
+><DL
+><DT
+>3.1. <A
+HREF="#AEN431"
+>Introduction</A
+></DT
+><DT
+>3.2. <A
+HREF="#AEN435"
+>How does it work?</A
+></DT
+><DT
+>3.3. <A
+HREF="#AEN446"
+>Important Notes About Security</A
+></DT
+><DD
+><DL
+><DT
+>3.3.1. <A
+HREF="#AEN465"
+>Advantages of SMB Encryption</A
+></DT
+><DT
+>3.3.2. <A
+HREF="#AEN472"
+>Advantages of non-encrypted passwords</A
+></DT
+></DL
+></DD
+><DT
+>3.4. <A
+HREF="#AEN481"
 ><A
 NAME="SMBPASSWDFILEFORMAT"
 ></A
 >The smbpasswd file</A
 ></DT
 ><DT
->2.5. <A
-HREF="#AEN325"
+>3.5. <A
+HREF="#AEN533"
 >The smbpasswd Command</A
 ></DT
 ><DT
->2.6. <A
-HREF="#AEN364"
+>3.6. <A
+HREF="#AEN572"
 >Setting up Samba to support LanManager Encryption</A
 ></DT
 ></DL
 ></DD
 ><DT
->3. <A
-HREF="#AEN379"
+>4. <A
+HREF="#AEN587"
 >Hosting a Microsoft Distributed File System tree on Samba</A
 ></DT
 ><DD
 ><DL
 ><DT
->3.1. <A
-HREF="#AEN390"
+>4.1. <A
+HREF="#AEN598"
 >Instructions</A
 ></DT
 ><DD
 ><DL
 ><DT
->3.1.1. <A
-HREF="#AEN425"
+>4.1.1. <A
+HREF="#AEN633"
 >Notes</A
 ></DT
 ></DL
@@ -258,83 +397,83 @@ HREF="#AEN425"
 ></DL
 ></DD
 ><DT
->4. <A
-HREF="#AEN434"
+>5. <A
+HREF="#AEN642"
 >Printing Support in Samba 2.2.x</A
 ></DT
 ><DD
 ><DL
 ><DT
->4.1. <A
-HREF="#AEN445"
+>5.1. <A
+HREF="#AEN653"
 >Introduction</A
 ></DT
 ><DT
->4.2. <A
-HREF="#AEN467"
+>5.2. <A
+HREF="#AEN675"
 >Configuration</A
 ></DT
 ><DD
 ><DL
 ><DT
->4.2.1. <A
-HREF="#AEN478"
+>5.2.1. <A
+HREF="#AEN686"
 >Creating [print$]</A
 ></DT
 ><DT
->4.2.2. <A
-HREF="#AEN513"
+>5.2.2. <A
+HREF="#AEN721"
 >Setting Drivers for Existing Printers</A
 ></DT
 ><DT
->4.2.3. <A
-HREF="#AEN530"
+>5.2.3. <A
+HREF="#AEN738"
 >Support a large number of printers</A
 ></DT
 ><DT
->4.2.4. <A
-HREF="#AEN541"
+>5.2.4. <A
+HREF="#AEN749"
 >Adding New Printers via the Windows NT APW</A
 ></DT
 ><DT
->4.2.5. <A
-HREF="#AEN566"
+>5.2.5. <A
+HREF="#AEN774"
 >Samba and Printer Ports</A
 ></DT
 ></DL
 ></DD
 ><DT
->4.3. <A
-HREF="#AEN574"
+>5.3. <A
+HREF="#AEN782"
 >The Imprints Toolset</A
 ></DT
 ><DD
 ><DL
 ><DT
->4.3.1. <A
-HREF="#AEN578"
+>5.3.1. <A
+HREF="#AEN786"
 >What is Imprints?</A
 ></DT
 ><DT
->4.3.2. <A
-HREF="#AEN588"
+>5.3.2. <A
+HREF="#AEN796"
 >Creating Printer Driver Packages</A
 ></DT
 ><DT
->4.3.3. <A
-HREF="#AEN591"
+>5.3.3. <A
+HREF="#AEN799"
 >The Imprints server</A
 ></DT
 ><DT
->4.3.4. <A
-HREF="#AEN595"
+>5.3.4. <A
+HREF="#AEN803"
 >The Installation Client</A
 ></DT
 ></DL
 ></DD
 ><DT
->4.4. <A
-HREF="#AEN617"
+>5.4. <A
+HREF="#AEN825"
 ><A
 NAME="MIGRATION"
 ></A
@@ -343,138 +482,138 @@ NAME="MIGRATION"
 ></DL
 ></DD
 ><DT
->5. <A
-HREF="#AEN661"
+>6. <A
+HREF="#AEN869"
 >security = domain in Samba 2.x</A
 ></DT
 ><DD
 ><DL
 ><DT
->5.1. <A
-HREF="#AEN679"
+>6.1. <A
+HREF="#AEN887"
 >Joining an NT Domain with Samba 2.2</A
 ></DT
 ><DT
->5.2. <A
-HREF="#AEN743"
+>6.2. <A
+HREF="#AEN951"
 >Samba and Windows 2000 Domains</A
 ></DT
 ><DT
->5.3. <A
-HREF="#AEN748"
+>6.3. <A
+HREF="#AEN956"
 >Why is this better than security = server?</A
 ></DT
 ></DL
 ></DD
 ><DT
->6. <A
-HREF="#AEN764"
+>7. <A
+HREF="#AEN972"
 >How to Configure Samba 2.2 as a Primary Domain Controller</A
 ></DT
 ><DD
 ><DL
 ><DT
->6.1. <A
-HREF="#AEN781"
+>7.1. <A
+HREF="#AEN989"
 >Prerequisite Reading</A
 ></DT
 ><DT
->6.2. <A
-HREF="#AEN787"
+>7.2. <A
+HREF="#AEN995"
 >Background</A
 ></DT
 ><DT
->6.3. <A
-HREF="#AEN827"
+>7.3. <A
+HREF="#AEN1035"
 >Configuring the Samba Domain Controller</A
 ></DT
 ><DT
->6.4. <A
-HREF="#AEN870"
+>7.4. <A
+HREF="#AEN1078"
 >Creating Machine Trust Accounts and Joining Clients 
 to the Domain</A
 ></DT
 ><DD
 ><DL
 ><DT
->6.4.1. <A
-HREF="#AEN884"
+>7.4.1. <A
+HREF="#AEN1092"
 >Manually creating machine trust accounts</A
 ></DT
 ><DT
->6.4.2. <A
-HREF="#AEN912"
+>7.4.2. <A
+HREF="#AEN1120"
 >Creating machine trust accounts "on the fly"</A
 ></DT
 ></DL
 ></DD
 ><DT
->6.5. <A
-HREF="#AEN923"
+>7.5. <A
+HREF="#AEN1131"
 >Common Problems and Errors</A
 ></DT
 ><DT
->6.6. <A
-HREF="#AEN971"
+>7.6. <A
+HREF="#AEN1179"
 >System Policies and Profiles</A
 ></DT
 ><DT
->6.7. <A
-HREF="#AEN1015"
+>7.7. <A
+HREF="#AEN1223"
 >What other help can I get ?</A
 ></DT
 ><DT
->6.8. <A
-HREF="#AEN1129"
+>7.8. <A
+HREF="#AEN1337"
 >Domain Control for Windows 9x/ME</A
 ></DT
 ><DD
 ><DL
 ><DT
->6.8.1. <A
-HREF="#AEN1159"
+>7.8.1. <A
+HREF="#AEN1367"
 >Configuration Instructions:	Network Logons</A
 ></DT
 ><DT
->6.8.2. <A
-HREF="#AEN1193"
+>7.8.2. <A
+HREF="#AEN1401"
 >Configuration Instructions:	Setting up Roaming User Profiles</A
 ></DT
 ><DD
 ><DL
 ><DT
->6.8.2.1. <A
-HREF="#AEN1201"
+>7.8.2.1. <A
+HREF="#AEN1409"
 >Windows NT Configuration</A
 ></DT
 ><DT
->6.8.2.2. <A
-HREF="#AEN1209"
+>7.8.2.2. <A
+HREF="#AEN1417"
 >Windows 9X Configuration</A
 ></DT
 ><DT
->6.8.2.3. <A
-HREF="#AEN1217"
+>7.8.2.3. <A
+HREF="#AEN1425"
 >Win9X and WinNT Configuration</A
 ></DT
 ><DT
->6.8.2.4. <A
-HREF="#AEN1224"
+>7.8.2.4. <A
+HREF="#AEN1432"
 >Windows 9X Profile Setup</A
 ></DT
 ><DT
->6.8.2.5. <A
-HREF="#AEN1260"
+>7.8.2.5. <A
+HREF="#AEN1468"
 >Windows NT Workstation 4.0</A
 ></DT
 ><DT
->6.8.2.6. <A
-HREF="#AEN1273"
+>7.8.2.6. <A
+HREF="#AEN1481"
 >Windows NT Server</A
 ></DT
 ><DT
->6.8.2.7. <A
-HREF="#AEN1276"
+>7.8.2.7. <A
+HREF="#AEN1484"
 >Sharing Profiles between W95 and NT Workstation 4.0</A
 ></DT
 ></DL
@@ -482,190 +621,190 @@ HREF="#AEN1276"
 ></DL
 ></DD
 ><DT
->6.9. <A
-HREF="#AEN1286"
+>7.9. <A
+HREF="#AEN1494"
 >DOMAIN_CONTROL.txt : Windows NT Domain Control &#38; Samba</A
 ></DT
 ></DL
 ></DD
 ><DT
->7. <A
-HREF="#AEN1311"
+>8. <A
+HREF="#AEN1519"
 >Unifed Logons between Windows NT and UNIX using Winbind</A
 ></DT
 ><DD
 ><DL
 ><DT
->7.1. <A
-HREF="#AEN1329"
+>8.1. <A
+HREF="#AEN1537"
 >Abstract</A
 ></DT
 ><DT
->7.2. <A
-HREF="#AEN1333"
+>8.2. <A
+HREF="#AEN1541"
 >Introduction</A
 ></DT
 ><DT
->7.3. <A
-HREF="#AEN1346"
+>8.3. <A
+HREF="#AEN1554"
 >What Winbind Provides</A
 ></DT
 ><DD
 ><DL
 ><DT
->7.3.1. <A
-HREF="#AEN1353"
+>8.3.1. <A
+HREF="#AEN1561"
 >Target Uses</A
 ></DT
 ></DL
 ></DD
 ><DT
->7.4. <A
-HREF="#AEN1357"
+>8.4. <A
+HREF="#AEN1565"
 >How Winbind Works</A
 ></DT
 ><DD
 ><DL
 ><DT
->7.4.1. <A
-HREF="#AEN1362"
+>8.4.1. <A
+HREF="#AEN1570"
 >Microsoft Remote Procedure Calls</A
 ></DT
 ><DT
->7.4.2. <A
-HREF="#AEN1366"
+>8.4.2. <A
+HREF="#AEN1574"
 >Name Service Switch</A
 ></DT
 ><DT
->7.4.3. <A
-HREF="#AEN1382"
+>8.4.3. <A
+HREF="#AEN1590"
 >Pluggable Authentication Modules</A
 ></DT
 ><DT
->7.4.4. <A
-HREF="#AEN1390"
+>8.4.4. <A
+HREF="#AEN1598"
 >User and Group ID Allocation</A
 ></DT
 ><DT
->7.4.5. <A
-HREF="#AEN1394"
+>8.4.5. <A
+HREF="#AEN1602"
 >Result Caching</A
 ></DT
 ></DL
 ></DD
 ><DT
->7.5. <A
-HREF="#AEN1397"
+>8.5. <A
+HREF="#AEN1605"
 >Installation and Configuration</A
 ></DT
 ><DT
->7.6. <A
-HREF="#AEN1403"
+>8.6. <A
+HREF="#AEN1611"
 >Limitations</A
 ></DT
 ><DT
->7.7. <A
-HREF="#AEN1415"
+>8.7. <A
+HREF="#AEN1623"
 >Conclusion</A
 ></DT
 ></DL
 ></DD
 ><DT
->8. <A
-HREF="#AEN1418"
+>9. <A
+HREF="#AEN1626"
 >UNIX Permission Bits and WIndows NT Access Control Lists</A
 ></DT
 ><DD
 ><DL
 ><DT
->8.1. <A
-HREF="#AEN1429"
+>9.1. <A
+HREF="#AEN1637"
 >Viewing and changing UNIX permissions using the NT 
 	security dialogs</A
 ></DT
 ><DT
->8.2. <A
-HREF="#AEN1438"
+>9.2. <A
+HREF="#AEN1646"
 >How to view file security on a Samba share</A
 ></DT
 ><DT
->8.3. <A
-HREF="#AEN1449"
+>9.3. <A
+HREF="#AEN1657"
 >Viewing file ownership</A
 ></DT
 ><DT
->8.4. <A
-HREF="#AEN1469"
+>9.4. <A
+HREF="#AEN1677"
 >Viewing file or directory permissions</A
 ></DT
 ><DD
 ><DL
 ><DT
->8.4.1. <A
-HREF="#AEN1484"
+>9.4.1. <A
+HREF="#AEN1692"
 >File Permissions</A
 ></DT
 ><DT
->8.4.2. <A
-HREF="#AEN1498"
+>9.4.2. <A
+HREF="#AEN1706"
 >Directory Permissions</A
 ></DT
 ></DL
 ></DD
 ><DT
->8.5. <A
-HREF="#AEN1505"
+>9.5. <A
+HREF="#AEN1713"
 >Modifying file or directory permissions</A
 ></DT
 ><DT
->8.6. <A
-HREF="#AEN1527"
+>9.6. <A
+HREF="#AEN1735"
 >Interaction with the standard Samba create mask 
 	parameters</A
 ></DT
 ><DT
->8.7. <A
-HREF="#AEN1591"
+>9.7. <A
+HREF="#AEN1799"
 >Interaction with the standard Samba file attribute 
 	mapping</A
 ></DT
 ></DL
 ></DD
 ><DT
->9. <A
-HREF="#AEN1601"
+>10. <A
+HREF="#AEN1809"
 >OS2 Client HOWTO</A
 ></DT
 ><DD
 ><DL
 ><DT
->9.1. <A
-HREF="#AEN1612"
+>10.1. <A
+HREF="#AEN1820"
 >FAQs</A
 ></DT
 ><DD
 ><DL
 ><DT
->9.1.1. <A
-HREF="#AEN1614"
+>10.1.1. <A
+HREF="#AEN1822"
 >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="#AEN1629"
+>10.1.2. <A
+HREF="#AEN1837"
 >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="#AEN1638"
+>10.1.3. <A
+HREF="#AEN1846"
 >Are there any other issues when OS/2 (any version) 
 		is used as a client?</A
 ></DT
 ><DT
->9.1.4. <A
-HREF="#AEN1642"
+>10.1.4. <A
+HREF="#AEN1850"
 >How do I get printer driver download working 
 		for OS/2 clients?</A
 ></DT
@@ -674,32 +813,32 @@ HREF="#AEN1642"
 ></DL
 ></DD
 ><DT
->10. <A
-HREF="#AEN1651"
+>11. <A
+HREF="#AEN1859"
 >HOWTO Access Samba source code via CVS</A
 ></DT
 ><DD
 ><DL
 ><DT
->10.1. <A
-HREF="#AEN1658"
+>11.1. <A
+HREF="#AEN1866"
 >Introduction</A
 ></DT
 ><DT
->10.2. <A
-HREF="#AEN1663"
+>11.2. <A
+HREF="#AEN1871"
 >CVS Access to samba.org</A
 ></DT
 ><DD
 ><DL
 ><DT
->10.2.1. <A
-HREF="#AEN1666"
+>11.2.1. <A
+HREF="#AEN1874"
 >Access via CVSweb</A
 ></DT
 ><DT
->10.2.2. <A
-HREF="#AEN1671"
+>11.2.2. <A
+HREF="#AEN1879"
 >Access via cvs</A
 ></DT
 ></DL
@@ -1534,7 +1673,7 @@ CLASS="CHAPTER"
 ><HR><H1
 ><A
 NAME="AEN212"
->Chapter 2. LanMan and NT Password Encryption in Samba 2.x</A
+>Chapter 2. Integrating MS Windows networks with Samba</A
 ></H1
 ><DIV
 CLASS="SECT1"
@@ -1542,7 +1681,1094 @@ CLASS="SECT1"
 CLASS="SECT1"
 ><A
 NAME="AEN223"
->2.1. Introduction</A
+>2.1. Agenda</A
+></H1
+><P
+>To identify the key functional mechanisms of MS Windows networking 
+to enable the deployment of Samba as a means of extending and/or 
+replacing MS Windows NT/2000 technology.</P
+><P
+>We will examine:</P
+><P
+></P
+><OL
+TYPE="1"
+><LI
+><P
+>Name resolution in a pure Unix/Linux TCP/IP 
+	environment
+	</P
+></LI
+><LI
+><P
+>Name resolution as used within MS Windows 
+	networking
+	</P
+></LI
+><LI
+><P
+>How browsing functions and how to deploy stable 
+	and dependable browsing using Samba
+	</P
+></LI
+><LI
+><P
+>MS Windows security options and how to 
+	configure Samba for seemless integration
+	</P
+></LI
+><LI
+><P
+>Configuration of Samba as:</P
+><P
+></P
+><OL
+TYPE="a"
+><LI
+><P
+>A stand-alone server</P
+></LI
+><LI
+><P
+>An MS Windows NT 3.x/4.0 security domain member
+		</P
+></LI
+><LI
+><P
+>An alternative to an MS Windows NT 3.x/4.0 Domain Controller
+		</P
+></LI
+></OL
+></LI
+></OL
+></DIV
+><DIV
+CLASS="SECT1"
+><HR><H1
+CLASS="SECT1"
+><A
+NAME="AEN245"
+>2.2. Name Resolution in a pure Unix/Linux world</A
+></H1
+><P
+>The key configuration files : </P
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN248"
+>2.2.1. <TT
+CLASS="FILENAME"
+>/etc/hosts</TT
+></A
+></H2
+><P
+>Contains a static list of IP Addresses and names.
+eg:</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>	127.0.0.1	localhost localhost.localdomain
+	192.168.1.1	bigbox.caldera.com	bigbox	alias4box</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>The purpose of <TT
+CLASS="FILENAME"
+>/etc/hosts</TT
+> is to provide a 
+name resolution mechanism so that uses do not need to remember 
+IP addresses.</P
+><P
+>Network packets that are sent over the physical network transport 
+layer communicate not via IP addresses but rather using the Media 
+Access Control address, or MAC address. IP Addresses are currently 
+32 bits in length and are typically presented as four (4) decimal 
+numbers that are separated by a dot (or period). eg: 168.192.1.1</P
+><P
+>MAC Addresses use 48 bits (or 6 bytes) and are typically represented 
+as two digit hexadecimal numbers separated by colons. eg: 
+40:8e:0a:12:34:56</P
+><P
+>Every network interfrace must have an MAC address. Associated with 
+a MAC address there may be one or more IP addresses. There is NO 
+relationship between an IP address and a MAC address, all such assignments 
+are arbitary or discretionary in nature. At the most basic level all 
+network communications takes place using MAC addressing. Since MAC 
+addresses must be globally unique, and generally remains fixed for 
+any particular interface, the assignment of an IP address makes sense 
+from a network management perspective. More than one IP address can 
+be assigned per MAC address. One address must be the primary IP address, 
+this is the address that will be returned in the ARP reply.</P
+><P
+>When a user or a process wants to communicate with another machine 
+the protocol implementation ensures that the "machine name" or "host 
+name" is resolved to an IP address in a manner that is controlled 
+by the TCP/IP configuration control files. The file 
+<TT
+CLASS="FILENAME"
+>/etc/hosts</TT
+> is one such file.</P
+><P
+>When the IP address of the destination interface has been 
+determined a protocol called ARP/RARP isused to identify 
+the MAC address of the target interface. ARP stands for Address 
+Resolution Protocol, and is a broadcast oriented method that 
+uses UDP (User Datagram Protocol) to send a request to all 
+interfaces on the local network segment using the all 1's MAC 
+address. Network interfaces are programmed to respond to two 
+MAC addresses only; their own unique address and the address 
+ff:ff:ff:ff:ff:ff. The reply packet from an ARP request will 
+contain the MAC address and the primary IP address for each 
+interface.</P
+><P
+>The <TT
+CLASS="FILENAME"
+>/etc/hosts</TT
+> file is foundational to all 
+Unix/Linux TCP/IP installations and as a minumum will contain 
+the localhost and local network interface IP addresses and the 
+primary names by which they are known within the local machine. 
+This file helps to prime the pump so that a basic level of name 
+resolution can exist before any other method of name resolution 
+becomes available.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN264"
+>2.2.2. <TT
+CLASS="FILENAME"
+>/etc/resolv.conf</TT
+></A
+></H2
+><P
+>This file tells the name resolution libraries:</P
+><P
+></P
+><UL
+><LI
+><P
+>The name of the domain to which the machine 
+	belongs
+	</P
+></LI
+><LI
+><P
+>The name(s) of any domains that should be 
+	automatically searched when trying to resolve unqualified 
+	host names to their IP address
+	</P
+></LI
+><LI
+><P
+>The name or IP address of available Domain 
+	Name Servers that may be asked to perform name to address 
+	translation lookups
+	</P
+></LI
+></UL
+></DIV
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN275"
+>2.2.3. <TT
+CLASS="FILENAME"
+>/etc/host.conf</TT
+></A
+></H2
+><P
+><TT
+CLASS="FILENAME"
+>/etc/host.conf</TT
+> is the primary means by 
+which the setting in /etc/resolv.conf may be affected. It is a 
+critical configuration file.  This file controls the order by 
+which name resolution may procede. The typical structure is:</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>	order hosts,bind
+	multi on</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>then both addresses should be returned. Please refer to the 
+man page for host.conf for further details.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN283"
+>2.2.4. <TT
+CLASS="FILENAME"
+>/etc/nsswitch.conf</TT
+></A
+></H2
+><P
+>This file controls the actual name resolution targets. The 
+file typically has resolver object specifications as follows:</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>	# /etc/nsswitch.conf
+	#
+	# Name Service Switch configuration file.
+	#
+
+	passwd:		compat
+	# Alternative entries for password authentication are:
+	# passwd:	compat files nis ldap winbind
+	shadow:		compat
+	group:		compat
+
+	hosts:		files nis dns
+	# Alternative entries for host name resolution are:
+	# hosts:	files dns nis nis+ hesoid db compat ldap wins
+	networks:	nis files dns
+
+	ethers:		nis files
+	protocols:	nis files
+	rpc:		nis files
+	services:	nis files</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>Of course, each of these mechanisms requires that the appropriate 
+facilities and/or services are correctly configured.</P
+><P
+>It should be noted that unless a network request/message must be 
+sent, TCP/IP networks are silent. All TCP/IP communications assumes a 
+principal of speaking only when necessary.</P
+><P
+>Samba version 2.2.0 will add Linux support for extensions to 
+the name service switch infrastructure so that linux clients will 
+be able to obtain resolution of MS Windows NetBIOS names to IP 
+Addresses. To gain this functionality Samba needs to be compiled 
+with appropriate arguments to the make command (ie: <B
+CLASS="COMMAND"
+>make 
+nsswitch/libnss_wins.so</B
+>). The resulting library should 
+then be installed in the <TT
+CLASS="FILENAME"
+>/lib</TT
+> directory and 
+the "wins" parameter needs to be added to the "hosts:" line in 
+the <TT
+CLASS="FILENAME"
+>/etc/nsswitch.conf</TT
+> file. At this point it 
+will be possible to ping any MS Windows machine by it's NetBIOS 
+machine name, so long as that machine is within the workgroup to 
+which both the samba machine and the MS Windows machine belong.</P
+></DIV
+></DIV
+><DIV
+CLASS="SECT1"
+><HR><H1
+CLASS="SECT1"
+><A
+NAME="AEN295"
+>2.3. Name resolution as used within MS Windows networking</A
+></H1
+><P
+>MS Windows networking is predicated about the name each machine 
+is given. This name is known variously (and inconsistently) as 
+the "computer name", "machine name", "networking name", "netbios name", 
+"SMB name". All terms mean the same thing with the exception of 
+"netbios name" which can apply also to the name of the workgroup or the 
+domain name. The terms "workgroup" and "domain" are really just a 
+simply name with which the machine is associated. All NetBIOS names 
+are exactly 16 characters in length. The 16th character is reserved. 
+It is used to store a one byte value that indicates service level 
+information for the NetBIOS name that is registered. A NetBIOS machine 
+name is therefore registered for each service type that is provided by 
+the client/server.</P
+><P
+>The following are typical NetBIOS name/service type registrations:</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>	Unique NetBIOS Names:
+		MACHINENAME&#60;00&#62;	= Server Service is running on MACHINENAME
+		MACHINENAME&#60;03&#62; = Generic Machine Name (NetBIOS name)
+		MACHINENAME&#60;20&#62; = LanMan Server service is running on MACHINENAME
+		WORKGROUP&#60;1b&#62; = Domain Master Browser
+
+	Group Names:
+		WORKGROUP&#60;03&#62; = Generic Name registered by all members of WORKGROUP
+		WORKGROUP&#60;1c&#62; = Domain Controllers / Netlogon Servers
+		WORKGROUP&#60;1d&#62; = Local Master Browsers
+		WORKGROUP&#60;1e&#62; = Internet Name Resolvers</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>It should be noted that all NetBIOS machines register their own 
+names as per the above. This is in vast contrast to TCP/IP 
+installations where traditionally the system administrator will 
+determine in the /etc/hosts or in the DNS database what names 
+are associated with each IP address.</P
+><P
+>One further point of clarification should be noted, the <TT
+CLASS="FILENAME"
+>/etc/hosts</TT
+> 
+file and the DNS records do not provide the NetBIOS name type information 
+that MS Windows clients depend on to locate the type of service that may 
+be needed. An example of this is what happens when an MS Windows client 
+wants to locate a domain logon server. It find this service and the IP 
+address of a server that provides it by performing a lookup (via a 
+NetBIOS broadcast) for enumeration of all machines that have 
+registered the name type *&#60;1c&#62;. A logon request is then sent to each 
+IP address that is returned in the enumerated list of IP addresses. Which 
+ever machine first replies then ends up providing the logon services.</P
+><P
+>The name "workgroup" or "domain" really can be confusing since these 
+have the added significance of indicating what is the security 
+architecture of the MS Windows network. The term "workgroup" indicates 
+that the primary nature of the network environment is that of a 
+peer-to-peer design. In a WORKGROUP all machines are responsible for 
+their own security, and generally such security is limited to use of 
+just a password (known as SHARE MORE security). In most situations 
+with peer-to-peer networking the users who control their own machines 
+will simply opt to have no security at all. It is possible to have 
+USER MODE security in a WORKGROUP environment, thus requiring use 
+of a user name and a matching password.</P
+><P
+>MS Windows networking is thus predetermined to use machine names 
+for all local and remote machine message passing. The protocol used is 
+called Server Message Block (SMB) and this is implemented using 
+the NetBIOS protocol (Network Basic Input Output System). NetBIOS can 
+be encapsulated using LLC (Logical Link Control) protocol - in which case 
+the resulting protocol is called NetBEUI (Network Basic Extended User 
+Interface). NetBIOS can also be run over IPX (Internetworking Packet 
+Exchange) protocol as used by Novell NetWare, and it can be run 
+over TCP/IP protocols - in which case the resulting protocol is called 
+NBT or NetBT, the NetBIOS over TCP/IP.</P
+><P
+>MS Windows machines use a complex array of name resolution mechanisms. 
+Since we are primarily concerned with TCP/IP this demonstration is 
+limited to this area.</P
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN307"
+>2.3.1. The NetBIOS Name Cache</A
+></H2
+><P
+>All MS Windows machines employ an in memory buffer in which is 
+stored the NetBIOS names and their IP addresses for all external 
+machines that that the local machine has communicated with over the 
+past 10-15 minutes. It is more efficient to obtain an IP address 
+for a machine from the local cache than it is to go through all the 
+configured name resolution mechanisms.</P
+><P
+>If a machine whose name is in the local name cache has been shut 
+down before the name had been expired and flushed from the cache, then 
+an attempt to exchange a message with that machine will be subject 
+to time-out delays. ie: It's name is in the cache, so a name resolution 
+lookup will succeed, but the machine can not respond. This can be 
+frustrating for users - but it is a characteristic of the protocol.</P
+><P
+>The MS Windows utility that allows examination of the NetBIOS 
+name cache is called "nbtstat". The Samba equivalent of this 
+is called "nmblookup".</P
+></DIV
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN312"
+>2.3.2. The LMHOSTS file</A
+></H2
+><P
+>This file is usually located in MS Windows NT 4.0 or 
+2000 in <TT
+CLASS="FILENAME"
+>C:\WINNT\SYSTEM32\DRIVERS\ETC</TT
+> and contains 
+the IP Address and the machine name in matched pairs. The 
+<TT
+CLASS="FILENAME"
+>LMHOSTS</TT
+> file performs NetBIOS name 
+to IP address mapping oriented.</P
+><P
+>It typically looks like:</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>	# Copyright (c) 1998 Microsoft Corp.
+	#
+	# This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS
+	# over TCP/IP) stack for Windows98
+	#
+	# This file contains the mappings of IP addresses to NT computernames
+	# (NetBIOS) names.  Each entry should be kept on an individual line.
+	# The IP address should be placed in the first column followed by the
+	# corresponding computername. The address and the comptername
+	# should be separated by at least one space or tab. The "#" character
+	# is generally used to denote the start of a comment (see the exceptions
+	# below).
+	#
+	# This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts
+	# files and offers the following extensions:
+	#
+	#      #PRE
+	#      #DOM:&#60;domain&#62;
+	#      #INCLUDE &#60;filename&#62;
+	#      #BEGIN_ALTERNATE
+	#      #END_ALTERNATE
+	#      \0xnn (non-printing character support)
+	#
+	# Following any entry in the file with the characters "#PRE" will cause
+	# the entry to be preloaded into the name cache. By default, entries are
+	# not preloaded, but are parsed only after dynamic name resolution fails.
+	#
+	# Following an entry with the "#DOM:&#60;domain&#62;" tag will associate the
+	# entry with the domain specified by &#60;domain&#62;. This affects how the
+	# browser and logon services behave in TCP/IP environments. To preload
+	# the host name associated with #DOM entry, it is necessary to also add a
+	# #PRE to the line. The &#60;domain&#62; is always preloaded although it will not
+	# be shown when the name cache is viewed.
+	#
+	# Specifying "#INCLUDE &#60;filename&#62;" will force the RFC NetBIOS (NBT)
+	# software to seek the specified &#60;filename&#62; and parse it as if it were
+	# local. &#60;filename&#62; is generally a UNC-based name, allowing a
+	# centralized lmhosts file to be maintained on a server.
+	# It is ALWAYS necessary to provide a mapping for the IP address of the
+	# server prior to the #INCLUDE. This mapping must use the #PRE directive.
+	# In addtion the share "public" in the example below must be in the
+	# LanManServer list of "NullSessionShares" in order for client machines to
+	# be able to read the lmhosts file successfully. This key is under
+	# \machine\system\currentcontrolset\services\lanmanserver\parameters\nullsessionshares
+	# in the registry. Simply add "public" to the list found there.
+	#
+	# The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE
+	# statements to be grouped together. Any single successful include
+	# will cause the group to succeed.
+	#
+	# Finally, non-printing characters can be embedded in mappings by
+	# first surrounding the NetBIOS name in quotations, then using the
+	# \0xnn notation to specify a hex value for a non-printing character.
+	#
+	# The following example illustrates all of these extensions:
+	#
+	# 102.54.94.97     rhino         #PRE #DOM:networking  #net group's DC
+	# 102.54.94.102    "appname  \0x14"                    #special app server
+	# 102.54.94.123    popular            #PRE             #source server
+	# 102.54.94.117    localsrv           #PRE             #needed for the include
+	#
+	# #BEGIN_ALTERNATE
+	# #INCLUDE \\localsrv\public\lmhosts
+	# #INCLUDE \\rhino\public\lmhosts
+	# #END_ALTERNATE
+	#
+	# In the above example, the "appname" server contains a special
+	# character in its name, the "popular" and "localsrv" server names are
+	# preloaded, and the "rhino" server name is specified so it can be used
+	# to later #INCLUDE a centrally maintained lmhosts file if the "localsrv"
+	# system is unavailable.
+	#
+	# Note that the whole file is parsed including comments on each lookup,
+	# so keeping the number of comments to a minimum will improve performance.
+	# Therefore it is not advisable to simply add lmhosts file entries onto the
+	# end of this file.</PRE
+></TD
+></TR
+></TABLE
+></P
+></DIV
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN320"
+>2.3.3. HOSTS file</A
+></H2
+><P
+>This file is usually located in MS Windows NT 4.0 or 2000 in 
+<TT
+CLASS="FILENAME"
+>C:\WINNT\SYSTEM32\DRIVERS\ETC</TT
+> and contains 
+the IP Address and the IP hostname in matched pairs. It can be 
+used by the name resolution infrastructure in MS Windows, depending 
+on how the TCP/IP environment is configured. This file is in 
+every way the equivalent of the Unix/Linux <TT
+CLASS="FILENAME"
+>/etc/hosts</TT
+> file.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN325"
+>2.3.4. DNS Lookup</A
+></H2
+><P
+>This capability is configured in the TCP/IP setup area in the network 
+configuration facility. If enabled an elaborate name resolution sequence 
+is followed the precise nature of which isdependant on what the NetBIOS 
+Node Type parameter is configured to. A Node Type of 0 means use 
+NetBIOS broadcast (over UDP broadcast) is first used if the name 
+that is the subject of a name lookup is not found in the NetBIOS name 
+cache. If that fails then DNS, HOSTS and LMHOSTS are checked. If set to 
+Node Type 8, then a NetBIOS Unicast (over UDP Unicast) is sent to the 
+WINS Server to obtain a lookup before DNS, HOSTS, LMHOSTS, or broadcast 
+lookup is used.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN328"
+>2.3.5. WINS Lookup</A
+></H2
+><P
+>Refer to above details for section <EM
+>DNS Lookups</EM
+>. A 
+WINS (Windows Internet Name Server) service is the equivaent of the 
+rfc1001/1002 specified NBNS (NetBIOS Name Server). A WINS server stores 
+the names and IP addresses that are registered by a Windows client 
+if the TCP/IP setup has been given at least one WINS Server IP Address.</P
+><P
+>To configure Samba to be a WINS server the following parameter needs 
+to be added to the <TT
+CLASS="FILENAME"
+>smb.conf</TT
+> file:</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>	wins support = Yes</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>To configure Samba to use a WINS server the following parameters are 
+needed in the smb.conf file:</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>	wins support = No
+	wins server = xxx.xxx.xxx.xxx</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>where <TT
+CLASS="REPLACEABLE"
+><I
+>xxx.xxx.xxx.xxx</I
+></TT
+> is the IP address 
+of the WINS server.</P
+></DIV
+></DIV
+><DIV
+CLASS="SECT1"
+><HR><H1
+CLASS="SECT1"
+><A
+NAME="AEN341"
+>2.4. How browsing functions and how to deploy stable and 
+dependable browsing using Samba</A
+></H1
+><P
+>As stated above, MS Windows machines register their NetBIOS names 
+(ie: the machine name for each service type in operation) on start 
+up. Also, as stated above, the exact method by which this name registration 
+takes place is determined by whether or not the MS Windows client/server 
+has been given a WINS server address, whether or not LMHOSTS lookup 
+is enabled, or if DNS for NetBIOS name resolution is enabled, etc.</P
+><P
+>In the case where there is no WINS server all name registrations as 
+well as name lookups are done by UDP broadcast. This isolates name 
+resolution to the local subnet, unless LMHOSTS is used to list all 
+names and IP addresses. In such situations Samba provides a means by 
+which the samba server name may be forcibly injected into the browse 
+list of a remote MS Windows network (using the "remote announce" parameter).</P
+><P
+>Where a WINS server is used, the MS Windows client will use UDP 
+unicast to register with the WINS server. Such packets can be routed 
+and thus WINS allows name resolution to function across routed networks.</P
+><P
+>During the startup process an election will take place to create a 
+local master browser if one does not already exist. On each NetBIOS network 
+one machine will be elected to function as the domain master browser. This 
+domain browsing has nothing to do with MS security domain control. 
+Instead, the domain master browser serves the role of contacting each local 
+master browser (found by asking WINS or from LMHOSTS) and exchanging browse 
+list contents. This way every master browser will eventually obtain a complete 
+list of all machines that are on the network. Every 11-15 minutes an election 
+is held to determine which machine will be the master browser. By nature of 
+the election criteria used, the machine with the highest uptime, or the 
+most senior protocol version, or other criteria, will win the election 
+as domain master browser.</P
+><P
+>Clients wishing to browse the network make use of this list, but also depend 
+on the availability of correct name resolution to the respective IP 
+address/addresses. </P
+><P
+>Any configuration that breaks name resolution and/or browsing intrinsics 
+will annoy users because they will have to put up with protracted 
+inability to use the network services.</P
+><P
+>Samba supports a feature that allows forced synchonisation 
+of browse lists across routed networks using the "remote 
+browse sync" parameter in the smb.conf file. This causes Samba 
+to contact the local master browser on a remote network and 
+to request browse list synchronisation. This effectively bridges 
+two networks that are separated by routers. The two remote 
+networks may use either broadcast based name resolution or WINS 
+based name resolution, but it should be noted that the "remote 
+browse sync" parameter provides browse list synchronisation - and 
+that is distinct from name to address resolution, in other 
+words, for cross subnet browsing to function correctly it is 
+essential that a name to address resolution mechanism be provided. 
+This mechanism could be via DNS, <TT
+CLASS="FILENAME"
+>/etc/hosts</TT
+>, 
+and so on.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><HR><H1
+CLASS="SECT1"
+><A
+NAME="AEN351"
+>2.5. MS Windows security options and how to configure 
+Samba for seemless integration</A
+></H1
+><P
+>MS Windows clients may use encrypted passwords alone, or encrypted 
+as well as plain text passwords in the authentication process. It 
+should be realized that with the SMB protocol the password is passed 
+over the network either in plain text or encrypted. When encrypted 
+passwords are used a password that has been entered by the user is 
+encrypted in two ways:</P
+><P
+></P
+><UL
+><LI
+><P
+>The case preserved password is encrypted 
+	using an MD5/DES one way hash
+	</P
+></LI
+><LI
+><P
+>The case is converted to upper case and then 
+	encrypted using an MD5/DES one way hash</P
+></LI
+></UL
+><P
+>Both of these enrypted passwords are sent over the network 
+in the one authentication datagram.</P
+><P
+>MS Windows 95 pre-service pack 1, MS Windows NT versions 3.x 
+and version 4.0 pre-service pack 3 will use either mode of 
+password authentication. All versions of MS Windows that follow 
+these versions no longer support plain text passwords by default.</P
+><P
+>MS Windows clients have a habit of dropping network mappings that 
+have been idle for 10 minutes or longer. When the user attempts to 
+use the mapped drive connection that has been dropped the SMB protocol 
+has a mechanism by which the connection can be re-established using 
+a cached copy of the password.</P
+><P
+>When Microsoft changed the default password mode, they dropped support for 
+caching of the plain text password. This means that when the registry 
+parameter is changed to re-enable use of plain text passwords it appears to 
+work, but when a dropped mapping attempts to revalidate it will fail if 
+the remote authentication server does not support encrypted passwords. 
+This means that it is definitely not a good idea to re-enable plain text 
+password support in such clients.</P
+><P
+>It is recommended that the following parameters be added to the 
+smb.conf file:</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>	passsword level = 8
+	username level = 8</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>these configuration parameters will compensate for the fact that 
+in some circumstances MS Windows and MS DOS clients may twiddle the 
+password that has been supplied by the user by converting characters to 
+upper case. The above entries will try every combination of upper and 
+lower case for the first 8 characters. Please refer to the man page 
+for smb.conf for more information on use of these parameters.</P
+><P
+>The best option to adopt is to enable support for encrypted passwords 
+where ever Samba is used. There are three configuration possibilities 
+for support of encrypted passwords:</P
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN368"
+>2.5.1. Use MS Windows NT as an authentication server</A
+></H2
+><P
+>This method involves the additions of the following parameters 
+in the smb.conf file:</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>	encrypt passwords = Yes
+	security = server
+	password server = "NetBIOS_name_of_PDC"</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>There are two ways of identifying whether or not a username and 
+password pair was valid or not. One uses the reply information provided 
+as part of the authentication messaging process, the other uses 
+just and error code.</P
+><P
+>The down-side of this mode of configuration is the fact that 
+for security reasons Samba will send the password server a bogus 
+username and a bogus password and if the remote server fails to 
+reject the username and password pair then an alternative mode 
+of identification of validation is used. Where a site uses password 
+lock out after a certain number of failed authentication attempts 
+this will result in user lockouts.</P
+><P
+>Use of this mode of authentication does require there to be 
+a standard Unix account for the user, this account can be blocked 
+to prevent logons by other than MS Windows clients.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN376"
+>2.5.2. Make Samba a member of an MS Windows NT security domain</A
+></H2
+><P
+>This method involves additon of the following paramters in the smb.conf file:</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>	encrypt passwords = Yes
+	security = domain
+	workgroup = "name of NT domain"
+	password server = *</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>The use of the "*" argument to "password server" will cause samba 
+to locate the domain controller in a way analogous to the way 
+this is done within MS Windows NT.</P
+><P
+>In order for this method to work the Samba server needs to join the 
+MS Windows NT security domain. This is done as follows:</P
+><P
+></P
+><UL
+><LI
+><P
+>On the MS Windows NT domain controller using 
+	the Server Manager add a machine account for the Samba server.
+	</P
+></LI
+><LI
+><P
+>Next, on the Linux system execute: 
+	<B
+CLASS="COMMAND"
+>smbpasswd -r PDC_NAME -j DOMAIN_NAME</B
+>
+	</P
+></LI
+></UL
+><P
+>Use of this mode of authentication does require there to be 
+a standard Unix account for the user, this account can be 
+blocked to prevent logons by other than MS Windows clients.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN390"
+>2.5.3. Configure Samba as an authentication server</A
+></H2
+><P
+>This mode of authentication demands that there be on the 
+Unix/Linux system both a Unix style account as well as and 
+smbpasswd entry for the user. The Unix system account can be 
+locked if required as only the encrypted password will be 
+used for SMB client authentication.</P
+><P
+>This method involves addition of the following parameters to 
+the smb.conf file:</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>	encrypt passwords = Yes
+	security = user</PRE
+></TD
+></TR
+></TABLE
+></P
+><P
+>in order for this method to work a Unix system account needs 
+to be created for each user, as well as for each MS Windows NT/2000 
+machine. The following structure is required.</P
+><DIV
+CLASS="SECT3"
+><HR><H3
+CLASS="SECT3"
+><A
+NAME="AEN397"
+>2.5.3.1. Users</A
+></H3
+><P
+>A user account that may provide a home directory should be 
+created. The following Linux system commands are typical of 
+the procedure for creating an account.</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>	# useradd -s /bin/bash -d /home/"userid" -m
+	# passwd "userid"
+	  Enter Password: <TT
+CLASS="USERINPUT"
+><B
+>pass</B
+></TT
+>
+	  
+	# smbpasswd -a "userid"
+	  Enter Password: <TT
+CLASS="USERINPUT"
+><B
+>pass</B
+></TT
+></PRE
+></TD
+></TR
+></TABLE
+></P
+></DIV
+><DIV
+CLASS="SECT3"
+><HR><H3
+CLASS="SECT3"
+><A
+NAME="AEN404"
+>2.5.3.2. MS Windows NT Machine Accounts</A
+></H3
+><P
+>These are required only when Samba is used as a domain 
+controller.  Refer to the Samba-PDC-HOWTO for more details.</P
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>	# useradd -a /bin/false -d /dev/null "machine_name"\$
+	# passwd -l "machine_name"\$
+	# smbpasswd -a -m "machine_name"</PRE
+></TD
+></TR
+></TABLE
+></P
+></DIV
+></DIV
+></DIV
+><DIV
+CLASS="SECT1"
+><HR><H1
+CLASS="SECT1"
+><A
+NAME="AEN409"
+>2.6. Configuration of Samba as ...</A
+></H1
+><P
+></P
+><UL
+><LI
+><P
+>A Stand-alone server - No special action is needed 
+	other than to create user accounts. Stand-alone servers do NOT 
+	provide network logon services, meaning that machines that use this 
+	server do NOT perform a domain logon but instead make use only of 
+	the MS Windows logon which is local to the MS Windows 
+	workstation/server.
+	</P
+></LI
+><LI
+><P
+>An MS Windows NT 3.x/4.0 security domain member - 
+	Refer to the previous section(s) above.
+	</P
+></LI
+><LI
+><P
+>An alternative to an MS Windows NT 3.x/4.0 
+	Domain Controller - In the smb.conf file the following parameters 
+	should be added:</P
+></LI
+></UL
+><P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><PRE
+CLASS="PROGRAMLISTING"
+>## please refer to the Samba PDC HOWTO chapter later in 
+## this collection for more details
+[global]
+	domain logons = Yes
+	; an OS level of 33 or more is recommended
+	os level = 33
+
+	[NETLOGON]
+		path = /somewhare/in/file/system
+		read only = yes
+		available = yes</PRE
+></TD
+></TR
+></TABLE
+></P
+></DIV
+></DIV
+><DIV
+CLASS="CHAPTER"
+><HR><H1
+><A
+NAME="AEN420"
+>Chapter 3. LanMan and NT Password Encryption in Samba 2.x</A
+></H1
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN431"
+>3.1. Introduction</A
 ></H1
 ><P
 >With the development of LanManager and Windows NT 
@@ -1560,8 +2786,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN227"
->2.2. How does it work?</A
+NAME="AEN435"
+>3.2. How does it work?</A
 ></H1
 ><P
 >LanManager encryption is somewhat similar to UNIX 
@@ -1625,8 +2851,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN238"
->2.3. Important Notes About Security</A
+NAME="AEN446"
+>3.3. Important Notes About Security</A
 ></H1
 ><P
 >The unix and SMB password encryption techniques seem similar 
@@ -1717,8 +2943,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN257"
->2.3.1. Advantages of SMB Encryption</A
+NAME="AEN465"
+>3.3.1. Advantages of SMB Encryption</A
 ></H2
 ><P
 ></P
@@ -1746,8 +2972,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN264"
->2.3.2. Advantages of non-encrypted passwords</A
+NAME="AEN472"
+>3.3.2. Advantages of non-encrypted passwords</A
 ></H2
 ><P
 ></P
@@ -1777,8 +3003,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN273"
->2.4. <A
+NAME="AEN481"
+>3.4. <A
 NAME="SMBPASSWDFILEFORMAT"
 ></A
 >The smbpasswd file</A
@@ -1996,8 +3222,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN325"
->2.5. The smbpasswd Command</A
+NAME="AEN533"
+>3.5. The smbpasswd Command</A
 ></H1
 ><P
 >The smbpasswd command maintains the two 32 byte password fields 
@@ -2134,8 +3360,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN364"
->2.6. Setting up Samba to support LanManager Encryption</A
+NAME="AEN572"
+>3.6. Setting up Samba to support LanManager Encryption</A
 ></H1
 ><P
 >This is a very brief description on how to setup samba to 
@@ -2181,16 +3407,16 @@ HREF="#SMBPASSWDFILEFORMAT"
 CLASS="CHAPTER"
 ><HR><H1
 ><A
-NAME="AEN379"
->Chapter 3. Hosting a Microsoft Distributed File System tree on Samba</A
+NAME="AEN587"
+>Chapter 4. Hosting a Microsoft Distributed File System tree on Samba</A
 ></H1
 ><DIV
 CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN390"
->3.1. Instructions</A
+NAME="AEN598"
+>4.1. Instructions</A
 ></H1
 ><P
 >The Distributed File System (or Dfs) provides a means of 
@@ -2346,8 +3572,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN425"
->3.1.1. Notes</A
+NAME="AEN633"
+>4.1.1. Notes</A
 ></H2
 ><P
 ></P
@@ -2379,16 +3605,16 @@ NAME="AEN425"
 CLASS="CHAPTER"
 ><HR><H1
 ><A
-NAME="AEN434"
->Chapter 4. Printing Support in Samba 2.2.x</A
+NAME="AEN642"
+>Chapter 5. Printing Support in Samba 2.2.x</A
 ></H1
 ><DIV
 CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN445"
->4.1. Introduction</A
+NAME="AEN653"
+>5.1. Introduction</A
 ></H1
 ><P
 >Beginning with the 2.2.0 release, Samba supports 
@@ -2471,8 +3697,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN467"
->4.2. Configuration</A
+NAME="AEN675"
+>5.2. Configuration</A
 ></H1
 ><DIV
 CLASS="WARNING"
@@ -2539,8 +3765,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN478"
->4.2.1. Creating [print$]</A
+NAME="AEN686"
+>5.2.1. Creating [print$]</A
 ></H2
 ><P
 >In order to support the uploading of printer driver 
@@ -2733,8 +3959,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN513"
->4.2.2. Setting Drivers for Existing Printers</A
+NAME="AEN721"
+>5.2.2. Setting Drivers for Existing Printers</A
 ></H2
 ><P
 >The initial listing of printers in the Samba host's 
@@ -2805,8 +4031,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN530"
->4.2.3. Support a large number of printers</A
+NAME="AEN738"
+>5.2.3. Support a large number of printers</A
 ></H2
 ><P
 >One issue that has arisen during the development
@@ -2880,8 +4106,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN541"
->4.2.4. Adding New Printers via the Windows NT APW</A
+NAME="AEN749"
+>5.2.4. Adding New Printers via the Windows NT APW</A
 ></H2
 ><P
 >By default, Samba offers all printer shares defined in <TT
@@ -2986,8 +4212,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN566"
->4.2.5. Samba and Printer Ports</A
+NAME="AEN774"
+>5.2.5. Samba and Printer Ports</A
 ></H2
 ><P
 >Windows NT/2000 print servers associate a port with each printer.  These normally
@@ -3023,8 +4249,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN574"
->4.3. The Imprints Toolset</A
+NAME="AEN782"
+>5.3. The Imprints Toolset</A
 ></H1
 ><P
 >The Imprints tool set provides a UNIX equivalent of the 
@@ -3041,8 +4267,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN578"
->4.3.1. What is Imprints?</A
+NAME="AEN786"
+>5.3.1. What is Imprints?</A
 ></H2
 ><P
 >Imprints is a collection of tools for supporting the goals 
@@ -3073,8 +4299,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN588"
->4.3.2. Creating Printer Driver Packages</A
+NAME="AEN796"
+>5.3.2. Creating Printer Driver Packages</A
 ></H2
 ><P
 >The process of creating printer driver packages is beyond
@@ -3089,8 +4315,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN591"
->4.3.3. The Imprints server</A
+NAME="AEN799"
+>5.3.3. The Imprints server</A
 ></H2
 ><P
 >The Imprints server is really a database server that 
@@ -3109,8 +4335,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN595"
->4.3.4. The Installation Client</A
+NAME="AEN803"
+>5.3.4. The Installation Client</A
 ></H2
 ><P
 >More information regarding the Imprints installation client 
@@ -3212,8 +4438,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN617"
->4.4. <A
+NAME="AEN825"
+>5.4. <A
 NAME="MIGRATION"
 ></A
 >Migration to from Samba 2.0.x to 2.2.x</A
@@ -3389,16 +4615,16 @@ TARGET="_top"
 CLASS="CHAPTER"
 ><HR><H1
 ><A
-NAME="AEN661"
->Chapter 5. security = domain in Samba 2.x</A
+NAME="AEN869"
+>Chapter 6. security = domain in Samba 2.x</A
 ></H1
 ><DIV
 CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN679"
->5.1. Joining an NT Domain with Samba 2.2</A
+NAME="AEN887"
+>6.1. Joining an NT Domain with Samba 2.2</A
 ></H1
 ><P
 >In order for a Samba-2 server to join an NT domain, 
@@ -3624,8 +4850,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN743"
->5.2. Samba and Windows 2000 Domains</A
+NAME="AEN951"
+>6.2. Samba and Windows 2000 Domains</A
 ></H1
 ><P
 >Many people have asked regarding the state of Samba's ability to participate in
@@ -3649,8 +4875,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN748"
->5.3. Why is this better than security = server?</A
+NAME="AEN956"
+>6.3. Why is this better than security = server?</A
 ></H1
 ><P
 >Currently, domain security in Samba doesn't free you from 
@@ -3735,16 +4961,16 @@ TARGET="_top"
 CLASS="CHAPTER"
 ><HR><H1
 ><A
-NAME="AEN764"
->Chapter 6. How to Configure Samba 2.2 as a Primary Domain Controller</A
+NAME="AEN972"
+>Chapter 7. How to Configure Samba 2.2 as a Primary Domain Controller</A
 ></H1
 ><DIV
 CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN781"
->6.1. Prerequisite Reading</A
+NAME="AEN989"
+>7.1. Prerequisite Reading</A
 ></H1
 ><P
 >Before you continue readingin this chapter, please make sure 
@@ -3771,8 +4997,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN787"
->6.2. Background</A
+NAME="AEN995"
+>7.2. Background</A
 ></H1
 ><DIV
 CLASS="NOTE"
@@ -3928,8 +5154,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN827"
->6.3. Configuring the Samba Domain Controller</A
+NAME="AEN1035"
+>7.3. Configuring the Samba Domain Controller</A
 ></H1
 ><P
 >The first step in creating a working Samba PDC is to 
@@ -4150,8 +5376,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN870"
->6.4. Creating Machine Trust Accounts and Joining Clients 
+NAME="AEN1078"
+>7.4. Creating Machine Trust Accounts and Joining Clients 
 to the Domain</A
 ></H1
 ><P
@@ -4208,8 +5434,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN884"
->6.4.1. Manually creating machine trust accounts</A
+NAME="AEN1092"
+>7.4.1. Manually creating machine trust accounts</A
 ></H2
 ><P
 >The first step in creating a machine trust account by hand is to 
@@ -4348,8 +5574,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN912"
->6.4.2. Creating machine trust accounts "on the fly"</A
+NAME="AEN1120"
+>7.4.2. Creating machine trust accounts "on the fly"</A
 ></H2
 ><P
 >The second, and most recommended way of creating machine trust accounts 
@@ -4396,8 +5622,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN923"
->6.5. Common Problems and Errors</A
+NAME="AEN1131"
+>7.5. Common Problems and Errors</A
 ></H1
 ><P
 ></P
@@ -4595,8 +5821,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN971"
->6.6. System Policies and Profiles</A
+NAME="AEN1179"
+>7.6. System Policies and Profiles</A
 ></H1
 ><P
 >Much of the information necessary to implement System Policies and
@@ -4752,8 +5978,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1015"
->6.7. What other help can I get ?</A
+NAME="AEN1223"
+>7.7. What other help can I get ?</A
 ></H1
 ><P
 >There are many sources of information available in the form 
@@ -5148,8 +6374,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1129"
->6.8. Domain Control for Windows 9x/ME</A
+NAME="AEN1337"
+>7.8. Domain Control for Windows 9x/ME</A
 ></H1
 ><DIV
 CLASS="NOTE"
@@ -5284,8 +6510,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1159"
->6.8.1. Configuration Instructions:	Network Logons</A
+NAME="AEN1367"
+>7.8.1. Configuration Instructions:	Network Logons</A
 ></H2
 ><P
 >To use domain logons and profiles you need to do the following:</P
@@ -5473,8 +6699,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1193"
->6.8.2. Configuration Instructions:	Setting up Roaming User Profiles</A
+NAME="AEN1401"
+>7.8.2. Configuration Instructions:	Setting up Roaming User Profiles</A
 ></H2
 ><DIV
 CLASS="WARNING"
@@ -5520,8 +6746,8 @@ CLASS="SECT3"
 ><HR><H3
 CLASS="SECT3"
 ><A
-NAME="AEN1201"
->6.8.2.1. Windows NT Configuration</A
+NAME="AEN1409"
+>7.8.2.1. Windows NT Configuration</A
 ></H3
 ><P
 >To support WinNT clients, inn the [global] section of smb.conf set the
@@ -5564,8 +6790,8 @@ CLASS="SECT3"
 ><HR><H3
 CLASS="SECT3"
 ><A
-NAME="AEN1209"
->6.8.2.2. Windows 9X Configuration</A
+NAME="AEN1417"
+>7.8.2.2. Windows 9X Configuration</A
 ></H3
 ><P
 >To support Win9X clients, you must use the "logon home" parameter. Samba has
@@ -5604,8 +6830,8 @@ CLASS="SECT3"
 ><HR><H3
 CLASS="SECT3"
 ><A
-NAME="AEN1217"
->6.8.2.3. Win9X and WinNT Configuration</A
+NAME="AEN1425"
+>7.8.2.3. Win9X and WinNT Configuration</A
 ></H3
 ><P
 >You can support profiles for both Win9X and WinNT clients by setting both the
@@ -5642,8 +6868,8 @@ CLASS="SECT3"
 ><HR><H3
 CLASS="SECT3"
 ><A
-NAME="AEN1224"
->6.8.2.4. Windows 9X Profile Setup</A
+NAME="AEN1432"
+>7.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,
@@ -5798,8 +7024,8 @@ CLASS="SECT3"
 ><HR><H3
 CLASS="SECT3"
 ><A
-NAME="AEN1260"
->6.8.2.5. Windows NT Workstation 4.0</A
+NAME="AEN1468"
+>7.8.2.5. Windows NT Workstation 4.0</A
 ></H3
 ><P
 >When a user first logs in to a Windows NT Workstation, the profile
@@ -5880,8 +7106,8 @@ CLASS="SECT3"
 ><HR><H3
 CLASS="SECT3"
 ><A
-NAME="AEN1273"
->6.8.2.6. Windows NT Server</A
+NAME="AEN1481"
+>7.8.2.6. Windows NT Server</A
 ></H3
 ><P
 >There is nothing to stop you specifying any path that you like for the
@@ -5894,8 +7120,8 @@ CLASS="SECT3"
 ><HR><H3
 CLASS="SECT3"
 ><A
-NAME="AEN1276"
->6.8.2.7. Sharing Profiles between W95 and NT Workstation 4.0</A
+NAME="AEN1484"
+>7.8.2.7. Sharing Profiles between W95 and NT Workstation 4.0</A
 ></H3
 ><DIV
 CLASS="WARNING"
@@ -5959,8 +7185,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1286"
->6.9. DOMAIN_CONTROL.txt : Windows NT Domain Control &#38; Samba</A
+NAME="AEN1494"
+>7.9. DOMAIN_CONTROL.txt : Windows NT Domain Control &#38; Samba</A
 ></H1
 ><DIV
 CLASS="WARNING"
@@ -6080,16 +7306,16 @@ within its registry.</P
 CLASS="CHAPTER"
 ><HR><H1
 ><A
-NAME="AEN1311"
->Chapter 7. Unifed Logons between Windows NT and UNIX using Winbind</A
+NAME="AEN1519"
+>Chapter 8. Unifed Logons between Windows NT and UNIX using Winbind</A
 ></H1
 ><DIV
 CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1329"
->7.1. Abstract</A
+NAME="AEN1537"
+>8.1. Abstract</A
 ></H1
 ><P
 >Integration of UNIX and Microsoft Windows NT through 
@@ -6110,8 +7336,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1333"
->7.2. Introduction</A
+NAME="AEN1541"
+>8.2. Introduction</A
 ></H1
 ><P
 >It is well known that UNIX and Microsoft Windows NT have 
@@ -6164,8 +7390,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1346"
->7.3. What Winbind Provides</A
+NAME="AEN1554"
+>8.3. What Winbind Provides</A
 ></H1
 ><P
 >Winbind unifies UNIX and Windows NT account management by 
@@ -6206,8 +7432,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1353"
->7.3.1. Target Uses</A
+NAME="AEN1561"
+>8.3.1. Target Uses</A
 ></H2
 ><P
 >Winbind is targeted at organizations that have an 
@@ -6230,8 +7456,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1357"
->7.4. How Winbind Works</A
+NAME="AEN1565"
+>8.4. How Winbind Works</A
 ></H1
 ><P
 >The winbind system is designed around a client/server 
@@ -6250,8 +7476,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1362"
->7.4.1. Microsoft Remote Procedure Calls</A
+NAME="AEN1570"
+>8.4.1. Microsoft Remote Procedure Calls</A
 ></H2
 ><P
 >Over the last two years, efforts have been underway 
@@ -6276,8 +7502,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1366"
->7.4.2. Name Service Switch</A
+NAME="AEN1574"
+>8.4.2. Name Service Switch</A
 ></H2
 ><P
 >The Name Service Switch, or NSS, is a feature that is 
@@ -6355,8 +7581,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1382"
->7.4.3. Pluggable Authentication Modules</A
+NAME="AEN1590"
+>8.4.3. Pluggable Authentication Modules</A
 ></H2
 ><P
 >Pluggable Authentication Modules, also known as PAM, 
@@ -6404,8 +7630,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1390"
->7.4.4. User and Group ID Allocation</A
+NAME="AEN1598"
+>8.4.4. User and Group ID Allocation</A
 ></H2
 ><P
 >When a user or group is created under Windows NT 
@@ -6430,8 +7656,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1394"
->7.4.5. Result Caching</A
+NAME="AEN1602"
+>8.4.5. Result Caching</A
 ></H2
 ><P
 >An active system can generate a lot of user and group 
@@ -6453,8 +7679,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1397"
->7.5. Installation and Configuration</A
+NAME="AEN1605"
+>8.5. Installation and Configuration</A
 ></H1
 ><P
 >The easiest way to install winbind is by using the packages 
@@ -6484,8 +7710,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1403"
->7.6. Limitations</A
+NAME="AEN1611"
+>8.6. Limitations</A
 ></H1
 ><P
 >Winbind has a number of limitations in its current 
@@ -6532,8 +7758,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1415"
->7.7. Conclusion</A
+NAME="AEN1623"
+>8.7. Conclusion</A
 ></H1
 ><P
 >The winbind system, through the use of the Name Service 
@@ -6548,16 +7774,16 @@ NAME="AEN1415"
 CLASS="CHAPTER"
 ><HR><H1
 ><A
-NAME="AEN1418"
->Chapter 8. UNIX Permission Bits and WIndows NT Access Control Lists</A
+NAME="AEN1626"
+>Chapter 9. UNIX Permission Bits and WIndows NT Access Control Lists</A
 ></H1
 ><DIV
 CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1429"
->8.1. Viewing and changing UNIX permissions using the NT 
+NAME="AEN1637"
+>9.1. Viewing and changing UNIX permissions using the NT 
 	security dialogs</A
 ></H1
 ><P
@@ -6595,8 +7821,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1438"
->8.2. How to view file security on a Samba share</A
+NAME="AEN1646"
+>9.2. How to view file security on a Samba share</A
 ></H1
 ><P
 >From an NT 4.0 client, single-click with the right 
@@ -6641,8 +7867,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1449"
->8.3. Viewing file ownership</A
+NAME="AEN1657"
+>9.3. Viewing file ownership</A
 ></H1
 ><P
 >Clicking on the <B
@@ -6727,8 +7953,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1469"
->8.4. Viewing file or directory permissions</A
+NAME="AEN1677"
+>9.4. Viewing file or directory permissions</A
 ></H1
 ><P
 >The third button is the <B
@@ -6789,8 +8015,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1484"
->8.4.1. File Permissions</A
+NAME="AEN1692"
+>9.4.1. File Permissions</A
 ></H2
 ><P
 >The standard UNIX user/group/world triple and 
@@ -6851,8 +8077,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1498"
->8.4.2. Directory Permissions</A
+NAME="AEN1706"
+>9.4.2. Directory Permissions</A
 ></H2
 ><P
 >Directories on an NT NTFS file system have two 
@@ -6883,8 +8109,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1505"
->8.5. Modifying file or directory permissions</A
+NAME="AEN1713"
+>9.5. Modifying file or directory permissions</A
 ></H1
 ><P
 >Modifying file and directory permissions is as simple 
@@ -6981,8 +8207,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1527"
->8.6. Interaction with the standard Samba create mask 
+NAME="AEN1735"
+>9.6. Interaction with the standard Samba create mask 
 	parameters</A
 ></H1
 ><P
@@ -7254,8 +8480,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1591"
->8.7. Interaction with the standard Samba file attribute 
+NAME="AEN1799"
+>9.7. Interaction with the standard Samba file attribute 
 	mapping</A
 ></H1
 ><P
@@ -7301,24 +8527,24 @@ CLASS="COMMAND"
 CLASS="CHAPTER"
 ><HR><H1
 ><A
-NAME="AEN1601"
->Chapter 9. OS2 Client HOWTO</A
+NAME="AEN1809"
+>Chapter 10. OS2 Client HOWTO</A
 ></H1
 ><DIV
 CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1612"
->9.1. FAQs</A
+NAME="AEN1820"
+>10.1. FAQs</A
 ></H1
 ><DIV
 CLASS="SECT2"
 ><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1614"
->9.1.1. How can I configure OS/2 Warp Connect or 
+NAME="AEN1822"
+>10.1.1. How can I configure OS/2 Warp Connect or 
 		OS/2 Warp 4 as a client for Samba?</A
 ></H2
 ><P
@@ -7376,8 +8602,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1629"
->9.1.2. How can I configure OS/2 Warp 3 (not Connect), 
+NAME="AEN1837"
+>10.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
 ><P
@@ -7429,8 +8655,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1638"
->9.1.3. Are there any other issues when OS/2 (any version) 
+NAME="AEN1846"
+>10.1.3. Are there any other issues when OS/2 (any version) 
 		is used as a client?</A
 ></H2
 ><P
@@ -7451,8 +8677,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1642"
->9.1.4. How do I get printer driver download working 
+NAME="AEN1850"
+>10.1.4. How do I get printer driver download working 
 		for OS/2 clients?</A
 ></H2
 ><P
@@ -7499,16 +8725,16 @@ CLASS="REPLACEABLE"
 CLASS="CHAPTER"
 ><HR><H1
 ><A
-NAME="AEN1651"
->Chapter 10. HOWTO Access Samba source code via CVS</A
+NAME="AEN1859"
+>Chapter 11. HOWTO Access Samba source code via CVS</A
 ></H1
 ><DIV
 CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1658"
->10.1. Introduction</A
+NAME="AEN1866"
+>11.1. Introduction</A
 ></H1
 ><P
 >Samba is developed in an open environnment.  Developers use CVS
@@ -7529,8 +8755,8 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN1663"
->10.2. CVS Access to samba.org</A
+NAME="AEN1871"
+>11.2. CVS Access to samba.org</A
 ></H1
 ><P
 >The machine samba.org runs a publicly accessible CVS 
@@ -7542,8 +8768,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1666"
->10.2.1. Access via CVSweb</A
+NAME="AEN1874"
+>11.2.1. Access via CVSweb</A
 ></H2
 ><P
 >You can access the source code via your 
@@ -7563,8 +8789,8 @@ CLASS="SECT2"
 ><HR><H2
 CLASS="SECT2"
 ><A
-NAME="AEN1671"
->10.2.2. Access via cvs</A
+NAME="AEN1879"
+>11.2.2. Access via cvs</A
 ></H2
 ><P
 >You can also access the source code via a 
diff --git a/docs/htmldocs/Samba-PDC-HOWTO.html b/docs/htmldocs/Samba-PDC-HOWTO.html
index c2cdd9c60bb..883de3a0abb 100644
--- a/docs/htmldocs/Samba-PDC-HOWTO.html
+++ b/docs/htmldocs/Samba-PDC-HOWTO.html
@@ -1418,6 +1418,765 @@ CLASS="SECT1"
 CLASS="SECT1"
 ><A
 NAME="AEN351"
+>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="AEN381"
+>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
+><PRE
+CLASS="PROGRAMLISTING"
+>[netlogon]
+     path = /data/dos/netlogon
+     writeable = no
+     guest ok = no</PRE
+></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
+><PRE
+CLASS="PROGRAMLISTING"
+>domain logons = yes
+logon script = %U.bat
+	</PRE
+></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
+><PRE
+CLASS="PROGRAMLISTING"
+>logon script = scripts\%U.bat
+	</PRE
+></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="AEN415"
+>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
+><I
+CLASS="EMPHASIS"
+>NOTE!</I
+> 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="AEN423"
+>Windows NT Configuration</A
+></H3
+><P
+>To support WinNT clients, inn the [global] section of smb.conf set the
+following (for example):</P
+><P
+><PRE
+CLASS="PROGRAMLISTING"
+>logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath</PRE
+></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="AEN431"
+>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
+><PRE
+CLASS="PROGRAMLISTING"
+>logon home = \\%L\%U\.profiles</PRE
+></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="AEN439"
+>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
+><PRE
+CLASS="PROGRAMLISTING"
+>logon home = \\%L\%U\.profiles
+logon path = \\%L\profiles\%U</PRE
+></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="AEN446"
+>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
+>	<I
+CLASS="EMPHASIS"
+>WARNING</I
+> - 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="AEN482"
+>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="AEN495"
+>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="AEN498"
+>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="AEN508"
 >DOMAIN_CONTROL.txt : Windows NT Domain Control &#38; Samba</A
 ></H1
 ><DIV