Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Windows Server 2003 : Creating a Baseline for Member Servers (part 1) - Creating a Baseline Policy & Setting Audit Policies

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
4/3/2011 11:38:51 AM
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.

Figure 1. The Computers container in the Active Directory Users And Computers console


Tip

You should have a basic familiarity with all of the security settings found in group policy objects.


Understanding Container 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.

Figure 2. A container object for member servers in the Active Directory Users And Computers console


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.

Figure 3. The Event Viewer console


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:

Figure 4. The Audit Policy container in the Group Policy Object Editor console


  • 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.

    Figure 5. The Advanced Security Settings dialog box
  • 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

Real World: GPO Application

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.

Other -----------------
- BizTalk 2010 Recipes : Orchestrations - Sending Messages
- BizTalk 2010 Recipes : Orchestrations - Receiving Messages
- SharePoint 2010 : Designing and Managing Pages and Sites for Knowledge Workers - Reviewing the Look and Feel Tools
- SharePoint 2010 : Designing and Managing Pages and Sites for Knowledge Workers - Reviewing the Site Administration Tools
- SharePoint 2010 : Designing and Managing Pages and Sites for Knowledge Workers - Reviewing the Galleries Tools
- Exchange Server 2010 : Installing Operations Manager 2007 R2 (part 3) - Deploying OpsMgr Agents
- Exchange Server 2010 : Installing Operations Manager 2007 R2 (part 2) - Importing Management Packs
- Exchange Server 2010 : Installing Operations Manager 2007 R2 (part 1) - Single Server OpsMgr 2007 R2 Install
- Using Operations Manager to Monitor Exchange Server 2010 : Securing OpsMgr
- Sharepoint 2010 : Designing and Managing Pages and Sites for Knowledge Workers - Reviewing the Users and Permissions Tools
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server