diff options
Diffstat (limited to 'docs/docbook/projdoc/Samba-PDC-HOWTO.sgml')
| -rw-r--r-- | docs/docbook/projdoc/Samba-PDC-HOWTO.sgml | 1530 |
1 files changed, 1220 insertions, 310 deletions
diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml b/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml index 699ba54a09..0b86bcba63 100644 --- a/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml +++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml @@ -8,17 +8,46 @@ <orgname>VA Linux Systems/Samba Team</orgname> <address><email>jerry@samba.org</email></address> </affiliation> + <firstname>David</firstname><surname>Bannon</surname> + <affiliation> + <orgname>Samba Team</orgname> + <address><email>dbannon@samba.org</email></address> + </affiliation> + </author> - <pubdate> (15 Apr 2001) </pubdate> + <pubdate> (26 Apr 2001) </pubdate> </chapterinfo> <title> -How to Configure Samba 2.2.x as a Primary Domain Controller +How to Configure Samba 2.2 as a Primary Domain Controller </title> <!-- ********************************************************** + Prerequisite Reading + +*************************************************************** --> +<sect1> +<title>Prerequisite Reading</title> + +<para> +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 +<ulink url="smb.conf.5.html"><filename>smb.conf(5)</filename></ulink> +manpage and the <ulink url="EMCRYPTION.html">Encryption chapter</ulink> +of this HOWTO Collection. +</para> + + +</sect1> + + + +<!-- ********************************************************** + Background Information *************************************************************** --> @@ -27,44 +56,82 @@ How to Configure Samba 2.2.x as a Primary Domain Controller Background </title> -<para><emphasis>Author's Note :</emphasis> 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. +<note> +<para> +<emphasis>Author's Note :</emphasis> 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. </para> +</note> <para> 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: +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 +<ulink url="UNIX_INSTALL.html"> UNIX_INSTALL.html</ulink>, please make sure +that your server is configured correctly before proceeding. Another good +resource in the <ulink url="smb.conf.5.html">smb.conf(5) man +page</ulink>. The following functionality should work in 2.2: </para> <itemizedlist> - <listitem><para>domain logons for Windows NT 4.0/2000 clients</para></listitem> + <listitem><para> + domain logons for Windows NT 4.0/2000 clients. + </para></listitem> - <listitem><para>placing a Windows 9x client in user level security</para></listitem> + <listitem><para> + placing a Windows 9x client in user level security + </para></listitem> - <listitem><para>retrieving a list of users and groups from a Samba PDC to - Windows 9x/NT/2000 clients </para></listitem> + <listitem><para> + retrieving a list of users and groups from a Samba PDC to + Windows 9x/NT/2000 clients + </para></listitem> - <listitem><para>roving user profiles</para></listitem> + <listitem><para> + roving (roaming) user profiles + </para></listitem> - <listitem><para>Windows NT 4.0 style system policies</para></listitem> + <listitem><para> + Windows NT 4.0 style system policies + </para></listitem> </itemizedlist> +<warning> + <title>Windows 2000 Service Pack 2 Clients</title> + <para> + Samba 2.2.1 is required for PDC functionality when using Windows 2000 + SP2 clients. + </para> +</warning> + + <para> The following pieces of functionality are not included in the 2.2 release: </para> <itemizedlist> - <listitem><para>Windows NT 4 domain trusts</para></listitem> + <listitem><para> + Windows NT 4 domain trusts + </para></listitem> - <listitem><para>Sam replication with Windows NT 4.0 Domain Controllers - (i.e. a Samba PDC and a Windows NT BDC or vice versa) </para></listitem> + <listitem><para> + SAM replication with Windows NT 4.0 Domain Controllers + (i.e. a Samba PDC and a Windows NT BDC or vice versa) + </para></listitem> - <listitem><para>Adding users via the User Manager for Domains</para></listitem> + <listitem><para> + Adding users via the User Manager for Domains + </para></listitem> - <listitem><para>Acting as a Windows 2000 Domain Controller (i.e. Kerberos - and Active Directory)</para></listitem> + <listitem><para> + Acting as a Windows 2000 Domain Controller (i.e. Kerberos and + Active Directory) + </para></listitem> </itemizedlist> <para> @@ -75,19 +142,6 @@ from NT4 domain logons and has been officially supported for some time. </para> -<para> -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 <ulink url="UNIX_INSTALL.html"> -UNIX_INSTALL.html</ulink>, please make sure that your server -is configured correctly before proceeding. Another good -resource in the <ulink url="smb.conf.5.html">smb.conf(5) man -page</ulink>. -</para> <para> Implementing a Samba PDC can basically be divided into 2 broad @@ -95,11 +149,14 @@ steps. </para> <orderedlist numeration="Arabic"> - <listitem><para>Configuring the Samba Domain Controller + <listitem><para> + Configuring the Samba PDC </para></listitem> - <listitem><para>Creating machine trust accounts - and joining clients to the domain</para></listitem> + <listitem><para> + Creating machine trust accounts and joining clients + to the domain + </para></listitem> </orderedlist> <para> @@ -164,7 +221,7 @@ Here is an example smb.conf for acting as a PDC: <ulink url="smb.conf.5.html#LOGONHOME">logon home</ulink> = \\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 <ulink url="smb.conf.5.html#LOGONSCRIPT">logon script</ulink> = logon.cmd ; necessary share for domain controller @@ -182,28 +239,32 @@ Here is an example smb.conf for acting as a PDC: </programlisting></para> <para> -There are a couple of points to emphasize in the above -configuration. +There are a couple of points to emphasize in the above configuration. </para> <itemizedlist> - <listitem><para>encrypted passwords must be enabled. - For more details on how to do this, refer to - <ulink url="ENCRYPTION.html">ENCRYPTION.html</ulink>. + <listitem><para> + Encrypted passwords must be enabled. For more details on how + to do this, refer to <ulink url="ENCRYPTION.html">ENCRYPTION.html</ulink>. </para></listitem> - <listitem><para>The server must support domain logons - and a <filename>[netlogon]</filename> share</para></listitem> + <listitem><para> + The server must support domain logons and a + <filename>[netlogon]</filename> share + </para></listitem> - <listitem><para>The server must be the domain master browser - in order for Windows client to locate the server as a DC.</para> - </listitem> + <listitem><para> + The server must be the domain master browser in order for Windows + client to locate the server as a DC. Please refer to the various + Network Browsing documentation included with this distribution for + details. + </para></listitem> </itemizedlist> <para> 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 <ulink url="smb.conf.5.html#DOMAINADMONUSERS">domain +in a short space), you should refer to the <ulink url="smb.conf.5.html#DOMAINADMINUSERS">domain admin users</ulink> and <ulink url="smb.conf.5.html#DOMAINADMINGROUP">domain admin group</ulink> smb.conf parameters for information of creating a Domain Admins style accounts. @@ -217,24 +278,28 @@ style accounts. to the Domain</title> <para> -First you must understand what a machine trust account is and what -it is used for. -</para> - -<para> -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. +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. </para> <para> 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 <filename>smbpasswd</filename>). -However, machine trust accounts only possess the NT password hash. +However, machine trust accounts only possess and use the NT password hash. +</para> + +<para> +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 <filename>/etc/passwd</filename> and smbpasswd. +Future releases will alleviate the need to create +<filename>/etc/passwd</filename> entries. </para> <para> @@ -242,25 +307,35 @@ There are two means of creating machine trust accounts. </para> <itemizedlist> - <listitem><para>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.</para></listitem> + <listitem><para> + 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. + </para></listitem> - <listitem><para>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.</para> - </listitem> + <listitem><para> + 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). + </para></listitem> </itemizedlist> +<sect2> +<title>Manually creating machine trust accounts</title> + <para> -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 <filename>/etc/passwd</filename> and smbpasswd. -Future releases will alleviate the need to create -<filename>/etc/passwd</filename> entries. +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 <command>vipw</command> 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: </para> +<para> +<prompt>root# </prompt>/usr/sbin/useradd -g 100 -d /dev/null -c <replaceable> +machine_nickname</replaceable> -m -s /bin/false <replaceable>machine_name</replaceable>$ +</para> <para> The <filename>/etc/passwd</filename> entry will list the machine name @@ -270,39 +345,60 @@ home directory. For example a machine called 'doppy' would have an </para> <para><programlisting> -doppy$:x:505:501:NTMachine:/dev/null:/bin/false +doppy$:x:505:501:<replaceable>machine_nickname</replaceable>:/dev/null:/bin/false </programlisting></para> <para> -If you are manually creating the machine accounts, it is necessary -to add the <filename>/etc/passwd</filename> (or NIS passwd -map) entry prior to adding the <filename>smbpasswd</filename> -entry. The following command will create a new machine account -ready for use. +Above, <replaceable>machine_nickname</replaceable> can be any descriptive name for the +pc i.e. BasementComputer. The <replaceable>machine_name</replaceable> 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 </para> + <para> -<prompt>root# </prompt> smbpasswd -a -m <replaceable>machine_name</replaceable> +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 <ulink +url="smbpasswd.6.html"><command>smbpasswd(8)</command></ulink> command +as shown here: </para> <para> -where <replaceable>machine_name</replaceable> is the machine's netbios -name. +<prompt>root# </prompt> smbpasswd -a -m <replaceable>machine_name</replaceable> </para> <para> -<emphasis>If you manually create a machine account, immediately join -the client to the domain.</emphasis> An open account like this -can allow intruders to gain access to user account information -in your domain. +where <replaceable>machine_name</replaceable> is the machine's netbios +name. </para> +<warning> + <title>Join the client to the domain immediately</title> + + <para> + Manually creating a machine trust account using this method is the + equivalent of creating a machine 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! + </para> +</warning> +</sect2> + + +<sect2> +<title>Creating machine trust accounts "on the fly"</title> + <para> -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 -<ulink url="smb.conf.5.html#ADDUSERSCRIPT">add user script</ulink> -parameter. Below is an example I use on a RedHat 6.2 Linux system. +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 <ulink +url="smb.conf.5.html#ADDUSERSCRIPT">add user script</ulink> +parameter. Below is an example from a RedHat 6.2 Linux system. </para> <para><programlisting> @@ -310,13 +406,13 @@ add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u </programlisting></para> <para> -In Samba 2.2.0, <emphasis>only the root account</emphasis> can be used to create -machine accounts on the fly like this. Therefore, it is required -to create an entry in smbpasswd for <emphasis>root</emphasis>. -The password <emphasis>SHOULD</emphasis> be set to s different -password that the associated <filename>/etc/passwd</filename> -entry for security reasons. +In Samba 2.2.1, <emphasis>only the root account</emphasis> can be used to create +machine accounts like this. Therefore, it is required to create +an entry in smbpasswd for <emphasis>root</emphasis>. The password +<emphasis>SHOULD</emphasis> be set to s different password that the +associated <filename>/etc/passwd</filename> entry for security reasons. </para> +</sect2> </sect1> <!-- ********************************************************** @@ -330,108 +426,145 @@ entry for security reasons. <para> </para> +<itemizedlist> +<listitem> + <para> + <emphasis>I cannot include a '$' in a machine name.</emphasis> + </para> + + <para> + A 'machine name' in (typically) <filename>/etc/passwd</> + of the machine name with a '$' appended. FreeBSD (and other BSD + systems ?) won't create a user with a '$' in their name. + </para> -<para> -<emphasis>I cannot include a '$' in a machine name.</emphasis> -</para> - -<para> -A 'machine name' in (typically) <filename>/etc/passwd</> -of the machine name with a '$' appended. FreeBSD (and other BSD -systems ?) won't create a user with a '$' in their name. -</para> + <para> + The problem is only in the program used to make the entry, once + made, it works perfectly. So create a user without the '$' and + use <command>vipw</> to edit the entry, adding the '$'. Or create + the whole entry with vipw if you like, make sure you use a + unique uid ! + </para> +</listitem> + +<listitem> + <para> + <emphasis>I get told "You already have a connection to the Domain...." + or "Cannot join domain, the credentials supplied conflict with an + existing set.." when creating a machine account.</emphasis> + </para> -<para> -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 <command>vipw</> to edit the entry, adding the '$'. Or create -the whole entry with vipw if you like, make sure you use a -unique uid ! -</para> + <para> + 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: + </para> + <para> + <prompt>C:\WINNT\></prompt> <command>net use * /d</command> + </para> -<para> -<emphasis>I get told "You already have a connection to the Domain...." -when creating a machine account.</emphasis> -</para> + <para> + 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. + </para> +</listitem> -<para> -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. -</para> +<listitem> + <para> + <emphasis>The system can not log you on (C000019B)....</emphasis> + </para> -<para> -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. -</para> + <para>I joined the domain successfully but after upgrading + to a newer version of the Samba code I get the message, "The system + can not log you on (C000019B), Please try a gain or consult your + system administrator" when attempting to logon. + </para> -<para> -<emphasis>I get told "Cannot join domain, the credentials supplied -conflict with an existing set.."</emphasis> -</para> + <para> + This occurs when the domain SID stored in + <filename>private/WORKGROUP.SID</filename> is + changed. For example, you remove the file and <command>smbd</command> 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. + </para> +</listitem> -<para> -This is the same basic problem as mentioned above, "You already -have a connection..." -</para> +<listitem> + <para> + <emphasis>The machine account for this computer either does not + exist or is not accessible.</emphasis> + </para> -<para> -<emphasis> -"The system can not log you on (C000019B)...."</emphasis> -</para> + <para> + When I try to join the domain I get the message "The machine account + for this computer either does not exist or is not accessible". Whats + wrong? + </para> -<para>I joined the domain successfully but after upgrading -to a newer version of the Samba code I get the message, "The system -can not log you on (C000019B), Please try a gain or consult your -system administrator" when attempting to logon. -</para> + <para> + This problem is caused by the PDC not having a suitable machine account. + If you are using the <parameter>add user script</parameter> method to create + accounts then this would indicate that it has not worked. Ensure the domain + admin user system is working. + </para> -<para> -This occurs when the domain SID stored in -<filename>private/WORKGROUP.SID</filename> is -changed. For example, you remove the file and <command>smbd</command> 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. -</para> + <para> + Alternatively if you are creating account entries manually then they + have not been created correctly. Make sure that you have the entry + correct for the machine 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. + </para> +</listitem> +<listitem> + <para> + <emphasis>When I attempt to login to a Samba Domain from a NT4/W2K workstation, + I get a message about my account being disabled.</emphasis> + </para> -<para> -<emphasis>"The machine account for this computer either does not -exist or is not accessible."</emphasis> -</para> + <para> + 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% + </para> + + <para> + At first be ensure to enable the useraccounts with <command>smbpasswd -e + %user%</command>, this is normaly done, when you create an account. + </para> -<para> -When I try to join the domain I get the message "The machine account -for this computer either does not exist or is not accessible". Whats -wrong ? -</para> + <para> + In order to work around this problem in 2.2.0, configure the + <parameter>account</parameter> control flag in + <filename>/etc/pam.d/samba</filename> file as follows: + </para> -<para> -This problem is caused by the PDC not having a suitable machine account. -If you are using the <command>add user script =</> method to create -accounts then this would indicate that it has not worked. Ensure the domain -admin user system is working. -</para> + <para><programlisting> + account required pam_permit.so + </programlisting></para> -<para> -Alternatively if you are creating account entries manually then they -have not been created correctly. Make sure that you have the entry -correct for the machine 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. -</para> + <para> + If you want to remain backward compatibility to samba 2.0.x use + <filename>pam_permit.so</filename>, it's also possible to use + <filename>pam_pwdb.so</filename>. There are some bugs if you try to + use <filename>pam_unix.so</filename>, if you need this, be ensure to use + the most recent version of this file. + </para> +</listitem> +</itemizedlist> </sect1> @@ -460,89 +593,98 @@ Profiles and Policies in Windows NT 4.0</ulink> available from Microsoft. Here are some additional details: </para> -<para> -<emphasis>What about Windows NT Policy Editor ?</emphasis> -</para> +<itemizedlist> -<para> -To create or edit <filename>ntconfig.pol</filename> you must use -the NT Server Policy Editor, <command>poledit.exe</command> which -is included with NT Server but <emphasis>not NT Workstation</emphasis>. -There is a Policy Editor on a NTws -but it is not suitable for creating <emphasis>Domain Policies</emphasis>. -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 <filename>poledit.exe, common.adm</> and <filename>winnt.adm</>. It is convenient -to put the two *.adm files in <filename>c:\winnt\inf</> which is where -the binary will look for them unless told otherwise. Note also that that -directory is 'hidden'. -</para> +<listitem> + <para> + <emphasis>What about Windows NT Policy Editor ?</emphasis> + </para> -<para>The Windows NT policy editor is also included with the -Service Pack 3 (and later) for Windows NT 4.0. Extract the files using -<command>servicepackname /x</command>, ie thats <command>Nt4sp6ai.exe -/x</command> for service pack 6a. The policy editor, <command>poledit.exe</command> 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. -</para> + <para> + To create or edit <filename>ntconfig.pol</filename> you must use + the NT Server Policy Editor, <command>poledit.exe</command> which + is included with NT Server but <emphasis>not NT Workstation</emphasis>. + There is a Policy Editor on a NTws + but it is not suitable for creating <emphasis>Domain Policies</emphasis>. + 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 <filename>poledit.exe, common.adm</> and <filename>winnt.adm</>. It is convenient + to put the two *.adm files in <filename>c:\winnt\inf</> which is where + the binary will look for them unless told otherwise. Note also that that + directory is 'hidden'. + </para> + <para> + The Windows NT policy editor is also included with the Service Pack 3 (and + later) for Windows NT 4.0. Extract the files using <command>servicepackname /x</command>, + ie thats <command>Nt4sp6ai.exe /x</command> for service pack 6a. The policy editor, + <command>poledit.exe</command> 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. + </para> +</listitem> -<para> -<emphasis>Can Win95 do Policies ?</emphasis> -</para> -<para> -Install the group policy handler for Win9x to pick up group -policies. Look on the Win98 CD in <filename>\tools\reskit\netadmin\poledit</filename>. -Install group policies on a Win9x client by double-clicking -<filename>grouppol.inf</filename>. 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.... -</para> +<listitem> + <para> + <emphasis>Can Win95 do Policies ?</emphasis> + </para> -<para> -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. -</para> + <para> + Install the group policy handler for Win9x to pick up group + policies. Look on the Win98 CD in <filename>\tools\reskit\netadmin\poledit</filename>. + Install group policies on a Win9x client by double-clicking + <filename>grouppol.inf</filename>. 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.... + </para> -<para> -<emphasis>How do I get 'User Manager' and 'Server Manager'</emphasis> -</para> + <para> + 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. + </para> +</listitem> -<para> -Since I don't need to buy an NT Server CD now, how do I get -the 'User Manager for Domains', the 'Server Manager' ? -</para> -<para> -Microsoft distributes a version of -these tools called nexus for installation on Windows 95 systems. The -tools set includes -</para> +<listitem> + <para> + <emphasis>How do I get 'User Manager' and 'Server Manager'</emphasis> + </para> + + <para> + Since I don't need to buy an NT Server CD now, how do I get + the 'User Manager for Domains', the 'Server Manager' ? + </para> + + <para> + Microsoft distributes a version of these tools called nexus for + installation on Windows 95 systems. The tools set includes + </para> -<itemizedlist> - <listitem><para>Server Manager</para></listitem> + <itemizedlist> + <listitem><para>Server Manager</para></listitem> - <listitem><para>User Manager for Domains</para></listitem> + <listitem><para>User Manager for Domains</para></listitem> - <listitem><para>Event Viewer</para></listitem> -</itemizedlist> + <listitem><para>Event Viewer</para></listitem> + </itemizedlist> -<para> -Click here to download the archived file <ulink -url="ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE">ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE</ulink> -</para> + <para> + Click here to download the archived file <ulink + url="ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE">ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE</ulink> + </para> -<para> -The Windows NT 4.0 version of the 'User Manager for -Domains' and 'Server Manager' are available from Microsoft via ftp -from <ulink url="ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE">ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE</ulink> -</para> + <para> + The Windows NT 4.0 version of the 'User Manager for + Domains' and 'Server Manager' are available from Microsoft via ftp + from <ulink url="ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE">ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE</ulink> + </para> +</listitem> +</itemizedlist> </sect1> @@ -564,12 +706,14 @@ 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.</para> -<para> -<emphasis>What are some diagnostics tools I can use to debug the domain logon -process and where can I find them?</emphasis> -</para> +<itemizedlist> +<listitem> + <para> + <emphasis>What are some diagnostics tools I can use to debug the domain logon + process and where can I find them?</emphasis> + </para> - <para> + <para> 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 'debug level' at which to run. See the man pages on smbd, nmbd and @@ -601,9 +745,9 @@ process and where can I find them?</emphasis> <listitem><para>smbclient -L //{netbios name of server}</para></listitem> </itemizedlist> - <para> + <para> An SMB enabled version of tcpdump is available from - <ulink url="http://www.tcpdump.org/">http://www.tcpdup.org/</ulink>. + <ulink url="http://www.tcpdump.org/">http://www.tcpdup.org/</ulink>. Ethereal, another good packet sniffer for UNIX and Win32 hosts, can be downloaded from <ulink url="http://www.ethereal.com/">http://www.ethereal.com</ulink>. @@ -620,11 +764,15 @@ process and where can I find them?</emphasis> local subnet. Be aware that Ethereal can read and write netmon formatted files. </para> +</listitem> + + +<listitem> + <para> + <emphasis>How do I install 'Network Monitor' on an NT Workstation + or a Windows 9x box?</emphasis> + </para> -<para> -<emphasis>How do I install 'Network Monitor' on an NT Workstation -or a Windows 9x box?</emphasis> -</para> <para> Installing netmon on an NT workstation requires a couple of steps. The following are for installing Netmon V4.00.349, which comes @@ -696,12 +844,17 @@ or a Windows 9x box?</emphasis> information on how to do this. Copy the files from a working Netmon installation. </para> +</listitem> -<sect2> -<title>URLs and similar</title> -<itemizedlist> + +<listitem> + <para> + The following is a list if helpful URLs and other links: + </para> + + <itemizedlist> <listitem><para>Home of Samba site <ulink url="http://samba.org"> http://samba.org</ulink>. We have a mirror near you !</para></listitem> @@ -728,36 +881,35 @@ or a Windows 9x box?</emphasis> <ulink url="ftp://ftp.microsoft.com/developr/drg/CIFS/"> ftp://ftp.microsoft.com/developr/drg/CIFS/</ulink></para></listitem> + </itemizedlist> +</listitem> </itemizedlist> -</sect2> - - -<sect2> -<title>Mailing Lists</title> -<para> -<emphasis>How do I get help from the mailing lists ?</emphasis> -</para> +<itemizedlist> +<listitem> + <para> + <emphasis>How do I get help from the mailing lists ?</emphasis> + </para> -<para> -There are a number of Samba related mailing lists. Go to <ulink -url="http://samba.org">http://samba.org</ulink>, click on your nearest mirror -and then click on <command>Support</> and then click on <command> -Samba related mailing lists</>. -</para> + <para> + There are a number of Samba related mailing lists. Go to <ulink + url="http://samba.org">http://samba.org</ulink>, click on your nearest mirror + and then click on <command>Support</> and then click on <command> + Samba related mailing lists</>. + </para> -<para> -For questions relating to Samba TNG go to -<ulink url="http://www.samba-tng.org/">http://www.samba-tng.org/</ulink> -It has been requested that you don't post questions about Samba-TNG to the -main stream Samba lists.</para> + <para> + For questions relating to Samba TNG go to + <ulink url="http://www.samba-tng.org/">http://www.samba-tng.org/</ulink> + It has been requested that you don't post questions about Samba-TNG to the + main stream Samba lists.</para> -<para> -If you post a message to one of the lists please observe the following guide lines : -</para> + <para> + If you post a message to one of the lists please observe the following guide lines : + </para> -<itemizedlist> + <itemizedlist> <listitem><para> Always remember that the developers are volunteers, they are not paid and they never guarantee to produce a particular feature at @@ -801,28 +953,787 @@ If you post a message to one of the lists please observe the following guide lin mailing lists go to a huge number of people, do they all need a copy of your smb.conf in their attach directory ?</para></listitem> + </itemizedlist> +</listitem> + + +<listitem> + <para> + <emphasis>How do I get off the mailing lists ?</emphasis> + </para> + + <para>To have your name removed from a samba mailing list, go to the + same place you went to to get on it. Go to <ulink + url="http://lists.samba.org/">http://lists.samba.org</ulink>, + click on your nearest mirror and then click on <command>Support</> and + then click on <command> Samba related mailing lists</>. Or perhaps see + <ulink url="http://lists.samba.org/mailman/roster/samba-ntdom">here</ulink> + </para> + + <para> + 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...) + </para> +</listitem> </itemizedlist> +</sect1> + + +<!-- ********************************************************** + + Windows 9x domain control + +*************************************************************** --> +<sect1> +<title>Domain Control for Windows 9x/ME</title> +<note> <para> -<emphasis>How do I get off the mailing lists ?</emphasis> +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) </para> +</note> - <para>To have your name removed from a samba mailing list, go to the - same place you went to to get on it. Go to <ulink url= - "http://lists.samba.org/">http://lists.samba.org</ulink>, click - on your nearest mirror and then click on <command>Support</> and - then click on <command> Samba related mailing lists</>. Or perhaps see - <ulink url="http://lists.samba.org/mailman/roster/samba-ntdom">here</ulink></para> +<para> +A domain and a workgroup are exactly the same thing in terms of network +browsing. The difference is that a distributable authentication +database is associated with a domain, for secure login access to a +network. Also, different access rights can be granted to users if they +successfully authenticate against a domain logon server (NT server and +other systems based on NT server support this, as does at least Samba TNG now). +</para> - <para> - 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...) - </para> -</sect2> -</sect1> +<para> +The SMB client logging on to a domain has an expectation that every other +server in the domain should accept the same authentication information. +Network browsing functionality of domains and workgroups is +identical and is explained in BROWSING.txt. It should be noted, that browsing +is total orthogonal to logon support. +</para> + +<para> +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. +</para> + + +<para> +When an SMB client in a domain wishes to logon it broadcast requests for a +logon server. The first one to reply gets the job, and validates its +password using whatever mechanism the Samba administrator has installed. +It is possible (but very stupid) to create a domain where the user +database is not shared between servers, 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. +</para> + +<para> +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. +</para> + +<para> +Network logon support as discussed in this section is aimed at Window for +Workgroups, and Windows 9X clients. +</para> + +<para> +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. +</para> + +<para> +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). +</para> + +<para> +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. +</para> + +<para> +Using these features you can make your clients verify their logon via +the Samba server; make clients run a batch file when they logon to +the network and download their preferences, desktop and start menu. +</para> + +<para> +Before launching into the configuration instructions, it is worthwhile looking +at how a Win9X client performs a logon: +</para> + +<orderedlist> +<listitem> + <para> + The client broadcasts (to the IP broadcast address of the subnet it is in) + a NetLogon request. This is sent to the NetBIOS address DOMAIN<00> at the + NetBIOS layer. The client chooses the first response it receives, which + contains the NetBIOS name of the logon server to use in the format of + \\SERVER. + </para> +</listitem> + +<listitem> + <para> + The client then connects to that server, logs on (does an SMBsessetupX) and + then connects to the IPC$ share (using an SMBtconX). + </para> +</listitem> + +<listitem> + <para> + The client then does a NetWkstaUserLogon request, which retrieves the name + of the user's logon script. + </para> +</listitem> + +<listitem> + <para> + The client then connects to the NetLogon share and searches for this + and if it is found and can be read, is retrieved and executed by the client. + After this, the client disconnects from the NetLogon share. + </para> +</listitem> + +<listitem> + <para> + The client then sends a NetUserGetInfo request to the server, to retrieve + the user's home share, which is used to search for profiles. Since the + response to the NetUserGetInfo request does not contain much more + the user's home share, profiles for Win9X clients MUST reside in the user + home directory. + </para> +</listitem> + +<listitem> + <para> + The client then connects to the user's home share and searches for the + user's profile. As it turns out, you can specify the users home share as + a sharename and path. For example, \\server\fred\.profile. + If the profiles are found, they are implemented. + </para> +</listitem> + +<listitem> + <para> + The client then disconnects from the user's home share, and reconnects to + the NetLogon share and looks for CONFIG.POL, the policies file. If this is + found, it is read and implemented. + </para> +</listitem> +</orderedlist> + + +<sect2> +<title>Configuration Instructions: Network Logons</title> + +<para> +To use domain logons and profiles you need to do the following: +</para> + + +<orderedlist> +<listitem> + <para> + 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). + </para> + + <para> + For example I have used: + </para> + + <para><programlisting> +[netlogon] + path = /data/dos/netlogon + writeable = no + guest ok = no +</programlisting></para> + + <para> + 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. + </para> +</listitem> + + + +<listitem> + <para> + in the [global] section of smb.conf set the following: + </para> + + <para><programlisting> +domain logons = yes +logon script = %U.bat + </programlisting></para> + + <para> + 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: + </para> + + <para><programlisting> +logon script = scripts\%U.bat + </programlisting></para> +</listitem> + +<listitem> + <para> + 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. + </para> + + <para> + 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. + </para> +</listitem> + + +<listitem> + <para> + 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. + </para> +</listitem> + +<listitem> + <para> + 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. + </para> +</listitem> +</orderedlist> +<warning> +<title>security mode and master browsers</title> +<para> +There are a few comments to make in order to tie up some +loose ends. There has been much debate over the issue of whether +or not it is ok to configure Samba as a Domain Controller in security +modes other than <constant>USER</constant>. The only security mode +which will not work due to technical reasons is <constant>SHARE</constant> +mode security. <constant>DOMAIN</constant> and <constant>SERVER</constant> +mode security is really just a variation on SMB user level security. +</para> + +<para> +Actually, this issue is also 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. +</para> + +<para> +Now back to the issue of configuring a Samba DC to use a mode other +than "security = user". If a Samba host is configured to use +another SMB server or DC in order to validate user connection +requests, then it is a fact that some other machine on the network +(the "password server") knows more about user than the Samba host. +99% of the time, this other host is a domain controller. Now +in order to operate in domain mode security, the "workgroup" parameter +must be set to the name of the Windows NT domain (which already +has a domain controller, right?) +</para> + +<para> +Therefore configuring a Samba box as a DC for a domain that +already by definition has a PDC is asking for trouble. +Therefore, you should always configure the Samba DC to be the DMB +for its domain. +</para> +</warning> + +</sect2> + + +<sect2> +<title>Configuration Instructions: Setting up Roaming User Profiles</title> + +<warning> +<para> +<emphasis>NOTE!</emphasis> Roaming profiles support is different +for Win9X and WinNT. +</para> +</warning> + +<para> +Before discussing how to configure roaming profiles, it is useful to see how +Win9X and WinNT clients implement these features. +</para> + +<para> +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. +</para> + + +<para> +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. +</para> + + + +<sect3> +<title>Windows NT Configuration</title> + +<para> +To support WinNT clients, inn the [global] section of smb.conf set the +following (for example): +</para> + +<para><programlisting> +logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath +</programlisting></para> + +<para> +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. +</para> + +<note> +<para> +[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.] +</para> +</note> + +</sect3> + + +<sect3> +<title>Windows 9X Configuration</title> + +<para> +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. +</para> + +<para> +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: +</para> + +<para><programlisting> +logon home = \\%L\%U\.profiles +</programlisting></para> + +<para> +then your Win9X clients will dutifully put their clients in a subdirectory +of your home directory called .profiles (thus making them hidden). +</para> + +<para> +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". +</para> + + +</sect3> + + +<sect3> +<title>Win9X and WinNT Configuration</title> + +<para> +You can support profiles for both Win9X and WinNT clients by setting both the +"logon home" and "logon path" parameters. For example: +</para> + +<para><programlisting> +logon home = \\%L\%U\.profiles +logon path = \\%L\profiles\%U +</programlisting></para> + +<note> +<para> +I have not checked what 'net use /home' does on NT when "logon home" is +set as above. +</para> +</note> +</sect3> + + + +<sect3> +<title>Windows 9X Profile Setup</title> + +<para> +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. +</para> + + +<para> +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. +</para> + +<orderedlist> +<listitem> + <para> + 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. + </para> +</listitem> + + +<listitem> + <para> + 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. + </para> +</listitem> + +</orderedlist> + +<para> +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. +</para> + +<para> +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. +</para> + +<para> +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'. +</para> + +<para> +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. +</para> + +<para> +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. +</para> + +<para> +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. +</para> + +<para> +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". +</para> + +<orderedlist> +<listitem> + <para> + instead of logging in under the [user, password, domain] dialog, + press escape. + </para> +</listitem> + +<listitem> + <para> + run the regedit.exe program, and look in: + </para> + + <para> + HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList + </para> + + <para> + 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. + </para> + + <para> + [Exit the registry editor]. + </para> +</listitem> + +<listitem> + <para> + <emphasis>WARNING</emphasis> - 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). + </para> + + <para> + 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. + </para> +</listitem> + +<listitem> + <para> + search for the user's .PWL password-cacheing file in the c:\windows + directory, and delete it. + </para> +</listitem> + + +<listitem> + <para> + log off the windows 95 client. + </para> +</listitem> + +<listitem> + <para> + 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. + </para> +</listitem> + +</orderedlist> + +<para> +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. +</para> + +<para> +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. +</para> + +</sect3> + + +<sect3> +<title>Windows NT Workstation 4.0</title> + +<para> +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. +</para> + +<note> +<para> +[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]. +</para> +</note> + +<para> +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. +</para> + +<para> +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]. +</para> + +<para> +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. +</para> + +<para> +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. +</para> + +<note> +<para> +[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]. +</para> + +<para> +[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]. +</para> + +<para> +[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]. +</para> +</note> + +</sect3> + + +<sect3> +<title>Windows NT Server</title> + +<para> +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. +</para> + +</sect3> + + +<sect3> +<title>Sharing Profiles between W95 and NT Workstation 4.0</title> + +<warning> +<title>Potentially outdated or incorrect material follows</title> +<para> +I think this is all bogus, but have not deleted it. (Richard Sharpe) +</para> +</warning> + +<para> +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. +</para> + +<para> +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]. +</para> + +<para> + +If you have this set up correctly, you will find separate user.DAT and +NTuser.DAT files in the same profile directory. +</para> + +<note> +<para> +[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]. +</para> +</note> + +</sect3> + +</sect2> +</sect1> <!-- ********************************************************** @@ -836,10 +1747,14 @@ If you post a message to one of the lists please observe the following guide lin DOMAIN_CONTROL.txt : Windows NT Domain Control & Samba </title> -<para> -This appendix was originally authored by John H Terpstra of the Samba Team -and is included here for posterity. -</para> +<warning> + <title>Possibly Outdated Material</title> + + <para> + This appendix was originally authored by John H Terpstra of + the Samba Team and is included here for posterity. + </para> +</warning> <para> @@ -858,13 +1773,8 @@ Windows NT SAM. 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). -</para> - -<para> 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.) </para> <para> |