Audit Active Directory: goals, shortcomings of the staff audit system and ways to overcome them

Dear habrovchane,
We offer you a translation of the book by Don Jones, MVP, an award-winning specialist and simply a very popular author in the United States.

There are three “A” security Active Directory (AD) - authentication, authorization, auditing. In this post, we present a fragment of the translation from the book Don Jones “Active Directory Troubleshooting, Auditing, and Best Practices” dedicated to AD auditing.

The objectives of the standard audit instruments

The purpose of the audit is quite trivial: to track everything that someone does. In the context of AD, this means keeping track of the use of all privileges, such as changing group memberships or unlocking user accounts. It also means that it is necessary to record user actions, such as successful and unsuccessful logins. Let's look more broadly - and for Windows, this means that auditing also includes access to files and folders, as well as changes to file access permissions.

Your goal in auditing may differ from those achieved within the framework of the operating system audit architecture. Remember that the audit system used in Windows - including AD, which is a copy of the file system architecture, came to us from the early 90s, when Windows NT appeared. At the same time, Microsoft could not have imagined that there would be organizations with thousands of file servers, hundreds of domain controllers and thousands of other servers running Exchange, SQL Server, SharePoint and other business platforms. We will consider below that the standard Windows audit tools are not always scalable in large infrastructures or even for medium-sized companies. Maybe you would like every event in the IT infrastructure to be fixed by the audit system, but this can create problems in performance, management and even logistics. Therefore, let's assume that your goal is to audit everything that happens in the IT infrastructure, and see what can be achieved by regular means.
')

Established audit system

Permissions apply to the discretionary access control list (DACL). Each DACL consists of one or more access control elements (ACEs). Each such element contains the permission or prohibition of a specific set of permissions with respect to a user or group. DACL is a part of “authorization” in the three A model: AD authenticates you and gives you a security token containing a unique security identifier (SID). This SID is compared with the ACE in the granular access control list (DACL) to determine what permissions you have when accessing these resources.
Audit works in a similar way. An object access control list (SACL) consists of one or more entries. Each entry indicates a specific action for a particular activity, performed by a user or group. A SACL is bound to a specific resource, such as a file or directory object, and when a particular action is performed on a resource, it is recorded in a log. By default, it is possible to record “success” and / or “failure” actions in the log. This means that you can choose to have a record in the journal when someone successfully used their permissions or when he tried to do it and was denied it. Figure 1 shows the SACL configuration for AD. As you can see, this resource - the domain controllers of the division - is set up so that some types of successful actions of the members of the “Everyone” group are recorded. That is, when someone successfully performs these actions, a journal entry is created.


Figure 1: SACL in AD.

What actions are subject to audit depends on what resources you work with. For example, Figure 2 shows the file system SACL, and you can see that various types of actions are available.


Figure 2: File System SACL.

Here you can choose what is to be audited, for example, creating folders, reading attributes, deleting files and the like. Thus, each resource can have its own SACL. In practice, most of us assign SACLs at a fairly high level of the hierarchy and thus allow these settings to spread to lower level objects through inheritance. Therefore, SACL is managed in a relatively small number of places. But we still need to configure them at least one for each server and for the main system. What does this mean: each server will need its own list of management of access to objects at least in the root of each logical drive, we will need a separate list in the root of AD and so on.
Other products may fall under this scheme. And they may not fall. For example, Exchange Server uses a similar structure for auditing, but SQL Server and SharePoint do not. However, here we consider only AD.
When an action for which an audit is configured occurs, Windows generates an audit record. All such records are stored in the security event log, which is shown in Figure 3. The problem with such a log is that every event gets there. Although it seems to be a good idea to keep all events in one place, the problem is that when it is necessary to extract separate records from it, it becomes problematic. Once again, this is due to the fact that Microsoft has a rather narrow view of the Active Directory audit system.


Fig. 3: Security event log.

Each Windows server has its own security event logs, including domain controllers. Although the access control lists for objects in AD can be configured on any domain controller and subsequently replicated to the others, only the domain controller that processes this action will create a log entry about it. The result: there is a centrally configured audit policy, but audit logs are highly dispersed.
Figure 4 shows how these audit records look like. They often include “raw” security identifiers and other non-obvious information. This example shows successful domain connections processed using the standard Kerberos protocol. The username and domain are empty in this example, but they are usually filled in.


Figure 4: Example of an audit record.

Over time, Microsoft began to solve problems associated with the presence of only one magazine, which contains so much information. In Windows Vista and Windows Server 2008, the parallel event log architecture was introduced, which made it easier to keep your own log for each product or technology. It was always possible - application, system, and security logs were supplemented, for example, with directory service logs. But this new architecture has become more integrated for several reasons. Figure 5 shows the old and new journals.


Fig.5: New and old magazines.

Unlike the Access Control List (DACL), the Object Access Control List (SACL) is not immediately used by the operating system. SACL simply indicates which actions are to be audited; The audit system itself must also be enabled in order for events to be recorded in logs. Figure 6 shows where this is typically configured in a group policy object.
Most organizations will configure auditing in high-level group policy objects, such as those that apply to all domain controllers or even all servers in a domain. The designated group policy object refers to configuring an audit policy, which includes enabling auditing for a login / connection event, account management actions, access to AD, and so on. The audit policy, as well as the SACL resources, must be configured in order to generate the desired audit events.


Fig. 6: Configure auditing in a group policy object.

