SANS Institute: Automated Auditing in a Windows 2000 Environment

Introduction

Auditing is often overlooked as a vital tool to prevent system intrusion and compromise. Just as specific security measures are suspect without a security policy providing the underlying structure and control, a security policy itself it suspect without a methodology to audit that policy for compliance.

The audit policy is actually considered part of the security policy. It can be defined as the set of tests that ensure that the security rules laid out in the security policy are actually being put in place. Moreover, the audit policy should contain the consequences of not adhering to the security policy.

It is impossible to enforce a security policy without managerial controls, operational controls and technical controls. Table 1 summarizes these controls. These controls can end up being implemented using a variety of methodologies, including written policy, training and technical tools.

Table 1 - Security Controls

The audit policy, being a subset of the security policy, follows the same guidelines. A policy can be written, but to actually use it, the controls must be implemented in some form. A control does not need to be computer-based in nature in order to fulfill this requirement.

The implementation of a control to audit social engineering may be to log suspicious activity in some type of logbook. While this is not an automated procedure, this information could be vital to detect and stop social engineering. Moreover, when checking the effectiveness of the anti-social engineering controls, management may choose to order a penetration test using social engineering. The logbook would act as the audit to ensure that the Help Desk personnel acted responsibly during the test.

Therefore, the purposes of an audit policy are to:

• Provide a record of activities to assist in possible prosecution
• Monitor the compliance with the security policy

Environment

Windows 2000 was designed to be backward compatible. In the Microsoft world that means connectivity and ease of use are emphasized and security is de-emphasized. Out of the box, the Windows 2000 operating system has a number of security holes that need to be closed up for safe operations.

Additionally, as new security features and hotfixes are added to combat newly discovered vulnerabilities, these too need to be put into place. Overall, keeping desktop and server operating systems configured securely takes a lot of time and effort as well as expertise. While most security groups can outline the proper technical controls to secure systems, it is up to the operations group to put these controls into place.

Wherever possible, it is best to enforce security policy using technical controls, such as those built into modern operating systems, such as identification (who you are), authentication (proof that this is really you) and authorization (what you are allowed to do.) However, in many large organizations, those responsible for operations make operating system security a priority.

Operations personnel tend to be driven reactively by the needs of the end users. As a result, these people may lack the time to learn about and configure the systems in a secure manner. This is compounded by the territoriality of computer personnel in general and the egos that inevitably come into play. This is made worse by the fact that most internal desktops, domain controllers and file servers are overseen by more junior personnel. The prevailing "wisdom" is that internal machines are protected by the firewall.

Differences in corporate culture and turf wars can prevent those responsible for system security from directly implementing anything stronger than a written security policy. Though upper management will enforce this security policy, there often needs to be proof that the systems are not in compliance before management will move on it. Additionally, after being repeated embarrassed by audit reports showing non-compliance, even the most egocentric certification holders will eventually toe the line.

Auditing systems by hand is extremely time consuming. It may prove impossible to get access to the systems because of territoriality. Lastly, it provides a personal reason to dislike the individual doing the auditing. In such situations, an automated auditing tool can sometimes provide the impetus for compliance. While the operations staff may not like seeing the audit failure reports coming from their managers, they won't be able to vent their spleen on the hapless security administrators!

The environment in which this auditing system is intended to be implemented in has a number of autonomous business groups with their own internal IT departments. Each of these business groups has their own Windows 2000 domain or domains. The internal groups have complete control over their domains.

The organization has implemented a single Active Directory, run by a central group. This central group runs the Active Directory and is responsible for

• Managing the Forest Root
• Managing the Active Directory Schema
• Active Directory replication topology and operations
• Management of Active Directory objects related to replication (i.e., site, site-link, subnet)
• Authorization of DHCP servers
• Creation of new domains
• Security policy for the Windows 2000 infrastructure

The central group falls under the same management structure as the group providing Internet connectivity.

Security Policy Subset

The following is the subset of the security policy that is audited by the auditing subsystem. There are several possible ways to implement this policy. Implementation of the policy is outside the scope of this discussion.

This policy was based on recommendations from the National Security Agency (NSA). Changes were made to these recommendations wherever it was deemed that the NSA guidelines would impact systems operations or where additional security was indicated.

Rather than echoing a clear and concise document, read the original paper, Guide to Securing Microsoft Windows 2000 Group Policy: Security Configuration Tool Set, available at: http://nsa2.www.conxion.com/win2k/download.htm
Changes from the NSA recommendations are discussed below.

