Chapter 2, Designing Active Directory for Security

|1| Chapter Overview

Designing Your Forest Structure

Designing Your Domain Structure

Designing an OU Structure

Designing an Audit Strategy

Chapter 2, Lesson 1

|2| Designing Your Forest Structure

1. Introduction

A. Single or multiple forest implementations affect Active Directory administration.

B. Identify duplicate efforts to ensure consistent security.

|3| 2. Active Directory Design Basics

A. Forests

1. A collection of domains that share a common schema, configuration, and global catalog

2. All domains in a forest are connected using transitive trust relationships.

B. Domain tree

1. A collection of domains that share a contiguous name space

C. Domain

1. A unit of replication within Active Directory

2. Break up the forest for replication and account policy by creating multiple domains within a forest.

D. OU

1. A container object within a domain used to organize security principals

2. Can exist within domains or other OUs

E. Sites

1. The physical network that exists for an organization

2. A section of the network with high network speeds

3. Used to find network services located in the same network as the client attempting to connect to the network service.

|4| 3. Deploying a Single Forest

A. Introduction

1. A single forest is the most common configuration.

2. A single forest shares information across every component domain.

Note Microsoft recommends that a domain controller (DC) be maintained in a separate forest to test all schema modifications before deploying the changes into a production environment, because a change made to the schema is a permanent change that cannot be deleted in Microsoft Windows 2000. You should understand that this is the only exception to initially configuring a single forest for deployment of Active Directory.

|5| B. Shared information

1. Schema

a. Defines all classes and attributes used within the forest

b. By default, the first DC installed on the forest is the schema operations master.

c. The schema operations master maintains the write-enabled copy of the schema.

2. Configuration

a. Maintains a listing of all domains and sites within a forest

b. Ensures that no duplicate names are created within a forest

3. Global catalog

a. Maintains a partial set of attributes for all objects

|6| C. Inter-domain trusts

1. Domains are joined together by Kerberos v5 transitive trust relationships.

2. Microsoft Windows NT 4.0 domain trusts are not transitive in nature.

Note In a Windows 2000 transitive trust, if Domain A trusts Domain B, and Domain B trusts Domain C, then Domain A trusts Domain C. In other words, if a domain trusts another domain, it also trusts all other domains trusted by that domain.

|7| D. Making the decision: single forest

1. Same software used across the organization

a. Active Directory–aware software may require changes to the schema.

b. Using standardized software lessens the chances of objections to schema modifications.

2. Minimizes forest-wide configuration

a. Reduces the number of administrative tasks that globally affect a forest

3. Reduces the management of forest-wide administrative groups

a. In a multiple forest, multiple sets of Enterprise Admins and Schema Admins administrative groups must be maintained.

4. Allows single, enterprise-wide searches

a. A global catalog server can be queried to perform forest-wide searches.

b. If multiple forests exist, additional software or multiple searches must be implemented to perform an enterprise search in a single command.

5. Reduces management of trust relationships

a. All domains within a forest are connected using transitive trust relationships.

b. There is no requirement to manually define trust relationships between domains in a single forest deployment.

Note There are circumstances where it is advantageous to define shortcut or cross-link trust relationships within a forest. These shortcut trusts allow faster authentication to take place when a resource is accessed in a domain other than the domain where the security principal accessing the account resides.

|8| E. Applying the decision: single forest at Wide World Importers

1. No actual business case requires the deployment of multiple forests.

2. Having distribution and service centers spread across national boundaries is not a business reason for creating separate forests.

3. Standardizing applications and the need for centrally managed user accounts indicates a need to implement a single forest.

Note Slide 9 lists the two major reasons to implement multiple forests. Slide 10 lists the individual costs associated with deploying multiple forests.

|9| 4. Deploying Multiple Forests

A. Introduction

1. Implement multiple forests in limited scenarios.

a. Used in decentralized organizations that perform much of their network operations within their own sector of the organization

b. Used by an ISP that does not want to have a common directory for all of their clients

|10| B. Disadvantages of deploying multiple forests

