The Windows Server 2003 default configuration is far
more secure than those of previous versions of the Microsoft Windows
operating system, but there are still security settings that you should
consider modifying from their defaults. The security requirements for
the various servers on your network might differ, but a good place to
start is creating a security configuration for a standard member server.
This gives you a baseline security configuration for member servers and
a starting point for modifications needed by servers performing
specific roles.
Creating a Baseline Policy
Many of the Windows Server 2003 security parameters used to create a baseline installation can be configured using a Group Policy Object (GPO).
A GPO can contain settings for a myriad of different configuration
parameters associated with the operating system and the applications
running on it. To use a GPO, you associate it with a particular Active
Directory directory service object, such as a domain, a site, or an
organizational unit. When you associate a GPO with an object, that
object’s contents receive all the configuration settings in the GPO. For
example, when you associate a GPO with a domain, all the objects in
that domain inherit the GPO settings.
Note Members servers are computers running Windows Server 2003 that are joined to a domain, but are not domain controllers. |
By default, Windows Server
2003 places all the member servers joined to a domain in a container
object, beneath the domain, called Computers (see Figure 1).
The Computers object is not a domain, site, or organizational unit
object, however, so you cannot associate a GPO with it. Furthermore,
this container also contains the computer objects for all your
workstations, so you would not want to apply a member server baseline to
it.
Tip You should have a basic familiarity with all of the security settings found in group policy objects. |
|
The Computers container object is a special Active Directory object called a container,
which Windows Server 2003 creates by default when you create the first
domain controller for a new domain. The system also creates other
container objects called Users, Builtin, and ForeignSecurityPrincipals.
The term container can be misleading in the case of these four container
objects, because many directory services, including Active Directory,
refer to any object that can have other objects beneath it as a
container. Objects that cannot contain other objects are called leaves.
The Computers, Users,
Builtin, and ForeignSecurityPrincipals container objects are different,
however, because their object type is literally called a container.
These container objects do not have the same properties as Active
Directory objects, such as domains, sites, and organizational units,
which function as generic containers. You cannot delete the Computers,
Users, Builtin, and ForeignSecurityPrincipals container objects, nor can
you create new objects using the container object type. You also cannot
associate GPOs with these objects. You can, however, create new generic
containers, such as organizational units, and associate GPOs with them.
|
To
create a baseline installation for your member servers only, the best
practice is to create a new organizational unit in your domain, then
move the computer objects representing the member servers into it, as
shown with the Members object in Figure 2.
This way, you can associate a GPO containing your security baseline
with the member servers’ organizational unit and all the objects in that
container will inherit the baseline security settings.
Tip
| Do
not put the computer objects for other types of systems, such as domain
controllers or workstations, in your member servers organizational unit
unless you want them to have the same baseline configuration as your
member servers. Workstations do not need most of the configuration
settings discussed in this lesson, and domain controllers have their own
requirements. As a rule, you should place each type of computer that
requires a different configuration in its own organizational unit. |
Setting Audit Policies
Auditing is an
important part of a secure baseline installation because it enables you
to gather information about the computer’s activities as they happen. If
a security incident occurs, you want to have as much information about
the event as possible, and auditing specific system elements makes the
information available. The problem with auditing is that it can easily
give you an embarrassment of riches. You can’t have too much information
when a security breach occurs, but most of the time your servers will
be operating normally. If you configure the system to audit too many
events, you can end up with enormous log files consuming large amounts
of disk space and making it difficult to find the information you need.
The object of an audit configuration is to achieve a balance between
enough auditing information and too much.
When
you configure Windows Server 2003 to audit events, the system creates
entries in the Security log that you can see in the Event Viewer console
(see Figure 3).
Each audit entry contains the action that triggered the event, the user
and computer objects involved, and the event’s date and time.
A GPO’s audit policies
are located in the Group Policy Object Editor console in the Computer
Configuration \Windows Settings\Security Settings\Local Policies\Audit
Policy container, as shown in Figure 4. Each policy creates an audit entry in response to the following events:
Audit Account Logon Events
A user logging on to or off another computer. The policy uses this
computer to authenticate the account. This policy is intended primarily
for domain controllers, which authenticate users as they log on to other
computers. There is typically no need to activate this policy on a
member server. Audit Account Management
Each account management event that occurs on the computer, such as
creating, modifying, or deleting a user object, or changing a password.
On a member server, this policy only applies to local account management
events. If your network relies on Active Directory for its accounts,
administrators seldom have to work with local accounts. However,
activating this policy can detect unauthorized users who are trying to
gain access to the local computer. Audit Directory Service Access
A user accessing an Active Directory object that has its own system
access control list (SACL). This policy only applies to domain
controllers, so there is no need for you to enable it on your member
servers. Audit Logon Events
Users logging on to or off the local computer when the local computer
or a domain controller authenticates them. You use this policy to track
user logons and logoffs, enabling you to determine which user was
accessing the computer when a specific event occurred. Audit Object Access
A user accesses an operating system element such as a file, folder, or
registry key. To audit elements like these, you must enable this policy
and you must enable auditing on the resource that you want to monitor.
For example, to audit user accesses of a particular file or folder, you
display its Properties dialog box with the Security tab active, navigate
to the Auditing tab in the Advanced Security Settings dialog box for
that file or folder (see Figure 5), and then add the users or groups whose access to that file or folder you want to audit.
Audit Policy Change
Someone changes one of the computer’s audit policies, user rights
assignments, or trust policies. This policy is a useful tool for
tracking changes administrators make to the computer’s security
configuration. For example, an administrator might disable a policy
temporarily to perform a specific task and then forget to reenable it.
Auditing enables you to track the administrator’s activities and notice
the oversight. Audit Privilege Use
A user exercises a user right. By default, Windows Server 2003 excludes
the following user rights from auditing because they tend to generate
large numbers of log entries: Bypass Traverse Checking, Debug Programs,
Create A Token Object, Replace Process Level Token, Generate Security
Audits, Backup Files And Directories, and Restore Files And Directories. Tip It
is possible to enable auditing of the user rights listed here by adding
the following key to the registry in the Windows operating system:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\FullPrivilegeAuditing=3,1.
However, if you do this, you should be prepared to deal with the large
number of log entries that auditing these user rights generates by
increasing the maximum size of the logs and having a policy for frequent
evaluation and clearance of the logs. |
Audit Process Tracking
The computer experiences an event such as a program activation or a
process exit. While this policy gathers information that is valuable
when analyzing a security incident, it also generates a large number of
log entries. Audit System Events Someone shuts down or restarts the computer or an event affecting system security or the security log occurs.
When you enable one of
these audit policies, you can select three possible values, which
determine the conditions for creating an audit entry, as follows:
Successes only (select the Success check box) Only when the specified action completes successfully Failure only (select the Failure check box) Only when the specified action fails Successes and Failures (select both the Success and Failure check boxes) Whether the specified action succeeds or fails No auditing (clear both the Success and Failure check boxes) No audit entries for the specified actions under any circumstances
Although
it might appear that the no auditing option is the same as leaving the
policy disabled, this is not necessarily the case. You can associate
multiple GPOs with a single Active Directory object and control the
order in which the system applies the GPO settings. If you have a GPO
that enables a particular policy, you can override the value for that
policy by creating another GPO with a different value for the same
policy and configuring it to override the first GPO’s settings. For
example, if one GPO enables the Success and Failure options for the
Audit Logon Events policy, you can override this setting with another
GPO that has the same policy enabled, but the Success and Failure check
boxes are cleared. |
|
For security
purposes, auditing failures can often be more valuable than auditing
successes. For example, the default Audit Account Logon Events policy
value for domain controllers is to audit successful logons only. This
enables you to determine who was logged on to the network at any time.
However, if an unauthorized user attempts to penetrate an administrative
account by guessing passwords, the audit log would not contain any
evidence of these attempts. Selecting the Failure check box for the
Audit Account Logon Events policy gives you information about the failed
logon attempts as well as the successful ones.
|