• A single cached logon is allowed on workstations only. This allows users to work locally without a local account if no domain controller can be contacted. Note that this is not foolproof, but it should reduce the user frustration level. If an administrative user must log on to a workstation, he or she should use a user level account and use the RUNAS command to perform administrative functions. If an administrative account is ever used at a local machine, the administrator must log out and log back in as a regular user (and then log out again) before leaving the machine in order to clear the cache of the administrative logon.
• Users are allowed to install printer drivers on workstations only. This is an accepted risk to allow ease of use.
• Workstations will not be set to crash if the security log is full. This is an accepted risk to allow ease of use.
• Workstation application, security and system logs are set to 2 GB and are overwritten if necessary after seven days. This is an accepted risk to allow ease of use.
• On domain controllers the following groups are restricted, i.e. can have no members:
  • Account Operators
  • Backup Operators
  • Guests
  • Pre-Windows 2000 Compatible Access
  • Print Operators
  • Server Operators
• This was done because with the advent of Active Directory, delegation of authority is far more granular than the far-reaching rights of these built-in groups.
• Table 2 lists the services restricted. Restricted services are set to:
  • Startup of the service is Disabled
  • DACL (permissions):
    • Authenticated Users - Allow Read
    • Everyone - Deny Change Permissions, Deny Take Ownership, Deny Start, Deny Stop, Deny Pause
  • SACL (Audit):
    • Everyone - Failed Start, Failed Change Permissions and Failed Take Ownership
• Table 3 explains the reasoning behind the service restrictions.

Table 2 - Restricted Services

Table 3 - Rationale for Service Restrictions

In order to allow the auditing system to operate properly and securely, several additional requirements were added to the security policy.

• The Windows 2000 Task Scheduler will be configured to startup automatically as the Local System account.
• Each machine must set the %MACHINEROLE% environmental variable to indicate whether the machine is a:
  • workstation
  • server
  • dc (i.e., domain controller)
• Each machine must have file sharing enabled, though users must be blocked from being able to share files or change the ACLs on file shares. These file shares will only be used for administrative purposes.

Auditing System Architecture

The auditing system is made up of four components. The first component, the Audit Setup subsystem, performs the initial setup of the Local Audit subsystem on each machine. The Audit Setup subsystem runs as a Site Group Policy startup script. The second component, the Local Audit subsystem, runs on the local machine and generates the raw audit data. The third component, the Audit Collection subsystem, runs on the audit server and collects the raw audit data from all of the audited machines. The final component, the Audit Report subsystem, runs on the audit server and generates Summary Reports and machine-specific Exception Reports. Figure 1 shows the auditing system architecture.

Figure 1 - Auditing System Architecture

Tools Utilized in the Audit System

Four tools were used to create this system. Batch files, PERL and the Microsoft Security Configuration and Analysis command line tool (SECEDIT.EXE) and the SUBINACL.EXE tool. The PERL engine used was ActivePerl, PERL version 5.005_03. ActivePerl and the SUBINACL.EXE tool are included on the Windows 2000 Resource Kit CD. No complex PERL modules were used, so any PERL engine should work.

Environmentally specific values such as file paths and environmental variables were passed to the PERL scripts as command line variables. Similarly, the PERL scripts communicated their results to the batch files by creating text files, for which the batch files could check existence. The PERL scripts also wrote batch files, which could be in turn executed by the batch file that executed the PERL script. No operating system specific commands were used with the PERL scripts.

The Microsoft Security Configuration and Analysis command line tool, SECEDIT.EXE, performs the bulk of the data collection. This tool is part of the Windows 2000 default installation. It is present on all workstations and servers.

Using the SECEDIT Command Line Tool

The SECEDIT command line tool is a powerful security analysis and configuration tool that is part of the default installation of Windows 2000. The SECEDIT tool is the command line version of the Microsoft Security Configuration and Analysis MMC snap-in. The Audit System only makes use of the analysis functionality of the tool. The SECEDIT tool has several requirements/limitations:

• The tool can not be run against a remote machine.
• The tool requires an analysis (or configuration) template
• The tool requires a database with the analysis (or configuration) template loaded into the database.

These requirements present some difficulties in using the tool in a distributed environment. The Audit System solves these problems as described in the following sections.

In order to create the template and the database, the Security Configuration and Analysis MMC snap-in is used. The base templates were obtained from NSA, who in turn based theirs on the templates Microsoft ships with Windows 2000. The NSA templates are available at: http://nsa2.www.conxion.com/win2k/download.htm

Once the proper template and database files are created, it is easy to use the SECEDIT tool. The format of the SECEDIT tool in analysis mode is:

SECEDIT /ANALYZE /DB databse.sdb /CFG template.inf" /LOG outputfile.txt /VERBOSE

