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 
            

http://www.microsoft.com/downloads/details.aspx? \ 
     FamilyID=92759d4b-7112-4b6c-ad4a-bbf3802a5c9b&DisplayLang=en 
    

http://www.pcc-services.com/custom_poledit.html 

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. 

#if version <= 2 

CLASS USER 

CATEGORY  !!GPOnly 

    POLICY !!GPOnlyPolicy 
    KEYNAME "Software\Policies"

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 
    

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 
    

SOFTWARE\Autodesk\AutoCAD LT\R9\ACLT-201:409 

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 
    

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 
    

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 
    

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: smathes@tiac.net.