|
Executive Summary: Microsoft System Center Operations Manager 2007 includes a feature called Audit Collection Services (ACS). ACS is a reporting tool, based on SQL Server Reporting Services, which simplifies the task of collecting and auditing security event log events on multiple Windows systems by gathering events from systems in your network and consolidating them in one location for reporting. ACS provides a number of useful reports, accessible through a Web browser, on security event types including access violations, account management events, forensic reports, planning, system integrity, and usage. |
Security event-log auditing is an important compliance tool for Windows administrators because the log contains an audit trail of security-related events that occurred on a system. Ordinarily, to seek proof of compliance, an auditor might need to search through the logs from multiple systems, which can be a time-consuming, error-prone job. Microsoft Systems Center Operations Manager 2007’s Audit Collection Services (ACS) feature simplifies the task of collecting and auditing security events on multiple Windows systems, by gathering security-log events from systems in your network and consolidating them in a centralized location. We’ll look at how to plan for, set up, and configure ACS in Operations Manager 2007, then explore how to use it for Security event-log auditing.
Planning Your ACS Deployment
Before you set up and configure ACS, you’ll need to spend some time planning for the deployment. ACS requires Operations Manager 2007 to be already deployed in your organization, and ACS can be installed only on a server running Operations Manager 2007. ACS uses Operations Manager to configure the audit-collection agent on managed servers and workstations. The client-side agent, called the ACS forwarder, is included in the Operations Manager agent but is disabled by default. The server component of ACS, called the ACS collector, is responsible for collecting events from ACS forwarders and storing them in a database. You can install more than one ACS collector for fault-tolerance and scalability. You can also configure ACS forwarders to send events to one collector and fail over to another, if required. Finally, you need an ACS database, which must be Microsoft SQL Server 2005 SP1 or later, and you’ll need SQL Server Reporting Services (SSRS).
You’ll need to ensure that each ACS server you use has plenty of memory and processing power, at minimum 2GB of RAM and a 2GHz processor. Each Operations Manager server with the ACS collector installed can support up to 150 domain controllers (DCs); 3,000 member servers; or 20,000 workstations or combination of DCs, member servers, and workstations, each with an ACS forwarder configured and enabled. For most enterprises, this means you’ll need to install ACS on more than one Operations Manager server.
Installing ACS
The first step in installing ACS is to install the ACS collector. You can do so by running SetupOM.exe from your Operations Manager installation disk and selecting Install Audit Collection Server. You should be logged on, as a member of the local Administrators group, to the system on which you’re installing the collector component. If you’ll be using a database on a remote machine to store collected events, the account you’re using should be a member of the local Administrators group on that machine, too, and the Administrators group or the user account should have the sysadmin role on the database server.
The collector installation is wizard based and begins with the Welcome screen. Clicking Next takes you to the License Agreement. If you accept the agreement and click Next, you then see the Database Installation Options screen, where you must choose either Create a new database or Use an existing database. I strongly recommend that, for performance reasons, you choose to create a new database.
You should be aware of another consideration, which is described in the online ACS documentation. If you’re using SQL Server 2005 Standard Edition, SQL Server database transactions will be temporarily paused while ACS runs daily reports. (This doesn’t occur with SQL Server 2005 Enterprise Edition.) This causes events to queue up in the collector for delivery to the database once processing has finished. If the database is shared with Operations Manager, it, too, will be affected by the pause in transactions.
The next step in the wizard prompts you for a data source name, which the collector uses when connecting to the database. The default is OpsMgrAC, and unless you have a compelling technical need to change the data source, I recommend that you accept the default. The next wizard step asks you to select a local database server or remote database server (which is the default). A dedicated remote database is preferable for performance reasons. If you want to use a remote database server, you must specify the database server machine name. If you don’t want to use the default database instance, enter the instance name you want to use. You can also specify the name of the database to be created; the default is OperationsManagerAC.
The next wizard step asks you to specify the authentication mode the collector uses when connecting to the database. The options are Windows authentication (default) and SQL authentication. Whenever possible, you should use Windows authentication for security reasons. If you chose to create a new database, you’ll be asked where to store the database and log files in the next wizard step.
The next step asks you to specify the time of day that database maintenance is performed and the number of days that events will be stored in the database. The defaults are 2:00 A.M. local time each day and 14 days. The next step asks you to select a timestamp format. The default is local time, meaning timestamps will be in the same time zone as the database server. The alternative is Coordinated Universal Time (UTC). If your collector will receive events from forwarders in different time zones, or if you’ll have collectors in different time zones, I recommend that you use UTC, which will probably help you more easily correlate events from different systems.
The next wizard step summarizes the actions that will be performed. Clicking Next begins installation of the collector. During installation, you’ll be prompted for credentials to use to configure the SQL Server database that will store events.
After the collector is installed, the ACS collector service should start to run. Be aware of a known issue that causes the collector service to fail to start, recording an Access denied error in the System event log. (See the Microsoft article at http://support.microsoft.com/?kbid=936579 for more information about this issue.) Although the article provides a specific event ID (4668), I’ve personally seen the same problem cause System event log entries that have other event IDs. The cause of the failure is that the %SystemRoot%\system32\Security\AdtServer\AcsConfig.xml file has the FAT Read-Only attribute set, and the Collector needs to be able to write to the file. You can clear the Read-Only attribute by entering at the command line
attrib -r
Then type
net start adtserver
to start the collector service.
Enabling ACS Forwarders
Once you’ve installed the collector, you need to enable your ACS forwarders, which you do through the Operations Manager 2007 Operations Console. Launch the console, then click the Monitoring button. Expand the Monitoring node, if required, then the Operations Manager node, then the Agent node, and then click Agent Health State. In the center of the Operations Manager console, you’ll see two panes displaying lists of systems. In the right pane, select the systems that you want to enable the forwarders on, then select Enable Audit Collection from the Health Service Tasks under Actions, as Figure 1 shows.
When the Run Task - Enable Audit Collection dialog box opens, click the Override button. In the Override Task Parameters dialog box, select the column New Value for the row CollectorServer. Enter the Fully Qualified Domain Name (FQDN) of your collector server, then click Override. Next, in the Run Task dialog box under Task Credentials, select Other and enter the credentials of a domain user who has administrative privileges on each machine configured as an ACS forwarder. The Run Task dialog box will look something like that in Figure 2. Click Run to begin enabling ACS. The task’s status will be displayed in a Task Status dialog box, as Figure 3 shows.
When you’ve configured and enabled the ACS forwarders, their status will be reflected in the Operations Manager console. If you click the Monitoring button, expand the Monitoring node, expand the Operations Manager node, expand the Agent node, then select Agent Health State, you’ll see the state of each agent deployed to a system. If the state is anything other than Healthy, double-click the entry to find out what the problem is. If a forwarder can’t communicate with a collector, the agent’s state will shift from Healthy to Warning.
Installing Operations Manager Reporting
ACS uses SSRS to provide preconfigured reports. If you haven’t already done so, you’ll need to install Operations Manager 2007 Reporting. To do so, run SetupOM.EXE from your Operations Manager installation disk and select Install Operations Manager 2007 Reporting. There are no special steps to take to install Reporting for ACS, but you should be aware that once Reporting is installed, permissions on the SSRS server will be strengthened for Operations Manager and previously configured reports might no longer be available. For this reason, you should not install Operations Manager 2007 Reporting onto an existing instance of SSRS (e.g., Microsoft Forefront Client Security).
You might encounter a problem when installing Operations Manager 2007 Reporting that causes the installation to fail. This is most likely caused by the installation program being unable to find a DC during installation. (You can find more information about this problem and a hotfix for it in the Microsoft article at http://support.microsoft.com/?kbid=936219.) Note that after the Reports installation wizard is finished, it might take some time for all the Operations Manager reports to be loaded and visible to you.
After you’ve installed Reporting, you need to manually install the ACS reports. Create a folder called C:\Tools\Audit Reports. Copy the ACS folder and its contents from the ReportModels folder on the Operations Manager installation disk to C:\Tools\Audit Reports. Next, copy the ReportingConfig.exe file from the SupportTools folder on the installation disk to the ACS folder on the hard drive. Now, open a command prompt on your collector and change to the folder C:\Tools\Audit Reports\ACS. Run the following command:
UploadAuditReports.cmd
This command takes three arguments. The first is the name of the database server and database instance in the format server\instance. If you’re using the default instance, simply supply the server name. The second argument is the URL of the SSRS server. If you’re using a database instance, append a $ followed by the instance name to the URL. The third and last argument is the name of the ACS folder, for example, UploadAuditReports ACSDB http://ACSDB/ReportServer "C:\TOOLS\AUDIT REPORTS\acs".
You might receive some warnings when you run the command for two files in particular: audit.smdl and audit5.smdl. Ignore these warnings. Once the command has run, open your browser and navigate to http://reportserverurl/Reports. You should find a folder called Audit Reports, which contains several predefined reports. At this point, you need to perform some additional configuration steps.
When viewing the contents of Audit Reports, click the Show Details icon on the toolbar at the upper right of your screen. Scroll down the list of displayed items until you reach Db Audit, and click it. In the Connect using section, select Windows integrated security. At the bottom of the page, click Apply to make the change permanent.
Viewing ACS Reports for Event Log Auditing
Although the Operations Manager Operations Console has a Reporting button, which is used to configure Reporting and view limited information, you view all ACS reports in the browser. Open your browser and navigate to http://reportserverurl/Reports and click the Audit Reports folder.
Standard reports are organized by group and include access violations, account management events, forensic reports, planning, system integrity, and usage, as Figure 4 shows. Some reports will return all relevant data—for example, Access Violation - Unsuccessful Logon Attempts—whereas others require you to enter data such as a username (e.g., Usage - User Logon), as Figure 5 shows. You can specify the dates between which you want event details. Events in reports are generally shown in descending order, with more recent events displayed first. Remember that ACS will keep data for only 14 days by default, unless you changed that setting during installation. Remember also that the Date/Time timestamp for each entry is either the local time of the collector server or UTC, depending on the installation setting you selected.
Optimizing ACS
If you have several collectors, for scalability and fault-tolerance, you might need to visit each one to generate reports when looking for certain activity, for example failed logons and logoffs. You can minimize the number of visits you make to collectors by planning in advance which forwarders will connect to which collectors and by allocating collectors to a group of forwarders. One strategy might be to have all forwarders in a geographic location or Active Directory site and use only collectors dedicated to that group, reducing the likelihood that you’ll need to access reports on remote collectors.
One detail you should be aware of is that forwarders work in idempotent mode. If a forwarder doesn’t receive confirmation that its events have been recorded by a collector, it will resend the events to a failover collector, if one was configured. (Unfortunately, you can’t trace which events are resent; you need to manually inspect each and determine which are duplicates.) This means that the same event could be recorded by more than one collector. A forwarder might fail to receive confirmation for a number of reasons, such as collector failure or network problems. By locating your collectors near your forwarders, you can make it less likely that network issues will cause events to be recorded more than once, based on the assumption that local networks are more reliable than long-distance links.
Going Forward with ACS
ACS is extremely flexible, and you can configure it further to optimize it. Consult the Operations Manager online help for more information about ACS configuration settings. I also recommend you visit the Microsoft Management Team’s Blog at blogs.technet.com/smsandmom/archive/tags/ACS/default.aspx for the latest information about ACS, including sizing information. Once you start using ACS, you’ll appreciate how much easier it will make the task of managing and reporting Security event-log data.