Where database.sdb is the database file, template.inf is the template file and outputfile.txt is the output of the tool. Keep in mind that this tool must be executed on the local workstation.

Data Formats

This system deals with files in several different formats. The preferred format is unformatted ANSI text. The SECEDIT.EXE tool outputs text data in Unicode. The Local Audit Script converts the input data from Unicode into ANSI text before it is used elsewhere. The report files are HTML-encoded ANSI text. This was done to provide a more effective report.

The Report Definition file, which provides user-friendly messages for the Exception Reports, is an ANSI text file with two fields. The first field is the raw exception report that will match the raw input data. The first field must only contain lowercase. The second field contains the user friendly report data formatted in HTML. The two fields are separated using the pattern "tab" "pipe" "tab". The "pipe" character, |, is also known as the "bar" character. This was done for readability in the Report Definition file. Table 4 summarizes the data files and their formats.

Data files are named on the local system using the NetBIOS name, which is represented by the %COMPUTERNAME% environmental variable. In order to prevent name collisions, the audit data files, machine-tracking files and audit exception reports on the Audit Server are named using Fully Qualified Domain Names (FQDN), i.e., DNS names.

Table 4 - Data Files

Bandwidth Considerations

Since this system is initially rolled out using a script that is run per Active Directory Site, the scripts could be easily tailored to use a local server to store the Audit Setup and Audit Collection scripts and support files. However, this should not be necessary in most circumstances. The system has been designed to minimize the impact of file copying across slow network links.

The auditing system only updates client scripts and support files if necessary. Therefore, it is unlikely that there will be a major impact on end users except for the very first time the machine starts up after the auditing system is rolled out or updated. Additionally, the files most likely to change, the audit template files, are checked and updated during the Audit Collection process. This process occurs in the background at 5:00 AM and should not impact end users.

The Audit Setup Subsystem

A site policy startup script (site.cmd) initiates the Audit Setup Subsystem upon machine start up. This script is the only thing being controlled by the Site Policy. Site Policies are controlled by the central group and are not used for anything else, so as not to violate the autonomy of the business units.    

The site policy startup script first creates the directory to house the Audit Collection subsystem. Next it checks for the existence of the files necessary for the Audit Setup subsystem. If these files are not present, the script will copy them from the Audit Server. At this point, the script will set the attributes and/or Access Control Lists (ACLs) on the directory and all the related files to keep the end users from interfering with the Audit Collection process. The directories created will have the Read Only, System and Hidden attributes set. All the files in the directories will have the rights shown in Table 5.

On the Audit Server, the Audit Collection subsystem is run under an account with membership in the AuditCollect group in the domain housing the Audit Server. This allows the Audit Collection subsystem to centrally collect the raw audit files in a controlled manner.

Table 5 - Access Control Entries on Local Audit Files

Since the Local System account will be running both the Group Policy engine and the Windows 2000 Task Scheduler, these ACLs should not interfere. The Windows 2000 Task Scheduler service always runs as the Local System account. The new Scheduled Tasks GUI interface allows certain tasks to run under other accounts, but this cannot be configured via the AT command. The Windows 2000 Task Scheduler service on the local machine runs the Local Audit subsystem as the Local System account.

The PERL engine is not available to the end users, only the Local System and it is not on the %PATH%. This was purposely done to prevent any viruses or worms that may infect the machine under the user context from using the scripting engine to cause further damage. In a production system, the executable, PERL.EXE, would also be renamed, but it was left with its default name to make the scripts more understandable. This will not interfere with normal PERL use on the machine. If the machine were being used to run PERL scripts an instance of the PERL scripting engine would have already been elsewhere on the machine and thus will still be available.

Next, the script cleans up any temporary files from any previous iteration of the Audit Setup subsystem. After this task has completed, the Audit Setup subsystem checks to see if the Windows Task Scheduler is configured to run the Local Audit subsystem every night at 4:00 AM. If it is not, the Audit Setup subsystem configures it. The command to run the Local Audit subsystem is:

AT 4:00 /EVERY:M,T,W,Th,F,Sa,Su "C:\AUDIT\HIDDEN\LOCALAUDIT.CMD"

Since file servers and domain controllers are only restarted occasionally, the Audit Collection subsystem is executed by the Windows 2000 Task Scheduler. Therefore, after ensuring that the proper support files and script files are in place, the Audit Setup subsystem checks the configuration of the Windows 2000 Task Scheduler. If the Windows 2000 Task Scheduler is not correctly the Audit Setup subsystem configures it correctly.

