Implementing System Policies
When you implement any network system, especially one with Microsoft Windows Workstations, it is very important to be able to control certain aspects of each connected Workstation and it's users. Which settings that can be changed, what programs that can be run, as well as how each workstation is presented to the user; all of these are important to maintain control of your network. This type of control is not only important from a security standpoint, but is almost equally important from a usability standpoint.
In order to provide this functionality for Windows based networks, Microsoft added the ability to adjust certain settings through System Policies. These policies allow you to enforce certain restrictions for network workstations by mandating certain Windows Registry settings that networked computers, users and groups must use. Let me re-iterate that - Policies are simply mandated registry settings for each machine and user on your network.
Microsoft Windows Policies were first implemented with Windows 95 and have changed little since their inception. These Policies were created with a tool called the System Policy Editor and are downloaded from a Domain Controller every time a user logged into a networked workstation. Since then, Microsoft incorporated Policies into it's Active Directory Service and renamed them to Group Policy Objects. When this happened the biggest change between Group Policy Objects and System Policies is that GPOs are no longer applied to the user's profile, but work alongside them. This means that GPOs do not "tatoo" the user's profile with registry settings. In other words, if you remove a policy with GPOs, the policy is no longer in effect, with System Policies, you must "undo" the policy to totally remove them from existing user's policies. However, with proper implementation of policies, the effects of "tatooing" a user's profile becomes minimal.
Currently Samba, the Free Software SMB Server, does not implement Active Directory functionality when using it as a Primary Domain Controller. If you deploy any Samba PDCs you will want to master System Policies using the SPE. So this article will cover the basics of Microsoft's older System Policy Editor, how to obtain it, use it and implement it's policies.
Obtaining Microsoft's SPE
In order to use System Policy Editor, you must first obtain it. Unfortunately, it is a proprietary tool so you must get it directly from the software maker, specifically Microsoft. The SPE is available with a few of their products; Windows NT Server, Windows 2000 Server, as well as their Office Resource Kits. However, the easiest place to obtain a the SPE is within Windows 2000 Service Pack 4. To install from Windows 2000 SP 4 follow these directions.
Getting SPE from Windows 2000 SP4
- Go to Microsoft's Windows 2000 home page at http://www.microsoft.com/windows2000/
- Download the Service Pack 4 Network Installation file.
- Once Downloaded, extract the files with the command "W2kSP4_EN.EXE /x"
- Launch the file "adminpack.msi" to install the server tools
- Run "poledit.exe"
Getting SPE from Windows NT SP6a
- Go to Microsoft's NT Server home page at http://www.microsoft.com/ntserver/
- Go to the Downloads Section and Download Service Pack 6a for x86 computers
- Extract the download with the command "NT4SP6ai.exe /x"
- Find the file "poleidt.exe" and copy it to the C:\Windows directory (or equivalent)
- Find files with the extension "*.adm" and copy them to the C:\Windows\inf directory (or equivalent)
- Run "poledit.exe"
NOTE: The version of the System Policy Editor included with NT4SP6a does not support Unicode, if you want to use any of the newer templates released by Microsoft (and others) you must either use the newer System Policy Editor from Windows 2000, or you can simply open up those templates with a text editor and re-save them without Unicode support.
It is very important that you install the System Policy Editor (SPE) on a machine based on the same Operating System as the machines you want to control. If you have Windows NT based Workstations, such as NT4, 2000 or XP, then run the SPE on a similar machine. If you mostly use Windows 9x machines, then install the SPE on a similar machine and use the "windows.adm" template instead of the "winnt.adm" template. Policies created on Windows 9x machines will not work with Windows NT based machines (and vice versa). The rest of this chapter is assuming that you are going to create and use Windows NT based policies.
Also, if you are going to adjust policies for specific groups, users and computers (instead of simply the Default Computer and Default User containers), you must run the policy editor on a machine connected to your Windows Domain.
Using the System Policy Editor
Basically what the System Policy Editor is used for is to create a single file that contains all of the policies for your network. This file is downloaded by your client computers every time a user logs into the server. This section will show you how to properly create the policy file and explain what to avoid when implementing System Policies.
When you first launch the System Policy Editor it will appear similar to the above picture. If you received an error upon starting, more than likely the SPE cannot find the default template files common.adm and winnt.adm. These template files are simple text files that that contain registry settings that allows you to control different aspects of computers or users. You can add as many template files as you need by going to Options -> Templates (see image below). You can get additional templates from Microsoft's website, or as I will cover in the next section, you can create your own custom templates that you can use.
Once you obtain all necessary templates, you can start creating your policies. By default the SPE will have a Default Computer object and a Default User object. I will talk more on these later, but first let's start adjusting policies to allow you to get the hang of it. We will start by simply opening the Default Computer object, it should look something like the image below (although the illustration does show a custom policy).
The little books you see on the screen are simply there for categorizing all of the policies into separate sections. When clicking on the plus sign next to the books, the subcategory will expand revealing the policies (or more subcategories). The actual policies are shown as little greyed out boxes. These boxes have 3 different states, greyed out, checked and cleared.
- The grayed out state simply means that the Policy will be overlooked. For example, if the computer does not have the registry setting enabled, it still will not be enabled, and vice-versa.
- The checked state means that the policy will be in effect on the computer.
- While the cleared state means that the registry setting will be cleared (if in fact it was enabled in the first place).
It might sound a little odd that there are 3 states for the policies, but once you throw in different groups you will quickly see why there are 3 states. A brief example of using a cleared state is to enable the policy of "Disable registry editing tools" to the Default User Container, but than clearing that policy for the Domain Administrators container, thus allowing anyone in the Domain Admin group access to registry editing tools, while other users that are not a Domain Admin will not be able to launch any registry editor.
Adding Computers, Groups & Users
When first creating a new policy file, you are able to adjust the "Default Computer" and the "Default User" containers. Any policy that you implement in these containers will be applied to every computer and every user on your network. For finer control of your network resources you are able to add additional containers to the policy file, such as specific computers, groups or users.
In my experience you will rarely want to add additional computers or users to your policy file, as there is usually a better way to implement policies through Groups. Illustration shows you an example of one of the networks that I implemented for a school. As you can see, I went with adding various groups to control the entire network population. This method seems to work very well. Not only is it easier to maintain and easier when adding new users, but it also reduces the size of the policy file. Keeping the policy file small should be a somewhat high priority because this file will be downloaded by the client every time a user logs into the computer. When you start adding specific computers or users to your policy file, the policy file will grow substantially resulting in every user downloading policies that they do not even use.
When implementing a group base policy template it is best to add groups that are a least common denominator, in that a user is only a member of 1 group within your policy file. This is sometimes easier said than done, but with proper preparation and research it can be done. However, if you inherit a network that is sub-optimal, there is a tool within the System Policy Editor called Group Priority that will help you maintain your sanity.
In these instances, what usually happens is that a policy is applied to one group and is not cleared in another group. For example, say you have 2 groups, one is Teachers and the other is Students. For some reason a share was implemented that only the group Students can access. So an unknowing administrator adds all the teachers to the student group. If the policy files are not setup correctly anyone in the Teachers group could inherit all of the policies of the student group.
To combat the problem of having the wrong policies applied to your users it is very important to "clear" out the unwanted policies in the user's default group. For instance if you want the Student groups to not be able to map a network drive, but allow the Teachers group to, make sure you implement that policy in the Student container and clear that policy in the Teacher container. Furthermore you must also ensure that the Teacher container has a higher group priority than the Student container, otherwise what you just did will not make a difference since the Student container could overpower the Teacher container.
Now that you have the basics of creating System Policies down, you should be able to properly apply policies and restrictions to your network users. Once you create your Policy File, save it as "NTConig.POL" and copy it to the "NETLOGON" share of all of your Domain Controllers.
However, In order to create policies effectively I highly recommend you utilize a spreadsheet containing all of the policies. I have created one for all of the default templates which you can download from my custom policies main page. Just remember that any time you spend planning the policies could save you day or even weeks of work after-the fact, especially if you inadvertently create a policy that makes your entire network inoperable.