Here you need to be attentive. I do not think that you want to include an audit of all events, not taking into account the consequences. A domain controller can generate thousands of connection events every minute (for example, when everyone logs on to their computers in the morning), and creating such a number of events requires processing power. If audit of all these events is really needed, then you will need to increase the size of the domain controller in order to cope with the load. The same should be done for file servers: if all events about successful access to files are logged, you need to increase the processing power to cope with the load.
Creating such a number of events can “log” the event log pretty seriously. As shown in Figure 7, you probably want to combine an audit policy with a well-planned event log policy, adjusting the size of the event logs, rollback actions, and other settings to ensure consistency in the workload of the system.


Figure 7: Configuring the event log in a group policy object.

Unlike the application log, with which you can be calm when it is overwritten as it is filled, this cannot be allowed in the security log, since important information may be lost. Therefore, you must set a suitable log size and set up procedures for regular archiving and clearing the log, depending on the load on the log.
What the regular Windows event logs are usually criticized for is that they are heavily dispersed. For example, an administrator can change group memberships on one domain controller, connect to a second domain controller to use an account in this group, and connect to a third controller to reset this group membership. All three events will be recorded in three different security event logs, which complicates the process of establishing the relationship between these events.
The solution that Microsoft offered to this problem in Windows Server 2008 was event log forwarding. Figure 8 shows how individual servers forward events to a central server, which collects all events in its own log.


Fig. 8: Event Log Forwarding.

As indicated, this feature can be configured in group policies, which makes it centrally controlled. This approach still has significant drawbacks, which we will discuss further.
This is how the staff audit system is built. Let's now talk about how organizations want to use this system, and where they need advanced features.

General business objectives for auditing change

Unlike the 90s, when Windows NT was developed, most companies today are subject to certain security policies. In many cases, when the security policy also implies compliance with the requirements of regulations and legislation. These requirements may include the obligation to audit all successful and unsuccessful actions occurring in the IT infrastructure, and generate a significant amount of traffic.
It is also important that those users (including administrators) whose actions are recorded in audit records cannot delete records from the event log. Organizations also want the ability to search, filter, and report on the entries in the event log. For example, the auditor wanted to see an audit record that corresponds to a change in the AD audit policy configuration, and then correlate these events with approved actions. What allows him to see that in AD only those changes that have been agreed and documented. Organizations also need to use in-house audit tools to resolve problems. When something went wrong in the IT infrastructure, the answer to the question: “What has changed?” Allows you to quickly solve the problem - and audit logs should help in finding the answer to this question quickly and efficiently. So what are the drawbacks of in-house audit tools?

Disadvantages of in-house audit tools

Unfortunately, the standard audit system has not proved itself very well. Ultimately, this is not Microsoft’s fault — after all, their job is not to anticipate any business need, but rather to provide a platform on which other companies can develop software that can meet specific business needs. That is what they did. A full-time audit system is a basic solution that is suitable for the smallest organizations that can hardly afford to purchase additional programs.
Objective number 1 - the audit of all events - is definitely feasible with the help of Windows, although it is necessary to take into account the size of the logs and the performance of the server. The standard architecture of the event log is not transparent, as we would like to see it, and the recording of tens of thousands of events per hour will definitely have an impact on the server.
Objective number 2 - the ability to make changes to the log - the bottleneck of the system. Unfortunately, it is almost impossible to exclude the possibility of administrators clearing the log. You can do this by fine-tuning privileges, creating special accounts for working with journals, and so on, but this is difficult and impractical for many organizations.
Suppose you did this. You are faced with the goal number 3 - the centralized generation of reports, alerts and event filtering. Forwarding event logs, even if it occurs, is not carried out in real time, significant delays are possible. But even if you are redirecting the event log, all the information is dumped into one place from where it can be pulled out using the primitive Event Viewer. Figure 9 shows the filtering capabilities of standard tools, and they are, of course, primitive.


Fig.9: In-house event log filtering tools.

As shown in the figure, you can filter by event types or by special text in the event description, as well as by other criteria. But the possibility of establishing the relationship between the various related events is missing.
As for using these events to solve problems - well, good luck! This, of course, is possible, but it usually looks like this: “look at the log, look at what the event identifier means, and determine if this is relevant to the real problem”. It is quite difficult for the regular Event Viewer to answer the question “All changes in AD in the last 4 hours”. Although the log will display the events associated with these changes — you configured an audit policy to capture them — the event log is not intended to perform the task of managing changes or auditing them. This is not an audit of changes in the proper meaning of this term, but an audit of the fact that someone made a change.
As shown in Figure 10, the values ​​of “before” and “after” of each change began to be recorded in AD Windows Server 2008, which makes it more suitable for auditing changes. However, this function is not very common in AD and it is still problematic to find the necessary events in a large journal.


Figure 10: Improved view of events in Windows Server 2008.

In most infrastructures, an effective audit policy involves the use of third-party solutions.

Third Party Opportunities

Tools for third-party auditing have several advantages.
First, they are better (and faster) collecting information from various server logs in a centralized repository. Often, such centralized storage is a SQL server database, although individual tools can send real-time events to an external logging mechanism, such as a syslog server, as shown in Figure 11.


Figure 11: Event forwarding to syslog server

The bottom line is that events from Windows should be retrieved and moved to a separate system as quickly as possible, where they would be protected in a way different from the event log. Databases in this case are quite a popular choice, because they can be protected and can be accessed with complex queries. And of course, with their help, you can generate reports. Therefore, most Active Directory auditing solutions collect events in SQL Server database in order to use report generation capabilities through SQL Server Reporting Services.
Third-party solutions can also use APIs to collect audit information - in addition to (or instead of) regular event logs. These APIs often provide more detailed information, including “before” and “after” values. In some cases, using the API can even reduce the server load.
Using centralized data storage, third-party tools can generate alerts in real time, generate reports, archive event records, analyze data and compare them.