The Audit Setup subsystem also creates a hidden share, HIDDEN$ = C:\HIDDEN\AUDIT, to allow the Audit Collection subsystem to collect the data. Having a central system collect the data in this manner requires that file sharing be enabled on the workstations. The use of file shares on workstations solely for administrative use is defined in the security policy. Once the share has been created, a resource kit utility, subinacl.exe, is used to set the ACL on the share so that only the AuditCollect group has any access.

Next, the Audit Collection subsystem creates an update for the machine-tracking file. After completing this task, the Audit Collection subsystem uses the checktracking.pl script to check for a machine-tracking file for the machine on the Audit Server. If there is not one present, it is created. On the audit server, the machine tracking files have a format of FQDN.log, where FQDN is the Fully Qualified Domain Name of the computer. This ensures there will be no name collisions within the Active Directory Forest, since each machine in an Active Directory Forest shares a single DNS namespace and thus must have a unique FQDN. Table 6 summarizes the files used by the Audit Setup subsystem.

Table 6 -Files Used by the Audit Setup Subsystem

The Local Audit Subsystem

Each night at 4:00 AM, the Windows Task Scheduler initiates the Local Audit subsystem by executing localaudit.cmd. This script first cleans up any temporary files from the previous running of the script.

Next the script creates an update for the machine tracking-file. The full machine-tracking file is stored on the audit server and is used to detect if machines are not running the audit scripts regularly and to ensure that the machines have been set up so that the proper audit template is used in auditing. The script writes the NetBIOS name of the computer (%COMPUTERNAME%), the date, the time and the machine role (%MACHINEROLE%) to the machine-tracking update file on the local machine.

As mandated by the security policy, each machine must contain the %MACHINEROLE% environment variable set to declare the role of the system in the Active Directory. Table 7 shows the possible settings. The %MACHINEROLE% variable dictates the audit template and the corresponding Security Configuration and Analysis database the machine will be audited against. If the variable is not set, the system is audited against the most restrictive audit policy (the domain controller audit policy.) Additionally, the machine-tracking file will indicate that the environmental variable is not set and the date. This data is not case sensitive.

Table 7 - %MACHINEROLE% Values

After the machine-tracking file update has been created, the Fully Qualified Domain Name (FQDN) of the computer will be determined and the computer name field in the machine-tracking update file will be replaced with the computer's FQDN. The FQDN is determined by using the output from the IPCONFIG /ALL command. The IPCONFIG /ALL command is run and redirected into a text file. The recordfqdn.pl script reads this text file and uses this information to revise the machine-tracking update file.

At this point the Microsoft Security Configuration and Analysis tool (SECEDIT) will be run in command line mode, writing verbose output to a specified log file. The audit template corresponding to the %MACHINEROLE% will be used. If the %MACHINEROLE% variable is not set, the machine will be audited against the strictest audit template, in this case, the domain controller audit template.

Once the Microsoft Security Configuration and Analysis tool has completed, a PERL script will run. This script (localaudit.pl) will convert the data from Unicode to ANSI and add the FQDN and the %SYSTEMROOT% and %SYSTEMDRIVE% variables to the beginning of the data file. The script will then write out the pre-processed audit data to a filename with the format yyyy-mm-dd-FQDN.raw, where:

• yyyy is the year.
• mm is the month
• dd is the day of the month
• FQDN is the fully qualified domain name of the machine (i.e., ws.realm.org)

This format will be preserved when the data is later copied to the Audit Server. The format prevents name collisions between computers in the enterprise, since the FQDN is a unique computer identifier within an Active Directory forest. The FQDN is also well known and understood by humans. The format also allows audit files from machines to sort together by date if being viewed in Windows Explorer. This can also prove useful. Table 8 summarizes the files used by the Local Audit subsystem.

Table 8 - Files Used by the Local Audit Subsystem

The Audit Collection Subsystem

Each day at 5:00 AM, the Windows Task Scheduler runs the Audit Collection subsystem on the Audit Server. The collect.cmd script controls the Audit Collection subsystem. The Windows 2000 Task Scheduler runs the Audit Collection subsystem as a user that is a member of the AuditCollect global security group in the domain where the Audit Server is housed. If this is not the case, the Audit Collection subsystem will not be able to collect any data files.

The first task of the collect.cmd script is to clean up the dynamically created data collection script from the previous iteration of the Audit Collect process. After this has been done, the collect.pl script is executed.

The collect.pl script builds a batch file, getdata.cmd, which will actually collect all the audit data. This methodology was used to avoid use the system() function in PERL and to keep operating system command out of the PERL scripts wherever possible. The script steps through all the files in the machine-tracking file directory. There is one file in the machine-tracking directory for each machine that has been set up by the Audit Setup subsystem. These files are used to build the machine list, which in turn determines which systems for which the getdata.cmd script will collect data and update the machine-tracking files.