1. A more complicated and expensive domain structure

a. Each domain must have at least one DC.

b. The creation of additional forests leads to additional hardware costs.

2. Additional management costs for forest-wide components

a. Schema modifications must be performed for each forest.

b. Administrative group membership must be managed in each forest.

3. Additional management costs for trust relationships

a. Explicit one-way trust relationships must be established between domains in the forests where resources are to be accessed.

b. Users from one forest cannot access resources in another forest without the creation of the explicit trust relationship.

c. Trust relationships can only be established between domains, not between forests.

4. Limited use of user principal names (UPNs)

a. UPNs are resolved by querying a global catalog server.

b. In multiple forests, only default UPNs can be used if users are going to authenticate by using UPNs.

c. UPN suffixes are not accessible because global catalogs are not shared between forests.

Note The following example is a UPN: account@DNSDomainName.

5. Smart cards limited to using default UPNs

a. To enable cross-forest logons, the UPN associated with a smart card must be based on the default UPN, not an alternative UPN.

6. Conclusion

a. Implementing multiple forests can result in some loss of functionality for the users within an organization.

b. The global catalog contains a partial replica of all objects in the organization only in a single forest environment.

|11| C. Making the decision: possible reasons for multiple forests

1. Short-lived joint ventures

a. When organizations are paired together for short term projects

b. When organizations will remain autonomous during and after the joint venture is completed

2. Mergers between companies running separate Active Directories

a. Initially, maintain separate Active Directory forests.

b. If the merger is permanent, merge the two forests into a single forest using directory migration tools.

c. Microsoft Active Directory Migration Tools (ADMT) allows for the migration of security principals between forests.

3. Disagreement on change policies

a. Modifications affect all domains in the forest because forests share a single schema and configuration.

b. Participants in a forest must agree on a business process for schema changes and membership in enterprise-level groups.

4. Differing schema requirements

a. Multiple forests are required when different schema modifications are needed.

b. Schema modifications cannot be limited to a single domain.

Note Modifications to the schema are permanent. Classes or attributes that are added to the schema can never be removed. They can only be marked as defunct.

5. Distrust among administrators

a. By default, the Enterprise Admins group is assigned privileges that allow management of all domains in the forest.

b. Some departments do not trust other department administrators to have administrative rights within their domain.

c. Remove the Enterprise Admins group from the Administrators group in each domain to prevent administrators from having administrative rights within each domain.

6. Scope of transitive trust relationships

a. Windows NT 4.0 trust relationships were established in a single direction to prevent users in the resource domain from accessing resources in master domains.

b. Due to transitive trust relationships, users in a domain can access resources in all other domains within the forest.

c. Separate forests must be implemented to restrict access to resources using trust relationships.

Note Trust relationships must be established between domains in the two forests, not simply established between two forests.

7. Limited replication of the global catalog

a. All objects in the forest have a partial set of attributes replicated to the global catalog.

b. Objects that are added to or deleted from the domain affect replication of the global catalog for all domains.

c. The entire global catalog is replicated to all global catalog servers in the forest.

8. Preventing user accounts from appearing in the global catalog

a. In secure environments, prevent users from knowing the existence of specific user accounts in the organization.

b. Put these user objects into a separate forest.

|12| D. Applying the decision: multiple forests at Wide World Importers

1. A merger takes place, due to either takeover or acquisition, where the other organization has already deployed Windows 2000 Active Directory.

a. During the initial period, maintain separate forests to allow connectivity between the two forests.

b. Explicit trust relationships must be defined between domains where resource access must take place.

c. To merge the two forests, schema modifications must be analyzed to ensure a smooth transition to a single forest.

Chapter 2, Lesson 2

|13| Designing Your Domain Structure

1. Introduction

A. After a decision has been made to create a single or multiple forest, determine how many domains are required.

B. Start with a single domain model, then determine if multiple domains are required.

2. Deploying a Single Domain

A. Introduction

1. Implement a single domain forest in organizations that maintain centralized control of user and computer accounts.

