Understanding the architecture of a product is vital for a customer in deciding if it is a good fit for their organization. Over the years, we've seen debates on whether agent-based or agent-less solutions are a better fit for organizations. A decision needs to be made whether or not the benefits of an agent merit its use.
In my 15+ year tenure at Quest, we have released both agent-based and agent-less Active Directory auditing solutions. I’d like to share why I think our agent-based solution is a ideal fit for auditing.
What are you trying to accomplish?
Many organizations need to audit who did what in their environment. A common request is that they want to be alerted when certain events occur in their environment. While some requirements are geared to meet audit requirements, fundamentally having the information as to what people are doing provides a level of accountability in your organization. The native event logs can provide some information about what a user has done, but to truly understand who did what, you need something beyond what Microsoft provides.
Auditing
Understanding that a change happened is important. Natively you can turn on auditing and view the log if you know where the change happened. This helps when you are asked to know what changes have occurred. However, even if you are just collecting the logs that are natively provided you should be aware of log tampering or rollover of events stored on your computers. A benefit of our agent is that it can make a copy of all the events that have happened in the situation where someone clears the event logs or the logs roll over before the events can be collected.
If you are just dealing with the native event logs, Quest does offer a solution called InTrust that can collect those logs centrally and store them for long-term retention requirements (avoids you having to know on which Domain Controller a change was made, as an example). Surprisingly you may also realize that the use of an agent can improve the performance of your Domain Controllers(Intrust also can use an agent architecture, but can optionally collect logs without an agent). Many people struggle with what to audit so may choose to audit it all. By clicking on Success and Failure for all these Policies (see figure 1) you will capture the native events, but you will also impact the performance on your Domain Controllers as it will take more processing to write these events to the Event Viewer. With Change Auditor we automatically audit the events taking place with additional information and do not rely on the native events. Change Auditor audits and alerts on 16 different platforms from a single console.
Auditing all these native events can generate a LOT of log data.
This is an example of the native audit log of Group Policy Object change.
Unfortunately this doesn’t tell me enough. The Object Name is displayed in its GUID (although a lot of tools can put a friendly name on that piece of data). What is missing here though is exactly what changed. I can see that a change happened, but I have no idea if this change is acceptable or not.
With Change Auditor I can see exactly what has changed. I’m able to see that the “Allow Log On Locally” policy changed and I can see that “lesterarms” was added and where the change originated from. By having this extra information I can determine if this change was acceptable or not. It is only by having our agent architecture that we are able to get the additional information about the changes that natively, you just can’t get.
Group Policy changes aren’t the only changes where our agent can provide additional information. This agent also allows you to see who is added or removed from your member server groups, who is added or removed from a nested group, and even correlating changes made from your on-premise Active Directory to Azure Active Directory.
Alerting
As events occur, Change Auditor sends those events to a Coordinator. Alerts can be configured based on events that have occurred. The right people in your organization are quickly notified when certain events occur.
Our agent-less technologies run on a scheduled basis to collect the logs. Based on the frequency that you are collecting logs, there may be a considerable lapse in time before agent-less technologies can notify you that a specific criteria has been met. Time is extremely important and Change Auditor allows you to be quickly notified when an event occurs.
Another popular scenario that people configure alerts for is the incorrect usage of accounts. If you have a new application in your environment, typically the service account should only be used from a handful of machines. You can configure alerts in Change Auditor so that if an account is ever used from a computer out of its allowed list you can immediately be notified.
This has an alert configured for whenever the GPOAdmin Service account is on an unauthorized computer.
Protection
Another benefit of an agent architecture is that we can add an extra layer of protection to your critical objects. Not only can we intercept events happening and provide you additional information, Quest Change Auditor can prevent changes from happening. Perhaps you want to protect your Default Domain Policy from being modified by users with Domain Admin rights. With Change Auditor you can ensure these changes don’t happen even by those with high privileged accounts.
This is an example of the times you can choose to configure protection of your critical Active Directory objects.
Hopefully you can see the value in having an agent for your auditing needs. Regardless if you have a SIEM solution or not, our tools provide additional information that natively you just can’t get.
If you are still against having an agent but need something to collect your logs centrally, please check out InTrust. If you would like to get additional information beyond what native logs provide, check out Change Auditor.