The getdata.cmd script is really a series of commands repeated for each machine with a corresponding entry in the machine-tracking directory. The first commands check the files used by the Local Audit subsystem and if they are not present, replace them and set the proper ACLs on them.

Next, as previously stated, the getdata.cmd script collects the local audit data from each machine with a corresponding entry in the machine-tracking directory. After this is done, a check is made to ensure that the audit file was copied and the machine-tracking file for that machine is updated from the local machine-tracking update file. Both the local audit data and the local machine-tracking update file are created by the Local Audit subsystem.

After the getdata.cmd script is created, the collect.pl script returns control to collect.cmd. This script then executes the getdata.cmd script. Any errors not internally redirected are placed into a single log file, COLLECT-ERRORS.LOG in the AUDITLOGS share of the audit server. Table 9 summarizes the files used by the Audit Collection subsystem.

Table 9 - Files Used by the Audit Collection Subsystem

The Audit Report Subsystem

The Audit Report subsystem runs on the audit server, once per day. It is controlled by the Windows 2000 Task Scheduler and runs at 8:00 AM daily. The Audit Report subsystem uses three sources of data. The first source is the machine-tracking files. This information is used to:

• Discover which machines should have run an audit
• Discover if these machines did and if not, when the last valid audit was completed
• Discover if these machines had the %MACHINEROLE% variable set to a valid value at the time the Local Audit process ran on them
• Determine which machines to examine for detailed exceptions to the audit policy

The second source of data is the actual machine-specific audit data. This data is generated by the Local Audit subsystem and moved to the Audit Server by the Audit Collection subsystem. This information is used to determine if a particular machine has any exceptions to the audit policy

The final source of information is the Report Definition file. This file is maintained on the Audit Server. It contains all the audit exceptions that can be reported by the SECEDIT utility and friendly error messages for these audit exceptions. This file is developed from the audit templates (audit_*.inf) generated by the Microsoft Security Configuration and Analysis tool.

Each line in an audit template file corresponds to the unique part of the error message in the verbose output from the SECEDIT tool. For example, the audit template file contains the following line:
MaximumPasswordAge = 90

The output from the SECEDIT utility contains the following corresponding line:
Mismatch - MaximumPasswordAge.

The Report Definitions file contains the common error definition and a friendly error message. Here is the corresponding line from the Report Definitions file:
maximumpasswordage    |    <li><b>Maximum password age</b> is incorrectly set<p>

The first field in the "unfriendly" or raw error message. The second field is the friendly error message. Note that the error message looks better when viewed in a web browser, as the audit reports are design to be viewed. The two fields are separated by a tab-pip-tab sequence for readability when working on the Report Definition file.

The Audit Report subsystem produces at least one output, the Summary Report. There may also be one or more Exception Reports. Exception Reports are per machine and are only generated if:

• The local audit ran successfully that day and the data was successfully moved to the audit server
• The machine was not in compliance with all the items in the audit template

The Summary Report shows:

• For machines that have successfully completed the audit process:
  • Whether or not the %MACHINEROLE% was configured properly at the time of the Local Audit
  • Whether or not the machine had any exceptions to the audit policy. If this is the case, a hyperlink to the Exception Report for that machine will be provided.
• For machines that have been set up by the Site Group Policy setup script:
  • The last time the audit was successfully completed
  • Whether or not the %MACHINEROLE% was configured properly at the time of that audit

The Summary Report also shows how long it took to execute the Summary Report and any associated Exception Reports. Figure 2 shows an example of a Summary Report.

Figure 2 - Summary Report

An Exception Report contains friendly error messages for each exception generated by the SECEDIT tool. These audit exceptions are grouped into subsections that correspond to the subsections in the Microsoft Security Configuration and Analysis Tool:

• Account Policies
• Audit Policy
• User Rights Assignment
• Security Options (Registry Settings)
• Event Log Settings
• Restricted Groups
• System Services
• Registry Permissions
• File System Permissions

Figure 3 and Figure 4 show an Exception Report. Table 10 summarizes the files used in the Audit Report Subsystem.

Table 10 - Files Used by the Audit Report Subsystem

Figure 3 - Exception Report (Part I)

Figure 4 - Exception Report (Part II)

Implementation Details

This system will deploy to the workstations, collect audit data and produce audit reports automatically. However, in order to do this a number of tasks must first be completed. These tasks are grouped into the following categories.

• Create audit templates and corresponding analysis databases
• Configure Audit Server
• Configure Site Group Policy

Create the Template and Database Files for Use with the SECEDIT Tool