2. Membership in the Administrators group in a single domain is easily monitored.

3. A single domain is the best choice for an Active Directory design when you want simplicity within the forest.

|14| B. Making the decision: advantages of a single domain

1. Reduces management of the forest

a. Administrators of the domain are ultimately the administrators of the forest.

b. There are no differentiations between enterprise administrators and domain administrators.

c. OUs are used to delegate administrative tasks to specific individuals.

2. Reduces the number of required DCs

a. Each domain requires a separate DC.

b. If multiple sites exist in the forest, only DCs from a single domain need to be placed at each site.

3. Reduces the dependency on global catalog servers for authentication

a. In a native-mode multiple-domain environment, the authenticating DC connects to a global catalog server to determine universal group membership.

b. In a single-domain environment, the authenticating DC knows about all objects in the forest.

Note The authenticating DC knows that only a single domain exists in the forest by querying the CN=configuration, DC=forestrootdomain naming context to determine all the domains that exist in the forest.

4. Provides an easier migration path to multiple domains

a. A single domain forest is easy to migrate to a multiple domain environment.

b. Reducing the number of domains in an existing forest requires the migration of user accounts between domains in the forest.

c. A domain must be empty to be removed from the forest.

|15| C. Applying the decision: using a single domain at Wide World Importers

1. Initially start with a single domain.

2. Business objectives may require the implementation of multiple domains.

2. It is easy to migrate from a single domain to multiple domains.

3. No additional costs are involved with initially deploying a single domain.

|16| 3. Deploying Multiple Domains

A. Introduction

1. Implement multiple domains when there is a requirement for differing account policies.

2. Account policies cannot be varied within a single domain.

|17| B. Understanding account policies

1. Overview

a. Account policies include three categories of configuration:

(1) Password policy

(a) Defines the characteristics of passwords that may be used to authenticate to the domain

(2) Account lockout policy

(a) Defines what actions must be taken when a specified number of failed logon attempts take place in a short duration of time

(3) Kerberos policy

(a) Defines the maximum ticket lifetimes for Kerberos authentication and tolerances for clock synchronization between client computers and servers

Note You must set the account policy at the domain level so that the domain settings are configured. The account policy configured at the OU level will affect only the local account databases of any computers in that OU. It will not affect any users authenticating with the domain when sitting at that computer.

|18| 2. Password policy

a. Enforce Password History

(1) Lets you configure how many previous passwords are maintained to prevent a user from re-using the same password

(2) Can have values between 0 and 24 passwords

b. Maximum Password Age

(1) Defines how often a password must be changed

(2) Values can be set from 0 (password will never expire) to 999 days

c. Minimum Password Age

(1) Defines how long a newly changed password must exist before the user can change it

(2) Prevents the user from performing a quick switch of passwords

d. Minimum Password Length

(1) Defines the minimum character length for a user’s password

(2) Passwords with less than the minimum required characters are rejected.

e. Passwords Must Meet Complexity Requirements

(1) Controls the format of passwords entered by the user

(2) Passwords cannot contain the user’s account name.

(3) Passwords must meet three of the following four requirements:

(a) UPPER CASE

(b) lower case

(c) 1234567890 (numeric)

(d) !@#$%^&*() (symbols)

f. Store Password Using Reversible Encryption For All Users In The Domain

(1) Stores the password in a reversible encryption format

(2) The password is saved in this format only after the user changes the password once the policy has been initially set.

(3) Reversible encryption is used by the Internet Information Server (IIS) when configured for digest authentication by dial-in users using Challenge Handshake Authentication Protocol (CHAP).

|19| 3. Account Lockout Policy

a. Account Lockout Duration

(1) Defines the length of time an account will be locked out

(2) Can be a value between 0 and 99999 minutes.

(3) Zero indicates the account is locked out until the account is reset.

b. Account Lockout Threshold

(1) Defines how many incorrect logon attempts are allowed before an account is locked out

(2) Values can be set between 0 and 999 logon attempts.

