diff options
Diffstat (limited to 'docs/htmldocs/using_samba/ch04.html')
| -rw-r--r-- | docs/htmldocs/using_samba/ch04.html | 2556 |
1 files changed, 2556 insertions, 0 deletions
diff --git a/docs/htmldocs/using_samba/ch04.html b/docs/htmldocs/using_samba/ch04.html new file mode 100644 index 0000000000..02cc979284 --- /dev/null +++ b/docs/htmldocs/using_samba/ch04.html @@ -0,0 +1,2556 @@ +<html> +<body bgcolor="#ffffff"> + +<img src="samba2_xs.gif" border="0" alt=" " height="100" width="76" +hspace="10" align="left" /> + +<h1 class="head0">Chapter 4. Windows NT Domains</h1> + + + +<p><a name="INDEX-1"/>In previous +chapters, we've focused on workgroup networking to +keep things simple and introduce you to networking with Samba in the +most painless manner we could find. However, workgroup computing has +its drawbacks, and for many computing environments, the greater +security and single logon of the Windows NT domain make it worthwhile +to spend the extra effort to implement a domain.</p> + +<p>In addition to the domain features of +<a name="INDEX-2"/>that we discussed in <a href="ch01.html">Chapter 1</a>, having a domain makes it possible to use +<em class="firstterm">logon scripts</em><a name="INDEX-3"/> and <em class="firstterm">roaming profiles +</em><a name="INDEX-4"/>(also called<em class="firstterm"> roving +profiles</em><a name="INDEX-5"/>). A logon +script is a text file of commands that are run during startup, and a +profile is a collection of information regarding the desktop +environment, including the contents of the Start menu, icons that +appear on the desktop, and other characteristics about the GUI +environment that users are allowed to customize. A roaming profile +can follow its owner from computer to computer, allowing her to have +the same familiar interface appear wherever she logs on.</p> + +<p>A Windows NT domain offers centralized control over the network. +<em class="firstterm">Policies</em><a name="INDEX-6"/> can be set up by an administrator to +define aspects of the users' environment and limit +the amount of control they have over the network and their computers. +It is also possible for administrators to perform remote +administration of the domain controllers from any Windows NT/2000/XP +workstation.</p> + +<p>Samba 2.2 has the ability to act as a primary domain controller, +supporting domain logons from Windows 95/98/Me/NT/2000/XP computers +and allowing Windows NT/2000/XP<a name="FNPTR-1"/><a href="#FOOTNOTE-1">[1]</a> systems to join the domain as domain +member servers. Samba can also join a domain as a member server, +allowing the primary domain controller to be a Windows NT/2000 system +or another Samba server.</p> + +<a name="samba2-CHP-4-NOTE-100"/><blockquote class="note"><h4 class="objtitle">TIP</h4> +<p>Samba 2.2 does not support <a name="INDEX-7"/><a name="INDEX-8"/><a name="INDEX-9"/>LDAP and <a name="INDEX-10"/>Kerberos authentication of Active +Directory, so it cannot act as a Windows 2000 Active Directory domain +controller. However, Samba can be added to an Active Directory domain +as a member server, with the Windows 2000 domain controllers running +in either mixed or native mode. The Windows 2000 server (even if it +is running in native mode) supports the Samba server by acting as a +<a name="INDEX-11"/><a name="INDEX-12"/>PDC emulator, using the Windows NT +style of authentication rather than the Kerberos style.</p> +</blockquote> + +<p>If you're adding a Samba server to a network that +has already been set up, you won't have to decide +whether to use a workgroup or a domain; you will simply have to be +compatible with what's already in place. If you do +have a choice, we suggest you evaluate both workgroup and domain +computing carefully before rolling out a big installation. You will +have a lot of work to do if you later need to convert one to the +other. One last thought on this matter is that Microsoft is +developing Windows in the direction of increased use of domains and +is intending that eventually Windows networks be composed solely of +Active Directory domains. If you implement a Windows NT domain now, +you'll be in a better position to transition to +Active Directory later, after Samba has better support for it.</p> + +<p>In this chapter, we cover various topics directly related to using +Samba in a Windows NT domain, including:</p> + +<ul><li> +<p>Configuring and using Samba as the primary domain controller</p> +</li><li> +<p>Setting up Windows 95/98/Me systems to log on to the domain</p> +</li><li> +<p>Implementing user-level security on Windows 95/98/Me</p> +</li><li> +<p>Adding Windows NT/2000/XP systems to the domain</p> +</li><li> +<p>Configuring logon scripts, roaming profiles, and system policies</p> +</li><li> +<p>Adding a Samba server to a domain as a member server</p> +</li></ul> + + + + +<div class="sect1"><a name="samba2-CHP-4-SECT-1"/> + +<h2 class="head1">Samba as the Primary Domain Controller</h2> + +<p><a name="INDEX-13"/>Samba 2.2 +is able to handle the most desired functions of a primary domain +controller in a Windows NT domain, handling domain logons and +authentication for accessing shared resources, as well as supporting +logon scripts, roaming profiles, and system policies.</p> + +<a name="samba2-CHP-4-NOTE-101"/><blockquote class="note"><h4 class="objtitle">TIP</h4> +<p>You will need to use at least Samba 2.2 to ensure that PDC +functionality for Windows NT/2000/XP clients is present. Prior to +Samba 2.2, only limited user authentication for NT clients was +present.</p> +</blockquote> + +<p>In this section, we will show you how to configure Samba as a PDC for +use with Windows 95/98/Me and Windows NT/2000/XP clients. The two +groups of Windows versions interact differently within domains, and +in some cases are supported in slightly different ways. If you know +you are going to be using only Windows 95/98/Me or Windows +NT/2000/XP, you can set up Samba to support only that group. However, +there isn't any harm in supporting both at the same +time.</p> + +<a name="samba2-CHP-4-NOTE-102"/><blockquote class="note"><h4 class="objtitle">TIP</h4> +<p>If you would like more information on how to set up +<a name="INDEX-14"/>domains, see the file +<em class="filename">Samba-PDC-HOWTO.html</em><a name="INDEX-15"/> +in the <em class="filename">docs/htmldocs</em> directory of the Samba +source distribution.</p> +</blockquote> + +<p>Samba must be the only domain controller for the domain. Make sure +that a PDC isn't already active, and that there are +no backup domain controllers. Samba 2.2 is not able to communicate +with backup domain controllers, and having domain controllers in your +domain with unsynchronized data would result in a very dysfunctional +network.</p> + +<a name="samba2-CHP-4-NOTE-103"/><blockquote class="note"><h4 class="objtitle">TIP</h4> +<p>Although Samba 2.2 cannot function as, or work with, a Windows NT +<a name="INDEX-16"/><a name="INDEX-17"/>BDC, it is possible to set up +another Samba server to act as a backup for a Samba PDC. For further +information, see the file +<em class="filename">Samba-BDC-HOWTO.html</em><a name="INDEX-18"/> +in the <em class="filename">docs/htmldocs</em> directory of the Samba +source distribution.</p> +</blockquote> + +<p>Configuring Samba to be a PDC is a matter of modifying the +<em class="filename">smb.conf</em> file, creating some directories, and +restarting the server.</p> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-1.1"/> + +<h3 class="head2">Modifying smb.conf</h3> + +<p>First you will need to start with an +<em class="filename">smb.conf</em><a name="INDEX-19"/><a name="INDEX-20"/> file that correctly configures Samba for +workgroup computing, such as the one we created in <a href="ch02.html">Chapter 2</a>, and insert the following lines into the +<tt class="literal">[global]</tt> section:</p> + +<blockquote><pre class="code">[global] + ; use the name of your Samba server instead of toltec + ; and your own workgroup instead of METRAN + netbios name = toltec + workgroup = METRAN + encrypt passwords = yes + + domain master = yes + local master = yes + preferred master = yes + os level = 65 + + security = user + domain logons = yes + + ; logon path tells Samba where to put Windows NT/2000/XP roaming profiles + logon path = \\%L\profiles\%u\%m + logon script = logon.bat + + logon drive = H: + ; logon home is used to specify home directory and + ; Windows 95/98/Me roaming profile location + logon home = \\%L\%u\.win_profile\%m + + time server = yes + + ; instead of jay, use the names of all users in the Windows NT/2000/XP + ; Administrators group who log on to the domain + domain admin group = root jay + + ; the below works on Red Hat Linux - other OSs might need a different command + add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u</pre></blockquote> + +<p>And after the <tt class="literal">[global]</tt> section, add these three +new shares:</p> + +<blockquote><pre class="code">[netlogon] + path = /usr/local/samba/lib/netlogon + writable = no + browsable = no + +[profiles] + ; you might wish to use a different directory for your + ; Windows NT/2000/XP roaming profiles + path = /home/samba-ntprof + browsable = no + writable = yes + create mask = 0600 + directory mask = 0700 + +[homes] + read only = no + browsable = no + guest ok = no + map archive = yes</pre></blockquote> + +<p>Now for the explanation. If you are comparing this example to the +configuration file presented in <a href="ch02.html">Chapter 2</a>, you +will notice that the first three parameter settings are similar. We +start out in the <tt class="literal">[global]</tt> section by setting the +NetBIOS name of the Samba server. We are using the default, which is +the DNS hostname, but are being explicit because the NetBIOS name is +used in UNCs that appear later in <em class="filename">smb.conf</em>. The +next two lines, setting the workgroup name and choosing to use +encrypted passwords, are identical to our +<em class="filename">smb.conf</em> file from <a href="ch02.html">Chapter 2</a>. +However, things are now a little different: even though it still +reads "workgroup", we are actually +setting the name of the domain. For a workgroup, using encrypted +passwords is optional; when using a domain, they are required.</p> + +<p>The next four lines set up our Samba PDC to handle browsing services. +The line <tt class="literal">domain</tt> <tt class="literal">master</tt> +<tt class="literal">=</tt> <tt class="literal">yes</tt> causes Samba to be the +domain master browser, which handles browsing services for the domain +across multiple subnets if necessary. Although it looks very similar, +<tt class="literal">local</tt> <tt class="literal">master</tt> +<tt class="literal">=</tt> <tt class="literal">yes</tt> does not cause Samba to +be the master browser on the subnet, but merely tells it to +participate in browser elections and allow itself to win. (These two +lines are yet more default settings that we include to be clear.) The +next two lines ensure that Samba wins the elections. Setting the +<tt class="literal">preferred</tt> <tt class="literal">master</tt> parameter +makes Samba force an election when it starts up. The +<tt class="literal">os</tt> <tt class="literal">level</tt> parameter is set +higher than that of any other system, which results in Samba winning +that election. (At the time of this writing, an <tt class="literal">os</tt> +level of 65 was sufficient to win over all versions of +Windows—but make sure no other Samba server is set higher!) We +make sure Samba is both the <a name="INDEX-21"/><a name="INDEX-22"/>domain and local master browser +because Windows NT/2000 PDCs always reserve the domain master browser +role for themselves and because Windows clients require things to be +that way to find the primary domain controller. It is possible to +allow another computer on the network to win the role of local master +browser, but having the same server act as both domain and local +masters is simpler and more efficient.</p> + +<p>The next two lines in the <tt class="literal">[global]</tt> section set up +Samba to handle the actual domain logons. We set +<tt class="literal">security</tt> <tt class="literal">=</tt> +<tt class="literal">user</tt> so that Samba will require a username and +password. This is actually the same as in the workgroup setup we +covered in <a href="ch01.html">Chapter 1</a> and <a href="ch02.html">Chapter 2</a> because it is the default. The only +reason we're including it explicitly is to avoid +confusion: another valid setting is <tt class="literal">security</tt> +<tt class="literal">=</tt> <tt class="literal">domain</tt>, but that is for +having another (Windows or Samba) domain controller handle the logons +and should never be found in the <em class="filename">smb.conf</em> of a +Samba PDC. The next line, <tt class="literal">domain</tt> +<tt class="literal">logons</tt> <tt class="literal">=</tt> +<tt class="literal">yes</tt>, is what tells Samba we want this server to +handle domain logons.</p> + +<p>Defining a logon path is necessary for supporting +<a name="INDEX-23"/><a name="INDEX-24"/>roaming profiles for +Windows NT/2000/XP clients. The UNC +<tt class="literal">\\%L\profiles\%u</tt> refers to a share held on the +Samba server where the profiles are kept. The variables +<tt class="literal">%L</tt> and <tt class="literal">%u</tt> are replaced by Samba +with the name of the server and the username of the logged on user, +respectively. The section in <em class="filename">smb.conf</em> defining +the <tt class="literal">[profiles]</tt> share contains the definition of +exactly where the profiles are kept on the server. +We'll get back to this topic a bit later in this +chapter.</p> + +<p>The <tt class="literal">logon</tt> <tt class="literal">script</tt> +<tt class="literal">=</tt> <tt class="literal">logon.bat</tt> line specifies the +name of an MS-DOS batch file that will be executed when the client +logs on to the domain. The path specified here is relative to the +<tt class="literal">[netlogon]</tt> share that is defined later in the +<em class="filename">smb.conf</em> file.</p> + +<p>The settings of <tt class="literal">logon</tt> <tt class="literal">drive</tt> and +<tt class="literal">logon</tt> <tt class="literal">home</tt> have a couple of +purposes. Setting <tt class="literal">logon</tt> <tt class="literal">drive</tt> +<tt class="literal">=</tt> <tt class="literal">H</tt>: allows the home directory +of the user to be connected to drive letter H on the client. The +<tt class="literal">logon</tt> <tt class="literal">home</tt> parameter is set to +the location of the home directory on the server, and again, +<tt class="literal">%u</tt> is replaced at runtime by the logged on +user's username. The home directory is used to store +roaming profiles for Windows 95/98/Me clients. These parameters tie +into the <tt class="literal">[homes]</tt> share that we are adding, as we +will explain a bit later.</p> + +<p>Setting <tt class="literal">time</tt> <tt class="literal">server</tt> +<tt class="literal">=</tt> <tt class="literal">yes</tt> causes Samba to advertise +itself as a <a name="INDEX-25"/>time service for the network. This is +optional.</p> + +<p>The <tt class="literal">domain</tt> <tt class="literal">admin</tt> +<tt class="literal">group</tt> parameter exists as a short-term measure in +Samba 2.2 to give Samba a list of users who have administrative +privileges in the domain. The list should contain any Samba users who +log on from Windows NT/2000/XP systems and are members of the +Administrators or Domain Admins groups, if roaming profiles are to +work correctly.</p> + +<p>The last parameter to add to the <tt class="literal">[global]</tt> section +is <tt class="literal">add</tt> <tt class="literal">user</tt> +<tt class="literal">script</tt>, and you will need it only if one or more +of your clients is a Windows NT/2000/XP system. We will tell you more +about this in <a href="ch04.html#samba2-CHP-4-SECT-2">Section 4.2</a> later in this chapter.</p> + +<p>The rest of the additions to <em class="filename">smb.conf</em> are the +definitions for three <a name="INDEX-26"/><a name="INDEX-27"/>shares. The +<tt class="literal">[netlogon]</tt><a name="INDEX-28"/> share is necessary for Samba to +handle domain logons because Windows clients need to connect to it +during the logon process and will fail if the share does not exist. +Other than that, the only function of <tt class="literal">[netlogon]</tt> +is to be a repository for logon scripts and system-policy files, +which we shall cover in detail later in this chapter. The path to a +directory on the Samba server is given, and because the clients only +read logon scripts and system-policy files from the share, the +<tt class="literal">writable</tt> <tt class="literal">=</tt> +<tt class="literal">no</tt> definition is used to make the share read-only. +Users do not need to see the share, so we set +<tt class="literal">browsable</tt> <tt class="literal">=</tt> +<tt class="literal">no</tt> to make the share invisible.</p> + +<p>The <tt class="literal">[profiles]</tt><a name="INDEX-29"/> share is needed for use with +Windows NT/2000/XP roaming profiles. The path points to a directory +on the Samba server where the profiles are kept, and in this case, +the clients must be able to read and write the profile data. The +<tt class="literal">create</tt> <tt class="literal">mask</tt> (read and write +permitted for the owner only) and <tt class="literal">directory</tt> +<tt class="literal">mask</tt> (read, write, and search permitted for the +owner only) are set up such that a user's profile +data can be read and written only by the user and not accessed or +modified by anyone else.</p> + +<p>The <tt class="literal">[homes]</tt><a name="INDEX-30"/> share is necessary for our +definitions of <tt class="literal">logon</tt> <tt class="literal">drive</tt> and +<tt class="literal">logon</tt> <tt class="literal">home</tt> to work. Samba uses +the <tt class="literal">[homes]</tt> share to add the home directory of the +user (found in <em class="filename">/etc/passwd</em> ) as a share. Instead +of appearing as "homes", the share +will be accessible on the client through a folder having the same +name as the user's username. We will cover this +topic in more detail in <a href="ch09.html">Chapter 9</a>.</p> + +<p>At this point, you might want to run +<em class="filename">testparm</em><a name="INDEX-31"/> to check your +<em class="filename">smb.conf</em> file. <a name="INDEX-32"/><a name="INDEX-33"/></p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-1.2"/> + +<h3 class="head2">Creating Directories on the Samba Server</h3> + +<p><a name="INDEX-34"/><a name="INDEX-35"/>The +<tt class="literal">[netlogon]</tt> and <tt class="literal">[profiles]</tt> +shares defined in our new <em class="filename">smb.conf</em> file +reference directories on the Samba server, and it is necessary to +create those directories with the proper permissions:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>mkdir /usr/local/samba/lib/netlogon</b></tt> +# <tt class="userinput"><b>chmod 775 /usr/local/samba/lib/netlogon</b></tt> +# <tt class="userinput"><b>mkdir /home/samba-ntprof</b></tt> +# <tt class="userinput"><b>chmod 777 /home/samba-ntprof</b></tt></pre></blockquote> + +<p>The directory names we use are just examples. You are free to choose +your own.</p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-1.3"/> + +<h3 class="head2">Restarting the Samba Server</h3> + +<p><a name="INDEX-36"/>At this +point, the only thing left to do is restart the Samba server, and the +changes will be put into effect:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>/etc/rc.d/init.d/smb restart</b></tt></pre></blockquote> + +<p>(or use whatever method works on your system, as discussed in <a href="ch02.html">Chapter 2</a>.) The server is now ready to accept domain +logons. <a name="INDEX-37"/></p> + + +</div> + + +</div> + + + +<div class="sect1"><a name="samba2-CHP-4-SECT-2"/> + +<h2 class="head1">Adding Computer Accounts</h2> + +<p>To interact in a domain, a Windows NT/2000/XP system must be a member +of the domain. <a name="INDEX-38"/>Domain membership is implemented +using <em class="firstterm">computer +accounts,</em><a name="INDEX-39"/><a name="INDEX-40"/> which are similar to user +accounts and allow a domain controller to keep information with which +to authenticate computers on the network. That is, the domain +controller must be able to tell if requests that arrive from a +computer are coming from a computer that it +"knows" as being part of the +domain. Each Windows NT/2000/XP system in the domain has a computer +account in the domain controllers' database, which +on a Windows NT/2000 hosted domain is the <a name="INDEX-41"/>SAM +database. Although Samba uses a different method (involving the +<em class="filename">smbpasswd</em><a name="INDEX-42"/> file), it also treats computer accounts +similarly to user accounts.</p> + +<p>To create a computer account, an administrator configures a Windows +NT/2000/XP system to be part of the domain. For Samba 2.2, the +"<a name="INDEX-43"/><a name="INDEX-44"/>domain +administrator" is the <a name="INDEX-45"/><a name="INDEX-46"/>root account on the Samba +server, and you will need to run the command:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>smbpasswd -a root</b></tt></pre></blockquote> + +<p>to add the root user to Samba's password database. +In this case, do not provide <em class="filename">smbpasswd</em> with the +same password as the actual root account on the server. Create a +different password to be used solely for creating computer accounts. +This will reduce the possibility of compromising the root password.</p> + +<p>When the computer account is created, two things must happen on the +Samba server. An entry is added to the <em class="filename">smbpasswd</em> +file, with a "username" that is the +NetBIOS name of the computer with a dollar sign +(<tt class="literal">$</tt>) appended to it. This part is handled by the +<em class="emphasis">smbpasswd</em> command, and you do not need to +perform any additional action to implement it.</p> + +<p>With Samba 2.2, an entry is also required in the +<em class="filename">/etc/passwd</em> file<a name="FNPTR-2"/><a href="#FOOTNOTE-2">[2]</a> to give the computer account a +user ID (UID) on the Samba server.</p> + +<p>This account will never be used to +log in to the Unix system, so it should not be given a valid home +directory or login shell. To make this part work, you must set the +<tt class="literal">add</tt> <tt class="literal">user</tt> +<tt class="literal">script</tt> parameter in your Samba configuration file, +using a command that adds the entry in the proper manner. On our Red +Hat Linux system, we set <tt class="literal">add</tt> +<tt class="literal">user</tt> <tt class="literal">script</tt> to:</p> + +<blockquote><pre class="code">/usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u</pre></blockquote> + +<p>This command adds an entry in <em class="filename">/etc/passwd</em> +similar to the following:</p> + +<blockquote><pre class="code">aztec$:x:505:100::/dev/null:/bin/false</pre></blockquote> + +<p>Again, notice that the username ends in a dollar sign. The user +account shown has a "home +directory" of <em class="filename">/dev/null</em>, a +group ID (GID) of 100, and a "login +shell" of <em class="filename">/bin/false</em>. The +<em class="emphasis">-M</em> flag in our <em class="emphasis">useradd</em> +command prevents it from creating the home directory. Samba replaces +the <tt class="literal">%u</tt> variable in the +<em class="emphasis">useradd</em> command with the NetBIOS name of the +computer, including the trailing dollar sign. The basic idea here is +to create an entry with a valid username and UID. These are the only +parts that Samba uses. It is important that the UID be unique, not +also used for other accounts—especially ones that are +associated with Samba users.</p> + +<p>If you are using some other variety of Unix, you will need to replace +our <em class="emphasis">useradd</em> command with a command that performs +the same function on your system. If a command such as +<em class="emphasis">useradd</em> does not come with your system, you can +write a shell script yourself that performs the same function. In any +case, the command should add a password hash that does not correspond +to any valid password. For example, in the<em class="filename"> +/etc/shadow</em> file of our Linux server, we find the +following two lines:</p> + +<blockquote><pre class="code">jay:%1%zQ7j7ok8$D/IubyRAY5ovM3bTrpUCn1:11566:0:99999:7::: +zapotec$:!!:11625:0:99999:7:::</pre></blockquote> + +<p>The first line is for <tt class="literal">jay</tt>'s user +account. The second field is the password hash—the long string +between the first and second colons. The second line is for the +computer account of <tt class="literal">zapotec</tt>, a domain member +server. Its "username" ends with a +dollar sign (<tt class="literal">$</tt>), and the second field in this case +has been set to "!!", which is an +arbitrary string not produced from any password. Therefore, there is +no valid password for this account on the Linux host. Just about any +ASCII string can be used instead of +"!!". For example, you could use +"DISABLED" instead.</p> + +<a name="samba2-CHP-4-NOTE-104"/><blockquote class="note"><h4 class="objtitle">TIP</h4> +<p>It is possible to <a name="INDEX-47"/><a name="INDEX-48"/><a name="INDEX-49"/><a name="INDEX-50"/>create the entries for +<em class="filename">/etc/passwd</em> and <em class="filename">smbpasswd</em> +manually; however, we suggest this method be used very carefully, and +only for initial testing, or as a last resort. The reason for this is +to maintain security. After the computer account has been created on +the server, the next Windows NT/2000/XP system on the network with a +matching NetBIOS name to log on to the domain will be associated with +this account. This allows crackers a window of opportunity to take +over computer accounts for their own purposes.</p> +</blockquote> + + +</div> + + + +<div class="sect1"><a name="samba2-CHP-4-SECT-3"/> + +<h2 class="head1">Configuring Windows Clients for Domain Logons</h2> + +<p><a name="INDEX-51"/>The client-side configuration for Windows +clients is really simple. All you have to do is switch from workgroup +to domain networking by enabling domain logons, and in the case of +Windows NT/2000/XP, also provide the root password you gave +<em class="filename">smbpasswd</em> for creating computer accounts. This +results in the Windows NT/2000/XP system becoming a member of the +domain.</p> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-3.1"/> + +<h3 class="head2">Windows 95/98/Me</h3> + +<p><a name="INDEX-52"/><a name="INDEX-53"/>To +enable domain logons with Windows 95/98/Me, open the Control Panel +and double-click the Network icon. Then click Client for Microsoft +Networks, and click the Properties button. At this point, you should +see a dialog box similar to <a href="ch04.html#samba2-CHP-4-FIG-1">Figure 4-1</a>. Select the +Logon to Windows Domain checkbox at the top of the dialog box, and +enter the name of the domain as you have defined it with the +<tt class="literal">workgroup</tt> parameter in the Samba configuration +file. Then click OK, and reboot the machine when asked.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-1"/><img src="figs/sam2_0401.gif"/></div><h4 class="head4">Figure 4-1. Configuring a Windows 95/98 client for domain logons</h4> +<a name="samba2-CHP-4-NOTE-105"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p>If <a name="INDEX-54"/>Windows complains that you are already +logged into the domain, you probably have an active connection to a +share in the workgroup (such as a mapped network drive). Simply +disconnect the resource temporarily by right-clicking its icon and +choosing the Disconnect pop-up menu item.</p> +</blockquote> + +<p>When Windows reboots, you should see the standard logon dialog with +an addition: a field for a domain. The domain name should already be +filled in, so simply enter your password and click the OK button. At +this point, Windows should consult the primary domain controller +(Samba) to see if the password is correct. (You can check the log +files if you want to see this in action.) If it worked, +congratulations! You have properly configured Samba to act as a +domain controller for Windows 95/98/Me machines, and your client is +successfully connected.</p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-3.2"/> + +<h3 class="head2">User-Level Security for Windows 95/98/Me</h3> + +<p><a name="INDEX-55"/><a name="INDEX-56"/><a name="INDEX-57"/>Now that you have a primary domain +controller to authenticate users, you can implement much better +security for shares that reside on Windows 95/98/Me +systems.<a name="FNPTR-3"/><a href="#FOOTNOTE-3">[3]</a> To enable this functionality, open the +Control Panel, double-click the Network icon, and click the Access +Control tab in the dialog box. The window should now look like <a href="ch04.html#samba2-CHP-4-FIG-2">Figure 4-2</a>.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-2"/><img src="figs/sam2_0402.gif"/></div><h4 class="head4">Figure 4-2. Setting user-level access control</h4> + +<p>Click the User-level access control radio button, and type in the +name of your domain in the text area. Click the OK button. If you get +the dialog box shown in <a href="ch04.html#samba2-CHP-4-FIG-3">Figure 4-3</a>, it means that +shares are already on the system.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-3"/><img src="figs/sam2_0403.gif"/></div><h4 class="head4">Figure 4-3. Error dialog while changing to user-level access control</h4> + +<p>In that case, you might want to cancel the operation and make a +record of each of the computer's shares, making it +easier to re-create them, and then redo this part. (To get a list of +shares, open an MS-DOS prompt window and run the +<tt class="literal">net</tt> <tt class="literal">view</tt> +<tt class="literal">\\</tt><em class="replaceable">computer_name</em> +command.) Otherwise, you will get a message asking you to reboot to +put the change in configuration into effect.</p> + +<p>After rebooting, you can create shares with user-level access +control. To do this, right-click the folder you wish to share, and +select Sharing.... This will bring up the Shared Properties dialog +box, shown in <a href="ch04.html#samba2-CHP-4-FIG-4">Figure 4-4</a>.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-4"/><img src="figs/sam2_0404.gif"/></div><h4 class="head4">Figure 4-4. The Shared Properties dialog</h4> + +<p>Click the Shared As: radio button, and give the share a name and +comment. Then click the Add... button, and you will see the Add Users +dialog box, shown in <a href="ch04.html#samba2-CHP-4-FIG-5">Figure 4-5</a>.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-5"/><img src="figs/sam2_0405.gif"/></div><h4 class="head4">Figure 4-5. The Add Users dialog</h4> + +<p>What has happened is that Windows has contacted the primary domain +controller (in this case, Samba) and requested a list of domain users +and groups. You can now select a user or group and add it to one or +more of the three lists on the righthand side of the window—for +Read Only, Full Access, or Custom Control—by clicking the +buttons in the middle of the window. When you are done, click the OK +button. If you added any users or groups to the Custom Control list, +you will be presented with the Change Access Rights dialog box, shown +in <a href="ch04.html#samba2-CHP-4-FIG-6">Figure 4-6</a>, in which you can specify the rights +you wish to allow. Then click the OK button to close the dialog box.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-6"/><img src="figs/sam2_0406.gif"/></div><h4 class="head4">Figure 4-6. The Change Access Rights dialog</h4> + +<p>You are now returned to the Shared Properties dialog box, where you +will see the Name: and Access Rights: columns filled in with the +permissions that you just created. Click the OK button to finalize +the process. Remember, you will have to perform these actions on any +folders that you had previously shared using share-level security. +<a name="INDEX-58"/><a name="INDEX-59"/></p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-3.3"/> + +<h3 class="head2">Windows NT 4.0</h3> + +<p><a name="INDEX-60"/><a name="INDEX-61"/>To +configure Windows NT for domain logons, log in to the computer as +Administrator or another user in the Administrators group, open the +Control Panel, and double-click the Network icon. If it +isn't already selected, click on the Network +Identification tab.</p> + +<p>Click the Change... button, and you should see the dialog box shown +in <a href="ch04.html#samba2-CHP-4-FIG-7">Figure 4-7</a>. In this dialog box, you can choose +to have the Windows NT client become a member of the domain by +clicking the checkbox marked Domain: in the Member of box. Then type +in the name of the domain to which you wish the client to log on; it +should be the same as the one you specified using the +<tt class="literal">workgroup</tt> parameter in the Samba configuration +file. Click the checkbox marked Create a Computer Account in the +Domain, and fill in "root" for the +text area labeled User Name:. In the Password: text area, fill in the +root password you gave <em class="emphasis">smbpasswd</em> for creating +computer accounts.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-7"/><img src="figs/sam2_0407.gif"/></div><h4 class="head4">Figure 4-7. Configuring a Windows NT client for domain logons</h4> +<a name="samba2-CHP-4-NOTE-106"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p>If Windows complains that you are already logged in, you probably +have an active connection to a share in the workgroup (such as a +mapped network drive). Disconnect the resource temporarily by +right-clicking its icon and choosing the Disconnect pop-up menu item.</p> +</blockquote> + +<p>After you press the OK button, Windows should present you with a +small dialog box welcoming you to the domain. Click the Close button +in the Network dialog box, and reboot the computer as requested. When +the system comes up again, the machine will automatically present you +with a logon screen similar to the one for Windows 95/98/Me clients, +except that the domain text area has a drop-down menu so that you can +opt to log on to either the local system or the domain. Make sure +your domain is selected, and log on to the domain using any +Samba-enabled user account on the Samba server.</p> +<a name="samba2-CHP-4-NOTE-107"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p>Be sure to select the correct domain in the Windows NT logon dialog +box. Once it is selected, it might take a moment for Windows NT to +build the list of available domains.</p> +</blockquote> + +<p>After you enter the password, Windows NT should consult the primary +domain controller (Samba) to see if the password is correct. Again, +you can check the log files if you want to see this in action. If it +worked, you have successfully configured Samba to act as a domain +controller for Windows NT machines. <a name="INDEX-62"/><a name="INDEX-63"/></p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-3.4"/> + +<h3 class="head2">Windows 2000</h3> + +<p><a name="INDEX-64"/><a name="INDEX-65"/>To +configure Windows 2000 for domain logons, log in to the computer as +Administrator or another user in the Administrators group, open the +Control Panel, and double-click the System icon to open the System +Properties dialog box. Click the Network Identification tab, and then +click the Properties button. You should now see the Identification +Changes dialog box shown in <a href="ch04.html#samba2-CHP-4-FIG-8">Figure 4-8</a>.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-8"/><img src="figs/sam2_0408.gif"/></div><h4 class="head4">Figure 4-8. The Identification Changes dialog</h4> + +<p>Click the radio button labeled +"Domain:" and fill in the name of +your domain in the text-entry area. Then click the OK button. This +will bring up the Domain Username and Password dialog box. Enter +"root" for the username. For the +password, use the password that you gave to +<em class="emphasis">smbpasswd</em> for the root account.</p> +<a name="samba2-CHP-4-NOTE-108"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p>If Windows complains that you are already logged in, you probably +have an active connection to a share in the workgroup (such as a +mapped network drive). Disconnect the resource temporarily by +right-clicking its icon and choosing the Disconnect pop-up menu item.</p> +</blockquote> + +<p>After you press the OK button, Windows should present you with a +small dialog box welcoming you to the domain. When you click the OK +button in this dialog box, you will be told that you need to reboot +the computer. Click the OK button in the System Properties dialog +box, and reboot the computer as requested. When the system comes up +again, the machine will automatically present you with a Log On to +Windows dialog box similar to the one shown in <a href="ch04.html#samba2-CHP-4-FIG-9">Figure 4-9</a>.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-9"/><img src="figs/sam2_0409.gif"/></div><h4 class="head4">Figure 4-9. The Windows 2000 logon window</h4> + +<p>If you do not see the Log on to: drop-down menu, click the Options +<< button and it will appear. Select your domain, rather than +the local computer, from the menu.</p> +<a name="samba2-CHP-4-NOTE-109"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p>Be sure to select the correct domain in the logon dialog box. Once it +is selected, it might take a moment for Windows to build the list of +available domains.</p> +</blockquote> + +<p>Enter the username and password of any Samba-enabled user in the User +name: and Password: fields, and either press the Enter key or click +the OK button. If it worked, your Windows session will start up with +no error dialogs. <a name="INDEX-66"/><a name="INDEX-67"/></p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-3.5"/> + +<h3 class="head2">Windows XP Home</h3> + +<p><a name="INDEX-68"/>You have our +condolences if you are trying to use the Home edition of Windows XP +in a domain environment! Microsoft has omitted support for Windows NT +domains from Windows XP Home, resulting in a product that is +ill-suited for use in a domain-based network.</p> + +<p>On the client side, Windows XP Home users cannot log on to a Windows +NT domain. Although it is still possible to access domain resources, +a username and password must be supplied each time the user connects +to a resource, rather than the "single +signon" of a domain logon. Domain features such as +logon scripts and roaming profiles are not supported.</p> + +<p>As a server, Windows XP Home cannot join a Windows NT domain as a +domain member server. It can serve files and printers, but only using +share-mode ("workgroup") security. +It can't even use user-mode security, as Windows +95/98/Me can.</p> + +<p>Considering these limitations, we do not recommend Windows XP Home +for any kind of local area network computing.</p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-3.6"/> + +<h3 class="head2">Windows XP Professional</h3> + +<p><a name="INDEX-69"/><a name="INDEX-70"/>To configure Windows XP +Professional for domain logons, log in to the computer as +Administrator or another user in the Administrators group, open the +Control Panel in Classic View, and double-click the System icon to +open the System Properties dialog box. Click the Computer Name tab +and then click the Change... button. You should now see the Computer +Name Changes dialog box shown in <a href="ch04.html#samba2-CHP-4-FIG-10">Figure 4-10</a>.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-10"/><img src="figs/sam2_0410.gif"/></div><h4 class="head4">Figure 4-10. The Computer Name Changes dialog</h4> + +<p>Click the radio button labeled +"Domain:", and fill in the name of +your domain in the text-entry area. Then click the OK button. This +will bring up the Domain Username and Password dialog box. Enter +"root" for the username. For the +password, use the password that you gave to +<em class="emphasis">smbpasswd</em> for the root account.</p> +<a name="samba2-CHP-4-NOTE-110"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p>If Windows complains that you are already logged in, you probably +have an active connection to a share in the workgroup (such as a +mapped network drive). Disconnect the resource temporarily by +right-clicking its icon and choosing the Disconnect pop-up menu item.</p> +</blockquote> + +<p>After you press the OK button, Windows should present you with a +small dialog box welcoming you to the domain. When you click the OK +button in this dialog box, you will be told that you need to reboot +the computer to put the changes into effect. Click the OK buttons in +the dialog boxes to close them, and reboot the computer as requested. +When the system comes up again, the machine will automatically +present you with a Log On to Windows dialog box similar to the one +shown in <a href="ch04.html#samba2-CHP-4-FIG-11">Figure 4-11</a>.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-11"/><img src="figs/sam2_0411.gif"/></div><h4 class="head4">Figure 4-11. The Windows XP logon window</h4> + +<p>If you get a dialog box at this point that tells you the domain +controller cannot be found, the solution is to change a registry +setting as follows.</p> + +<p>Open the Start Menu and click the Run... menu item. In the text area +in the dialog box that opens, type in +"regedit" and click the OK button +to start the Registry Editor. You will be editing the registry, so +follow the rest of the directions very carefully. Click the +"<tt class="literal">+</tt>" button next +to the HKEY_LOCAL_MACHINE folder, and in the contents that open up, +click the "<tt class="literal">+</tt>" +button next to the SYSTEM folder. Continue in the same manner to open +CurrentControlSet, then Services, then Netlogon. (You will have to +scroll down many times to find Netlogon in the list of services.) +Then click the Parameters folder, and you will see items appear in +the right side of the window. Double-click +"requiresignorseal", and a dialog +box will open. In the Value data: text area, change the +"1" to a +"0" (zero), and click the OK +button, which modifies the registry both in memory and on disk. Now +close the Registry Editor and log off and back on again.</p> + +<p>If you do not see the Log on to: drop-down menu, click the Options +<< button and it will appear. Select your domain from the menu, +rather than the local computer.</p> +<a name="samba2-CHP-4-NOTE-111"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p>Be sure to select the correct domain in the logon dialog box. Once it +is selected, it might take a moment for Windows to build the list of +available domains.</p> +</blockquote> + +<p>Enter the username and password of any Samba-enabled user in the User +name: and Password: fields, and either press the Enter key or click +the OK button. If it worked, your Windows session will start up with +no error dialogs. <a name="INDEX-71"/> <a name="INDEX-72"/><a name="INDEX-73"/></p> + + +</div> + + +</div> + + + +<div class="sect1"><a name="samba2-CHP-4-SECT-4"/> + +<h2 class="head1">Logon Scripts</h2> + +<p><a name="INDEX-74"/>After a Windows client connects with a +domain controller (either to authenticate a user, in the case of +Windows 95/98/Me, or to log on to the domain, in the case of Windows +NT/2000/XP), the client downloads an MS-DOS batch file to run. The +domain controller supplies the file assuming one has been made +available for it. This batch file is the logon script and is useful +in setting up an initial environment for the user.</p> + +<p>In a Unix environment, the ability to run such a script might lead to +a very complex initialization and deep customization. However, the +Windows environment is mainly oriented to the GUI, and the +command-line functions are more limited. Most commonly, the logon +script is used to run a <em class="emphasis">net</em> command, such as +<em class="emphasis">net use</em><a name="INDEX-75"/>, to connect a network drive letter, +like this:</p> + +<blockquote><pre class="code">net use T: \\toltec\test</pre></blockquote> + +<p>This command will make our <tt class="literal">[test]</tt> share (from +<a href="ch02.html">Chapter 2</a>) show up as the T: drive in My Computer. +This will happen automatically, and T: will be available to the user +at the beginning of her session, instead of requiring her to run the +<em class="emphasis">net use</em> command or connect the T: drive using +the Map Network Drive function of Windows Explorer.</p> + +<p>Another useful command is:</p> + +<blockquote><pre class="code">net use H: /home</pre></blockquote> + +<p>which <a name="INDEX-76"/><a name="INDEX-77"/>connects the +user's home directory to a drive letter (which can +be H:, as shown here, or some other letter, as defined by +<tt class="literal">logon</tt> <tt class="literal">drive</tt>). For this to work, +you must have a <tt class="literal">[homes]</tt> share defined in your +<em class="filename">smb.conf</em> file.</p> + +<p>If you are using <a name="INDEX-78"/><a name="INDEX-79"/>roaming profiles, you should definitely +have:</p> + +<a name="INDEX-80"/><blockquote><pre class="code">net time \\<em class="replaceable">toltec</em> /set /yes</pre></blockquote> + +<p>in your logon script. (As usual, replace +"toltec" with the name of your +Samba PDC.) This will make sure the clocks of the Windows clients are +synchronized with the PDC, which is important for roaming profiles to +work correctly.</p> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-4.1"/> + +<h3 class="head2">Creating a Logon Script</h3> + +<p><a name="INDEX-81"/>In our +<em class="filename">smb.conf</em> file, we have the line:</p> + +<a name="INDEX-82"/><blockquote><pre class="code">logon script = logon.bat</pre></blockquote> + +<p>This defines the location and name of the logon script batch file on +the Samba server. The path is relative to the +<tt class="literal">[netlogon]</tt><a name="INDEX-83"/> share, defined later in the +file like this:</p> + +<blockquote><pre class="code">[netlogon] + path = /usr/local/samba/lib/netlogon + writable = no + browsable = no</pre></blockquote> + +<p>With this example, the logon script is +<em class="filename">/user/local/samba/lib/netlogon/logon.bat</em>. We +include the directives <tt class="literal">writable</tt> +<tt class="literal">=</tt> <tt class="literal">no</tt>, to make sure network +clients cannot change anything in the <tt class="literal">[netlogon]</tt> +share, and also <tt class="literal">browsable</tt> <tt class="literal">=</tt> +<tt class="literal">no</tt>, which keeps them from even seeing the share +when they browse the contents of the server. Nothing in +<tt class="literal">[netlogon]</tt> should ever be modified by +nonadministrative users. Also, the permissions on the directory for +<tt class="literal">[netlogon]</tt> should be set appropriately (no write +permissions for "other" users), as +we showed you earlier in this chapter.</p> + +<p>Notice also that the extension of our logon script is +<em class="filename">.bat</em><a name="INDEX-84"/>. Be careful about this—an extension +of <em class="filename">.cmd</em><a name="INDEX-85"/> will work for Windows NT/2000/XP clients, +but will result in errors for Windows 95/98/Me clients, which do not +recognize <em class="filename">.cmd</em> as an extension for batch files.</p> + +<p>Because the logon script will be executed on a Windows system, it +must be in MS-DOS text-file format, with the end of line composed of +a carriage return followed by a linefeed. The Unix convention is a +newline, which is simply a linefeed character, so if you use a Unix +text editor to create your logon script, you must somehow make it use +the appropriate characters. With +<em class="emphasis">vim</em><a name="INDEX-86"/><a name="INDEX-87"/> (a clone of the <em class="emphasis">vi</em> +editor that is distributed with Red Hat Linux), the method is to +create a new file and use the command:</p> + +<blockquote><pre class="code">:se ff=dos</pre></blockquote> + +<p>to set the file format to MS-DOS style before typing in any text. +With <em class="emphasis">emacs</em><a name="INDEX-88"/>, the same can be done using the command:</p> + +<blockquote><pre class="code">^X <em class="replaceable">Enter</em> f dos <em class="replaceable">Enter</em></pre></blockquote> + +<p>where <tt class="literal">^X</tt> is a Control-X character and +<tt class="literal">Enter</tt> is a press of the Enter key. Another method +is to create a Unix-format file in any text editor and then convert +it to MS-DOS format using the +<em class="emphasis">unix2dos</em><a name="INDEX-89"/> program:</p> + +<blockquote><pre class="code">$ <tt class="userinput"><b>unix2dos unix_file >logon.bat</b></tt></pre></blockquote> + +<p>If your system does not have <em class="emphasis">unix2dos</em>, +don't worry. You can implement it yourself with the +following two-line Perl script:</p> + +<blockquote><pre class="code">#!/usr/bin/perl +open FILE, $ARGV[0]; +while (<FILE>) { s/$/\r/; print }</pre></blockquote> + +<p>Or, you can use Notepad on a Windows system to write your script and +then drag the logon script over to a folder on the Samba server. In +any case, you can <a name="INDEX-90"/>check the format of your script using +the <em class="emphasis">od</em><a name="INDEX-91"/> command, like this:</p> + +<blockquote><pre class="code">$ <tt class="userinput"><b>od -c logon.bat</b></tt></pre></blockquote> + +<p>You should see output resembling this:</p> + +<blockquote><pre class="code">0000000 n e t u s e T : \ \ t o l +0000020 t e c \ t e s t \r \n +0000032</pre></blockquote> + +<p>The important detail here is that at the end of each line is a +<tt class="literal">\r</tt> <tt class="literal">\n</tt>, which is a carriage +return followed by a linefeed.</p> + +<p>Our example logon script, containing a single <em class="emphasis">net +use</em> command, was created and set up in a way that allows +it to be run successfully on any Windows client, regardless of which +Windows version is installed on the client and which user is +authenticating or logging on to the domain. But what if we need to +have different users, computers, or Windows versions running +different logon scripts?</p> + +<p>One method is to use variables inside the <a name="INDEX-92"/>logon script that cause commands to be +conditionally executed. For details on how to do this, you can +consult a reference on batch-file programming for MS-DOS and Windows +NT command language. One such reference is <em class="citetitle">Windows NT +System Administration</em>, published by +O'Reilly.</p> + +<p>Windows batch-command language is very limited in functionality. +Fortunately, Samba also supports a means by which customization can +be handled. The +<em class="filename">smb.conf</em><a name="INDEX-93"/><a name="INDEX-94"/> file contains variables that can be +used to insert (at runtime) the name of the server +(<tt class="literal">%L</tt><a name="INDEX-95"/>), the username of the person who is +accessing the server's resources +(<tt class="literal">%u</tt><a name="INDEX-96"/>), or the computer name of the client +system (<tt class="literal">%m</tt><a name="INDEX-97"/>). To give an example, if we set up the +path to the logon script as:</p> + +<blockquote><pre class="code">logon script = %u/logon.bat</pre></blockquote> + +<p>we would then put a directory for each user in the +<tt class="literal">[netlogon]</tt> share, with each directory named the +same as the user's username, and in each directory +we would put a customized <em class="filename">logon.bat</em> file. Then +each user would have his own custom logon script. We will give you a +better example of how to do this kind of thing in the next section, +<a href="ch04.html#samba2-CHP-4-SECT-5">Section 4.5</a>.</p> + +<a name="samba2-CHP-4-NOTE-112"/><blockquote class="note"><h4 class="objtitle">TIP</h4> +<p>For more information on Samba configuration file variables, such as +the <tt class="literal">%L</tt>, <tt class="literal">%u</tt>, and +<tt class="literal">%m</tt> variables we just used, see <a href="ch06.html">Chapter 6</a> and <a href="appb.html">Appendix B</a>.</p> +</blockquote> + +<p>When modifying and testing your logon script, don't +just log off of your Windows session and log back on to make your +script run. Instead, restart (reboot) your system before logging back +on. Because Windows often keeps the <tt class="literal">[netlogon]</tt> +share open across logon sessions, the reboot ensures that Windows and +Samba have completely released and reconnected the +<tt class="literal">[netlogon]</tt> share, and the new version of the logon +script is being run while logging on.</p> + +<p>More information regarding <a name="INDEX-98"/>logon scripts can be found in the +O'Reilly book, <em class="emphasis">Managing Windows NT +Logons</em>. <a name="INDEX-99"/> <a name="INDEX-100"/><a name="INDEX-101"/></p> + + +</div> + + +</div> + + + +<div class="sect1"><a name="samba2-CHP-4-SECT-5"/> + +<h2 class="head1">Roaming Profiles</h2> + +<p><a name="INDEX-102"/>One benefit of the centralized +authentication of Windows NT domains is that a user +<a name="INDEX-103"/>can log on from more than just one +computer. To help users feel more "at +home" when logged on at a computer other than their +usual one, Microsoft has added the ability for +users' personal settings to +"roam" from one computer to +another.</p> + +<p>All Windows versions can be configured individually for each user of +the computer. Windows NT/2000/XP supports the ability to handle +multiple user accounts, and Windows 95/98/Me can be configured for +use by multiple users, keeping the configuration settings for each +user separate. Each user can configure the +computer's settings to her liking, and the system +saves these settings as the user's +<em class="firstterm">profile</em>, such that upon logging on to the +system, the user is presented with her familiar desktop.</p> + +<p>Some of the settings, such as folder options or the image used for +the desktop background, are held in the registry. Others, including +the documents and folders appearing on the desktop and the contents +of the Start menu, are stored as folders and files in the filesystem.</p> + +<p>When the profile is stored on the local system, it is called a +<em class="firstterm">local profile</em><a name="INDEX-104"/>. On Windows NT, local profiles are +stored in <em class="filename">C:\winnt\profiles</em>. On Windows 2000/XP, +they can be found in <em class="filename">C:\Documents and Settings. +</em>On Windows 95/98/Me, when configured for a single user +(the default case), the local profile is scattered in places such as +the registry and directories such as +<em class="filename">C:\Windows\Desktop</em> and +<em class="filename">C:\Windows\Start Menu</em>. When Windows 95/98/Me is +configured for multiple users, the local profile of the preexisting +user is moved to a folder in <em class="filename">C:\Windows\Profiles</em> +that has the same name as the user, and any users that are +subsequently added to the computer have their local profiles created +in that directory as well. You can browse through the local profiles +to see their structure—each has a <a name="INDEX-105"/><a name="INDEX-106"/><a name="INDEX-107"/><a name="INDEX-108"/><a name="INDEX-109"/>registry file +(<em class="filename">USER.DAT</em><a name="INDEX-110"/><a name="INDEX-111"/> for Windows 95/98/Me and +<em class="filename">NTUSER.DAT</em><a name="INDEX-112"/><a name="INDEX-113"/> for Windows NT/2000/XP) and some folders +that contain shortcuts and documents.</p> + +<p>A roaming profile is a user profile that is stored on a server and +"follows" its owner around the +network so that when the user logs on to the domain from another +computer, his profile is downloaded from the server and his familiar +desktop appears on that computer as well.</p> +<a name="samba2-CHP-4-NOTE-113"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p><a name="INDEX-114"/>Samba can +support roaming profiles, and it is a fairly simple matter to +configure it for them. However, this is one feature that we recommend +you <em class="emphasis">do not</em> use, at least until you are sure you +understand roaming profiles well and are very confident that you can +implement them with no harm incurred. If you want to (or are required +to) implement roaming profiles for your Windows clients, we suggest +you first set up a small domain with a Samba server and a few Windows +clients exclusively for the purposes of research and testing. +<em class="emphasis">Under no circumstances should you attempt to implement +roaming profiles in a careless or frivolous manner</em>.</p> +</blockquote> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-5.1"/> + +<h3 class="head2">How Roaming Profiles work</h3> + +<p><a name="INDEX-115"/>We will start out by explaining to you +how roaming profiles work when set up correctly. You will need a +clear understanding of them to tell the difference between when they +are working as they are designed and when they are not. In addition, +roaming profiles can be a source of confusion for your users in many +ways, and you should know how to detect when a problem with a client +is related to roaming profile function or dysfunction.</p> + +<a name="samba2-CHP-4-NOTE-114"/><blockquote class="note"><h4 class="objtitle">TIP</h4> +<p><a name="INDEX-116"/>A definitive source of +documentation on Windows NT roaming profiles is the Microsoft white +paper <em class="citetitle">Implementing Policies and Profiles for Windows NT +4.0</em><a name="INDEX-117"/>, which can be found at +<a href="http://www.microsoft.com/ntserver/techresources/management/prof_policies.asp">http://www.microsoft.com/ntserver/techresources/management/prof_policies.asp</a>.</p> +</blockquote> + +<p>During the domain logon process, the roaming profile is copied from +the domain controller and used as a local profile during the +user's logon session. When the user logs off the +domain, the local profile is copied back to the domain controller and +stored as the new roaming profile. When the local profile is changed, +the server does not receive an update until the user logs off the +domain or shuts down or reboots the client. The client does not send +an update to the server during the logon session, and a client does +not receive an update of a setting changed on another client during a +logon session. When the user does log off, changes in the +configuration settings in the local profile are sent to the server, +and the updates of the roaming profile are available for the next +logon session.</p> + +<p>This simple behavior can lead to unexpected results when users are +<a name="INDEX-118"/>logged on to the domain +on more than one client at a time. If a user makes a change to the +configuration settings on one client and then logs off, the settings +can result in the roaming profile being modified accordingly. But the +next client that logs off might cause those changes to be +overwritten, and if so, the settings from the first client will be +lost. The behavior of different Windows versions varies with regard +to this, and we've seen a wide variety of +behaviors—not always in alignment with +Microsoft's documentation or even working the same +way on separate occasions. Sometimes Windows will refuse to overwrite +a profile, perhaps giving an "access +denied" error, and at other times it will seem to +work while producing odd side effects. A common source of confusion +is what happens if a file is added to or deleted from the desktop, +which is by default configured to be part of the profile. A deleted +file might later reappear, and it is even possible for a file to +irrecoverably disappear without warning (on Windows 95/98). Or maybe +a file that is added to the desktop on one client never gets added to +the roaming profile and fails to propagate to other clients. This +behavior is somewhat improved on Windows 2000/XP, which attempts to +merge items into the profile that are added on concurrently logged-on +clients.</p> + +<p>One factor that comes into play is that Windows compares the +<a name="INDEX-119"/>timestamps of the local and roaming +profiles and can refuse to overwrite a roaming profile if it is newer +than the local profile on the client, or vice versa. For this reason, +it is important to keep the clocks of the Windows clients and the +Samba PDC synchronized. We have already shown you how to do this, +using the <em class="emphasis">net time +\\</em><em class="replaceable">server</em> +<em class="emphasis">/set</em> <em class="emphasis">/yes</em> command in the +logon script.</p> + +<p><a name="INDEX-120"/>Even when the server and clients are +correctly configured, a number of things that can happen make things +seem "broken." The most common +occurrence is that some shortcuts on clients other than the one that +created the roaming profile will not work. These shortcuts can exist +on the desktop or as items in the Start menu. This behavior is a +result of applications or files that exist on one computer but not +others. Windows will display these shortcuts, but if they appear on +the desktop, they will have a generic icon and will bring up an error +message if a user double-clicks them.</p> + +<a name="samba2-CHP-4-NOTE-115"/><blockquote class="note"><h4 class="objtitle">TIP</h4> +<p>Because profiles can and usually do include the contents of the +desktop and other folders, it is possible for the roaming profile to +grow to a huge size due to actions of a user, such as creating new +files on the desktop or copying files there. By default, Internet +Explorer keeps its disk cache in the <em class="filename">Temporary Internet +Files</em><a name="INDEX-121"/><a name="INDEX-122"/> folder in the profile and has been +known to populate this directory with thousands of files. This can +result in a huge roaming profile that causes network congestion and +very large delays while users are logging on to the domain. (A fix +for this can be found in article Q185255 in the Microsoft Knowledge +Base.)</p> +</blockquote> + +<p>One behavior we've seen a few times is that if, for +some reason (e.g., a network error or misconfiguration), the roaming +profile is not available during the logon process, Windows will use +the local profile on the client instead. When this happens, the user +might receive an unfamiliar profile, and all the benefits of roaming +profiles are lost for that logon session.</p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-5.2"/> + +<h3 class="head2">Configuring Samba for Roaming Profiles</h3> + +<p><a name="INDEX-123"/><a name="INDEX-124"/>In an ideal world, different Windows +versions would share the same roaming profile, allowing users to log +on to the domain from any Windows client system, ranging from Windows +95 to Windows XP, and enjoy their familiar settings. It would even be +possible to be logged on concurrently from multiple clients, and a +change made to the profile on any of them would quickly propagate to +all the others. Settings in a roaming profile made on a client that +didn't apply to another would be handled sanely.</p> + +<p>Unfortunately, this scenario does not work in reality, and it is +important to maintain separate roaming profiles to prevent different +Windows versions from using or modifying a roaming profile created +by, and/or in use by, another version.</p> + +<p>We do this by using configuration file variables to point to +different profile directories. If you look at <a href="appb.html#samba2-APP-B-TABLE-1">Table B-1</a> in <a href="appb.html#samba2-APP-B#samba2-APP-B">Appendix B</a>, which shows +the variables that can be used, you might be tempted to use the +<a name="INDEX-125"/><tt class="literal">%a</tt> variable, which +is replaced by the name of the operating system the client is +running. However, this does not work because all of Windows 95/98/Me +will be seen as the same operating system, and likewise for Windows +2000/XP. So, we use <a name="INDEX-126"/><tt class="literal">%m</tt> to get the +NetBIOS name of the client, and combine that with a symbolic link to +point to the directory containing the profile for the Windows version +that particular client is running.</p> + +<p>Our additions to <em class="filename">smb.conf</em> that appeared earlier +in this chapter included the two lines:</p> + +<blockquote><pre class="code">logon path = \\%L\profiles\%u\%m +logon home = \\%L\%u\.win_profile\%m</pre></blockquote> + +<p>The first line specifies where the roaming profiles for Windows +NT/2000/XP clients are kept, and the second line performs the same +function for Windows 95/98/Me clients. In both cases, the location is +specified as a UNC, but +<tt class="literal">logon</tt><a name="INDEX-127"/> <tt class="literal">path</tt> (for Windows +NT/2000/XP) is specified relative to the +<tt class="literal">[profiles]</tt> share, while +<tt class="literal">logon</tt><a name="INDEX-128"/> <tt class="literal">home</tt> (for Windows +95/98/Me) is specified relative to the user's home +directory. This is done to comply with Samba's +emulation of Windows NT/2000 PDC behavior.</p> + +<p>The <tt class="literal">logon</tt> <tt class="literal">home</tt> UNC must begin +by specifying the user's home directory, which in +our previous example would be <tt class="literal">\\%L\%u</tt>. The +variable <tt class="literal">%L</tt><a name="INDEX-129"/> expands to the NetBIOS name of the +server (in this case, toltec), and +<tt class="literal">%u</tt><a name="INDEX-130"/> expands to the name of the user. This +must be done to allow the command:</p> + +<a name="INDEX-131"/><blockquote><pre class="code">C:\><tt class="userinput"><b>net use h: /home</b></tt></pre></blockquote> + +<p>to function correctly to connect the user's home +directory to drive letter H: on all Windows clients. (The drive +letter used for this purpose is defined by <tt class="literal">logon</tt> +<tt class="literal">drive</tt>.) We add the directory +<em class="filename">.win_profile</em><a name="INDEX-132"/> to the UNC to put the Windows +95/98/Me roaming profile in a subdirectory of the +user's home directory.</p> +<a name="samba2-CHP-4-NOTE-116"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p>Note that in both <tt class="literal">logon path</tt> and <tt class="literal">logon +home</tt>, we absolutely avoid making the profile directory the +same as the user's home directory, and the directory +that contains the profile is not used for any other purpose. This is +because when the roaming profile is updated, all directories and +files in the roaming-profile directory that are not part of the +roaming profile are deleted.</p> +</blockquote> + +<p>In the <tt class="literal">logon</tt> <tt class="literal">path</tt> line in +<em class="filename">smb.conf</em>, we use <tt class="literal">%u</tt> to put +the profiles directory in a subdirectory in the +<tt class="literal">[profiles]</tt> share, such that each user gets her own +directory that holds her roaming profiles.</p> + +<p>We define the <tt class="literal">[profiles]</tt> share like this:</p> + +<blockquote><pre class="code">[profiles] + writable = yes + create mask = 0600 + directory mask = 0700 + browsable = no + path = /home/samba-ntprof</pre></blockquote> + +<p>The first four parameters in the previous share definition specify to +allow roaming profiles to be written with the users' +permissions, to create files with read and write permissions for the +owner, and to create directories with read, write, and search +permissions for the owner and no access allowed for other users. As +with the <tt class="literal">[netlogon]</tt> share, we set +<tt class="literal">browsable</tt> <tt class="literal">=</tt> +<tt class="literal">no</tt> so that the share will not show up on the +clients in Windows Explorer.</p> + +<p>We've decided to put our Windows NT/2000/XP profiles +in <em class="filename">/home</em>, the default location of the home +directories on Linux. This will make it simple to include the roaming +profiles in backups of the home directories. You can use another +directory if you like.</p> + +<p>Notice that in both <tt class="literal">logon</tt> <tt class="literal">path</tt> +and <tt class="literal">logon</tt> <tt class="literal">home</tt>, the directory +we specify ends in <tt class="literal">%m</tt>, which Samba replaces with +the NetBIOS name of the client. We are using the +client's computer name to identify indirectly which +version of Windows it is running.</p> + +<p>Initially, the directories you specify to hold the roaming profiles +will be empty and will become populated as clients log off for the +first time. (Samba will even create the directories if they do not +already exist.) At first, the directories will simply contain +profiles that are identical to the clients' local +profiles, and we highly recommend that you make a backup at this +point before things get complicated. A listing of the roaming profile +directory for user <tt class="literal">iman</tt>, after she has logged off +from Windows 98 clients <tt class="literal">mixtec</tt> and +<tt class="literal">pueblo</tt> and Windows Me clients +<tt class="literal">huastec</tt> and <tt class="literal">navajo</tt>, might look +something like the following:</p> + +<blockquote><pre class="code">$ <tt class="userinput"><b>ls -l /home/iman/.win_profile</b></tt> +total 4 +drwx------ 6 iman iman 4096 Dec 8 18:09 huastec +drwx------ 9 iman iman 4096 Dec 7 03:47 mixtec +drwx------ 11 iman iman 4096 Dec 7 03:05 navajo +drwx------ 11 iman iman 4096 Dec 7 03:05 pueblo</pre></blockquote> + +<p>If things were left like this, the clients would not share their +roaming profiles, so next we change from using separate directories +to having symbolic links point to common directories:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>mv mixtec Win98</b></tt> +# <tt class="userinput"><b>mv navajo WinMe</b></tt> +# <tt class="userinput"><b>rm huastec pueblo</b></tt> +# <tt class="userinput"><b>ln -s Win98 pueblo</b></tt> +# <tt class="userinput"><b>ln -s WinMe huastec</b></tt> +# <tt class="userinput"><b>chown iman:iman *</b></tt> +# <tt class="userinput"><b>ls -l /home/iman/.win_profile</b></tt> +total 6 +lrwxrwxrwx 1 iman iman 5 Nov 16 01:40 huastec -> WinMe +lrwxrwxrwx 1 iman iman 5 Nov 16 01:40 mixtec -> Win98 +lrwxrwxrwx 1 iman iman 5 Nov 21 17:24 navajo -> WinMe +lrwxrwxrwx 1 iman iman 5 Nov 23 01:16 pueblo -> Win98 +drwx------ 9 iman iman 4096 Dec 7 03:47 Win98 +drwx------ 11 iman iman 4096 Dec 7 03:05 WinMe</pre></blockquote> + +<p>Now when <tt class="literal">iman</tt> logs on to the domain from either +Windows 98 system, the client from which she is logging on will get +the profile stored in the <em class="filename">Win98</em> directory (that +started out as her local profile on <tt class="literal">mixtec</tt>). This +works likewise for the Windows Me clients.</p> + +<p>To show a more complete example, here is a listing of a fully +operational Windows 95/98/Me profiles directory:</p> + +<a name="INDEX-133"/><blockquote><pre class="code">$ <tt class="userinput"><b>ls -l /home/jay/.win_profile</b></tt> +total 12 +lrwxrwxrwx 1 jay jay 9 Nov 16 22:14 aztec -> /home/jay +lrwxrwxrwx 1 jay jay 5 Nov 16 01:40 hopi -> Win95 +lrwxrwxrwx 1 jay jay 5 Nov 16 01:40 huastec -> WinMe +lrwxrwxrwx 1 jay jay 5 Nov 16 01:38 maya -> Win98 +lrwxrwxrwx 1 jay jay 5 Nov 16 01:40 mixtec -> Win98 +lrwxrwxrwx 1 jay jay 5 Nov 21 17:24 navajo -> WinMe +lrwxrwxrwx 1 jay jay 5 Nov 23 01:16 pueblo -> Win98 +lrwxrwxrwx 1 jay jay 5 Nov 22 02:06 ute -> Win95 +drwx------ 6 jay jay 4096 Dec 8 18:09 Win95 +drwx------ 9 jay jay 4096 Dec 7 03:47 Win98 +drwx------ 11 jay jay 4096 Dec 7 03:05 WinMe +lrwxrwxrwx 1 jay jay 5 Nov 21 22:48 yaqui -> Win98 +lrwxrwxrwx 1 jay jay 9 Nov 16 22:14 zuni -> /home/jay</pre></blockquote> + +<p>Again, the computer name of each client exists in this directory as a +symbolic link that points to the directory containing the actual +roaming profile. For example, <tt class="literal">maya</tt>, a client that +runs Windows 98, has a symbolic link named <em class="filename">maya</em> +to the <em class="filename">Win98</em> directory. A listing of +<em class="filename">Win98</em> shows:</p> + +<blockquote><pre class="code">$ <tt class="userinput"><b>ls -l Win98</b></tt> +total 148 +drwxr-xr-x 3 jay jay 4096 Nov 23 01:30 Application Data +drwxr-xr-x 2 jay jay 4096 Nov 23 01:30 Cookies +drwxr-xr-x 3 jay jay 4096 Dec 7 03:47 Desktop +drwxr-xr-x 3 jay jay 4096 Nov 23 01:30 History +drwxr-xr-x 2 jay jay 4096 Nov 23 01:30 NetHood +drwxr-xr-x 2 jay jay 4096 Dec 7 03:47 Recent +drwxr-xr-x 3 jay jay 4096 Nov 23 01:30 Start Menu +-rw-r--r-- 1 jay jay 114720 Dec 7 03:46 USER.DAT</pre></blockquote> + +<p>The contents of the <em class="filename">Win95</em> and +<em class="filename">WinMe</em> directories appear similar and contain +roaming profiles that work exactly as they should on their respective +operating systems.</p> + +<p>Notice in the previous listing that <em class="filename">aztec</em> and +<em class="filename">zuni</em> are symbolic links to +<em class="filename">/home/jay</em>. We've cautioned you +never to configure a roaming profile directory to be a +user's home directory, but this is to handle +something different. The clients <tt class="literal">aztec</tt> and +<tt class="literal">zuni</tt> are Windows XP systems, which handle +<tt class="literal">logon</tt> <tt class="literal">home</tt> differently than +other versions of Windows. We have set <tt class="literal">logon</tt> +<tt class="literal">home</tt> <tt class="literal">=</tt> +<tt class="literal">\\%L\%u\</tt>.<tt class="literal">win</tt> +<tt class="literal">profile</tt>, and all versions of Windows except for +Windows XP strip off everything after <tt class="literal">\\%L\%u</tt> and +correctly locate the home directory—in this case, +<em class="filename">/home/jay</em>. Windows XP uses the full UNC, so we +simply add a symbolic link to redirect it to the correct directory to +get the <em class="emphasis">net use H: /home</em> command to work as it +should. The roaming profiles for Windows XP systems are not affected +by this and are kept with the other roaming profiles in the Windows +NT/2000/XP family, as shown in this listing:</p> + +<blockquote><pre class="code">$ <tt class="userinput"><b>ls -l /home/samba-ntprof/jay</b></tt> +total 16 +lrwxrwxrwx 1 jay jay 5 Nov 20 03:45 apache -> Win2K +lrwxrwxrwx 1 jay jay 5 Nov 13 12:35 aztec -> WinXP +lrwxrwxrwx 1 jay jay 5 Nov 13 12:34 dine -> WinNT +lrwxrwxrwx 1 jay jay 5 Nov 24 03:44 inca -> Win2K +lrwxrwxrwx 1 jay jay 5 Nov 13 12:34 pima -> Win2K +drwx------ 13 jay jay 4096 Dec 3 15:24 qero +drwx------ 13 jay jay 4096 Dec 1 20:31 Win2K +drwx------ 12 jay jay 4096 Nov 30 17:04 WinNT +drwx------ 13 jay jay 4096 Nov 20 01:23 WinXP +lrwxrwxrwx 1 jay jay 5 Nov 20 06:09 yavapai -> WinXP +lrwxrwxrwx 1 jay jay 5 Nov 13 12:34 zapotec -> Win2K +lrwxrwxrwx 1 jay jay 5 Nov 13 12:35 zuni -> WinXP</pre></blockquote> + +<p>As you can see, we are using a similar method for the Windows +NT/2000/XP roaming profiles. In the listing, +<em class="filename">qero</em> is not a symbolic link, but rather a +directory that holds the roaming profile for <tt class="literal">qero</tt>, +a Windows 2000 client that has recently been added. We had not +created a symbolic link called <em class="filename">qero</em> before +installing Windows 2000, so when jay logged off for the first time, +Samba created a directory named <em class="filename">qero</em> and copied +the roaming profile received from the client to the new directory. +Because this is a separate directory from <em class="filename">Win2K</em>, +which all other Windows 2000 clients are using to share their roaming +profiles, the roaming profile for <tt class="literal">qero</tt> works like +a local profile, except that it is stored on the primary domain +controller.</p> + +<p>This might seem like an odd thing to do, but it has some purpose. +Sometimes you might wish to isolate a client in this manner, +especially while the operating system is being installed and +initially configured. Remember, if that client, with its default +local profile, is logged off the domain, the local profile will be +written to the roaming profile directory. If the client were using +the shared roaming profile directory, the effect could be +undesirable, to say the least. Using our method, the +<em class="filename">qero</em> directory can later be renamed to make it +into an archival backup, or it can just be deleted. Then a new +symlink named <em class="filename">qero</em> can be created to point to +the <em class="filename">Win2K</em> directory, and <tt class="literal">qero</tt> +will share the roaming profile in <em class="filename">Win2K</em> with the +other Windows 2000 clients.</p> + +<p>An alternative method is simply to create the +<a name="INDEX-134"/>symbolic +links before the clients are added to the network. After you become +more comfortable with the way roaming profiles work, you might find +this method to be simpler and quicker.</p> + +<p>Again, we urge you to be careful about letting different versions of +Windows share the same roaming profile. The method of configuring +roaming profiles we've shown you here allows you to +test a configuration for a few clients at a time without affecting +your whole network of clients. For example, we could install a small +number of Windows 2000 and Windows XP systems in the domain for +testing purposes and then create symlinks for them that point to a +directory called <em class="filename">Win2KXP</em> to find out if sharing +roaming profiles between our Windows 2000 and Windows XP systems +meets our expectations. The <em class="filename">Win2KXP</em> directory +could be created as an empty directory, in which case it would have a +roaming profile written to it by the first of the clients to log off. +Or, <em class="filename">Win2KXP</em> could simply be a renamed roaming +profile directory that was created by one of the clients when it was +added to the domain. <a name="INDEX-135"/><a name="INDEX-136"/></p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-5.3"/> + +<h3 class="head2">Configuring Windows 95/98/Me for Roaming Profiles</h3> + +<p><a name="INDEX-137"/><a name="INDEX-138"/>For roaming profiles to work on +Windows 95/98/Me clients, all you need to do is change one setting to +allow each user to have a separate local profile. This has the side +effect of enabling roaming profiles as well.</p> + +<p>Open the Control Panel and double-click the Passwords icon to open +the Passwords Properties dialog box. Click the User Profiles tab, and +the dialog box will appear as shown in <a href="ch04.html#samba2-CHP-4-FIG-12">Figure 4-12</a>.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-12"/><img src="figs/sam2_0412.gif"/></div><h4 class="head4">Figure 4-12. The Windows 98 Passwords Properties dialog</h4> + +<p>Click the button labeled "Users can customize their +preferences and desktop settings." In the User +profile settings box, you can check the options you prefer. When +done, click the OK button and reboot as requested. During this first +reboot, Windows will copy the local profile data to +<em class="filename">C:\windows\profiles</em> but will not attempt to copy +the roaming profile from the server. The next time the system is shut +down, the local profile will be copied to the server, and when +Windows reboots, it will copy the roaming profile from the server.</p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-5.4"/> + +<h3 class="head2">Configuring Windows NT/2000/XP for Roaming Profiles</h3> + +<p><a name="INDEX-139"/><a name="INDEX-140"/><a name="INDEX-141"/><a name="INDEX-142"/>Roaming profiles are enabled by +default on Windows NT/2000/XP. In case you would like to check or +modify your settings, follow these directions.</p> + +<p>Make sure you are logged in to the local system as Administrator or +another user in the Administrators group. Open the Control Panel and +double-click the System icon. On Windows NT/2000, click the User +Profiles tab, or on Windows XP, click the Advanced tab and then the +Settings button in the User Profiles box. You should see the dialog +box in <a href="ch04.html#samba2-CHP-4-FIG-13">Figure 4-13</a>.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-13"/><img src="figs/sam2_0413.gif"/></div><h4 class="head4">Figure 4-13. The Windows 2000 System Properties, User Profiles tab</h4> + +<p>Notice in the figure that there are two entries for the username +<tt class="literal">jay</tt>. The entry ZAPOTEC\jay refers to the account +on the local system, and METRAN\jay refers to the domain account. +Recall that when a user logs on, a drop-down menu in the dialog box +allows him to log on to a domain or log in to the local system. When +<tt class="literal">jay</tt> logs in to the local machine, only the local +profile is used. When logged on to the domain, the configuration +shown will use the roaming profile. To switch a +user's profile type for a domain logon account, +click the account name to select it, then click the Change Type... +button near the bottom of the dialog box. The Change Profile Type +dialog box will appear. Click the radio button for either roaming or +local profile, and then click the OK buttons for each dialog box.</p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-5.5"/> + +<h3 class="head2">Mandatory Profiles</h3> + +<p><a name="INDEX-143"/>With a simple +modification, a <a name="INDEX-144"/>roaming profile can be made into a +<a name="INDEX-145"/>mandatory +profile, which has the quality of being unmodifiable by its owner. +Mandatory profiles are used in some computing environments to +simplify administration. The theory is that if users cannot modify +their profiles, less can go wrong, and it is also possible to use the +same standardized profile for all users.</p> + +<p>In practice, some issues come up. Because the users can still modify +the configuration settings in their local profile during their logon +session, confusion can result the next time they log on to the domain +and discover their changes have been +"lost." If the user of a client +reinstalls an application in a different place, the shortcuts to the +program on the desktop, in the Start menu, or in a Quick Launch bar +cannot be permanently deleted. They will reappear every time the user +logs back on to the domain. Essentially, a mandatory profile is a +roaming profile that always fails to update to the server upon +logging off!</p> + +<p>Another complication is that different versions of Windows behave +differently with mandatory profiles. If a user who has a mandatory +profile creates a new file on her desktop, the file might be missing +the next time the user logs off and on again or reboots. Some Windows +versions preserve desktop files in the local profile (even if the +file does not exist in the mandatory profile), whereas others do not.</p> + +<p>To change a <a name="INDEX-146"/><a name="INDEX-147"/>roaming profile to a mandatory +profile, all you have to do is rename the +<em class="filename">.dat</em><a name="INDEX-148"/><a name="INDEX-149"/> file in the roaming profile directory +on the server to have a <em class="filename">.man</em> extension instead. +For a Windows 95/98/Me roaming profile, you would rename +<em class="filename">USER.DAT</em> to <em class="filename">USER.MAN</em>, and +for a Windows NT/2000/XP roaming profile, you would rename +<em class="filename">NTUSER.DAT</em> to <em class="filename">NTUSER.MAN</em>. +Also, you might want to make the roaming-profile directory and its +contents read-only, to make sure that a user can't +change it by logging into his Unix user account on the Samba host +system.</p> + +<p>If you want to have all your users share a mandatory profile, you can +change the definitions of <tt class="literal">logon</tt> +<tt class="literal">path</tt> and <tt class="literal">logon</tt> +<tt class="literal">home</tt> in your <em class="filename">smb.conf</em> file to +point to a shared mandatory profile on the server and adjust your +directory structure and symbolic links accordingly. For example, +<tt class="literal">logon</tt> <tt class="literal">path</tt> and +<tt class="literal">logon</tt> <tt class="literal">home</tt> might be defined +like this:</p> + +<blockquote><pre class="code">logon path = \\%L\profiles\%m +logon home = \\%L\%u\.win_profile\%m</pre></blockquote> + +<p>Notice that we've removed the <tt class="literal">%u</tt> +part of the path for <tt class="literal">logon</tt> +<tt class="literal">path</tt>, and we would also change the directory +structure on the server to do away with the separation of the +profiles by username and have just one profile for each Windows +NT/2000/XP version.</p> + +<p>We cannot use the same treatment for <tt class="literal">logon</tt> +<tt class="literal">home</tt> because it is also used to specify the home +directory. In this case, we would change the symbolic links in each +user's <em class="filename">.win_profile</em> directory +to point to a common mandatory profile directory containing the +mandatory profiles for each of Windows 95/98/Me. Again, check the +ownership and permissions on the files in the directory, and modify +them if necessary to make sure a user can't modify +any files by logging into her Unix account on the Samba host system.</p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-5.6"/> + +<h3 class="head2">Logon Script and Roaming-Profile Options</h3> + +<p><a href="ch04.html#samba2-CHP-4-TABLE-1">Table 4-1</a> summarizes the options commonly used in +association with Windows NT domain <a name="INDEX-150"/><a name="INDEX-151"/>logon +scripts and roaming profiles.</p> + +<a name="samba2-CHP-4-TABLE-1"/><h4 class="head4">Table 4-1. Logon-script options</h4><table border="1"> + + + + + + +<tr> +<th> +<p>Option</p> +</th> +<th> +<p>Parameters</p> +</th> +<th> +<p>Function</p> +</th> +<th> +<p>Default</p> +</th> +<th> +<p>Scope</p> +</th> +</tr> + + +<tr> +<td> +<p><tt class="literal">logon</tt> <tt class="literal">script</tt></p> +</td> +<td> +<p>string (MS-DOS path)</p> +</td> +<td> +<p>Name of logon script batch file</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">logon</tt> <tt class="literal">path</tt></p> +</td> +<td> +<p>string (UNC server and share name)</p> +</td> +<td> +<p>Location of roaming profile</p> +</td> +<td> +<p><tt class="literal">\\%N\%U\profile</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">logon</tt> <tt class="literal">drive</tt></p> +</td> +<td> +<p>string (drive letter)</p> +</td> +<td> +<p>Specifies the logon drive for a home directory</p> +</td> +<td> +<p><tt class="literal">Z</tt>:</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">logon</tt> <tt class="literal">home</tt></p> +</td> +<td> +<p>string (UNC server and share name)</p> +</td> +<td> +<p>Specifies a location for home directories for clients logging on to +the domain</p> +</td> +<td> +<p><tt class="literal">\\%N\%U</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> + +</table> + + +<div class="sect3"><a name="samba2-CHP-4-SECT-5.6.1"/> + +<a name="INDEX-152"/><h3 class="head3">logon script</h3> + +<p>This option specifies a Windows batch file that will be executed on +the client after a user has logged on to the domain. Each logon +script should be stored in the root directory of the +<tt class="literal">[netlogon]</tt> share or a subdirectory. This option +frequently uses the <tt class="literal">%U</tt> or <tt class="literal">%m</tt> +variables (user or NetBIOS name) to point to an individual script. +For example:</p> + +<blockquote><pre class="code">[global] + logon script = %U.bat</pre></blockquote> + +<p>will execute a script based on the username. If the user who is +connecting is <tt class="literal">fred</tt> and the path of the +<tt class="literal">[netlogon]</tt> share maps to the directory +<em class="filename">/export/samba/netlogon</em>, the script should be +<em class="filename">/export/samba/netlogon/fred.bat</em>. Because these +scripts are downloaded to the client and executed on the Windows +side, they must have MS-DOS-style newline characters rather than Unix +newlines.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-4-SECT-5.6.2"/> + +<a name="INDEX-153"/><h3 class="head3">logon path</h3> + +<p>This option specifies the location where roaming profiles are kept. +When the user logs on, a roaming profile will be downloaded from the +server to the client and used as the local profile during the logon +session. When the user logs off, the contents of the local profile +will be uploaded back to the server until the next time the user +connects.</p> + +<p>It is often more secure to create a separate share exclusively for +storing user profiles:</p> + +<blockquote><pre class="code">[global] + logon path = \\hydra\profile\%U</pre></blockquote> + +<p>For more information on this option, see <a href="ch04.html#samba2-CHP-4-SECT-5">Section 4.5</a> earlier in this chapter.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-4-SECT-5.6.3"/> + +<a name="INDEX-154"/><h3 class="head3">logon drive</h3> + +<p>This option specifies the drive letter on a Windows NT/2000/XP client +to which the home directory specified with the +<tt class="literal">logon</tt> <tt class="literal">home</tt> option will be +mapped. Note that this option will work with Windows NT/2000/XP +clients only. For example:</p> + +<blockquote><pre class="code">[global] + logon drive = I:</pre></blockquote> + +<p>You should always use drive letters that will not conflict with fixed +drives on the client machine. The default is Z:, which is a good +choice because it is as far away from A:, C:, and D: as possible.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-4-SECT-5.6.4"/> + +<a name="INDEX-155"/><h3 class="head3">logon home</h3> + +<p>This option specifies the location of a user's home +directory for use by the MS-DOS <em class="emphasis">net</em> commands. +For example, to specify a home directory as a share on a Samba +server, use the following:</p> + +<blockquote><pre class="code">[global] + logon home = \\hydra\%U</pre></blockquote> + +<p>Note that this works nicely with the <tt class="literal">[homes]</tt> +service, although you can specify any directory you wish. Home +directories can be mapped with a logon script using the following +command:</p> + +<a name="INDEX-156"/><blockquote><pre class="code">C:\><tt class="userinput"><b>net use i: /home </b></tt></pre></blockquote> + + +</div> + + +</div> + + +</div> + + + +<div class="sect1"><a name="samba2-CHP-4-SECT-6"/> + +<h2 class="head1">System Policies</h2> + +<p>A <a name="INDEX-157"/>system policy can be used in a Windows +NT domain as a remote administration tool for implementing a similar +computing environment on all clients and limiting the abilities of +users to change configuration settings on their systems or allowing +them to run only a limited set of programs. One application of system +policies is to use them along with mandatory profiles to implement a +collection of computers for public use, such as in a library, school, +or Internet cafe.</p> + +<p>A system policy is a collection of registry settings that is stored +in a file on the PDC and is automatically downloaded to the clients +when users log on to the domain. The file containing the settings is +created on a Windows system using the <a name="INDEX-158"/>System Policy Editor. Because the format +of the registry is different between Windows 95/98/Me and Windows +NT/2000/XP, it is necessary to make sure that the file that is +created is in the proper format. This is a very simple matter because +when the System Policy Editor runs on Windows 95/98/Me, it will +create a file in the format for Windows 95/98/Me, and if it is run on +Windows NT/2000/XP, it will use the format needed by those versions. +After the policy file is created with the System Policy Editor, it is +stored on the primary domain controller and is automatically +downloaded by the clients during the logon process, and the policies +are applied to the client system.</p> + +<p>On Windows NT 4.0 Server, you can run the System Policy Editor by +logging in to the system as Administrator or another user in the +Administrators group, opening the Start menu, and selecting Programs, +then Administrative Tools, then System Policy Editor. On Windows 2000 +Advanced Server, open the Start menu and click Run . . . . In the +dialog box that comes up, type in +<tt class="literal">C:\winnt\poledit.exe</tt>, and click the OK button.</p> + +<p>If you are using a Windows version other than NT Server or Windows +2000 Advanced Server, you must install the System Policy Editor, and +getting a copy of it can be a little tricky. If you are running +Windows NT 4.0 Workstation or Windows 2000 Professional and have a +Windows NT 4.0 Server installation CD-ROM, you can run the file +<em class="filename">\Clients\Svrtools\Winnt\Setup.bat</em> from that CD +to install the Client-based Network Administration Tools, which +includes <em class="emphasis">poledit.exe</em>. Then open the Start menu, +click Run..., type <tt class="literal">C:\winnt\system32\poledit.exe</tt> +into the text area, and click the OK button.</p> + +<p>If you are using Windows 95/98, insert a Windows 95 or Windows 98 +distribution CD-ROM<a name="FNPTR-4"/><a href="#FOOTNOTE-4">[4]</a> into your CD-ROM drive, +then open the Control Panel and double-click the Add/Remove Programs +button.</p> + +<p>Click the Windows Setup tab, and then click the Have Disk... +button. In the new dialog box that appears, click the Browse... +button, then select the CD-ROM drive from the Drives drop-down menu. +Then:</p> + +<ul><li> +<p>If you are using a Windows 95 installation CD-ROM, double-click the +admin, then apptools, then poledit folder icons.</p> +</li><li> +<p>If you are using a Windows 98 installation CD-ROM, double-click the +tools, then reskit, then netadmin, then poledit folder icons.</p> +</li></ul> +<p>You should see "<a name="INDEX-159"/>grouppol.inf" appear in +the File name: text area on the left of the dialog box. Click the OK +buttons in two dialog boxes, and you will be presented with a dialog +box in which you should select both the Group Policies and System +Policy Editor checkboxes. Then click the Install button. Close the +remaining dialog box, and you can now run the System Policy Editor by +opening the Start menu and selecting Programs, then Accessories, then +System Tools, then System Policy Editor. Or click the Run... item in +the Start Menu, and enter <tt class="literal">C:\Windows\Poledit</tt>.</p> + +<p>When the System Policy Editor starts up, select New Policy from the +File menu, and you will see a window similar to that in <a href="ch04.html#samba2-CHP-4-FIG-14">Figure 4-14</a>.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-14"/><img src="figs/sam2_0414.gif"/></div><h4 class="head4">Figure 4-14. The System Policy Editor window</h4> + +<p>The next step is to make a selection from the File menu to add +policies for users, groups, and computers. For each item you add, you +will be asked for the username, or name of the group or computer, and +a new icon will appear in the window. Double-clicking one of the +icons will bring up the Properties dialog box, such as the one shown +in <a href="ch04.html#samba2-CHP-4-FIG-15">Figure 4-15</a>.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-15"/><img src="figs/sam2_0415.gif"/></div><h4 class="head4">Figure 4-15. The Properties dialog of System Policy Editor</h4> + +<p>The upper window in the dialog shows the registry settings that can +be modified as part of the system policy, and the lower window shows +descriptive information or more settings pertaining to the one +selected in the upper window. Notice in the figure that there are +three checkboxes and that they are all in different states:</p> + +<dl> +<dt><b>Checked</b></dt> +<dd> +<p>Meaning that the registry setting is enabled in the policy</p> +</dd> + + + +<dt><b>White (unchecked)</b></dt> +<dd> +<p>Which clears the registry setting</p> +</dd> + + + +<dt><b>Gray</b></dt> +<dd> +<p>Which causes the registry setting on the client to be unmodified</p> +</dd> + +</dl> + +<p>Basically, if all the items are left gray (the default), the system +policy will have no effect. The registry of the logged-on client will +not be modified. However, if any of the items are either checked or +unchecked (white), the registry on the client will be modified to +enable the setting or clear it.</p> +<a name="samba2-CHP-4-NOTE-117"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p>In this section, we are giving you enough information on using the +System Policy Editor to get you started—or, should we say, +enough rope with which to hang yourself. Remember that a system +policy, once put into action, will be modifying the registries of all +clients who log on to the domain. The usual warnings about editing a +Windows registry apply here with even greater importance. Consider +how difficult (or even impossible) it will be for you to restore the +registries on all those clients if anything happens to go wrong. +<em class="emphasis">As with roaming profiles, casual or careless implementation +of system policies can easily lead to domain-wide +disaster</em>.</p> + +<p>Creating a good system policy file is a complex topic, which we +cannot cover in detail here. It would take a whole book, and yes, +there happens to be an O'Reilly book on the subject, +<em class="citetitle">Windows System Policy Editor</em>. Another +definitive source of documentation on Windows NT system policies and +the System Policy Editor is the Microsoft white paper +<em class="citetitle">Implementing Policies and Profiles for Windows NT +4.0</em>, which can be found at <a href="http://www.microsoft.com/ntserver/techresources/management/prof_policies.asp">http://www.microsoft.com/ntserver/techresources/management/prof_policies.asp</a>.</p> +</blockquote> + +<p>Once you have created a policy, click the OK button and use the Save +As... item from the File menu to save it. Use the filename +<em class="filename">config.pol</em><a name="INDEX-160"/> for a Windows 95/98 system policy and +<em class="filename">ntconfig.pol</em><a name="INDEX-161"/> for a policy that will be used on Windows +NT/2000/XP clients. Finally, copy the <em class="filename">.pol</em> file +to the directory used for the <tt class="literal">[netlogon]</tt> share on +the Samba PDC. The <em class="filename">config.pol</em> and +<em class="filename">ntconfig.pol</em> files must go in this +directory—unlike roaming profiles and logon scripts, there is +no way to specify the location of the system policy files in +<em class="filename">smb.conf</em>. If you want to have different system +policies for different users or computers, you must perform that part +of the configuration within the System Policy Editor.</p> + +<a name="samba2-CHP-4-NOTE-118"/><blockquote class="note"><h4 class="objtitle">TIP</h4> +<p>If you have, or will have, any <a name="INDEX-162"/><a name="INDEX-163"/>Windows Me clients on your network, +be careful. Microsoft has stated that Windows Me does not support +system policies. The odd thing about this is that it will download +the policy from a <em class="filename">config.pol</em> file on the PDC, +but there is no guarantee that the results will be what was intended. +Check the effect of your system policy carefully on your Windows Me +clients to make sure it is working how you want.</p> +</blockquote> + +<p>When a user logs on to the domain, her Windows client will download +the <em class="filename">.pol</em> file from the server, and the settings +in it (that is, the items either checked or cleared in the System +Policy Editor) will override the client's settings.</p> + +<p>If things "should work" but +don't, try shutting down the Windows client and +restarting, rather than just logging off and on again. Windows +sometimes will hold the <tt class="literal">[netlogon]</tt> share open +across logon sessions, and this can prevent the client from getting +the updated <em class="filename">.pol</em> file from the server. +<a name="INDEX-164"/> +<a name="INDEX-165"/></p> + + +</div> + + + +<div class="sect1"><a name="samba2-CHP-4-SECT-7"/> + +<h2 class="head1">Samba as a Domain Member Server</h2> + +<p><a name="INDEX-166"/>Up to now, +we've focused on configuring and using Samba as the +primary domain controller. If you already have a domain controller on +your network, either a Windows NT/2000 Server system or a Samba PDC, +you can add a Samba server to the domain as a domain member server. +This involves setting up the Samba server to have a computer account +with the primary domain controller, in a similar way that Windows +NT/2000/XP clients can have computer accounts on a Samba PDC. When a +client accesses shares on the Samba domain member server, Samba will +pass off the authentication to the domain controller rather than +performing the task on the local system. If the PDC is a Windows +server, any number of Windows BDCs might exist that can handle the +authentication instead of the PDC.</p> + +<p>The first step is to add the Samba server to the domain by creating a +computer account for it on the primary domain controller. You can do +this using the <em class="emphasis">smbpasswd</em> command, as follows:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>smbpasswd -j <em class="replaceable">DOMAIN</em> -r <em class="replaceable">PDCNAME</em> -U<em class="replaceable">admin_acct</em>%<em class="replaceable">password</em></b></tt></pre></blockquote> + +<p>In this command, <em class="replaceable">DOMAIN</em> is replaced by the +name of the domain the Samba host is joining, +<em class="replaceable">PDCNAME</em> is replaced by the computer name +of the primary domain controller, +<em class="replaceable">admin_acct</em> is replaced by the username of +an administrative account on the domain controller (either +Administrator—or another user in the Administrators +group—on Windows NT/2000, and root on Samba), and +<em class="replaceable">password</em> is replaced with the password of +that user. To give a more concrete example, on our domain that has a +Windows NT 4 Server primary domain controller or a Windows 2000 +Active Directory domain controller named <tt class="literal">SINAGUA</tt>, +the command would be:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>smbpasswd -j METRAN -r SINAGUA -UAdministrator%hup8ter</b></tt></pre></blockquote> + +<p>and if the PDC is a Samba system, we would use the command:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>smbpasswd -j METRAN -r toltec -Uroot%jwun83jb</b></tt></pre></blockquote> + +<p>where <tt class="literal">jwun83jb</tt> is the password for the root user +that is contained in the<em class="filename"> smbpasswd</em> file, as we +explained earlier in this chapter.</p> + +<p>If you did it right, <em class="emphasis">smbpasswd</em> will respond with +a message saying the domain has been joined. The security +identifier<a name="FNPTR-5"/><a href="#FOOTNOTE-5">[5]</a> returned to Samba from the PDC is kept in +the file <em class="filename">/usr/local/samba/private/secrets.tdb</em>. +The information in +<em class="filename">secrets.tdb</em><a name="INDEX-167"/> is security-sensitive, so make sure to +protect <em class="filename">secrets.tdb</em> in the same way you would +treat Samba's password file.</p> + +<p>The next step is to modify the +<em class="filename">smb.conf</em><a name="INDEX-168"/> file. Assuming you are starting with a +valid <em class="filename">smb.conf</em> file that correctly configures +Samba to function in a workgroup, such as the one we used in <a href="ch02.html">Chapter 2</a>, it is simply a matter of adding the following +three lines to the <tt class="literal">[global]</tt> section:</p> + +<blockquote><pre class="code">workgroup = METRAN +security = domain +password server = *</pre></blockquote> + +<p>The first line establishes the name of the domain (even though it +says "workgroup"). Instead of +METRAN, use the name of the domain you are joining. Setting security +to "domain" causes Samba to hand +off authentication to a domain controller, and the +<tt class="literal">password</tt> <tt class="literal">server</tt> +<tt class="literal">=</tt> <tt class="literal">*</tt> line tells Samba to find +the domain controller for authentication (which could be the primary +domain controller or a backup domain controller) by querying the WINS +server or using broadcast packets if a WINS server is not available.</p> + +<p>At this point, it would be prudent to run +<em class="emphasis">testparm</em> to check that your +<em class="filename">smb.conf</em> is free of errors. Then restart the +Samba daemons.</p> + +<p>If the PDC is a Windows NT system, you can use Server Manager to +check that the Samba server has been added successfully. Open the +Start menu, then select Programs, then Administrative Tools (Common), +and then Server Manager. Server Manager starts up with a window that +looks like <a href="ch04.html#samba2-CHP-4-FIG-16">Figure 4-16</a>.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-16"/><img src="figs/sam2_0416.gif"/></div><h4 class="head4">Figure 4-16. The Windows NT Server Manager window</h4> + +<p>As you can see, we've added both +<tt class="literal">toltec</tt> and <tt class="literal">mixtec</tt> to a domain +for which the Windows NT 4.0 Server system, +<tt class="literal">sinagua</tt>, is the primary domain controller.</p> + +<p>You can check your setup on Windows 2000 Advanced Server by opening +the Start menu and selecting Programs, then Administrative Tools, +then Active Directory Users and Computers. The window that opens up +will look like <a href="ch04.html#samba2-CHP-4-FIG-17">Figure 4-17</a>.</p> + +<div class="figure"><a name="samba2-CHP-4-FIG-17"/><img src="figs/sam2_0417.gif"/></div><h4 class="head4">Figure 4-17. The Windows 2000 Active Directory Users and Computers window</h4> + +<p>Click Computers in the left side of the window with the Tree tab. You +should see your Samba system listed in the right pane of the window. +<a name="INDEX-169"/></p> + + +</div> + + + +<div class="sect1"><a name="samba2-CHP-4-SECT-8"/> + +<h2 class="head1">Windows NT Domain Options</h2> + +<p><a href="ch04.html#samba2-CHP-4-TABLE-2">Table 4-2</a> shows the options that are commonly used +in association with Samba on a Windows NT domain.</p> + +<a name="samba2-CHP-4-TABLE-2"/><h4 class="head4">Table 4-2. Windows NT domain options</h4><table border="1"> + + + + + + +<tr> +<th> +<p>Option</p> +</th> +<th> +<p>Parameters</p> +</th> +<th> +<p>Function</p> +</th> +<th> +<p>Default</p> +</th> +<th> +<p>Scope</p> +</th> +</tr> + + +<tr> +<td> +<p><tt class="literal">domain logons</tt></p> +</td> +<td> +<p>boolean</p> +</td> +<td> +<p>Indicates whether Windows domain logons are to be used</p> +</td> +<td> +<p><tt class="literal">No</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">domain master</tt></p> +</td> +<td> +<p>boolean</p> +</td> +<td> +<p>For telling Samba to take the role of domain master browser</p> +</td> +<td> +<p>Auto</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">add user script</tt></p> +</td> +<td> +<p>string (command)</p> +</td> +<td> +<p>Script to run to add a user or computer account</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">delete user</tt> <tt class="literal">script</tt></p> +</td> +<td> +<p>string (command)</p> +</td> +<td> +<p>Script to run to delete a user or computer account</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">domain admin group</tt></p> +</td> +<td> +<p>string (list of users)</p> +</td> +<td> +<p>Users that are in the Domain Admins group</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">domain guest group</tt></p> +</td> +<td> +<p>string (list of users)</p> +</td> +<td> +<p>Users that are in the Domain Guests group</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">password server</tt></p> +</td> +<td> +<p>string (list of computers)</p> +</td> +<td> +<p>List of domain controllers used for authentication when Samba is +running as a domain member server</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">machine password timeout</tt></p> +</td> +<td> +<p>numeric (seconds)</p> +</td> +<td> +<p>Sets the renewal interval for NT domain machine passwords</p> +</td> +<td> +<p><tt class="literal">604,800</tt> (1 week )</p> +</td> +<td> +<p>Global</p> +</td> +</tr> + +</table> + +<p>Here are detailed explanations of each <a name="INDEX-170"/>Windows NT domain option listed +in <a href="ch04.html#samba2-CHP-4-TABLE-2">Table 4-2</a>.</p> + + +<div class="sect2"><a name="samba2-CHP-4-SECT-8.1"/> + +<a name="INDEX-171"/><h3 class="head2">domain logons</h3> + +<p>This option configures Samba to accept domain logons as a primary +domain controller. When a client successfully logs on to the domain, +Samba will return a special token to the client that allows the +client to access domain shares without consulting the PDC again for +authentication. Note that the Samba machine must employ user-level +security (<tt class="literal">security</tt> <tt class="literal">=</tt> +<tt class="literal">user</tt>) and must be the PDC for this option to +function. In addition, Windows machines will expect a +<tt class="literal">[netlogon]</tt> share to exist on the Samba server.</p> + + +<div class="sect3"><a name="samba2-CHP-4-SECT-8.1.1"/> + +<a name="INDEX-172"/><h3 class="head3">domain master</h3> + +<p>In a Windows network, a local master browser handles browsing within +a subnet. A Windows domain can be made up of a number of subnets, +each of which has its own local master browser. The primary domain +controller serves the function of domain master browser, collecting +the browse lists from the local master browser of each subnet. Each +local master browser queries the domain master browser and adds the +information about other subnets to their own browse lists. When Samba +is configured as a primary domain controller, it automatically sets +<tt class="literal">domain</tt> <tt class="literal">master</tt> +<tt class="literal">=</tt> <tt class="literal">yes</tt>, making itself the domain +master browser.</p> + +<p>Because Windows NT PDCs always claim the role of domain master +browser, Samba should never be allowed to be domain master if there +is a Windows PDC in the domain.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-4-SECT-8.1.2"/> + +<a name="INDEX-173"/><h3 class="head3">add user script</h3> + +<p>There are two ways in which <tt class="literal">add</tt> +<tt class="literal">user</tt> <tt class="literal">script</tt> can be used. When +the Samba server is set up as a primary domain controller, it can be +assigned to a command that will run on the Samba server to add a +Windows NT/2000/XP computer account to Samba's +password database. When the user on the Windows system changes the +computer's settings to join a domain, he is asked +for the username and password of a user who has administrative rights +on the domain controller. Samba authenticates this user and then runs +the <tt class="literal">add</tt> <tt class="literal">user</tt> +<tt class="literal">script</tt> with root permissions.</p> + +<p>When Samba is configured as a domain member server, the +<tt class="literal">add</tt> <tt class="literal">user</tt> +<tt class="literal">script</tt> can be assigned to a command to add a user +to the system. This allows Windows clients to add users that can +access shares on the Samba system without requiring an administrator +to create the account manually on the Samba host.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-4-SECT-8.1.3"/> + +<a name="INDEX-174"/><h3 class="head3">delete user script</h3> + +<p>There are times when users are automatically deleted from the domain, +and the <tt class="literal">delete</tt> <tt class="literal">user</tt> +<tt class="literal">script</tt> can be assigned to a command that removes a +user from the Samba host as a Windows server would do. However, you +might not want this to happen, because the Unix user might need the +account for reasons other than use with Samba. Therefore, we +recommend that you be very careful about using this option.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-4-SECT-8.1.4"/> + +<a name="INDEX-175"/><h3 class="head3">domain admin group</h3> + +<p>In a domain of Windows systems, it is possible for a server to get a +list of the members of the Domain Admins group from a domain +controller. Samba 2.2 does not have the ability to handle this, and +the <tt class="literal">domain</tt> <tt class="literal">admin</tt> +<tt class="literal">group</tt> parameter exists as a manual means of +informing Samba who is in the group. The list should contain root +(necessary for adding computer accounts) and any users on Windows +NT/2000/XP clients in the domain who are in the Domain Admins group. +These users must be recognized by the primary controller in order for +them to perform some administrative duties such as adding users to +the domain.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-4-SECT-8.1.5"/> + +<a name="INDEX-176"/><h3 class="head3">password server</h3> + +<p>In a Windows domain in which the domain controllers are a Windows +primary domain controller, along with any number of Windows backup +domain controllers, clients and domain member servers authenticate +users by querying either the PDC or any of the BDCs. When Samba is +configured as a domain member server, the <tt class="literal">password</tt> +<tt class="literal">server</tt> parameter allows some control over how +Samba finds a domain controller. Earlier versions of Samba could not +use the same method that Windows systems use, and it was necessary to +specify a list of systems to try. When you set +<tt class="literal">password</tt> <tt class="literal">server</tt> +<tt class="literal">=</tt> <tt class="literal">*</tt>, Samba 2.2 is able to find +the domain controller in the same manner that Windows does, which +helps to spread the requests over several backup domain controllers, +minimizing the possibility of them becoming overloaded with +authentication requests. We recommend that you use this method.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-4-SECT-8.1.6"/> + +<a name="INDEX-177"/><h3 class="head3">machine password timeout</h3> + +<p>The <tt class="literal">machine</tt> <tt class="literal">password</tt> +<tt class="literal">timeout</tt> global option sets a retention period for +Windows NT domain machine passwords. The default is currently set to +the same time period that Windows NT 4.0 uses: 604,800 seconds (one +week). Samba will periodically attempt to change the +<em class="firstterm">machine account password</em>, which is a password +used specifically by another server to report changes to it. This +option specifies the number of seconds that Samba should wait before +attempting to change that password. The timeout period can be changed +to a single day by specifying the following:</p> + +<blockquote><pre class="code">[global] + machine password timeout = 86400</pre></blockquote> + +<a name="samba2-CHP-4-NOTE-119"/><blockquote class="note"><h4 class="objtitle">TIP</h4> +<p>If you would like more information on how Windows NT uses domain +usernames and groups, we recommend Eric <a name="INDEX-178"/>Pearce's +<em class="citetitle">Windows NT in a Nutshell</em>, published by +O'Reilly. <a name="INDEX-179"/></p> +</blockquote> + + +</div> + + +</div> + + +</div> + +<hr/><h4 class="head4">Footnotes</h4><blockquote><a name="FOOTNOTE-1"/> <p><a href="#FNPTR-1">[1]</a> When we include +Windows XP in discussions of Windows NT domains in this book, we are +referring to Windows XP Professional and not to the Home edition. The +reason for this is explained in the section on Windows XP later in +this chapter.</p> <a name="FOOTNOTE-2"/> <p><a href="#FNPTR-2">[2]</a> The entry in +<em class="filename">/etc/passwd</em> might not be required in future +Samba versions.</p> <a name="FOOTNOTE-3"/> <p><a href="#FNPTR-3">[3]</a> If you want to follow our example in this +section, and your network doesn't have any Windows +systems offering shares, see <a href="ch05.html">Chapter 5</a> for +directions on how to create one. Make sure you understand how to set +up shares before continuing with the directions presented +here!</p> <a name="FOOTNOTE-4"/> <p><a href="#FNPTR-4">[4]</a> The version of the System Policy +Editor distributed with Windows 98 is an update of the version +shipped with Windows 95. Use the version from the Windows 98 +distribution if you can.</p> <a name="FOOTNOTE-5"/> <p><a href="#FNPTR-5">[5]</a> This security identifier (SID) is part of +an access token that allows the PDC to identify and authenticate the +client.</p> </blockquote><hr/><h4 class="head4"><a href="toc.html">TOC</a></h4></body></html> |