Additional Study Topics: Utilities | Groups | Migration Issues | RIS
I.
Configuring
and troubleshooting security in a directory services infrastructure
With any
networking product, all security features come down to two main categories: use of
security tools and use of proper administrative techniques and configuration parameters.
It is only through balancing both items that proper security is maintained.
A. Applying
security policies using Group Policy
1. Group
Policies allow for many restrictions in the user’s desktop environment.
2. When to use
security policies
a. Only work
with Windows 2000 environments, although similar tools can be applied to NT 4.0 and 9x
desktops
b. Allow for
consistent client environment for entire organization
c. Allow users
to maintain look and feel of desktop (including applications) while moving throughout the
organization
d. May only be
necessary in larger network installations
3. How to create
security policies
a. Described in
Exercise 12-1 on page 614and accomplished by the student already
b. GPOs are
applied in LSDOU order.
B. Security
configuration and analysis
1. Windows 2000
comes with a preconfigured tool that allows for the configuration, analysis, and
resolution of security issues within a Windows 2000 domain. The tool, however, has to be
run on each computer, as it is specific to the local computer only.
2. Security
templates
a. The Security
Templates console allows for the creation of security templates in a number of areas.
b. Account
policies
i.
Minimum
password length
ii.
Account
lockout duration
iii.
Kerberos
settings
c. Local
policies
i.
Audit policy
ii.
User rights
and others that affect the local system
d. Event logs
e. Restricted
groups
f. System
services
g. Registry
h. File system
i. Some security
template files have been predefined and included with the OS
3. Why perform a
security analysis?
a. Allows for a
quick inspection that compares the security actually applied to the system with that of
settings recommended by Microsoft
4. Setting
rights on system services
a. Services
include file and print, telephony, and network services
b. Allows for
the restriction of service access to the user who logged on
5. Setting
rights on a file system
a. Similar to
setting rights on the service system, the file system allows for the setting of
permissions down to the folder and file level.
C. Implementing
an audit policy
1. Involves
recording events as they happen in the system’s log files, to be viewed by Event
Viewer
2. Why audit
events?
a. Only way to
monitor attempts to break into a system
b. Good way to
see what is happening in the network
c. Only way to
ensure accountability within network administration, as administrative use can be audited
to see who made what changes to the network, as well as to the security settings
3. How to
implement an audit policy
a. Can only be
set on resources that reside on NTFS drives
b. Will only
audit events specifically configured for monitoring by the administrator
c. System will
not interpret events as possible problems; administrator must consistently review events
to find potential problems.
4. Configuring
auditing
a. Auditing can
be configured for two types of items: Active Directory items such as user accounts, and
file and print items.
i.
Considered
separate as they are monitored from two separate places—one on domain controllers and
one on local member servers sharing resources
b. Making the
security policy changes effective
i.
Security
policies normally take 8 hours to propagate.
ii.
Restarting
the computer or running secedit /refreshpolicy machine_policy at the command prompt will
speed the process up.
c. Auditing
Active Directory objects
i.
Objects and
security can be monitored for use of certain permissions, such as a user or administrator
who uses permissions associated with full control.
ii.
In some
situations, it may be necessary to increase that configuration down to the Read level.
d. Auditing
files, folders, and printers
i.
Same as
auditing Active Directory, with the monitoring being done on files and printer on the
local system instead of the domain controller
e. Best
practices
i.
“Logon
Logoff failure” helps catch instances of passwords being guessed at, as well as
providing a record of who was on the network and when.
ii.
Auditing
successful events such as user and group management helps track misuses of privileges.
iii.
“Success
or Failure” of access to files, folders, and “read/write access” helps
track suspected users who attempt to access secure data.
iv.
Success/failure
audit for printer management helps track attempts to change network printers.
v.
Auditing
success/failure of process-tracking events helps track attacks from virus programs.
II.
Monitoring
and analyzing security events
With a proper
auditing process configured, half the battle is done. However, the process of analyzing
and interpreting that data is much more important and time consuming.
A. Events to
monitor
1. All events
should not be monitored or audited; there are simply too many possible variables.
2. All
mission-critical or highly secure data should be monitored at the appropriate level.
a. Not every
item should not be audited for “read,” but may need to be monitored for
“write,” or “full control.”
b. All use of
administrative authority should be audited and monitored to ensure proper accountability
from administrators.
B. The security
event log
1. Stores all
security events as well as all audited data.
2. By default,
only administrators have permission to view security events, while the application and
system logs are available to all users.
3. Locating
events in the security log
a. When a large
amount of data is being collected by the security log, two methods exist for sorting out
the data relevant to your query.
i.
Find: The
Find option allows for all events to be searched for information matching a certain
criteria in a certain field, such as a certain event number or a certain data.
ii.
Filtering
Events: Similar to Find, except it will only show items that meet a certain criteria.
Basically, filtering is less specific than Find, but may take a little more time to
discover what you’re looking for.
b. Filtering
should be used to see a complete picture of what is going on, while Find should be used to
locate a specific event.
4. Security log
settings
a. Logs can fill
quickly when monitoring a large number of events. Configuring the logs properly will
prevent the needed data from being lost due to full logs.
5. Archiving
security logs
a. As mentioned
above, the data collected will eventually run out of space if not dealt with. Data in log
files can either be written over or saved to allow for access at a later time.
6. Clearing
security logs
a. When logs
have been reviewed and nothing in them seems worth keeping, they can simply be discarded.
C. Interpreting
security events
1. Data that
shows up in the security log is directly related to auditing that was configured by the
administrator. This means data shown on each server will not always be consistent, but the
use and configuration of the files should be.
2. Use online
resources to help interpret security events that are uncommon.
a. TechNet
b. Resource Kit
c. Microsoft
Direct Access Support
3. Use
information provided in the logs to determine what needs to be monitored more often and
what should be monitored less.
D. Events with
similar IDs
1. Details of
all events need to be closely monitored, as there are a number of instances in which
events may have the same event ID or very similar descriptions and actually be related to
completely separate events.
2. Normally, the
event ID will not provide the most relevant information.
3. Use the
description and the detail to search Microsoft’s support databases, as the use of
event ID will not produce as many relevant hits.