1) Download the NSA templates and recommendations from: http://nsa2.www.conxion.com/win2k/download.htm

a) Make sure to obtain the following:

i) sceregvl2.inf

ii) W2K Server.inf

iii) W2K Workstation.inf

iv) Guide to Securing Microsoft Windows 2000 Group Policy: Security Configuration Tool Set

2) Read the recommendations: Guide to Securing Microsoft Windows 2000 Group Policy: Security Configuration Tool Set

3) Make backup copies of the NSA templates to make local changes. This retains the original templates untouched for future reference.

COPY "W2K Server.inf " audit_server.inf
COPY "W2K Server.inf " audit_dc.inf
COPY "W2K Workstation.inf " audit_ workstation.inf

4) Copy the NSA templates and the audit system templates into the %SYSTEMROOT%\security\templates directory.

5) Rename the original %SYSTEMROOT%\inf\ sceregvl.inf file:
REN %SYSTEMROOT%\inf\ sceregvl.inf %SYSTEMROOT%\inf\ sceregvl.inf.old

6) Copy the NSA Security Configuration and Analysis update file to the %SYSTEMROOT%\inf directory renaming it to the name of the original file.

COPY sceregvl2.inf %SYSTEMROOT%\inf\ sceregvl.inf

7) Refresh the SCECLI.DLL settings. This adds some new items to the Security Configuration and Analysis interface.

REGSVR32 SCECLI.DLL

8) Set up a custom Microsoft Management Console for working with this system.

a) Click Start->Run, type mmc and press Enter.

b) Select Add/Remove Snap-in from the Console menu.

c) Click the Add button on the Add/Remove Snap-in window.

d) Select Security Configuration and Analysis from the Add Standalone Snap-in window and press the Add button one time.

e) Select Security Templates from the Add Standalone Snap-in window and press the Add button one time.

f) Press the Close button on the Add Standalone Snap-in window.

g) Press the OK button on the Add/Remove Snap-in window.

h) The MMC should look similar to Figure 5.

Figure 5

i) Select Save from the Console menu and save the MMC as Audit Template Configuration. By default this saves it in the current user’s Administrative Tools menu. This is a good place.

j) Open each of the audit_* templates and customize them to suit the security policy. The audit reports will be based off the settings in the templates. Figure 6 shows the audit_workstation template being updated.

Figure 6

k) Once any changes have been made, highlight the template name in the left-hand window of the Audit Template Configuration MMC and select Save from the Action menu.

l) Repeat this on any other templates that have been updated.

m) Do not close the Audit Template Configuration MMC.

9) Create the databases.

a) Click on Security Configuration and Analysis in the left-hand window.

b) Figure 7 shows the screen that comes up if no database has been defined. This should be the case since this MMC was just created.

Figure 7

c) Following the directions on the screen:

i) Right-click on Security Configuration and Analysis in the left-hand window.

ii) Choose Open Database.

iii) Type in a new database name (audit_dc.sdb, audit_server.sdb or audit_workstation.sdb) and click the Open button as shown in Figure 8.

Figure 8

iv) In order to create databases for use with the Audit System, select the security template that corresponds with the database name as shown in Table 11 when prompted to Import Template. See Figure 9.

Table 11 - Database and Template Names for the Audit System

Figure 9

v) Repeat these steps until the three databases listed in Table 11 have been created.

10) Close the Audit Template Configuration MMC. If a message similar to Figure 10 comes up, the click Yes and recreate the corresponding database. The best way to do this is to delete the database file and then go through the preceding steps to recreate the database.

Figure 10

11) The templates end up stored in:

%SYSTEMROOT%\security\templates.

12) The databases end up stored in:

%SYSTEMDRIVE%\Documents and Settings\%USERNAME%\My Documents\Security\Database

Copy the most restrictive template and database to the template and database that will be used when there is no %MACHINEROLE% on the system.

COPY audit_dc.sdb audit_.sdb

COPY audit_dc.inf audit_.inf

Audit Server Setup

The next task is to set up the Audit Server. It involves creating a user and a group under which to run the Audit Collection and Audit Report subsystems as well as the ability to access the audit data files. Next the proper shares must be created and the permissions set. After this, the audit system files must be placed in the proper locations. Lastly, the Windows 2000 Task Scheduler on the Audit Server must be configured to run the Audit Collection and Audit Report subsystems at the proper times as the proper user.

1) Create the user and group for running the Windows 2000 Task Scheduler on the audit server.

a) Click Start->Run->Administrative Tools->Active Directory Users and Computers.

b) Double-click the domain containing the Audit Server from the right-hand window.

c) Click the users folder (or any organizational unit that would hold the proper user for this task.)