c. Reset Account Lockout Counter After

(1) Defines how often the account lockout counter will be reset to 0

(2) If the policy has a value of 30 minutes, the account lockout counter will be reset to a value of 0 after a period of 30 minutes since the last failed logon attempt.

|20| 4. Kerberos Policy

a. Enforce User Logon Restrictions

(1) Verifies that the account has not been locked out each time that a Kerberos service ticket is requested

(2) This prevents a locked-out account from acquiring any additional service tickets.

b. Maximum Lifetime For Service Ticket

(1) Defines how long a service ticket can be stored in the service ticket’s cache

(2) The service must discard the service ticket and acquire a new service ticket or renew the existing service ticket.

c. Maximum Lifetime For User Ticket

(1) Defines the maximum lifetime for a Kerberos ticket issued to a user account

(2) The ticket is discarded from the user’s Kerberos ticket cache.

d. Maximum Lifetime For User Ticket Renewal

(1) Defines the maximum amount of time for which a ticket may be renewed

(2) A new ticket must be acquired from the Kerberos Distribution Center.

e. Maximum Tolerance For Computer Clock Synchronization

(1) Defines how much a client’s computer clock can be out of sync with a server’s computer clock

(2) Kerberos protocol uses a timestamp to prevent replay attacks of Kerberos authentication stream.

(3) If the clocks are out of sync by a period greater than this policy setting, the authentication attempt will fail.

(4) The clock synchronization setting ensures that replay attacks are prevented on the network.

|21| C. Making the decision: when to deploy multiple domains

1. Differing account policies

a. All account policy settings are applied at the domain level.

b. Multiple domains must be created if different account policy settings are required.

Note Account policies can be defined at the OU level in Group Policy. This will not affect domain account policies but will affect local account database policies. This means that different account policy settings can be set for users who authenticate with the local security account management database of their computer, rather than those that are set for domain authentication.

2. Replication issues

a. Replication traffic can saturate slow WAN links.

b. Configuring separate domains at branch offices limits replication to the schema, configuration, and global catalog.

c. Implement the new domain as a child domain of the current domain or as a domain in a separate tree within the forest.

3. International considerations

a. Some countries require management of the network within the country where the network exists.

b. A separate domain must be established.

4. Political reasons

a. Many departments may want to maintain autonomy by managing separate domains within a forest.

b. Although this is not a business case for creating separate domains, it is a common scenario that should be addressed.

c. Some organizations use OUs to delegate administration instead of creating separate domains.

5. Separating enterprise administration accounts into a separate domain

a. Enterprise-level administration groups exist in the forest root domain.

b. These include Schema Admins and Enterprise Admins groups.

c. Creating a forest root domain that is empty restricts who can manage these accounts.

Note All members of the Domain Admins group in the forest root have the ability to change membership in the Enterprise Admins and Schema Admins groups. Membership in all three groups should be carefully monitored to ensure that group memberships are not changed without authorization.

|22| D. Applying the decision: multiple domains at Wide World Importers

1. Separate account policies need to be defined for the Engineering department.

(a) Multiple domains are required.

(b) At least two domains are needed: the Engineering department and the remaining organization users.

4. Separate domains are not required for offices in the United States and Canada.

5. The current utilization of WAN links is sufficient to support replication of a single domain.

6. The organization can choose to deploy either a two-domain or three-domain forest.

Chapter 2, Lesson 3

|23| Designing an OU Structure

1. Introduction

A. An OU structure must be created for every domain that exists in the forest.

B. The OU structure must provide the framework for delegating administration to portions of the organization’s Active Directory.

C. The OU design must also provide the necessary structure to allow Group Policy deployment.

|24| 2. Planning for Delegation of Administration

A. Introduction

1. Windows 2000 design is based on the ability to delegate administration to

a. Specific OUs

b. Specific objects within an OU

c. Specific attributes of an object

|25| 2. Windows NT required that administration be delegated by creating resource domains.

3. Windows NT resource domains often led to excessive user rights being assigned and excessive resource domains being created.

