Windows Server 2003 on HP ProLiant Servers : Security Planning and Design (part 1)

Migrating from Windows NT to Windows Server 2003 presents considerably different challenges in security planning than if you are migrating from Windows 2000, chiefly because if you are at Windows 2000, you probably already migrated from Windows NT and resolved security issues at that point. This section focuses primarily on a Windows NT-to-2000 migration, although there will be notes about security features that are different in 2003, such as the Kerberos cross forest trust.

Security Groups

Windows 2000 introduced two new security groups: universal groups and domain local groups. Other groups, such as built-in and global groups, have been around since Windows NT, but Windows Server 2003 does not introduce any new classes of groups. This section is not intended to educate you on the details of these groups, but how security requirements should be specified in the AD design document. The most significant change in Windows 2000 or 2003 security groups from Windows NT security groups is the addition of universal and domain local groups.

When you create universal groups, as Table 1 indicates, you can include accounts, global groups, and other universal groups from any domain in the forest. This gives the Administrator a great deal of power and flexibility in creating groups with forest-wide scope. Universal groups are only available in Windows 2000 native mode domains and in Windows Server 2003 domain functional level domains. Only GC servers can enumerate universal group membership because only GCs know about all objects in all domains in the forest.

The domain local group is seen by all machines in the domain. This gives you the capability of assigning a local group to a resource without having to create it on every single computer in the domain. Domain local groups, like universal groups, are only available in Windows 2000 native mode domains and in Windows Server 2003 native mode (Windows Server 2003 Domain functional level) domains.

Table 1 is a good summary of universal, local, domain local, and global groups.

When migrating from Windows NT 4.0, it's imperative that you make a comprehensive list of all groups defined in the Windows NT domain(s). You might be surprised to find out how many groups are defined and how few are used. In the county government case study noted previously, it had a very small staff of users, but the security group listing was several pages long. A chart such as that in Table 2 helps map the old groups to the new Windows Server 2003 designations and identifies groups that should be eliminated. Remember, the migration is a good opportunity for a house cleaning of groups. 

Role Based Security

Role-based security is a common sense approach. Traditionally, users were assigned security permissions based on their job titles. Role-based security is applied based on the user's job function. Using the group scopes described in the previous section and the user job functions, you can create a map such as that shown in Table 3. You can use the following list to help define these roles; of course, you will probably be able to identify other roles.

• Identify specific tasks that will need to be performed, such as creating users, changing passwords, starting and stopping services, and managing and creating print queues. Identify tasks that are domain- and OU-centered.

• Identify the permissions that are required to perform those tasks.

• Identify specific job functions such as OU Admin, Domain Admin, Enterprise Admin, Desktop Support, Print Operators, Backup Operators, and so forth.

• Map each job function to the required permissions to perform the tasks that are associated with that function.

After these definitions are made, create a global group for each job junction identified, and add the members with that job function to the group. Create a domain local group and apply the appropriate permissions. Add the global group created for the function to the domain local group.

NTFS and Share Permissions

NT File System (NTFS) and share permissions should be mapped out in a form using a table format, for example. This table identifies each directory and the permissions granted to each group. You also should develop a strategy for defining share and NTFS permissions. For instance, because share permissions are less granular and less secure than NTFS permissions, a common strategy is to leave share permissions open and then restrict NTFS permissions. This strategy should also take into account applications that might have their own requirements. You must thoroughly test user access to appropriate data—both gaining access to data they are permitted to access, and being denied access to data they are not permitted to access.

Computer Security Templates

Computer security is determined by the security template used. These templates are stored in %systemroot%\security\templates and contain security settings for basic, secure, and high secure conditions. Although some are applied by default, the Administrator can import them into any Group Policy. They are intended merely as an aid to the Administrator and should not be considered a perfect answer. Windows 2000 contains 12 default security templates:

• Basicdc.inf: Basic security for DCs.

• Securedc.inf: Medium-level security for DCs.

• Hisecdc.inf: High-level security for DCs.

• DCsecurity.inf: Default security settings for DCs.

• Basicsv.inf: Default template used for servers that are not DCs.

• Basicws.inf: Basic security for workstations.

• Securews.inf: Medium-level security for workstations.

• Hisecws.inf: High-level security for workstations.

• Compatws.inf: Relaxed security settings to allow legacy applications to run.

• Setup Security.inf: Default security settings.

In addition, you can create your own template by creating a GPO, modifying the security settings, and then exporting the settings into an INF file. In the Group Policy Editor, go to Computer Configuration\Windows Settings, right-click on Security Settings, and select Export Policy. Save to the %systemroot%\security\templates folder, and the templates will be easy to import to other GPOs. Table 4 provides a matrix of the security settings for each of these templates in Windows 2000.