Section 5.6. Miscellaneous Server Preparation Tasks

5.6. Miscellaneous Server Preparation Tasks

My father would say, "Dinner is not over until the dishes have been done." The makings of a great network environment take a lot of effort and attention to detail. So far, you have completed most of the complex (and to many administrators, the interesting part of server configuration) steps, but remember to tie it all together. Here are a few more steps that must be completed so that your network runs like a well-rehearsed orchestra.

5.6.1. Configuring Directory Share Point Roots

In your smb.conf file, you have specified Windows shares. Each has a path parameter. Even though it is obvious to all, one of the common Samba networking problems is caused by forgetting to verify that every such share root directory actually exists and that it has the necessary permissions and ownership.

Here is an example, but remember to create the directory needed for every share:

root#  mkdir  -p  /data/{accounts,finsvcs,piops} root#  mkdir  -p  /apps root#  chown  -R  root:root /data root#  chown  -R  root:root /apps root#  chown  -R  bobj:Accounts /data/accounts root#  chown  -R  bobj:Finances /data/finsvcs root#  chown  -R  bobj:PIOps /data/pidata root#  chmod  -R  ug+rwxs,o-rwx /data root#  chmod  -R  ug+rwx,o+rx-w /apps 

5.6.2. Configuring Profile Directories

You made a conscious decision to do everything it would take to improve network client performance. One of your decisions was to implement folder redirection. This means that Windows user desktop profiles are now made up of two components: a dynamically loaded part and a set of file network folders.

For this arrangement to work, every user needs a directory structure for the network folder portion of his or her profile as shown here:

root#  mkdir -p /var/lib/samba/profdata root#  chown root:root /var/lib/samba/profdata root#  chmod 755 /var/lib/samba/profdata # Per user structure root#  cd /var/lib/samba/profdata root#  mkdir -p username root#  for i in InternetFiles Cookies History AppData \                       LocalSettings MyPictures MyDocuments Recent root#  do root#  mkdir username/$i root#  done root#  chown -R username:Domain\ Users username root#  chmod -R 750 username 

You have three options insofar as the dynamically loaded portion of the roaming profile is concerned:

• You may permit the user to obtain a default profile.

• You can create a mandatory profile.

• You can create a group profile (which is almost always a mandatory profile).

Mandatory profiles cannot be overwritten by a user. The change from a user profile to a mandatory profile is effected by renaming the NTUSER.DAT to NTUSER.MAN, that is, just by changing the filename extension.

The location of the profile that a user can obtain is set in the user's account in the LDAP passdb backend. You can manage this using the Idealx smbldap-tools or using the Windows NT4 Domain User Manager^[20].

^[20] <ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE>

It may not be obvious that you must ensure that the root directory for the user's profile exists and has the needed permissions. Use the following commands to create this directory:

root#  mkdir -p /var/lib/samba/profiles/username root#  chown username:Domain\ Users        /var/lib/samba/profiles/username root#  chmod 700 /var/lib/samba/profiles/username 

5.6.3. Preparation of Logon Scripts

The use of a logon script with Windows XP Professional is an option that every site should consider. Unless you have locked down the desktop so the user cannot change anything, there is risk that a vital network drive setting may be broken or that printer connections may be lost. Logon scripts can help to restore persistent network folder (drive) and printer connections in a predictable manner. One situation in which such breakage may occur in particular is when a mobile PC (notebook) user attaches to another company's network that forces environment changes that are alien to your network.

If you decide to use network logon scripts, by reference to the smb.conf files for the domain controllers, you see that the path to the share point for the NETLOGON share defined is /var/lib/samba/netlogon. The path defined for the logon script inside that share is scripts\logon.bat. This means that as a Windows NT/200x/XP client logs onto the network, it tries to obtain the file logon.bat from the fully qualified path /var/lib/samba/netlogon/scripts. This fully qualified path should therefore exist whether you install the logon.bat.

You can, of course, create the fully qualified path by executing:

root#  mkdir -p /var/lib/samba/netlogon/scripts 

You should research the options for logon script implementation by referring to TOSHARG2, Chapter 24, Section 24.4. A quick Web search will bring up a host of options. One of the most popular logon facilities in use today is called KiXtart^[21].

^[21] <http://www.kixtart.org>

5.6.4. Assigning User Rights and Privileges

The ability to perform tasks such as joining Windows clients to the domain can be assigned to normal user accounts. By default, only the domain administrator account (root on UNIX systems because it has UID=0) can add accounts. New to Samba 3.0.11 is the ability to grant this privilege in a very limited fashion to particular accounts.

By default, even Samba-3.0.11 does not grant any rights even to the Domain Admins group. Here we grant this group all privileges.

Samba limits privileges on a per-server basis. This is a deliberate limitation so that users who are granted rights can be restricted to particular machines. It is left to the network administrator to determine which rights should be provided and to whom.

STEPS FOR ASSIGNMENT OF USER RIGHTS AND PRIVILEGES

1.	Log onto the PDC as the root account.
2.	Execute the following command to grant the Domain Admins group all rights and privileges: root# net -S MASSIVE -U root%not24get rpc rights grant \ "MEGANET2\Domain Admins" SeMachineAccountPrivilege \ SePrintOperatorPrivilege SeAddUsersPrivilege \ SeDiskOperatorPrivilege SeRemoteShutdownPrivilege Successfully granted rights. Repeat this step on each domain controller, in each case substituting the name of the server (e.g., BLDG1, BLDG2) in place of the PDC called MASSIVE.
3.	In this step the privilege will be granted to Bob Jordan (bobj) to add Windows workstations to the domain. Execute the following only on the PDC. It is not necessary to do this on BDCs or on DMS machines because machine accounts are only ever added by the PDC: root# net -S MASSIVE -U root%not24get rpc rights grant \ "MEGANET2\bobj" SeMachineAccountPrivilege Successfully granted rights.
4.	Verify that privilege assignments have been correctly applied by executing: net rpc rights list accounts -Uroot%not24get MEGANET2\bobj SeMachineAccountPrivilege S-0-0 No privileges assigned BUILTIN\Print Operators No privileges assigned BUILTIN\Account Operators No privileges assigned BUILTIN\Backup Operators No privileges assigned BUILTIN\Server Operators No privileges assigned BUILTIN\Administrators No privileges assigned Everyone No privileges assigned MEGANET2\Domain Admins SeMachineAccountPrivilege SePrintOperatorPrivilege SeAddUsersPrivilege SeRemoteShutdownPrivilege SeDiskOperatorPrivilege