|26| B. Delegating control to an OU

1. The Delegation Of Control Wizard

a. Used to delegate administration to specific OUs

b. Allows you to delegate the management of Active Directory objects

c. To access, right-click a container in Active Directory Users And Computers and select Delegate Control.

|27| 2. Default options set by the Delegation Of Control Wizard

a. Users Or Groups

(1) Users or groups that will be delegated administrative control

b. Tasks To Delegate

(1) Management of user accounts

(2) Resetting passwords

(3) Reading user information

(4) Managing groups

(5) Modifying membership of groups and managing Group Policy links

c. Custom Tasks

(1) Delegate full control of all objects in the folder.

(2) Reference the object classes that the user or security group can manage.

d. Custom Permissions

(1) If custom tasks are selected, the permissions that will be delegated to the user or security group selected can be defined.

(2) Manually delegate permissions from the Advanced option of any Active Directory container’s Security tab.

(3) Use the Permission Entry dialog box to configure custom permissions for the container.

(4) Can be applied to:

(a) The container and all child objects

(b) Just the container

(c) Only to specific objects that exist in the container

Note The Security tab is available only when Advanced Features are enabled in Active Directory Users And Computers.

|28| C. Making the decision: delegation of administration design

1. Overview

a. Ensure that only the minimum rights are delegated to the selected security principals.

b. Consider what rights to delegate to specific users or groups.

c. Rights do not have to be assigned based on the Account Operators or Server Operators groups.

d. Test the design.

(1) Delegate the desired permissions to a blank security group.

(2) Create a new user account that is only a member of the newly created security group.

(3) Test both the tasks that the delegated administrator is to perform and the tasks that are not to be delegated to the administrator.

e. Audit success and failures for directory management to ensure that only approved management functions are taking place.

f. Enable success and failure audits for directory service access on the OU.

(1) Audit settings should be configured on the Default Domain Controllers policy, assuming that all DCs remain in the OU.

|29| 2. Determine to which users administration will be delegated.

a. Select only the users that require delegated user rights.

b. Create a separate security group and delegate the permissions directly to that group, and then add the user as a member of the group.

c. It is not recommended to assign permissions directly to the user.

d. If a user’s role changes, only the membership of the security group changes, not the delegated permissions on the OU.

|30| 3. Determine where to delegate administration in the OU hierarchy.

a. Delegate control higher in the OU hierarchy to reduce the number of places that delegation must take place.

4. Determine which types of objects should be delegated for administration.

a. Delegated administration is frequently required only for a specific class of objects.

b. Limit delegation only to the classes of objects that the delegated user will manage, rather than delegating full control of all classes of objects.

5. Determine the minimum set of rights required.

a. The Delegation Of Control Wizard allows delegation of administration based on an entire object.

b. Often the best solution is to provide administration rights to only a subset of attributes for an object.

|31| D. Applying the decision: delegation of administration design at Wide World Importers

1. Business requirements

a. Create an OU structure for the Engineering domain to allow the Engineering department at each distribution center to nominate an Engineer to manage the user accounts.

b. The nominated user will also be responsible for maintaining group memberships of the Engineering user accounts for their distribution center.

c. The head of the IT department for Engineers at the Washington office is required to manage all Engineering accounts within the domain.

d. OU structure facilitates the required delegation of authority required by the Engineering department.

|32| 2. Proposed solution

a. Engineering Users OU

(1) A domain local group can be given the ability to manage all user accounts.

(2) The head of the IT department for Engineers can be made a member to manage the users.

(3) The head of the Engineering IT department can manage all user accounts in the Engineering department.

b. Distribution Center OU

(1) Separate domain local groups can be delegated user account administration for each distribution center OU.

(2) The nominated engineers at each center can be made members of this group so they are limited to managing only user accounts from their distribution center.

(3) This design is based on an OU structure that facilitates delegation of administration.

|33| 3. Planning for Group Policy Deployment

A. Introduction

1. Group Policy can be applied to local computers, sites, domains, and OUs.

