ACS Forwarders and High Availability - Part 1

If your organization has implemented Audit Collection Services (ACS) then you will already know that there is a “one to one” relationship between an ACS Collector and an ACS Database.  If your organization has requirements for High Availability or you are forced to maintain strict auditing of Security events then you may be asking the question about what happens to your ACS Forwarders when their respective ACS Collector becomes unavailable.

There are 3 possible scenarios that could occur when your ACS Collector becomes unavailable so this will be a 3 part series detailing what happens within each scenario.

Before I dive in to the details of Scenario 1 a little bit of background information is needed:

There is a file called ACSConfig.xml which is located at %systemroot%\system32\security\AdtServer. This file contains some useful information that is needed by the Collector to perform its functions. Some of that information is entries for each Forwarder that has communicated with the Collector along with a Sequence Number. This sequence number corresponds to the EventRecordID of the event on the Forwarder and this is how ACS keeps track of which events have been collected.

This file is updated every 5 minutes by the AdtServer service with information that it has stored in memory.

Scenario #1: One ACS Collector / ACS Database pair

In this scenario, your organization has deployed one ACS Collector along with one ACS Database as that is all that is needed to satisfy the performance and scalability requirements for ACS.  There have also been no additional steps taken to maintain ACS Forwarder availability.

If the ACS Collector were to become unavailable then the ACS Forwarder no longer has anywhere to forward events and the Security Event Log on the Forwarder is basically acting as the queue for the backlog of events.

If you bring the same ACS Collector back online (the previous ACSConfig.xml file is present) AND you are still within your Event Retention Period (default 72 hours) then you will not miss any events.

If you bring a new ACS Collector online and reconfigure the ACS Forwarder or you bring up the old ACS Collector but you are no longer within the Event Retention Period then the ACS Collector will collect the last 72 hours’ worth of events only and carry on from there.

Eric Fitzgerald has written a blog that describes the Event Retention Period with ACS here.

PROS

· No failover configuration is needed as no failover actually occurs

· As long as the original ACS Collector is brought online (or the ACSConfig.xml file is restored) then there is the potential for no loss of data within the Event Retention Period.

· There will be no or minimal duplication of data as long as the original ACSConfig.xml is present on the ACS Collector

CONS

· If the original ACSConfig.xml file is not present then you will get duplication of data that is equivalent to the Event Retention Period.

· Data will be lost if ACS Collector is unavailable for longer than the Event Retention Period

· Your organization becomes vulnerable to a malicious intruder that could potentially manipulate the Security Event Log during the time in which the ACS Collector is unavailable.

In Part 2 of this series, I will discuss the behavior that occurs when you have deployed multiple collectors and database pairings and then rely on the ACS Forwarder to fail over to one of the other available Collector/Database pairings.

In Part 3 of this series, I will discuss how to create a warm standby ACS Collector so that multiple Database installations are not necessary. This is a new feature for Operations Manager SP1.