Security in Windows Server 2003

Similar to the security model in previous versions of Windows dating back to Windows NT, the domain remains the security boundary in a Windows Server 2003 network. Any security configurations that are made apply only to the domain that they were configured in; they do not automatically cross from one domain to another. Each domain will have its own security policies.

In Windows Server 2003, the foundation of the Active Directory security model is the association of an Access Control List (ACL) with each object, attribute, and container to control access to these items by users and groups. In Chapter 4, "Managing and Maintaining Access to Resources," we briefly examined how the network administrator is able to assign individual users and groups varying levels of permissions for objects and their attributes, and even hide those attributes from certain groups of users. This type of security provides the network administrator with a high degree of control over individual objects and their attributes.

As networks get larger and grow in scope, having this type of granular security control is more important. In addition, in the larger organization it is essential to be able to have this type of control to be able to implement a comprehensive organizational security plan. Because of the different needs of each department or location, there might need to be a distinct security plan for each separate entity. For example, the security needs for the accounting department will usually be far greater and more complex than those needed in the mailroom.

As the complexity of the organizational security plan grows, there is a need to simplify the implementation of security as much as possible to ensure that the proper policies are implemented in the proper areas, and for the proper users. Fortunately, Active Directory comes with several tools that can be used to simplify the configuration and management of network security. We examine some of these tools and show you how to implement them in the Active Directory environment.

Applying Security Policies

In Chapter 9, "Implementing Group Policy," we covered the use of Group Policies in a Windows Server 2003 network. In addition to creating Group policies that control users and computers, we can create Security policies that control the security configuration of Active Directory and its objects. The settings contained in these security policies are used to define the security behavior of the network.

Windows Server 2003 uses the Group Policy Object to apply security permissions. Security configurations are created within the Group policy object to control various security areas of Windows Server 2003 clients. By default, Group Policies are applied when the computer starts up, and they are periodically refreshed to pick up any changes that are made to the policies.

Configuring Security Policies

Security policies can be found in two places in the Group Policy snap-in of the Active Directory Users and Computers console. The computer configuration policies are contained in the Computer Configuration container. These policies are used to control the security configuration of computers on the network. These policies will be applied to the computer as its operating system is initialized.

The other security policy is used to enforce lockdown policies on users on the network. These policies are contained in the User Configuration container. These policies will be applied whenever a user logs on to the network.

The Group Policy snap-in allows you to define security policies with the Security Settings extension. The Security Settings extension allows you to define the security configuration for local computers, the domain, and the site within a Group Policy Object. Using a group policy simplifies security administration by allowing the administrator to specify the security settings once, and then apply these settings to all the objects in a container as part of the Group Policy enforcement.

Nine security areas can be configured. These settings are located in the Security Settings node of a Group Policy object, as shown in Figure 16.1. They are

• Account Policies

• File System

• Local Policies

• Event Log

• IP Security Policies

• Public Key Policies

• Registry

• Restricted Groups

• Software Restriction Policies

• Wireless Network

• System Services

Figure 16.1. Group Policy console showing Security Policy areas.

Note: The Big Four

We are going to cover only the top four items in the list, because they are the ones most likely to appear on the exam. For more information on Security Policies, especially the items we won't cover here, see Windows Server 2003 Security Policy Settings at http://technet2.microsoft.com/WindowsServer/en/Library/bcd7ea4c-f989-4cee-969a-920f62f555111033.mspx?mfr=true.

Although most of the policy areas can be applied at the site, domain, or organizational unit (OU) level, there are some policy areas that apply only at the domain. For example, you cannot define different account or public key policies for different OUs in the same domain. All other policy areas can be specified at the level of the site or the OU. Unlike domain controllers, which receive their policies directly from Active Directory, workstations and member servers are allowed to define their own local policies.

Account Policies

Account policies are used to configure the security attributes for the user accounts in the domain. This policy will be the default policy for any machines that are members of the domain. However, you can set an account policy at the OU level, but these settings will apply only to the local user accounts of the nondomain controller computers contained in that Organizational Unit (OU).

These attributes are the following:

• Account Lockout Policy This policy disables a user account after a specified number of failed logon attempts. There are three settings that can be configured:

  • Lockout Count This is the number of failed logon attempts permitted before the account is disabled.

  • Lockout Reset Time This is the time interval between attempts before the lockout count is returned to zero.

  • Lockout Duration This is the time interval after the account is locked out that the account will remain disabled.

