SysAdminMag.com
Windows Policies through Samba
Steve Mathes, Nancy Voorhis, and Joss Stubblefield
Samba is indispensable in a mixed-environment network. From merely sharing files to functioning as a Windows Domain Controller, it affords a network much of the power of a Windows server. It provides vital interoperability between Windows and Unix/Linux operating systems. Unfortunately, the current stable version of Samba (3.x) does not support Windows Active Directory, and thus fails to support the full set of XP Group Policies. Creating desktop policies for end users running Windows can be difficult or impossible for anyone needing control of newer features. Policies available from Samba must be created by -- and are limited by -- the Windows NT policy editor.
However, with a little work and a lot of caution, templates for the NT Policy Editor can be tweaked or created to gain control of the Windows registry for all versions of Windows (through XP).
Getting Started
The following raw materials are required:
1. A Samba installation configured as a Windows Domain Controller.
2. The Windows NT Policy Editor (poledit.exe) and a Windows 2000 workstation on which to run it. The Policy Editor is on the installation disks for Windows 2000 Server Edition. It can also be obtained as part of the Windows 2000 Resource Kit from Microsoft:
http://www.microsoft.com/downloads/details.aspx? \
FamilyID=f08d28f3-b835-4847-b810-b6539362473&DisplayLang=en
3. An up-to-date set of Group Policy templates, also
known as .adm files, from the most recent version of Windows XP that you
plan to run. These will be found on a recent install of the software. On
recent versions of Windows XP, they are located in the directory
\WINDOWS\inf\, or they can be obtained by downloading "Group Policy
.adm files" from Microsoft:
http://www.microsoft.com/downloads/details.aspx? \
FamilyID=92759d4b-7112-4b6c-ad4a-bbf3802a5c9b&DisplayLang=en
Additionally, custom templates can be found on the Web
that address some of the more common
configuration needs specific to Samba. The best example of this (and
strongly recommended) is a template by Mike
Petersen that can be found at:
http://www.pcc-services.com/custom_poledit.htmlConfiguration Running poledit.exe with the freshly downloaded and non-customized .adm files provides the user with configuration options that are only appropriate to Windows NT. Still, these options provide a little bit of control. In any case, it is a good idea to run the software before editing any of the .adm files. To begin, place all the .adm files in a directory where they will be easy to find. Then, run poledit.exe. The first time poledit is run, it will attempt to load template files from %system32%\WINNT\INF. The files it expects may not be present depending on the workstation's version of Windows. If the policy editor doesn't find the files, a warning message will pop up that complains that the program is "Unable to open template file WINNT\INF\COMMON.adm: The system cannot find the file specified." This is okay, so click OK. A list of files will appear. Click CANCEL. You will then be faced with the Custom Policy Editor window in an extremely unresponsive color of gray. Go to the menu called Options and select Policy Template. Use this to load all of the .adm files. Once you have finished adding files and clicked OK, things will seem to stall. It takes many minutes for these files to load, especially system.adm. When this is finished, you will be back to the gray screen. Go to File and select New Policy. The background of the window will turn white, and you will see two icons, one for Default Computer and another for User. Those accustomed to the Windows Group Policy Editor (gpedit.msc) will see a most familiar user interface. The Group Policy Editor creates a configuration file that is not readable by Samba but still uses the same .adm templates. This coincidence allows the use of poledit.exe to control a greater number of settings on more current versions of Windows. Configuration The NT Policy Editor changes the registry and, therefore, controls three possible settings for each configuration choice. One setting enables the value for a key, another leaves it unchanged, and a third disables or changes the value. It is important to remember that registry settings persist unless actively changed. (This persistence can be very problematic, which is why Microsoft changed the mechanism in the Group Policy Editor.) Without the help of customized .adm files, the poledit.exe program fails to display any settings for newer versions of Windows. These templates are Unicode text files and can be viewed and edited in any Unicode-capable text editor, including Windows Notepad. These are Windows configuration files, presumably expecting things like Windows line-endings. It is recommended that they be modified with a Windows text editor. The current set of these files at the time of this writing included at least the following:
system.adm - system settings (the interesting stuff). conf.adm - NetMeeting settings. inetres.adm - Internet Explorer settings. wmplayer.adm Windows Media Player settings. wuau.adm - Windows Update settings.With the poledit.exe program safely off, open one of the .adm configuration files in Notepad. Shown below are the first few lines from a recent version of system.adm from Windows XP:
#if version <= 2
CLASS USER
CATEGORY !!GPOnly
POLICY !!GPOnlyPolicy
KEYNAME "Software\Policies"
The condition on the first line of this file
establishes this as a series of values for earlier Windows versions. These
values will appear in poledit.exe. However, any conditionals defining
values greater than 2 will not. Getting them to appear should merely
require changing the number. There will be a single line where "#if version <= 3" needs to be changed
to "#if version <= 2". This will
make an entire section of choices appear in poledit.exe.
There is just one problem. Some keywords used by the
newer gpedit.msc are not recognized by poledit.exe. If some of the wrong
conditionals are changed, the .adm file will refuse to load. Fortunately,
an exhaustive list of these keywords is unnecessary, as they are already
well marked in the .adm file.
Keywords that are unrecognized by poledit.exe are not
scattered haphazardly throughout sections of already-defined conditionals.
Instead, each instance of an "illegal" keyword is given its own
block. Furthermore, all of these keywords in the templates provided by
Microsoft are marked as requiring a Windows version greater than or equal
to 4, whereas any that can be changed are marked as less than or equal to 2
or 3.
Here is an example:
#if version >= 4
EXPLAIN !!.administrativeServices_Help
#endif
The keyword "EXPLAIN" is set apart quite
clearly, and if the version number were modified, trying to load the .adm
file would cause an exception in poledit.exe. Thus, at least with the
system.adm available at the time of this writing, it is safe to say that
the line designating "#if version <= 3" should be changed to
"#if version <= 2".
Modify the system.adm file appropriately as described
above and save it under a new name, such as myCustom.adm. Place the modified .adm file into the directory with all
the others. Run poledit.exe and add the new file to the list by selecting the Options menu.
Now, clicking on either the User or the Default
Computer icon will reveal a greatly expanded tree of Categories. Notice
that some of the Categories are labeled "Windows Unsupported
Template". If you expand one of the Category tabs, you will see the
name of your altered .adm file. All the Categories between this one and the
next "Unsupported" tab come from that .adm file. This can be
handy to know when it is necessary to see whether you got what you expected
from a specific .adm file. After surfing through the tabs, you will also
discover multiple tabs that seem to alter the same setting. This makes
sense, if your custom template duplicates settings from the stock
templates.
Custom Files and Keywords
Many registry settings appear after modifying the .adm
files provided by Microsoft. Sometimes this is not enough. Suppose (for
example) you need to modify some setting in the registry that was added by
third-party software.
The format for creating a custom .adm file from
scratch can be dangerously simple. Note that a poorly formed .adm file
could result in a policy that corrupts a user's profile or even
cripples a workstation. Creating a custom .adm
file that alters the registry by creating a new key or by haphazardly altering a key without
the benefit of examples, experience, and
knowledge can produce very unfortunate consequences.
With caution, however, a great deal of control can be achieved.
Below is an example of a complete and relatively safe
custom file designed to set a single key in the registry, based on the
commonplace need to set a default path for an application:
CLASS USER
CATEGORY "Custom Settings"
KEYNAME "SOFTWARE\Autodesk\AutoCAD LT\R9\ACLT-201:409"
POLICY "Set LocalRootFolder path"
PART "Path to LocalRootFolder" EDITTEXT
DEFAULT "M:\.tmp\"
VALUENAME "LocalRootFolder"
END PART
END POLICY
END CATEGORY ;Custom Settings
The syntax is relatively simple to decipher. The
CATEGORY keyword refers to what will appear as a tab in the policy Editor.
The registry key fated to be altered is:
SOFTWARE\Autodesk\AutoCAD LT\R9\ACLT-201:409If this key does not already exist, the policy editor will create it. This key has a string value named "LocalRootFolder" that can be accessed through poledit.exe after clicking on the "Set LocalRootFolder path" tab. It should be noted that all of the keywords in the above example are coherent with poledit.exe. Also note that this policy would have no effect if the AutoCAD software in the example contained no instructions for looking at this key. Finally, note that for purposes of organization, many different custom .adm files could be created, each named according to its function. If this method were chosen, however, merely removing the file and re-running poledit.exe would fail to unset the key. Again, all policies that have been set must be actively un-set; all values inserted in the registry must be actively removed or changed. The complete list of keywords and an exhaustive description of how to create custom templates is available from Microsoft:
http://www.microsoft.com/downloads/details.aspx? \
FamilyID=652e8fd2-8de0-473e-927d-572a64df844b&displaylang=en
Saving and Testing
After running poledit.exe and setting up your
policies, you will need to save your policy. You will be prompted for a
file name. Any policy file used by Samba must be named NTConfig.POL.
Case-sensitivity in this file name is important now that it will be used by
Samba.
Before going any further, it is important to have a
deployment plan. It is recommended that all workstations on which this
policy will be tested have backups or at least some plan in place for
recovering from corrupted registries.
It is important to manually delete any locally stored
profiles on workstations before testing new policies. New policies will not
always take effect otherwise. This is true even if the new policy contains
a setting to "not allow logins unless the profile is available from
the server" and "not use local copy of profile". You
could even set a key to keep from saving a profile locally. These are
available choices on the templates from Microsoft. If they worked as
advertised, they would force a clean profile from the server upon login.
This is true of any policies set with the Group Policy Editor.
Windows sometimes fails to delete the locally stored
copy of the profile even when everything is set up correctly. There is
another tool from Microsoft called the User Profile Hive Cleanup Service
that, when installed on each workstation, tries to ensure that old profiles
get deleted. It is not perfect, either, especially in mixed environments
with Samba, Windows 2000, and Windows XP. However, it is highly recommended
as much better than nothing. Without it, testing can become confusing as
older profiles can be inadvertently loaded from the local workstation. The
latest version of User Profile Hive Cleanup Service can be downloaded from
Microsoft at:
http://www.microsoft.com/downloads/details.aspx? \
familyid=1B286E6D-8912-4E18-B570-42470E2F3582&displaylang=en
Before you begin testing, manually delete any locally
stored user profiles on the Windows computers. They can be found and
removed under "My Computer, Properties, User Profiles".
NTConfig.POL is placed in the directory defined by the
"netlogon" share defined in your smb.conf file. Permissions
should look like this:
-rw-r--r-- 1 root root 24576 Jul 27 15:41 NTConfig.POL
Then next time anyone logs into the domain defined by
this Samba installation, these settings will take effect on their
workstation. We humbly recommend that the settings be tested on a quiet
day.
Steve Mathes, Nancy Voorhis, and Joss Stubblefield are experts in the integration of Linux and Windows. Steve has just retired as Director of Technology at The Derryfield School, where Joss Stubblefield has inherited his position. Nancy Voorhis has been a networking consultant for more than 10 years. They can be reached at: [email protected].