d) Create a user named Auditor with a strong password.

i) Do not allow the user to change the password or allow the password to expire.

Automatic expiration of service accounts usually severely impacts the system. These passwords should still be changed, but this should be done manually and then tested using a Standard Operating Procedure on a regular basis.

e) Create a global security group called AuditCollect. Make the user Auditor the only member. Members of this group will be able to access the HIDDEN$ shares on the machines and view and/or alter audit data. Members of this group will also be able to alter the audit data, scripts, reports and support files on the Audit Server.

f) Create a global security group called AuditReports. Place any one who should be able to view all the audit reports in this group.

2) Create the file structure and place the files for the Audit System in the proper places.

a) Create the following file structure, where E: is not the system or boot partition.

E:\
+- AUDIT
   +--auditlogs
       +---machinelist
   +---auditreports
   +---auditscripts

b) Place the Audit System files in the proper locations as indicated in Table 12.

Location	File
E:\AUDIT\auditscripts	y-with-crlf.txt
	audit_.inf
	audit_dc.inf
	audit_server.inf
	audit_workstation.inf
	localaudit.cmd
	localaudit.pl
	recordfqdn.pl
	attest.pl
	PerlCRT.dll
	perlcore.dll
	perl.exe
	subinacl.exe
	checktracking.pl
	auditreport.cmd
	audit_workstation.sdb
	audit_dc.sdb
	audit_server.sdb
	audit_.sdb
	auditreport.pl
	auditreport.cmd
	reportdefinitions.txt
	collect.pl
	collect.cmd

Table 12 - Audit System File Locations on the Audit Server

c) Remove the ACLs for Everyone on these files and directories. This can be done by simply unchecking the "Allow inheritable permissions from parent to propagate to this object" checkbox on the Security properties page for the E:\AUDIT directory.

d) Grant Full Control to the AuditCollect group on the E:\AUDIT directory. This will automatically propagate downwards. These rights should also be granted to any other group whose members may be performing maintenance and troubleshooting of the Audit System.

e) Grant Read permissions to the AuditReports group on the E:\AUDIT\auditreports directory.

3) Create the shares used for the Audit System.

a) Create shares and assign share permissions as outlined in Table 13.

Share Name	Path	Permissions
Auditlogs	E:\AUDIT\auditlogs	Audit_server_domain\AuditCollect: Full Control
Auditscripts	E:\AUDIT\auditscripts	Everyone: Read Audit_server_domain\AuditCollect: Full Control
Auditreports	E:\AUDIT\auditreports	Audit_server_domain\AuditReports: Read Audit_server_domain\AuditCollect: Full Control

Table 13 – Shares on the Audit Server Used by the Audit System

4) Configure the Windows 2000 Task Scheduler to execute the Audit Collection subsystem.

a) Click on Start->Control Panel

b) Double-click the Scheduled Tasks applet as shown in Figure 11.

Figure 11

c) Double-click the Scheduled Tasks applet and the Scheduled Tasks applet will start as shown in Figure 12.

Figure 12

d) Click Next as shown in Figure 13.

Figure 13

e) Click the Browse button as shown in Figure 14.

Figure 14

f) Browse to the E:\AUDIT\auditscripts directory and choose collect.cmd as shown in Figure 15.

g) Click Open.

Figure 15

h) Enter Audit Collection Subsystem in the task name field and select the Daily radio button as shown in Figure 16.

i) Click Next.

Figure 16

j) Set the Start Time for 5:00 AM and accept the rest of the defaults on this page as shown in Figure 17.

k) Click Next.

Figure 17

l) Place the Audit_server_domain\Auditor in the user name field and place the correct password in the password and confirmation fields as shown in Figure 18.

m) Click Next.

Figure 18

n) Click the Finish button as shown in Figure 19.

Figure 19

5) The settings for the Audit Collection and Audit Report subsystems are contained in Table 14.

Setting	Audit Collection Subsystem	Audit Report Subsystem
Program to Schedule	collect.cmd	auditreport.cmd
Task Name	Audit Collection Subsystem	Audit Report Subsystem
Perform This Task	Daily	Daily
Start Time	5:00 AM	8:00 AM
User Name	Audit_server_domain\Auditor	Audit_server_domain\Auditor

Table 14 – Task Scheduler Configuration Summary for Audit System Tasks on the Audit Server

6) Configure the Windows 2000 Task Scheduler to execute the Audit Report subsystem.

a) Use the same methodology as discussed above for configuring the Audit Collection subsystem.

b) The settings for the Audit Collection subsystem are contained in Table 14.

Site Group Policy Setup

