summaryrefslogtreecommitdiff
path: root/docs/htmldocs/Samba-PDC-HOWTO.html
diff options
context:
space:
mode:
authorGerald Carter <jerry@samba.org>2001-06-01 11:50:38 +0000
committerGerald Carter <jerry@samba.org>2001-06-01 11:50:38 +0000
commit05b2b2cdd4895b6d2a4d345192bfd4fed1e0ec25 (patch)
tree0c08619346abcac14ae3eb579b60e8c58bf84822 /docs/htmldocs/Samba-PDC-HOWTO.html
parente07b85ab195509cd1bd83e813ecf464f5629c566 (diff)
downloadsamba-05b2b2cdd4895b6d2a4d345192bfd4fed1e0ec25.tar.gz
samba-05b2b2cdd4895b6d2a4d345192bfd4fed1e0ec25.tar.bz2
samba-05b2b2cdd4895b6d2a4d345192bfd4fed1e0ec25.zip
syncing up with SAMBA_2_2
(This used to be commit 1bc58c21b15fcdb0a504d051f60e20c4e24441e6)
Diffstat (limited to 'docs/htmldocs/Samba-PDC-HOWTO.html')
-rw-r--r--docs/htmldocs/Samba-PDC-HOWTO.html1631
1 files changed, 1339 insertions, 292 deletions
diff --git a/docs/htmldocs/Samba-PDC-HOWTO.html b/docs/htmldocs/Samba-PDC-HOWTO.html
index 668f7f9aff..883de3a0ab 100644
--- a/docs/htmldocs/Samba-PDC-HOWTO.html
+++ b/docs/htmldocs/Samba-PDC-HOWTO.html
@@ -1,7 +1,7 @@
<HTML
><HEAD
><TITLE
->How to Configure Samba 2.2.x as a Primary Domain Controller</TITLE
+>How to Configure Samba 2.2 as a Primary Domain Controller</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD
@@ -20,7 +20,7 @@ CLASS="TITLEPAGE"
CLASS="TITLE"
><A
NAME="AEN1"
->How to Configure Samba 2.2.x as a Primary Domain Controller</A
+>How to Configure Samba 2.2 as a Primary Domain Controller</A
></H1
><HR></DIV
><DIV
@@ -29,44 +29,127 @@ CLASS="SECT1"
CLASS="SECT1"
><A
NAME="AEN3"
+>Prerequisite Reading</A
+></H1
+><P
+>Before you continue readingin this chapter, please make sure
+that you are comfortable with configuring basic files services
+in smb.conf and how to enable and administrate password
+encryption in Samba. Theses two topics are covered in the
+<A
+HREF="smb.conf.5.html"
+TARGET="_top"
+><TT
+CLASS="FILENAME"
+>smb.conf(5)</TT
+></A
+>
+manpage and the <A
+HREF="EMCRYPTION.html"
+TARGET="_top"
+>Encryption chapter</A
+>
+of this HOWTO Collection.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><HR><H1
+CLASS="SECT1"
+><A
+NAME="AEN9"
>Background</A
></H1
+><DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
><P
+><B
+>Note: </B
><I
CLASS="EMPHASIS"
>Author's Note :</I
-> This document
-is a combination of David Bannon's Samba 2.2 PDC HOWTO
-and the Samba NT Domain FAQ. Both documents are superceeded by this one.</P
+> This document is a combination
+of David Bannon's Samba 2.2 PDC HOWTO and the Samba NT Domain FAQ.
+Both documents are superceeded by this one.</P
+></BLOCKQUOTE
+></DIV
><P
>Version of Samba prior to release 2.2 had marginal capabilities to
-act as a Windows NT 4.0 Primary Domain Controller (PDC). The following
-functionality should work in 2.2.0:</P
+act as a Windows NT 4.0 Primary Domain Controller (PDC). Beginning with
+Samba 2.2.0, we are proud to announce official support for Windows NT 4.0
+style domain logons from Windows NT 4.0 (through SP6) and Windows 2000 (through
+SP1) clients. This article outlines the steps necessary for configuring Samba
+as a PDC. It is necessary to have a working Samba server prior to implementing the
+PDC functionality. If you have not followed the steps outlined in
+<A
+HREF="UNIX_INSTALL.html"
+TARGET="_top"
+> UNIX_INSTALL.html</A
+>, please make sure
+that your server is configured correctly before proceeding. Another good
+resource in the <A
+HREF="smb.conf.5.html"
+TARGET="_top"
+>smb.conf(5) man
+page</A
+>. The following functionality should work in 2.2:</P
><P
></P
><UL
><LI
><P
->domain logons for Windows NT 4.0/2000 clients</P
+> domain logons for Windows NT 4.0/2000 clients.
+ </P
></LI
><LI
><P
->placing a Windows 9x client in user level security</P
+> placing a Windows 9x client in user level security
+ </P
></LI
><LI
><P
->retrieving a list of users and groups from a Samba PDC to
- Windows 9x/NT/2000 clients </P
+> retrieving a list of users and groups from a Samba PDC to
+ Windows 9x/NT/2000 clients
+ </P
></LI
><LI
><P
->roving user profiles</P
+> roving (roaming) user profiles
+ </P
></LI
><LI
><P
->Windows NT 4.0 style system policies</P
+> Windows NT 4.0 style system policies
+ </P
></LI
></UL
+><DIV
+CLASS="WARNING"
+><P
+></P
+><TABLE
+CLASS="WARNING"
+BORDER="1"
+WIDTH="100%"
+><TR
+><TD
+ALIGN="CENTER"
+><B
+>Windows 2000 Service Pack 2 Clients</B
+></TD
+></TR
+><TR
+><TD
+ALIGN="LEFT"
+><P
+> Samba 2.2.1 is required for PDC functionality when using Windows 2000
+ SP2 clients.
+ </P
+></TD
+></TR
+></TABLE
+></DIV
><P
>The following pieces of functionality are not included in the 2.2 release:</P
><P
@@ -74,21 +157,25 @@ functionality should work in 2.2.0:</P
><UL
><LI
><P
->Windows NT 4 domain trusts</P
+> Windows NT 4 domain trusts
+ </P
></LI
><LI
><P
->Sam replication with Windows NT 4.0 Domain Controllers
- (i.e. a Samba PDC and a Windows NT BDC or vice versa) </P
+> SAM replication with Windows NT 4.0 Domain Controllers
+ (i.e. a Samba PDC and a Windows NT BDC or vice versa)
+ </P
></LI
><LI
><P
->Adding users via the User Manager for Domains</P
+> Adding users via the User Manager for Domains
+ </P
></LI
><LI
><P
->Acting as a Windows 2000 Domain Controller (i.e. Kerberos
- and Active Directory)</P
+> Acting as a Windows 2000 Domain Controller (i.e. Kerberos and
+ Active Directory)
+ </P
></LI
></UL
><P
@@ -98,25 +185,6 @@ support Windows 9x style domain logons is completely different
from NT4 domain logons and has been officially supported for some
time.</P
><P
->Beginning with Samba 2.2.0, we are proud to announce official
-support for Windows NT 4.0 style domain logons from Windows NT
-4.0 and Windows 2000 (including SP1) clients. This article
-outlines the steps necessary for configuring Samba as a PDC.
-Note that it is necessary to have a working Samba server
-prior to implementing the PDC functionality. If you have not
-followed the steps outlined in <A
-HREF="UNIX_INSTALL.html"
-TARGET="_top"
->UNIX_INSTALL.html</A
->, please make sure that your server
-is configured correctly before proceeding. Another good
-resource in the <A
-HREF="smb.conf.5.html"
-TARGET="_top"
->smb.conf(5) man
-page</A
->.</P
-><P
>Implementing a Samba PDC can basically be divided into 2 broad
steps.</P
><P
@@ -125,13 +193,14 @@ steps.</P
TYPE="1"
><LI
><P
->Configuring the Samba Domain Controller
+> Configuring the Samba PDC
</P
></LI
><LI
><P
->Creating machine trust accounts
- and joining clients to the domain</P
+> Creating machine trust accounts and joining clients
+ to the domain
+ </P
></LI
></OL
><P
@@ -145,7 +214,7 @@ CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
-NAME="AEN40"
+NAME="AEN49"
>Configuring the Samba Domain Controller</A
></H1
><P
@@ -251,7 +320,7 @@ TARGET="_top"
> = \\homeserver\%u
; specify a generic logon script for all users
- ; this is a relative path to the [netlogon] share
+ ; this is a relative **DOS** path to the [netlogon] share
<A
HREF="smb.conf.5.html#LOGONSCRIPT"
TARGET="_top"
@@ -305,16 +374,14 @@ TARGET="_top"
> = 0700</PRE
></P
><P
->There are a couple of points to emphasize in the above
-configuration.</P
+>There are a couple of points to emphasize in the above configuration.</P
><P
></P
><UL
><LI
><P
->encrypted passwords must be enabled.
- For more details on how to do this, refer to
- <A
+> Encrypted passwords must be enabled. For more details on how
+ to do this, refer to <A
HREF="ENCRYPTION.html"
TARGET="_top"
>ENCRYPTION.html</A
@@ -323,23 +390,27 @@ TARGET="_top"
></LI
><LI
><P
->The server must support domain logons
- and a <TT
+> The server must support domain logons and a
+ <TT
CLASS="FILENAME"
>[netlogon]</TT
-> share</P
+> share
+ </P
></LI
><LI
><P
->The server must be the domain master browser
- in order for Windows client to locate the server as a DC.</P
+> The server must be the domain master browser in order for Windows
+ client to locate the server as a DC. Please refer to the various
+ Network Browsing documentation included with this distribution for
+ details.
+ </P
></LI
></UL
><P
>As Samba 2.2 does not offer a complete implementation of group mapping between
Windows NT groups and UNIX groups (this is really quite complicated to explain
in a short space), you should refer to the <A
-HREF="smb.conf.5.html#DOMAINADMONUSERS"
+HREF="smb.conf.5.html#DOMAINADMINUSERS"
TARGET="_top"
>domain
admin users</A
@@ -356,28 +427,38 @@ CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
-NAME="AEN83"
+NAME="AEN92"
>Creating Machine Trust Accounts and Joining Clients
to the Domain</A
></H1
><P
->First you must understand what a machine trust account is and what
-it is used for.</P
-><P
->A machine trust account is a user account owned by a computer.
+>A machine trust account is a samba user account owned by a computer.
The account password acts as the shared secret for secure
-communication with the Domain Controller. Hence the reason that
-a Windows 9x host is never a true member of a domain because
-it does not posses a machine trust account and thus has no shared
-secret with the DC.</P
+communication with the Domain Controller. This is a security feature
+to prevent an unauthorized machine with the same netbios name from
+joining the domain and gaining access to domain user/group accounts.
+Hence a Windows 9x host is never a true member of a domain because it does
+not posses a machine trust account, and thus has no shared secret with the DC.</P
><P
>On a Windows NT PDC, these machine trust account passwords are stored
-in the registry. A Samba PDC stores these accounts in he same location
+in the registry. A Samba PDC stores these accounts in the same location
as user LanMan and NT password hashes (currently <TT
CLASS="FILENAME"
>smbpasswd</TT
>).
-However, machine trust accounts only possess the NT password hash.</P
+However, machine trust accounts only possess and use the NT password hash.</P
+><P
+>Because Samba requires machine accounts to possess a UNIX uid from
+which an Windows NT SID can be generated, all of these accounts
+must have an entry in <TT
+CLASS="FILENAME"
+>/etc/passwd</TT
+> and smbpasswd.
+Future releases will alleviate the need to create
+<TT
+CLASS="FILENAME"
+>/etc/passwd</TT
+> entries. </P
><P
>There are two means of creating machine trust accounts.</P
><P
@@ -385,30 +466,52 @@ However, machine trust accounts only possess the NT password hash.</P
><UL
><LI
><P
->Manual creation before joining the client
- to the domain. In this case, the password is set to a known
- value -- the lower case of the machine's netbios name.</P
+> Manual creation before joining the client to the domain. In this case,
+ the password is set to a known value -- the lower case of the
+ machine's netbios name.
+ </P
></LI
><LI
><P
->Creation of the account at the time of
- joining the domain. In this case, the session key of the
- administrative account used to join the client to the domain acts
- as an encryption key for setting the password to a random value.</P
+> Creation of the account at the time of joining the domain. In
+ this case, the session key of the administrative account used to join
+ the client to the domain acts as an encryption key for setting the
+ password to a random value (This is the recommended method).
+ </P
></LI
></UL
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN106"
+>Manually creating machine trust accounts</A
+></H2
><P
->Because Samba requires machine accounts to possess a UNIX uid from
-which an Windows NT SID can be generated, all of these accounts
-will have an entry in <TT
-CLASS="FILENAME"
->/etc/passwd</TT
-> and smbpasswd.
-Future releases will alleviate the need to create
-<TT
-CLASS="FILENAME"
->/etc/passwd</TT
-> entries.</P
+>The first step in creating a machine trust account by hand is to
+create an entry for the machine in /etc/passwd. This can be done
+using <B
+CLASS="COMMAND"
+>vipw</B
+> or any 'add userr' command which is normally
+used to create new UNIX accounts. The following is an example for a Linux
+based Samba server:</P
+><P
+><TT
+CLASS="PROMPT"
+>root# </TT
+>/usr/sbin/useradd -g 100 -d /dev/null -c <TT
+CLASS="REPLACEABLE"
+><I
+>machine_nickname</I
+></TT
+> -m -s /bin/false <TT
+CLASS="REPLACEABLE"
+><I
+>machine_name</I
+></TT
+>$</P
><P
>The <TT
CLASS="FILENAME"
@@ -423,20 +526,40 @@ CLASS="FILENAME"
><P
><PRE
CLASS="PROGRAMLISTING"
->doppy$:x:505:501:NTMachine:/dev/null:/bin/false</PRE
+>doppy$:x:505:501:<TT
+CLASS="REPLACEABLE"
+><I
+>machine_nickname</I
+></TT
+>:/dev/null:/bin/false</PRE
></P
><P
->If you are manually creating the machine accounts, it is necessary
-to add the <TT
-CLASS="FILENAME"
->/etc/passwd</TT
-> (or NIS passwd
-map) entry prior to adding the <TT
-CLASS="FILENAME"
->smbpasswd</TT
->
-entry. The following command will create a new machine account
-ready for use.</P
+>Above, <TT
+CLASS="REPLACEABLE"
+><I
+>machine_nickname</I
+></TT
+> can be any descriptive name for the
+pc i.e. BasementComputer. The <TT
+CLASS="REPLACEABLE"
+><I
+>machine_name</I
+></TT
+> absolutely must be
+the netbios name of the pc to be added to the domain. The "$" must append the netbios
+name of the pc or samba will not recognize this as a machine account</P
+><P
+>Now that the UNIX account has been created, the next step is to create
+the smbpasswd entry for the machine containing the well known initial
+trust account password. This can be done using the <A
+HREF="smbpasswd.6.html"
+TARGET="_top"
+><B
+CLASS="COMMAND"
+>smbpasswd(8)</B
+></A
+> command
+as shown here:</P
><P
><TT
CLASS="PROMPT"
@@ -454,167 +577,283 @@ CLASS="REPLACEABLE"
>machine_name</I
></TT
> is the machine's netbios
-name.</P
+name. </P
+><DIV
+CLASS="WARNING"
><P
-><I
-CLASS="EMPHASIS"
->If you manually create a machine account, immediately join
-the client to the domain.</I
-> An open account like this
-can allow intruders to gain access to user account information
-in your domain.</P
-><P
->The second way of creating machine trust accounts is to add
-them on the fly at the time the client is joined to the domain.
-You will need to include a value for the
-<A
+></P
+><TABLE
+CLASS="WARNING"
+BORDER="1"
+WIDTH="100%"
+><TR
+><TD
+ALIGN="CENTER"
+><B
+>Join the client to the domain immediately</B
+></TD
+></TR
+><TR
+><TD
+ALIGN="LEFT"
+><P
+> Manually creating a machine trust account using this method is the
+ equivalent of creating a machine account on a Windows NT PDC using
+ the "Server Manager". From the time at which the account is created
+ to the time which th client joins the domain and changes the password,
+ your domain is vulnerable to an intruder joining your domain using a
+ a machine with the same netbios name. A PDC inherently trusts
+ members of the domain and will serve out a large degree of user
+ information to such clients. You have been warned!
+ </P
+></TD
+></TR
+></TABLE
+></DIV
+></DIV
+><DIV
+CLASS="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN134"
+>Creating machine trust accounts "on the fly"</A
+></H2
+><P
+>The second, and most recommended way of creating machine trust accounts
+is to create them as needed at the time the client is joined to
+the domain. You will need to include a value for the <A
HREF="smb.conf.5.html#ADDUSERSCRIPT"
TARGET="_top"
>add user script</A
>
-parameter. Below is an example I use on a RedHat 6.2 Linux system.</P
+parameter. Below is an example from a RedHat 6.2 Linux system.</P
><P
><PRE
CLASS="PROGRAMLISTING"
>add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u </PRE
></P
><P
->In Samba 2.2.0, <I
+>In Samba 2.2.1, <I
CLASS="EMPHASIS"
>only the root account</I
> can be used to create
-machine accounts on the fly like this. Therefore, it is required
-to create an entry in smbpasswd for <I
+machine accounts like this. Therefore, it is required to create
+an entry in smbpasswd for <I
CLASS="EMPHASIS"
>root</I
->.
-The password <I
+>. The password
+<I
CLASS="EMPHASIS"
>SHOULD</I
-> be set to s different
-password that the associated <TT
+> be set to s different password that the
+associated <TT
CLASS="FILENAME"
>/etc/passwd</TT
->
-entry for security reasons.</P
+> entry for security reasons.</P
+></DIV
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
-NAME="AEN122"
+NAME="AEN145"
>Common Problems and Errors</A
></H1
><P
></P
><P
-><I
+></P
+><UL
+><LI
+><P
+> <I
CLASS="EMPHASIS"
>I cannot include a '$' in a machine name.</I
-></P
+>
+ </P
><P
->A 'machine name' in (typically) <TT
+> A 'machine name' in (typically) <TT
CLASS="FILENAME"
>/etc/passwd</TT
>
-of the machine name with a '$' appended. FreeBSD (and other BSD
-systems ?) won't create a user with a '$' in their name.</P
+ of the machine name with a '$' appended. FreeBSD (and other BSD
+ systems ?) won't create a user with a '$' in their name.
+ </P
><P
->The problem is only in the program used to make the entry, once
-made, it works perfectly. So create a user without the '$' and
-use <B
+> The problem is only in the program used to make the entry, once
+ made, it works perfectly. So create a user without the '$' and
+ use <B
CLASS="COMMAND"
>vipw</B
> to edit the entry, adding the '$'. Or create
-the whole entry with vipw if you like, make sure you use a
-unique uid !</P
+ the whole entry with vipw if you like, make sure you use a
+ unique uid !
+ </P
+></LI
+><LI
><P
-><I
+> <I
CLASS="EMPHASIS"
>I get told "You already have a connection to the Domain...."
-when creating a machine account.</I
-></P
-><P
->This happens if you try to create a machine account from the
-machine itself and use a user name that does not work (for whatever
-reason) and then try another (possibly valid) user name.
-Exit out of the network applet to close the initial connection
-and try again.</P
+ or "Cannot join domain, the credentials supplied conflict with an
+ existing set.." when creating a machine account.</I
+>
+ </P
><P
->Further, if the machine is a already a 'member of a workgroup' that
-is the same name as the domain you are joining (bad idea) you will
-get this message. Change the workgroup name to something else, it
-does not matter what, reboot, and try again.</P
+> This happens if you try to create a machine account from the
+ machine itself and already have a connection (e.g. mapped drive)
+ to a share (or IPC$) on the Samba PDC. The following command
+ will remove all network drive connections:
+ </P
><P
-><I
-CLASS="EMPHASIS"
->I get told "Cannot join domain, the credentials supplied
-conflict with an existing set.."</I
-></P
+> <TT
+CLASS="PROMPT"
+>C:\WINNT\&#62;</TT
+> <B
+CLASS="COMMAND"
+>net use * /d</B
+>
+ </P
><P
->This is the same basic problem as mentioned above, "You already
-have a connection..."</P
+> Further, if the machine is a already a 'member of a workgroup' that
+ is the same name as the domain you are joining (bad idea) you will
+ get this message. Change the workgroup name to something else, it
+ does not matter what, reboot, and try again.
+ </P
+></LI
+><LI
><P
-><I
+> <I
CLASS="EMPHASIS"
->"The system can not log you on (C000019B)...."</I
-></P
+>The system can not log you on (C000019B)....</I
+>
+ </P
><P
>I joined the domain successfully but after upgrading
-to a newer version of the Samba code I get the message, "The system
-can not log you on (C000019B), Please try a gain or consult your
-system administrator" when attempting to logon.</P
+ to a newer version of the Samba code I get the message, "The system
+ can not log you on (C000019B), Please try a gain or consult your
+ system administrator" when attempting to logon.
+ </P
><P
->This occurs when the domain SID stored in
-<TT
+> This occurs when the domain SID stored in
+ <TT
CLASS="FILENAME"
>private/WORKGROUP.SID</TT
> is
-changed. For example, you remove the file and <B
+ changed. For example, you remove the file and <B
CLASS="COMMAND"
>smbd</B
> automatically
-creates a new one. Or you are swapping back and forth between
-versions 2.0.7, TNG and the HEAD branch code (not recommended). The
-only way to correct the problem is to restore the original domain
-SID or remove the domain client from the domain and rejoin.</P
+ creates a new one. Or you are swapping back and forth between
+ versions 2.0.7, TNG and the HEAD branch code (not recommended). The
+ only way to correct the problem is to restore the original domain
+ SID or remove the domain client from the domain and rejoin.
+ </P
+></LI
+><LI
+><P
+> <I
+CLASS="EMPHASIS"
+>The machine account for this computer either does not
+ exist or is not accessible.</I
+>
+ </P
><P
+> When I try to join the domain I get the message "The machine account
+ for this computer either does not exist or is not accessible". Whats
+ wrong?
+ </P
+><P
+> This problem is caused by the PDC not having a suitable machine account.
+ If you are using the <TT
+CLASS="PARAMETER"
><I
+>add user script</I
+></TT
+> method to create
+ accounts then this would indicate that it has not worked. Ensure the domain
+ admin user system is working.
+ </P
+><P
+> Alternatively if you are creating account entries manually then they
+ have not been created correctly. Make sure that you have the entry
+ correct for the machine account in smbpasswd file on the Samba PDC.
+ If you added the account using an editor rather than using the smbpasswd
+ utility, make sure that the account name is the machine netbios name
+ with a '$' appended to it ( ie. computer_name$ ). There must be an entry
+ in both /etc/passwd and the smbpasswd file. Some people have reported
+ that inconsistent subnet masks between the Samba server and the NT
+ client have caused this problem. Make sure that these are consistent
+ for both client and server.
+ </P
+></LI
+><LI
+><P
+> <I
CLASS="EMPHASIS"
->"The machine account for this computer either does not
-exist or is not accessible."</I
-></P
+>When I attempt to login to a Samba Domain from a NT4/W2K workstation,
+ I get a message about my account being disabled.</I
+>
+ </P
><P
->When I try to join the domain I get the message "The machine account
-for this computer either does not exist or is not accessible". Whats
-wrong ?</P
+> This problem is caused by a PAM related bug in Samba 2.2.0. This bug is
+ fixed in 2.2.1. Other symptoms could be unaccessible shares on
+ NT/W2K member servers in the domain or the following error in your smbd.log:
+ passdb/pampass.c:pam_account(268) PAM: UNKNOWN ERROR for User: %user%
+ </P
><P
->This problem is caused by the PDC not having a suitable machine account.
-If you are using the <B
+> At first be ensure to enable the useraccounts with <B
CLASS="COMMAND"
->add user script =</B
-> method to create
-accounts then this would indicate that it has not worked. Ensure the domain
-admin user system is working.</P
-><P
->Alternatively if you are creating account entries manually then they
-have not been created correctly. Make sure that you have the entry
-correct for the machine account in smbpasswd file on the Samba PDC.
-If you added the account using an editor rather than using the smbpasswd
-utility, make sure that the account name is the machine netbios name
-with a '$' appended to it ( ie. computer_name$ ). There must be an entry
-in both /etc/passwd and the smbpasswd file. Some people have reported
-that inconsistent subnet masks between the Samba server and the NT
-client have caused this problem. Make sure that these are consistent
-for both client and server.</P
+>smbpasswd -e
+ %user%</B
+>, this is normaly done, when you create an account.
+ </P
+><P
+> In order to work around this problem in 2.2.0, configure the
+ <TT
+CLASS="PARAMETER"
+><I
+>account</I
+></TT
+> control flag in
+ <TT
+CLASS="FILENAME"
+>/etc/pam.d/samba</TT
+> file as follows:
+ </P
+><P
+><PRE
+CLASS="PROGRAMLISTING"
+> account required pam_permit.so
+ </PRE
+></P
+><P
+> If you want to remain backward compatibility to samba 2.0.x use
+ <TT
+CLASS="FILENAME"
+>pam_permit.so</TT
+>, it's also possible to use
+ <TT
+CLASS="FILENAME"
+>pam_pwdb.so</TT
+>. There are some bugs if you try to
+ use <TT
+CLASS="FILENAME"
+>pam_unix.so</TT
+>, if you need this, be ensure to use
+ the most recent version of this file.
+ </P
+></LI
+></UL
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
-NAME="AEN150"
+NAME="AEN193"
>System Policies and Profiles</A
></H1
><P
@@ -630,97 +869,112 @@ Profiles and Policies in Windows NT 4.0</A
><P
>Here are some additional details:</P
><P
-><I
+></P
+><UL
+><LI
+><P
+> <I
CLASS="EMPHASIS"
>What about Windows NT Policy Editor ?</I
-></P
+>
+ </P
><P
->To create or edit <TT
+> To create or edit <TT
CLASS="FILENAME"
>ntconfig.pol</TT
> you must use
-the NT Server Policy Editor, <B
+ the NT Server Policy Editor, <B
CLASS="COMMAND"
>poledit.exe</B
> which
-is included with NT Server but <I
+ is included with NT Server but <I
CLASS="EMPHASIS"
>not NT Workstation</I
>.
-There is a Policy Editor on a NTws
-but it is not suitable for creating <I
+ There is a Policy Editor on a NTws
+ but it is not suitable for creating <I
CLASS="EMPHASIS"
>Domain Policies</I
>.
-Further, although the Windows 95
-Policy Editor can be installed on an NT Workstation/Server, it will not
-work with NT policies because the registry key that are set by the policy templates.
-However, the files from the NT Server will run happily enough on an NTws.
-You need <TT
+ Further, although the Windows 95
+ Policy Editor can be installed on an NT Workstation/Server, it will not
+ work with NT policies because the registry key that are set by the policy templates.
+ However, the files from the NT Server will run happily enough on an NTws.
+ You need <TT
CLASS="FILENAME"
>poledit.exe, common.adm</TT
> and <TT
CLASS="FILENAME"
>winnt.adm</TT
>. It is convenient
-to put the two *.adm files in <TT
+ to put the two *.adm files in <TT
CLASS="FILENAME"
>c:\winnt\inf</TT
> which is where
-the binary will look for them unless told otherwise. Note also that that
-directory is 'hidden'.</P
+ the binary will look for them unless told otherwise. Note also that that
+ directory is 'hidden'.
+ </P
><P
->The Windows NT policy editor is also included with the
-Service Pack 3 (and later) for Windows NT 4.0. Extract the files using
-<B
+> The Windows NT policy editor is also included with the Service Pack 3 (and
+ later) for Windows NT 4.0. Extract the files using <B
CLASS="COMMAND"
>servicepackname /x</B
->, ie thats <B
+>,
+ ie thats <B
CLASS="COMMAND"
->Nt4sp6ai.exe
-/x</B
-> for service pack 6a. The policy editor, <B
+>Nt4sp6ai.exe /x</B
+> for service pack 6a. The policy editor,
+ <B
CLASS="COMMAND"
>poledit.exe</B
-> and the
-associated template files (*.adm) should
-be extracted as well. It is also possible to downloaded the policy template
-files for Office97 and get a copy of the policy editor. Another possible
-location is with the Zero Administration Kit available for download from Microsoft.</P
+> and the associated template files (*.adm) should
+ be extracted as well. It is also possible to downloaded the policy template
+ files for Office97 and get a copy of the policy editor. Another possible
+ location is with the Zero Administration Kit available for download from Microsoft.
+ </P
+></LI
+><LI
><P
-><I
+> <I
CLASS="EMPHASIS"
>Can Win95 do Policies ?</I
-></P
+>
+ </P
><P
->Install the group policy handler for Win9x to pick up group
-policies. Look on the Win98 CD in <TT
+> Install the group policy handler for Win9x to pick up group
+ policies. Look on the Win98 CD in <TT
CLASS="FILENAME"
>\tools\reskit\netadmin\poledit</TT
>.
-Install group policies on a Win9x client by double-clicking
-<TT
+ Install group policies on a Win9x client by double-clicking
+ <TT
CLASS="FILENAME"
>grouppol.inf</TT
>. Log off and on again a couple of
-times and see if Win98 picks up group policies. Unfortunately this needs
-to be done on every Win9x machine that uses group policies....</P
+ times and see if Win98 picks up group policies. Unfortunately this needs
+ to be done on every Win9x machine that uses group policies....
+ </P
><P
->If group policies don't work one reports suggests getting the updated
-(read: working) grouppol.dll for Windows 9x. The group list is grabbed
-from /etc/group.</P
+> If group policies don't work one reports suggests getting the updated
+ (read: working) grouppol.dll for Windows 9x. The group list is grabbed
+ from /etc/group.
+ </P
+></LI
+><LI
><P
-><I
+> <I
CLASS="EMPHASIS"
>How do I get 'User Manager' and 'Server Manager'</I
-></P
+>
+ </P
><P
->Since I don't need to buy an NT Server CD now, how do I get
-the 'User Manager for Domains', the 'Server Manager' ?</P
+> Since I don't need to buy an NT Server CD now, how do I get
+ the 'User Manager for Domains', the 'Server Manager' ?
+ </P
><P
->Microsoft distributes a version of
-these tools called nexus for installation on Windows 95 systems. The
-tools set includes</P
+> Microsoft distributes a version of these tools called nexus for
+ installation on Windows 95 systems. The tools set includes
+ </P
><P
></P
><UL
@@ -738,26 +992,30 @@ tools set includes</P
></LI
></UL
><P
->Click here to download the archived file <A
+> Click here to download the archived file <A
HREF="ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE"
TARGET="_top"
>ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE</A
-></P
+>
+ </P
><P
->The Windows NT 4.0 version of the 'User Manager for
-Domains' and 'Server Manager' are available from Microsoft via ftp
-from <A
+> The Windows NT 4.0 version of the 'User Manager for
+ Domains' and 'Server Manager' are available from Microsoft via ftp
+ from <A
HREF="ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE"
TARGET="_top"
>ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE</A
-></P
+>
+ </P
+></LI
+></UL
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
-NAME="AEN190"
+NAME="AEN237"
>What other help can I get ?</A
></H1
><P
@@ -766,11 +1024,16 @@ of mailing lists, RFC's and documentation. The docs that come
with the samba distribution contain very good explanations of
general SMB topics such as browsing.</P
><P
-><I
+></P
+><UL
+><LI
+><P
+> <I
CLASS="EMPHASIS"
>What are some diagnostics tools I can use to debug the domain logon
-process and where can I find them?</I
-></P
+ process and where can I find them?</I
+>
+ </P
><P
> One of the best diagnostic tools for debugging problems is Samba itself.
You can use the -d option for both smbd and nmbd to specifiy what
@@ -812,7 +1075,7 @@ CLASS="COMMAND"
></UL
><P
> An SMB enabled version of tcpdump is available from
- <A
+ <A
HREF="http://www.tcpdump.org/"
TARGET="_top"
>http://www.tcpdup.org/</A
@@ -835,12 +1098,15 @@ TARGET="_top"
local subnet. Be aware that Ethereal can read and write netmon
formatted files.
</P
+></LI
+><LI
><P
-><I
+> <I
CLASS="EMPHASIS"
>How do I install 'Network Monitor' on an NT Workstation
-or a Windows 9x box?</I
-></P
+ or a Windows 9x box?</I
+>
+ </P
><P
> Installing netmon on an NT workstation requires a couple
of steps. The following are for installing Netmon V4.00.349, which comes
@@ -935,14 +1201,11 @@ CLASS="FILENAME"
information on how to do this. Copy the files from a working
Netmon installation.
</P
-><DIV
-CLASS="SECT2"
-><HR><H2
-CLASS="SECT2"
-><A
-NAME="AEN237"
->URLs and similar</A
-></H2
+></LI
+><LI
+><P
+> The following is a list if helpful URLs and other links:
+ </P
><P
></P
><UL
@@ -1008,44 +1271,44 @@ TARGET="_top"
></P
></LI
></UL
-></DIV
-><DIV
-CLASS="SECT2"
-><HR><H2
-CLASS="SECT2"
-><A
-NAME="AEN261"
->Mailing Lists</A
-></H2
+></LI
+></UL
><P
-><I
+></P
+><UL
+><LI
+><P
+> <I
CLASS="EMPHASIS"
>How do I get help from the mailing lists ?</I
-></P
+>
+ </P
><P
->There are a number of Samba related mailing lists. Go to <A
+> There are a number of Samba related mailing lists. Go to <A
HREF="http://samba.org"
TARGET="_top"
>http://samba.org</A
>, click on your nearest mirror
-and then click on <B
+ and then click on <B
CLASS="COMMAND"
>Support</B
> and then click on <B
CLASS="COMMAND"
->Samba related mailing lists</B
->.</P
+> Samba related mailing lists</B
+>.
+ </P
><P
->For questions relating to Samba TNG go to
-<A
+> For questions relating to Samba TNG go to
+ <A
HREF="http://www.samba-tng.org/"
TARGET="_top"
>http://www.samba-tng.org/</A
>
-It has been requested that you don't post questions about Samba-TNG to the
-main stream Samba lists.</P
+ It has been requested that you don't post questions about Samba-TNG to the
+ main stream Samba lists.</P
><P
->If you post a message to one of the lists please observe the following guide lines :</P
+> If you post a message to one of the lists please observe the following guide lines :
+ </P
><P
></P
><UL
@@ -1113,35 +1376,799 @@ CLASS="EMPHASIS"
smb.conf in their attach directory ?</P
></LI
></UL
+></LI
+><LI
><P
-><I
+> <I
CLASS="EMPHASIS"
>How do I get off the mailing lists ?</I
-></P
+>
+ </P
><P
>To have your name removed from a samba mailing list, go to the
- same place you went to to get on it. Go to <A
+ same place you went to to get on it. Go to <A
HREF="http://lists.samba.org/"
TARGET="_top"
>http://lists.samba.org</A
->, click
- on your nearest mirror and then click on <B
+>,
+ click on your nearest mirror and then click on <B
CLASS="COMMAND"
>Support</B
> and
- then click on <B
+ then click on <B
CLASS="COMMAND"
> Samba related mailing lists</B
>. Or perhaps see
- <A
+ <A
HREF="http://lists.samba.org/mailman/roster/samba-ntdom"
TARGET="_top"
>here</A
-></P
+>
+ </P
><P
> Please don't post messages to the list asking to be removed, you will just
- be referred to the above address (unless that process failed in some way...)
- </P
+ be referred to the above address (unless that process failed in some way...)
+ </P
+></LI
+></UL
+></DIV
+><DIV
+CLASS="SECT1"
+><HR><H1
+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
@@ -1149,12 +2176,35 @@ CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
-NAME="AEN300"
+NAME="AEN508"
>DOMAIN_CONTROL.txt : Windows NT Domain Control &#38; Samba</A
></H1
+><DIV
+CLASS="WARNING"
><P
->This appendix was originally authored by John H Terpstra of the Samba Team
-and is included here for posterity.</P
+></P
+><TABLE
+CLASS="WARNING"
+BORDER="1"
+WIDTH="100%"
+><TR
+><TD
+ALIGN="CENTER"
+><B
+>Possibly Outdated Material</B
+></TD
+></TR
+><TR
+><TD
+ALIGN="LEFT"
+><P
+> This appendix was originally authored by John H Terpstra of
+ the Samba Team and is included here for posterity.
+ </P
+></TD
+></TR
+></TABLE
+></DIV
><P
><I
CLASS="EMPHASIS"
@@ -1171,12 +2221,9 @@ Windows NT SAM.</P
><P
>Windows NT Server can be installed as either a plain file and print server
(WORKGROUP workstation or server) or as a server that participates in Domain
-Control (DOMAIN member, Primary Domain controller or Backup Domain controller).</P
-><P
->The same is true for OS/2 Warp Server, Digital Pathworks and other similar
-products, all of which can participate in Domain Control along with Windows NT.
-However only those servers which have licensed Windows NT code in them can be
-a primary Domain Controller (eg Windows NT Server, Advanced Server for Unix.)</P
+Control (DOMAIN member, Primary Domain controller or Backup Domain controller).
+The same is true for OS/2 Warp Server, Digital Pathworks and other similar
+products, all of which can participate in Domain Control along with Windows NT.</P
><P
>To many people these terms can be confusing, so let's try to clear the air.</P
><P
generated by cgit (git 2.34.1) at 2024-11-27 08:14:53 +0000