2. Group Policy can be configured for both users and computers.

3. An OU structure can ultimately separate computers and users into separate OUs.

|34| B. Group policy is applied in a specific order.

1. Local policy

2. Site policy

3. Domain policy

4. OU policy

5. Child OU policies

|35| C. Group Policy inheritance

1. Group Policy is inherited by default.

2. If a policy is defined at the domain level, all OUs under that domain will have the Group Policy setting applied.

a. Exception: If the Group Policy setting is defined in an OU closer to the user, that overrides the previous setting.

3. A Group Policy setting defined at a parent OU will be inherited by child OUs in the OU hierarchy.

Note Understand that Group Policy settings are inherited within a domain, not between domains. If a Group Policy is defined at the forest root domain, it is not inherited by child domains created below the forest root. A domain can only inherit site Group Policy settings.

D. Blocking Group Policy inheritance

1. Block Group Policy inheritance by configuring the Block Policy Inheritance option within the properties of the OU.

2. Blocking inheritance prevents Group Policy settings defined in parent containers from being applied at child containers.

E. No Override Policy option

1. The No Override Inheritance setting prevents lower level Group Policy objects from overriding the policies defined at higher levels of the Active Directory structure.

2. If both the No Override and Block Policy Inheritance settings are set, the No Override option will always take precedence.

Note It is important that you understand that blocking policy inheritance makes it very difficult for administrators to troubleshoot Group Policy application errors.

F. Group Policy filters

1. Group Policy can be filtered so that the policy is only applied to specific Windows 2000 security groups.

2. This is performed in the Security tab of the Group Policy object.

G. Applying Group Policies

1. The Security group must be assigned two specific permissions.

a. Read: Allows the members of the security group to read the properties and settings of the Group Policy object.

b. Apply Group Policy: Indicates that those properties and settings will be applied to the security group.

|36| H. Making the decision: OU Group Policy requirements

1. Create an OU structure that does not require blocking inheritance.

a. The default application model for Group Policy does not take place when policy inheritance is blocked.

b. Troubleshooting Group Policy application is difficult and may require resource kit tools.

Note When troubleshooting Group Policy application problems, you can use the Gpresult.exe tool from the Microsoft Windows 2000 Server Resource Kit to determine exactly which Group Policies were applied to the computer and user account. This reduces the troubleshooting to only the Group Policies that were actually applied to the user or computer object.

2. Limit the use of Site Group Policies in a multiple-domain environment.

a. Site Group Policies are stored in the domain where the site Group Policy was defined.

b. A user or computer may have to contact a remote DC to load the site Group Policy.

3. The number of levels of OUs do not affect performance.

a. The number of OUs, not the levels of OUs, affect logon performance.

b. If too many Group Policy objects are defined, authentication can take a long time.

4. Apply only the necessary settings.

a. Prevent user settings from being applied if the Group Policy object is only applying computer settings.

(1) Reduces processing time and prevents extraneous information from being added to the Group Policy accidentally.

|37| I. Applying the decision: OU design based on Group Policy at Wide World Importers

1. Two requirements make it necessary to configure a Group Policy:

a. Deployment of consistent security configuration for all computers

|38| (1) Create an OU structure that groups computers into OUs based on the security template that the computers have assigned.

(2) DCs will be located in the Domain Controllers OU.

(3) A separate OU named Wide World Computers will be created with two sub-OUs: Workstations and Servers.

(4) Three security templates can now be deployed:

(a) The Basicdc.inf template would be deployed at the Domain Controllers OU.

(b) The Basicws.inf template would be deployed at the Workstations OU.

(c) The Basicsv.inf template would be deployed at the Servers OU.

|39| b. Deployment of software for users

(1) Define a single OU to deploy applications. This can be located anywhere within the OU structure.

(2) The Accounting users OU will contain all of the Accounting department user accounts.

(3) Define a Group Policy object that assigns the Accounting software to all user accounts within the OU.

(4) Microsoft Office 2000 distribution can be deployed at the Domain Group Policy object.

