Discover the scripted, reproducible way to make modifications
The Windows NT family—Windows XP, Windows 2000, NT 4.0, and NT 3.x—has a reputation for being unsecure. In my opinion, however, these platforms (as well as Novell NetWare and the UNIX variants) are all secure because they're equipped with thousands of "locks"—OS pieces that offer some degree of security by letting you specify that only person X can perform action Y to object Z. The difference between NT and NetWare, however, is that although both OSs offer such locks, an out-of-the-box NetWare installation secures the locks, then tells administrators to choose what they want to unlock. In contrast, an out-of-the-box NT installation leaves most of its locks unlocked, then lets administrators select the locks they want. (This information doesn't apply to Windows Server 2003, the design of which follows the NetWare strategy. Win2K has more locked-by-default options than NT 4.0, and XP is tighter out of the box than Win2K Professional.)
The locks present a dilemma for Windows Server 2003, XP, and Win2K administrators: What if properly securing workstations and servers is theoretically possible but is too time-consuming in practice? XP is an excellent OS, but if you have to visit every desktop and adjust a few dozen permissions and rights to make sure the desktop is secure, rolling out XP or any other NT variant becomes an expensive and time-consuming proposition. What you need is a way to script the process of setting up security that automatically adjusts the entire gamut of security-related settings to fit your particular organization.
Fortunately, such a method exists. Security templates are ASCII text files that let you specify settings for local rights and security settings, local group membership, services, file and directory permissions, and registry key permissions. After you create a security template, you can use just one command to apply it, and all its settings take effect. An hour's worth of tinkering with the registry, the Microsoft Management Console (MMC) Computer Management snap-in, and other tools becomes a moment's work.
Security templates aren't new in Windows Server 2003 or XP; they first appeared in NT 4.0 Service Pack 4 (SP4). But every administrator needs to know what they can do. Templates don't let you modify anything that you couldn't modify otherwise, but they provide a scripted, reproducible way to make modifications and easily audit systems to ensure that they meet the template's requirements. You can use the GUI to make these changes manually, but that process is time-consuming. Templates let you easily perform the following five security-related tasks.
Templates can adjust local group memberships. If your users' desktop PCs run NT variations, you've probably struggled with the question of how much power to give users over their desktops. Some companies let everyone become local administrators, some offer Power User status to users, and others give users only simple User status.
If you restrict users' powers on their desktops, I guarantee that at some point you'll relax those restrictions, at least temporarily. For example, suppose you set up workstations that restrict the local Administrators group to only the local Administrator account and the Domain Admins group. But what if a support person "temporarily" elevates a user account to the Administrators group with the innocent intention of undoing the action later, then forgets to restore the accurate permissions? If you apply a security template that says "only Administrator and Domain Admins can be in the local Administrators group," reapplying the template will kick out anyone who isn't supposed to be in the group.
Templates automate the process of setting security information, just as if you sat down and used the GUI to do so. But the template isn't a guardian angel that constantly monitors a system to ensure that your desired template settings are always enforced. The only way to ensure that your settings remain in force is to manually reapply the template on a regular basis or create a Group Policy that applies the template. (Group Policies reapply themselves roughly every 90 minutes.) You can do anything with Group Policies that you can do with security templates, and the ability to automatically reapply Group Policies makes them an attractive option. But if you plan to use Group Policies, you need an Active Directory (AD) domain. Templates, however, work with or without an AD domain.
Adjust NTFS Permissions
You can use security templates to adjust NTFS permissions. Suppose you want to give the C:\stuff directory System/Full Control and Administrators/Full Control NTFS permissions and deny access to everyone else. A template can apply those permissions and restrictions. Also, because you can apply templates to many machines (provided you use Group Policies), you can enforce the set of NTFS permissions on the entire domain. If you're like most NT administrators, you've looked at NT's default file and directory permissions (Everyone/Full Control) in horror and decided to tighten up the ACLs. But you can easily make a mistake and tighten the ACLs to the point at which no one can use a computer, so you'll probably have to experiment to find just the right balance. After you strike that balance, you can express it in a template that you can then apply to any or all systems.
Enable and Disable Services
You can turn services on and off and control who has permissions to turn them on and off. Do you want to shut off Microsoft IIS on all but a few machines? Doing so can be a pain because Win2K and NT 4.0 install IIS on every server by default. (Fortunately, Windows Server 2003 doesn't.) IIS probably isn't the only default service you'd like to nuke. You might also want to apply your scythe to the Server, Computer Browser, Index, and Wireless Zero Configuration services, but walking around to all your systems and disabling the services is too much trouble. Fortunately, a template can do the job for you.
Security templates let you turn off (dynamic status) and even disable (startup status) services. When I first started working with templates, I was surprised to learn that templates also let you control who has the permissions to turn services on and off. I had no idea that services have associated ACLs and that templates let you adjust those ACLs. For example, if you want to give Mary the power to start and stop the Server service without making her an administrator, you can use a template to do so.
Adjust Registry Permissions
Security templates let you adjust registry permissions. The registry contains a lot of information that users can read but not change. For example, you might have upgraded AutoCAD-equipped NT 4.0 workstations to Win2K, but suddenly your users need to be local administrators to run AutoCAD. What happened in the registry to wreak such havoc?
Well-written applications store their software settings in two registry keys: HKEY_LOCAL_MACHINE\SOFTWARE and HKEY_CURRENT_USER\Software. Someone with administrative rights should perform the initial installation and adjust most of the settings, which should be stored in HKEY_LOCAL_MACHINE\SOFTWARE. But users want and need to adjust some aspects of their applications, and the applications need to store those preferences somewhere. If applications stored all user preferences in HKEY_LOCAL_MACHINE\SOFTWARE, users would need to find an administrator every time they wanted to change, for instance, default units from English to metric. Well-written applications store the minor options—user preferences—in a registry subkey in HKEY_CURRENT_USER\Software, so you need to give users write permissions to this subkey. Applications need to be able to read both the major settings in HKEY_LOCAL_MACHINE\SOFTWARE and the minor settings in HKEY_CURRENT_USER\Software. So users who don't have administrative rights must be able to at least read HKEY_LOCAL_MACHINE\SOFTWARE and both read and write to HKEY_CURRENT_USER\Software.
Unfortunately, many software vendors don't understand the differences between HKEY_LOCAL_MACHINE\SOFTWARE and HKEY_CURRENT_USER\Software and save everything in HKEY_LOCAL_MACHINE\SOFTWARE. This tactic doesn't cause a problem in NT 4.0 because NT 4.0's default registry permissions let anyone write to HKEY_LOCAL_MACHINE. In such a case, no one complains when AutoCAD writes everything, including the minor user preferences, to HKEY_LOCAL_MACHINE\SOFTWARE. Regular users can run AutoCAD under NT 4.0 because the ACLs on HKEY_LOCAL_MACHINE are loose. But Win2K features a new set of default registry ACLs that provide: read-only permission for nonadministrative users on HKEY_LOCAL_MACHINE. Thus, AutoCAD won't run unless you're logged on as a local administrator.
What's the solution? Get a new version of the software or roll the XP or Win2K registry ACLs back to NT 4.0's looser levels. You can use a registry editor (regedit in XP or Windows Server 2003 and regedt32 in Win2K) to perform the latter solution manually, or you can use a template to adjust the registry permissions. And you don't even have to create the template, because Microsoft has already done it for you: \winnt\security\templates\compatws.inf will do the job. Another Microsoft template, \winnt\security\templates\basicws.inf, resets the permissions to the default Win2K permissions.
Control Local Security Policy Settings
Security templates can control local security policy settings. Every machine has dozens of local security settings, such as settings that show the name of the last person who logged on or how often to change passwords on locally stored accounts. In NT 4.0, you control those settings with the local version of User Manager: lusrmgr.exe. In Win2K, you use the Local Security Policy snap-in: secpol.msc.
Here's how you change the settings. Start Local Security Policy (it's in Administrative Tools) or just click Start, Run; enter secpol.msc; and click Enter. You can use Local Security Policy to turn auditing on and off, control password policies, hand out or restrict the many user rights in XP and Win2K, and control IP Security (IPSec). In fact, Local Security Policy is about the only tool that controls IPSec, a useful security feature in XP and Win2K.
I hope you're thinking about what you can do with a well-built template; just one file can do everything this article covers. Next time, I'll walk you through the creation and deployment of one of these templates.