The Site Group Policy has a single function in the Audit System. It functions as a tool to deliver the Audit System components to the local machine, the Audit Setup subsystem. In order to ensure that the system is properly configured the Audit Setup subsystem runs each time the machine is started, checking the Local Audit system and updating it if necessary.

1) Click Start->Programs->Administrative Tools->AD Sites and Services.

2) Select the Site you want to configure a Group Policy for. In this example, Default-First-Site-Name is used as shown in Figure 20.

Figure 20

3) Select Properties from the Action menu and the properties for the Default-First-Site-Name will be displayed as shown in Figure 21.

Figure 21

4) Click on the Group Policy tab.

5) Click the New button and rename New Group Policy Object to Audit Setup as shown in Figure 22.

Figure 22

6) While Group Policy Object Link labeled Audit Setup is selected, click the Properties button. The Audit Setup Properties will be displayed as shown in Figure 23.

Figure 23

7) Click the "Disable User Configuration settings" checkbox. No user configuration settings are used and this will speed up the processing of the Group Policy object. A confirmation dialog will be presented as shown in Figure 24.

8) Click Yes.

Figure 24

9) Click OK to close the Audit Policy Properties window.

10) While Group Policy Object Link named Audit Setup is selected, click the Edit button. The Group Policy will be displayed as shown in Figure 25.

Figure 25

11) In the left-hand window, under Computer Configuration, double-click Windows Settings.

12) Next, select Scripts as shown in Figure 26.

Figure 26

13) In the right-hand window, select Startup, then choose Properties from the Action menu. The Startup Properties will be displayed as shown in Figure 27.

Figure 27

14) Click on the Show Files button. This will bring up a Windows Explorer window showing the scripts defined for this Group Policy object. There should not be any files in this directory.

15) Copy the site.cmd file into this directory. The easiest way to do this is to open up another instance of Windows Explorer and copy and paste the file into the Group Policy object scripts Window. When this step has been competed, the Group Policy object scripts window should look like Figure 28.

Figure 28

16) Close the Group Policy object scripts window.

17) On the Startup Properties window, click the Add button. The Add a Script dialog will be presented as shown in Figure 29.

Figure 29

18) Click the Browse button and select the site.cmd file as shown in Figure 30.

Figure 30

19) Click the Open button and the site.cmd script will show up in the Add a Script dialog as shown in Figure 31.

Figure 31

20) Click the OK button on the Add a Script dialog. At this point the Startup Properties will show the site.cmd script as shown in Figure 32.

Figure 32

21) Click the OK button on the Startup Properties window.

22) Close the Group Policy window.

23) Click the Close button on the Default-First-Site-Name Properties window.

24) Close the AD Sites and Services window.

File Locations

Table 15 summarizes all the files and file locations in the Audit Subsystem

Table 15 – File Locations of All Audit System Files

Subsystem Executors

Table 16 summarizes all the subsystems, how they are executed and the credentials that they run under.

Table 16 – Subsystem Execution Details

Summary

The Auditing System laid out in this paper will provide a fairly complete level of automated auditing against Windows 2000 systems. It can aid administrators in maintaining properly secured operating systems on server and workstation platforms. This system can be a valuable aid to monitor all the systems in an Active Directory Forest for compliance with technical security controls.

Bibliography

• Haney, Julie, M. Guide to Securing Microsoft Windows 2000 Group Policy: Security Configuration Tool Set. National Security Agency. 2001
• Pierce, Clinton. Sams Teach Yourself Perl in 24 Hours. Sams Publishing. 2000.
• Opitz, David. Guide to Windows 2000 Kerberos Settings. National Security Agency. 2001
• McGovern, Owen R., Haney, Julie, M. Guide to Securing Microsoft Windows 2000 File and Disk Resources. National Security Agency. 2001
• Fossen, Jason. Windows 2000: Active Directory and Group Policy. SANS Institute. 2001.
• Lowe-Norris, Alistair G. Windows 2000 Active Directory.O’Reilly & Associates, Inc. 2000.
• Distributed Perl Documentation (5.005_02): http://www.perl.com/CPAN-local/doc/manual/html/index.html

Author’s Note: A good deal of research went into using Visual Basic or Visual Basic Scripting to assist in gathering the audit data, but due to time restrictions this could not be placed in the final paper. These are all excellent books.

• Esposito, Dino. Windows Script Host Programmer’s Reference. Wrox Press Ltd. 1999.
• Eck, Thomas. Windows NT/2000 ADSI Scripting for System Administration. MTP. 2000.
• Perry, Greg., Hettihewa, Sanjaya. Sams Teach Yourself Visual Basic 6 in 24 Hours. Sams Publishing. 1998.