• Password Policy Several options are available for password policy. For example, both the minimum password length and maximum password age can be specified. In addition, Windows Server 2003 allows you to require the use of Complex Passwords. Complex Passwords have to be at least six characters long and must contain a mix of different characters. A complex password cannot contain any part of the username or the user's full name. You can also prevent users from reusing passwords or simple variations of previous passwords.

• Kerberos Authentication Policy You can modify the default Kerberos settings at the domain level. This can include the ticket lifetime and enforcement of user logons.

Note: Account Policies

It is not necessary to apply an account policy to organization units that don't contain computers. The account policies that apply to the users in the organizational unit can only be applied as a domain policy.

To modify the Account Policies, follow the procedure in Step by Step 16.1.

Step by Step

16.1 Modifying Account Policies

1.	Click Start, All Programs, Administrative Tools, Domain Security Policy.
2.	From the Domain Security Policy snap-in, click Security settings, and then click Account Policies.
3.	Click Password Policies, and then in the right pane of the console, right click Minimum Password Length (see Figure 16.2). Figure 16.2. Default Domain Security Settings MMC, showing Windows Server 2003 default Password Policy.
4.	From the pop-up menu, click Security.
5.	The Security Policy Setting window appears. Select the Define This Policy Setting check box.
6.	Set the password length in the Characters box to 7.
7.	Click OK to save.

When configuring the account policies, it is best to balance the level of security desired with the overhead created by having security policies that are too restrictive. Although no one wants to have a network that is vulnerable to security breaches, having an overly restrictive lockout policy can create an excessive workload for the user help desk personnel. In addition, if the password format and length is too difficult to remember, most users will write down their passwords, potentially leaving them where an unauthorized user could find them. Usually, a password length of seven characters is optimum both for security exposure and user convenience.

Remember that password, lockout, and Kerberos policies are applied at the domain level only. A Windows Server 2003 domain controller will ignore any policies defined at the OU or site level.

Event Log Policies

The Event Log policies are used to configure the application, system, and security event logs on Windows Server 2003 computers. For example, you can specify the following:

• Access rights for each type of log

• Maximum log size

• Length of retention

• Log retention methods

The settings for the event logs can be controlled at the site, domain, or OU level. Generally, domain controllers should be configured with larger logs, and they should be retained longer than the logs on workstations. In addition, you might want to configure the access rights of the event logs on domain controllers so that they can be viewed only by administrators. Event and security logs will be covered at length later in the chapter.

File System Policies

File system policies can be used to configure security for files and folders. For example, to ensure that only administrators can modify system files and folders on all the computers in the domain, you can configure a policy that will grant full control over system files and folders to administrators while giving users read permission only. In addition, file system policies can also be used to prevent users from being able to see certain files and folders.

This type of security configuration can be specified once in the file system policy and then applied to all the computers in the domain. This can save the network administrator a lot of time and effort when locking down the file system on a large number of computers.

File System policies can also be used to control the security auditing of user access to certain files and folders when auditing is enabled. You can specify which users and which user events are logged for both failed and successful events. We will look at this at greater length in the section on Audit Policy.

Local Computer Policies

Local computer policies are used to control the security of the local computer. The policies that will affect the local computer and its users are stored in the \%systemroot%\system32\GroupPolicy folder. Local computer policies allow the administrator to control and audit a variety of events and tasks. These events and tasks can be broken down into three areas:

• Audit Policy

• User Rights Assignment

• Security Options

Local Computer Policies allow the network administrator to control the security of the individual computers from a central location. By applying this policy to a domain, site, or organizational unit it saves the administrator time and effort since there is no need to visit individual computers. By separating different types of computers such as domain controllers, member servers, and user workstations into different organizational units, the administrator can tailor the policies for each type of machine. In addition, by assigning different user rights to different user groups, this also allows the administrator to grant more extensive rights that might be needed in the Developers group while limiting the rights of users in the Warehouse group.

Audit Policy

The Audit policy is used to specify which security events will be logged in the Security log on the local computer. This can include events such as logons and user access of specified files and folders. You can audit successful attempts, unsuccessful attempts, or both. Auditing and audit policies will be covered at length later in this chapter.