Deploying Suse Linux Enterprise Server

Purchase "Deploying Suse Linux Enterprise Server"
at Lulu.com

Configuring the Samba Server

Additional Domain Controller Functions

When dealing with Windows Networking, a good understanding of what Domains are and what options you have when deploying servers in a Domain environment is necessary to ensure that you optimally configure your server(s) for your environment. This section provides basic information on Windows Domain networking that will help you fully configure Samba to be optimized for your network.

User Profiles

Microsoft Windows stores all of the User's Data into what are called "Profiles". With Windows XP (and 2000) these Profiles are located within the "Documents and Settings" folder of the system drive (other Windows versions place these in a different folder). These Profiles not only contain all of the Registry Settings for the User, but also contain their Documents, Favorites, Emails, etc. Over time these profiles can become quite large.

When you implement a Windows Network you are able to place these Profiles onto a network drive if you wish. This gives the advantage of having all user's profiles located at single network location reducing the overhead of backing them up. It also gives you the advantage of having each user's settings "follow" them to whichever computer they happen to login to on the network. When you implement profiles in this way on the network, they are referred to as either "Server Side Profiles" or "Roaming Profiles".

To implement "Roaming Profiles" with Samba, you simply need to create the Profiles share and set a few directives within the Samba configuration file. To create the Profiles Share, simply create a directory on the server to hold the profiles, such as "/srv/samba/profiles" (make sure all users who log into the Domain will be able to write to this directory). Then add a Samba share similar to the following into your smb.conf file.