Chapter 2, Lesson 4

|40| Designing an Audit Strategy

1. Configuring Audit Settings

|41| A. Overview

1. Auditing is used to determine

a. Who accessed specific resources

b. Who performed specific actions

2. Auditing is tracked in the Security Log of the Windows 2000 Event Viewer

3. Audit settings can be configured within the audit policy.

4. Indicate which individual objects to include in the audit.

|42| B. Audit Policies defined for a domain

1. Audit Account Logon Events

a. Occurs when a user logs on to a computer

b. If the user logs on to the local computer, the event is recorded in the computer’s audit log.

c. If the user logs on to a domain, the authenticating DC records the account logon event.

2. Audit Account Management

a. Occurs when a user creates, changes, or deletes a user account or group

b. Also occurs when a user account is renamed, disabled, or enabled, or a password is set or changed

3. Audit Directory Service Access

a. Occurs when a user gains access to an Active Directory object

b. Specific Active Directory objects must be configured to log this type of audit.

4. Audit Logon Events

a. Occurs any time a user authenticates with the local computer or with Active Directory

b. Includes physically logging on at a computer or establishing a network connection to the computer

5. Audit Object Access

a. Occurs any time a user gains access to a file, folder, or printer

b. Specific files, folders, or printers must be configured for auditing.

6. Audit Policy Change

a. Occurs any time Local Policies are changed in Group Policy

b. Includes user rights, audit policy, or security options

7. Audit Privilege Use

a. Occurs any time a user exercises a user right

8. Audit Process Tracking

a. Occurs any time an application performs an action

b. Used to determine what files and registry keys an application requires access to when it’s operating

9. Audit System Events

a. Occurs any time a server is restarted or shut down

b. Occurs any time the security log is reset on the computer

|43| C. Making the decision: determining the audit strategy

1. Determine where to apply the audit settings.

a. Audit settings can be defined at the local, site, domain, or individual OU level.

b. Audit policies are applied in a specific order:

(1) Local computer

(2) Site level

(3) Domain level

(4) First level of OUs

(5) Child OUs

Note Audit policies will only be applied for policies that are defined.

2. Define DC audit settings in the Domain Controllers OU.

a. By default, all DCs are located in the Domain Controllers OU.

b. Ensure that consistent auditing is performed across all DCs in a domain.

3. Collect computers with similar audit requirements into common OUs.

a. Allows audit policy settings to be applied to the OU level

4. Do not audit all events.

a. If excessive auditing is performed, the event log will be filled with unnecessary data.

b. Select the events that are essential to the auditing needs.

5. Mix failure and success audits.

a. Use failure audits to detect intrusion attempts and internal users attempting unauthorized tasks.

b. Use success audits to determine if an intrusion has been successful.

6. Match audit strategy to the organization’s risk level.

a. The lower the risk level, the more events that should be audited.

|44| D. Applying the decision: determining the audit strategy for Wide World Importers

1. Overview

a. The current network deployment is only concerned with internal network auditing.

b. Less emphasis can be placed on auditing for external attacks.

|45| 2. Proposed auditing structure

a. Audit the failure of the account logon events.

b. Audit the success and failure of the account management events.

c. Audit the success and failure of the object access events.

d. Audit the success and failure of the policy change events.

e. Audit the success and failure of the system events.

|46| 3. Information contained in the security log

a. All account management tasks

(1) Determines when user accounts were created, modified, or deleted and who performed the task

b. Account logon event failures

(1) Identifies any attempted break-in attempts

(2) Include success events to determine if a break-in attempt is successful

c. Success and failure auditing for object access. (Note that you must enable both for the files to be audited.)

(1) Can determine who is accessing a file or folder object

(2) File or folder to be stored on an NTFS volume on which auditing is enabled.

d. Success and failure events for policy changes

(1) Ensures changes to the audit policy will be recorded in the audit logs

e. Success and failure for system events

(1) Enables you to detect any attempts to restart the server.

(2) The events will record who attempted to restart the server and when the restart took place.