I have struggled with two challenges since I began working with Windows NT. For years, I couldn't figure out how to push Registry security settings to users across a network or how to create user Registry entries for software on systems that the user already has a profile on. These tasks are challenging not because the Registry function is difficult, but because efficiently pushing Registry entries to all the users in a domain can be difficult. I know I'm not the only systems administrator who has struggled with these problems because audiences at my speaking engagements regularly ask me how to perform these tasks.
You can use tools such as regini or regsec from the Microsoft Windows NT Server 4.0 Resource Kit, Microsoft Windows NT Workstation 4.0 Resource Kit, and Microsoft Windows NT 3.51 Resource Kit to accomplish both tasks. However, the tools are command-line based, so they are complex and difficult to use.
System policies provide the easiest way to manage systems and users across your network. NT's System Policy Editor (SPE) makes enterprisewide Registry changes quick and efficient. Service Pack 2 (SP2) expands SPE's default options to include new entries, but despite its new entries, SPE can't solve the Registry security and software access problems. (For more information about SPE and NT system policies, see "Related Articles in Windows NT Magazine.")
Until recently, the only way I knew to expand SPE's capabilities was to edit the templates that create the interface, but this way can be confusing. You can create templates through a text editor such as Notepad or a sophisticated tool such as Policy Template Editor, but these tools cannot address the two challenges I described. Fortunately, I recently found a method for resolving my challenges: You can edit the policy file, ntconfig.pol, directly.
Ntconfig.pol
Ntconfig.pol is a Registry hive similar to the hives that create the keys Registry editors usually modify. You can load the ntconfig.pol hive into regedt32 and modify the policy file directly. Understand that this is an advanced policy function and that incorrect policy changes might severely damage your systems. Always back up the Registry before modifying hives, and test changes in a small, controlled environment before applying them to your network.
To load ntconfig.pol, open regedt32 and select HKEY_LOCAL_MACHINE. Select Load Hive from the Registry menu. Find ntconfig.pol in the NETLOGON share, and click Open. When you open ntconfig.pol, regedt32 asks you for a name for the hive. The name has no permanent effect on your system; it makes policy changes more convenient for you. You can enter any name you want. I call my ntconfig.pol hive Policy.
After you enter a name, the hive opens, as Screen 1 shows. Select Read Only Mode from regedt32's Options menu to protect the Registry until you're ready to make changes. Double-click the Policy key and examine the structure of the keys within it. Expand each key to see how the activated settings fit together. When you finish exploring, you're ready to solve your users' security and software access problems.
Challenge 1: Registry Security
When users have access to the Internet, one of an administrator's biggest challenges is regulating which programs users download and install on their systems. Some commercial software requires administrative rights for installation, but much of the freeware and shareware available on the Internet doesn't require special permissions to download.
To restrict users from installing software on one computer, you need to change permissions for the HKEY_LOCAL_MACHINE\SOFTWARE Registry key. (For a description of each permission option's function, see the sidebar "Security Permissions in the Registry.") Run regedt32, select the SOFTWARE key, select Permissions from the Security drop-down menu, and select the users you want to set permissions for. The SOFTWARE key's default settings include Full Control for CREATOR OWNER, SYSTEM, and the local Administrators group. These users can make changes freely; they can add and remove software, use applications that have entries in the SOFTWARE key, and modify permissions.
All other users are in the Everyone group. As Screen 2 shows, the default Special Access permissions for the Everyone group let users perform all Registry functions except creating a link to another key, changing the key's permissions (which the Write Discretionary Access ControlÂDACÂcheck box controls), and changing the key's ownership. To prevent users in the Everyone group from installing new software without preventing them from using the software that the SOFTWARE key lists, you need to remove their Set Value and Create Subkey permissions. Change the Everyone group's permissions from Special Access to Read. Then, users in the group will have only Query Value, Enumerate Subkeys, Notify, and Read Control permissions.
This Registry solution successfully prevents users from installing software on a system, but making this change on hundreds or thousands of computers is an administrative challenge. No System Policy Editor (SPE) function makes security changes, and you can't easily write a custom template to facilitate the change.
Adding security settings to a policy. Like SPE, ntconfig.pol adds entries to the Registry in such a way that every change you make adds to the current Registry entries. Making changes is like laying a transparency (the policy) on top of a sheet of paper (the existing Registry). Unchanged information shows through, and new settings replace only the settings that you modify. Ntconfig.pol's Users\.default key already contains a Software key. All you need to do to change the SOFTWARE key's permissions for users throughout your network is modify the Users\.default\Software key as you would modify an individual user's HKEY_LOCAL_MACHINE\SOFTWARE key.
In regedt32, open HKEY_LOCAL_MACHINE\Policy\Users\.default\Software. Select the Software key and click Security, Permissions. Choose the Everyone group, and set permissions for the group to Read. This prepares the policy file to send all the systems on your network the SOFTWARE key's permissions update (which will replace current security settings in the SOFTWARE key for the Everyone group) the next time users log on. This procedure will prevent all users except administrators from installing software that registers itself with NT.
Challenge 2: Software Access
Most new software places Registry entries in the HKEY_LOCAL_MACHINE hive. These entries control general access to the application's files, the location of the executable and auxiliary files, and the components that the software installs. Some software places Registry entries that control functions such as button bars, default data file locations, and other software settings in the HKEY_CURRENT_USER hive. Such software requires every authorized user's personal profile to contain the software's HKEY_CURRENT_USER settings. A user whose profile doesn't contain these settings can see the files in NT Explorer but can't run the software.
Changing the default profile won't help you solve this problem because programs use settings in the default profile only to create new profiles. A program that requires users to have its HKEY_CURRENT_USER Registry entries can't use the default profile's settings for users whose profiles don't contain the necessary entries. Therefore, if you place a program's settings in the default profile's ntuser.dat file, users you create profiles for in the future will be able to use the software, but the change won't affect users who already have profiles.
Adding software settings to a policy. You can change the policy file to push a program's HKEY_CURRENT_USER Registry entries to users who already have profiles. You must copy the Registry key that the software enters in HKEY_CURRENT_USER to the default profile's HKEY_LOCAL_MACHINE hive. Adding the software settings to the policy is more difficult than passing security settings to users across the network because regedt32 doesn't have a simple copy function. To copy a Registry key from one hive to another, you must copy the key to a disk, create an empty key in the target hive, and restore the file you saved on the disk to the new key. Be extremely careful when you use this technique to copy keys. When you replace one key with another, NT deletes all the original key's information. To avoid deleting Registry information, restore Registry data only onto empty keys.
Suppose I need to give everyone in my company access to a video-capture program from Hyperionics called HyperCam. When I install HyperCam, the installation process saves the software's settings in the HKEY_CURRENT_USER\Software\Hyperionics key on all my users' computers. Screen 3 shows this Registry key. To provide all my users access to HyperCam, I load ntconfig.pol into regedt32 and open the HKEY_LOCAL_MACHINE\Policy\Users\.default\Software key. I click Edit, Add to add a key with the name Hyperionics to the default user's Software key. Screen 4 shows the new key.
I open HKEY_CURRENT_USER\Software\Hyperionics and click Registry, Save Key to copy the data in the Hyperionics key to my hard disk. (Where you save the file doesn't matter as long as you remember where it is.) Next, I select the HKEY_LOCAL_MACHINE\Policy\Users\.default\Software key that I created and click Registry, Restore. A Restore Key dialog box appears; I use its Browse function to find the Hyperionics file on my hard disk. I select the file and confirm my choice, and regedt32 prompts me with a dialog box for an additional confirmation. Screen 5 shows this dialog box, which warns you that the data you are restoring will overwrite the values in the current key. I click OK to continue, and regedt32 transfers all the information from the HKEY_CURRENT_USER Hyperionics key to the default profile's new HKEY_LOCAL_MACHINE Hyperionics key. The system policy then gives every user access to HyperCam.
Another Ntconfig.pol Procedure
In addition, you can edit the policy file to create custom templates that include REG_MULTI_SZ entries. "Map Your Drives with Policies" in the March 1998 Windows NT Magazine Reader to Reader column shows how to write a policy that creates network drive connections. If you have several systems with the same configuration and directory structure, you might want to give them access to the same shares. You can't write a policy in SPE to make the shares available because NT stores your shares as MULTI_SZ Registry entries. To create a policy for your shares, you need to edit the ntconfig.pol file directly.
Because regedt32 doesn't have copy and paste functions, select the HKEY_ LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares key on a system with the correct shares and click Registry, Save Key to save the key to a disk. Load ntconfig.pol into regedt32, and add a LanmanServer key to the HKEY_LOCAL_MACHINE\Policy\Computers\.default\SYSTEM\CurrentControlSet\Services key. Create a Shares key in the new LanmanServer key. (Making this change in the .default location will add these shares to all your systems. If you want to add them to only a few systems, you can add the LanmanServer and Shares keys to named computers by replacing .default in the HKEY_LOCAL_MACHINE Registry key with each computer's name.)
After you create the LanmanServer and Shares keys, select the new Shares key and click Registry, Restore. Open the file you saved to disk. NT will add all the shares, which are MULTI_SZ Registry entries, to the default profile in the ntconfig.pol file. When the designated computers receive the policy, NT will overwrite the systems' current shares with the shares in the policy.
Closing the Policy
After you use regedt32 to change ntconfig.pol, you need to unload the hive from regedt32 so that NT can use it as a policy file. Select the Policy key and click Registry, Unload Hive. NT will prompt you to save the changes. After you confirm the changes, NT will remove the hive from the Registry editor and save ntconfig.pol to its original location.
Procedure Limitations
When I demonstrate these procedures, people often ask me, "Why do you continue to write policy templates or use SPE profiles when you can edit the policy file directly?" I don't edit ntconfig.pol for all my policy changes because creating policies in this way has three limitations.
First, if you make changes to the policy through ntconfig.pol, you can't later use the SPE GUI to maintain those entries; you can change them only through regedt32. This limitation makes troubleshooting difficult. Be careful! Test your entries on a small scale before editing the policy file for a large network.
Second, when you create HKEY_LOCAL_MACHINE entries in the default profile for a program's HKEY_CURRENT_USER settings, users gain access to the software, but regedt32 doesn't create menu entries or desktop icons for it. To overcome this limitation, you must use SPE to create custom desktop and menu folders for the users whom you give access to a program.
Third, this procedure works extremely well for adding entries to the Registry, but removing Registry entries through ntconfig.pol is very difficult. When you deactivate the policy through SPE, the tool might make a special entry that removes a value or key. I recommend editing the policy file directly only to add keys, values, and settings--never to remove them.
Flexible System Policies
Editing the policy file directly through regedt32 offers you many options. I described procedures for the default user, but you can easily use the same techniques to add software access or restrict permissions for specific users or groups. Simply create keys for their individual or group policies instead of the default user profile.
Modifying NT policy files directly is a convenient addition to SPE's system policies functionality. The ability to use REG_MULTI_SZ entries, the flexibility to add large amounts of Registry data automatically, the option of setting user permissions in the Registry, and the ease of adding items to the policy file make editing system policies easier than ever.