[profiles]
        comment = Network Profiles Service
        path = /srv/samba/profiles
        read only = No
        store dos attributes = Yes
        create mask = 0600
        directory mask = 0700
        hide files = /desktop.ini/outlook*.lnk/*Briefcase*
        browseable = no

Then you add the following to the Global Section of the smb.conf file. Note that you can even separate out the profiles by different Windows versions if you wish by adding a "%a" at the end of the "logon path" directive ( logon path = \\%L\profiles\%U\%a ).

    logon path = \\%L\profiles\%U
    logon home = \\%L\%U\.9xprofile
    logon drive = P:

Now, if you wish to simply use Local Profiles (Profiles stored on the local machine), you simply set the "logon path" and "logon home" directives to nothing (null). Note that when using Local Profiles the "logon drive" directive will not automatically mount the User's Home folder to a drive letter (so you will probably want to do this with a logon script).

    logon path = 
    logon home =

Note: You can utilize a Network Wide "Default profile" for your network by adding a "Default User" directory to the "netlogon" share. This ensures that all of the User's will start from the same profile. This avoids having to deal with different Computer Vendor's shipping Default Profiles, which tend to be quite a bit larger than a normal "Default Profile".

System Policies

To control what your user's can and cannot do on your Windows Client Computers, Microsoft implemented what is called "System Polices" (later re-implemented as Group Policy Objects for their Active Directory). These Policies give you the ability to get a handle on your Windows Clients.

This section will cover how to utilize System Policies to attack different problems you may have with utilizing Microsoft Windows Clients. This is not meant to be a full tutorial on using the System Policy Editor, but is here to give you a good understanding of how to utilize good Policies to reduce your "Total Cost of Ownership" in respect of managing Windows Clients. For a full tutorial of using Microsoft's System Policy Editor, visit this page.

In order to fully manage your Windows Clients without resorting to implementing highly complex, unmanageable Policies, I am going to illustrate how you can easily implement an easy to understand, easy to implement "Fool-Proof" System Policy.

The first step in implementing a "Fool-Proof" System Policy is to understand what you want the System Policy to do. Normally, I usually attack Windows Clients from two separate issues. The first issue is to simply use the Policy to change the default behavior of the Windows clients. This allows you to redirect various folders and to adjust the software to make it easier for the user to utilize their computer.

The second issue to tackle using System Policies is to use them to prevent your users from accessing things that they should not access, such as registry editing tools, etc. This issue is where some stumbling blocks may occur. If you do not configure your policies correctly they can easily overlap each other and before you know it all of your users may become affected. To avoid this I will show you how to implement sensible policies based on different Windows Groups.

Note: This page assumes that you are utilizing the default Policy Templates included with the System Policy Editor, as well as my custom policy template file.

Changing Default Windows Behavior

Utilizing System Policies to change the default Microsoft Windows behavior can do wonders for your User's output and morale. For instance, using "Folder Redirection" you can reduce the amount of time a User spends waiting for the computer to login as well as reduce the amount of time it takes the user to find the files that they work on. You can also reduce the User's Frustration by changing the erratic behavior of how Microsoft Windows handles different situations.

Folder Redirection: Implementing Folder Redirection can greatly reduce your network bandwidth during logins. It can also move important files from the volatile User's Profile into something more permanent such as their home directory. To utilize folder redirection, ensure the directories you are redirecting to already exist (create them within the "/etc/skel/" folder prior to adding the users to your server), ensure that the user's home folder is mapped to a drive letter (in this case "P:\"), then set the following policies, notice that I give an example of what I usually set it to.

Custom Application Data Folder - P:\.winsettings\appdata
Custom Desktop Folder* - P:\WinDesktop
Custom My Music Folder - P:\Music
Custom My Pictures Folder - P:\Pictures
Custom My Documents Folder - P:\Documents
Custom Start Menu* - P:\.winsettings\startmenu
Custom Programs Folder* - P:\.winsettings\programs
Custom Templates - P:\.winsettings\templates
Do NOT Sync Redirected Folders - Ensure this is checked
Disable Offline Files - Ensure this is checked

For the folders above with an * ensure that you also set the "Windows NT Shell\Custom folders\Custom ..." Policies (from the default adm files) to the exact same settings. You may notice that there are other redirection options available, however, these may present problems and I don't recommend setting them.

Policies regarding Profiles - Along with utilizing Folder Redirection, there are other policies you can utilize to ensure that your User's Profiles remain somewhat small and manageable. The most important ones are listed below.

Default User Properties - Windows NT User Profiles - Exclude directories in roaming profiles - - Good defaults are: "Temporary Internet Files;Temp;Local Settings"
Default Computer Properties - Windows NT User Profiles - Delete Cached Copies of Roaming Profiles

There are other Policies that pertain to Profiles, including changing the default options in regards to Roaming Profiles, Limiting the Profile Size, etc. These may be useful in certain deployments.

Changing Other Default Options - Within my "custom.adm" policy template I include quite a few policies to change some of the Windows default options. These policies may be beneficial for your deployment and you should look at them to be implemented within the "Default Computer" or "Default User" Policy group (as these are applied to everyone who logs into your network).

Creating Lock-Down Policies

The other important function of Policies is to restrict your Users from doing something they should not be doing (such as editing the registry). This seems like it would be straightforward, but many administrators find stumbling blocks when these restrictive policies inadvertently get applied to some users.

To avoid these issues, the easiest way to implement these restrictive policies is to create various Windows Groups that have no other purpose on your network except to apply restrictive policies. For instance, you can create a "Normal Policy" group that has moderate restrictions applied, then create another Windows Group called "Restrictive Policy" that has further restrictions on it's users. The trick here is to add the User to only one of these Groups. This virtually eliminates the problems where a User is a member of multiple Groups that have different Policies applied.

Note: If you move a user from being a member of a "Restricted Policy" group to a member of a "Normal Policy" group, in order to remove the "tattooing" effects of the old policy from being applied, simply delete the User's Roaming Profile (or local profile) and have the User log back in. If you implement Folder Redirection correctly, deleting a User's profile should only have a minimal impact on the user.

Finishing Up the Policies

Once you create your Policy File, save it as "NTConfig.POL" and copy it to the "NETLOGON" share of all of your Domain Controllers. Whenever a User logs into a Windows Client it will check for this file and apply the policies to that User (and computer). Just remember that Microsoft Windows Vista clients will not apply any System Policies, so you will probably have to rely on local policies and/or login scripts if you utilize Windows Vista Clients.

Note: In order to create effective policies, I highly recommend that you document all of your policies by utilizing a spreadsheet. Any time you spend planning your policies can save you days or even weeks of work after-the fact, especially if you inadvertently create a policy that makes your entire network inoperable!

Logon Scripts

Another way of controlling clients is through the use of Logon Scripts. Whenever a user logs into a workstation connected to the Samba Domain, you can force the computer to run a script. This allows you to do various tasks such as syncing the time or mapping network drives to drive letters.

To force a script to execute when the user logs into the machine, simply add the following directive within the Global Section of the smb.conf file:

logon script = login.bat

Where "login.bat" is a DOS based text file which includes something similar to:

	net time \\Servername /set /yes
	net use L: \\Servername\Company /persistent:no
	net use O: \\Servername\Office /persistent:no

Most of the deployments I configure, I usually make use of the Kixtart scripting language to give some sort of reconfigurability to the Logon script without having to resort to create one for every user. For instance, I always create shares that are only accessed by members of certain groups, so I simply create an IF statement stating that if the user is in this group map a drive letter to this share. For instance, an example script I use is:

BREAK OFF
$ = SETTITLE("Domain Login")
BIG
COLOR G/N
?@DOMAIN
?
SMALL
COLOR W/N
?@TIME " - " @WKSTA " - " @USERID
?"Do not close this Window, it will automatically close"
?

        USE P: "\\Servername\" + @USERID

IF InGroup( "Domainname\Domain Admins", "Servername\Domain Admins" )
        SetTime "\\Servername"
ENDIF

IF InGroup( "Domainname\Company", "Servername\Company" )
        USE L: "\\Servername\Company"
ENDIF

IF InGroup( "Domainname\Office", "Servername\Office" )
        USE O: "\\Servername\Office"
ENDIF

IF InGroup( "Domainname\NetAdmins", "Servername\NetAdmins" )
        USE Z: "\\Servername\AdminUtils"
ENDIF

Then, I simply set "logon script = kix32 login.kix" within the smb.conf file and ensure that the kix32.exe file is located within the netlogon share. Also, to reduce network bandwidth I always copy the kix32.exe file into the PATH of the Windows Workstations as the Windows command interpreter will utilize the local copy of kix32.exe to interpret the script (as opposed to the one within the netlogon share).

Note: Utilizing Kixtart for your logon script will also open up quite a few possibilities, such as writing Registry Keys. This is especially useful for Windows Vista clients (which apparently do not support System Policies).