Active Directory Audit and Monitoring

Microsoft SQL Server is a database server. If I need a database server for a project, I can simply spin up a server and install Microsoft SQL Server on it and then use it to store data. In this situation, my requirement is static. As long as I am using the software/service, I need a working database server. But when it comes to cyber security, the requirements are not static – they change very often. There are new bugs and security threats found every day. A security solution we use today may not work well against new threats found in the future. The only possible way to address this challenge is to "continuously improve" the solutions in place. To do this, we can use the following steps as guidelines. These four steps are connected to each other and work as a life cycle rather than one-time process:

1. Identify
2. Protect
3. Detect
4. Respond

Before we come up with a solution, we first need to "...

Auditing and monitoring AD using built-in Windows tools and techniques

Microsoft offers built-in features and tools to monitor and audit AD environments. In this section, we are going to review these features and tools.

Windows Event Viewer

As an engineer, I am sure you are well aware of Windows Event Viewer. It is a built-in tool that can be used to view and filter event logs on a local or remote computer. The events shown there are generated by the operating system, services, server roles, and applications. This is the most commonly used tool in Windows systems for auditing and troubleshooting purposes.

We also can write custom events to event logs. This is useful if you plan to run a script or action based on a particular event ID. This can be done by using the Write-Eventlog cmdlet.

As shown in the following screenshot, Windows Event Viewer (Local) has four different categories to group event logs:

Figure 19.1: Windows Event Viewer

In the preceding list, Windows Logs and Application and Service Logs both have additional predefined subcategories.

Custom Views

Event Viewer allows the creation of Custom Views based on event level, time, log type, source type, event ID, task category, keywords, users, or computers. Event Viewer catches thousands of different events. Using Custom Views, we can filter events and access the information we need. All these custom-made views will be listed under the Custom Views section. It also has predefined custom views.

These predefined custom views are based on the server roles. When AD DS roles are added, it also creates a custom view in the event log to group all the AD DS-related events, as shown in the following screenshot:

Figure 19.2: Windows Event Viewer Role logs

The data that appears in these custom views will also be available on other logs such as Windows Logs.

Windows Logs

The Windows Logs section includes five Windows log files. These mostly contain OS-related events:

• Application log: This log contains the events collected from various applications running on the system. These events can be from Microsoft or any other application.
• Security log: This log includes events such as successful and failed system login attempts. Engineers can specify which security events need to be recorded using audit policies.
• Setup log: This includes events related to application setup and adding/removing server roles.
• System log: This log includes events related to Windows system components. As an example, an event related to an automatic service start failure will be listed under this log.
• Forwarded Events: Using Event Viewer, we can connect to another remote computer and view the events. However, it may be required to watch for specific events from multiple sources. As an example, let's assume we need to collect events...

Applications and Services Logs

The Application and Services Logs category was introduced after Windows Server 2008. This stores the events related to applications and their components. Most of the events listed here are more suited for application developers doing debugging and application-level troubleshooting.

This category has four log types:

• Admin: Events listed in this log are understandable by end users and IT professionals. This information can be used for basic application troubleshooting. Most of these log entries will include instructions or links to knowledge base articles from the application vendor to find out more about the given issue or to fix it.
• Operational: Operational events include information about configuration or status changes of an application/service. These events are useful for application diagnosis.
• Analytic: This log is hidden and disabled by default. This is usually only enabled during the application or service diagnosis process...

Subscriptions

This category lists down the event subscriptions created with remote computers. Here, we can create/edit/disable event subscriptions, check the runtime status, and forcibly run subscription jobs.

When we open up an event, it gives different levels of information, such as the following:

• A general description about the problem
• The log file name
• The event source to indicate where it came from
• The event ID number
• The level of the error (critical, information, or warning)
• The username of the error owner
• Links to TechNet, KB, or other sources to get more information about the event
• The time of the event
• Hostname of the source computer

In the previous section, I explained Applications and Services Logs and the types of data available under it. There are a few different Applications and Services Logs related to the AD service.

AD DS event logs

Apart from the events under the Windows Logs category, AD DS and related service events can be found under the following logs. These are located under the Applications and Services Logs category:

• AD Web Services
• DFS Replication
• Directory Service
• DNS Server
• File Replication Service (only if using FRS)

Apart from events, AD DS and related services have other system log files that record data about service installation/uninstallation, performance, service errors/failures, and so on.

AD DS log files

These log files can be used for auditing, troubleshooting, or debugging purposes.

The default location for these log files is %SystemRoot%\Debug:

• DCPromo.log: This log file is created during the AD promotion process. It also records events during the demotion process. This log contains events such as the following:
  • AD DS configuration settings
  • Information about schema preparation
  • Information about directory partition creation/modifications
  • Information about data replication
  • Service configuration status
  • Information about creating AD databases and the SYSVOL directory
• DCPromoUI.log: This log file can be considered as a progress report for the AD DS promotion/demotion process. It starts the logging process as soon as the AD DS configuration wizard opens, and ends when it completes the installation successfully (until the reboot request is accepted) or when it is aborted due...

AD audit

The only way to identify potential security threats and security breaches in infrastructure is through continuous monitoring and auditing. When it comes to auditing, the Windows system itself provides advanced auditing capabilities to identify such security issues. However, by default, only certain types of actions are audited. These auditing settings are handled by Windows audit policies.

Here, we are only going to look at advanced security audit policies, which were first introduced with Windows Server 2008 R2.

There are 10 categories of events we can audit in a Windows system:

• System events
• Logon/logoff events
• Object access events
• Privilege use events
• Detailed tracking events
• Policy change events
• Account management events
• Directory Service (DS) access events
• Account logon events
• Global object access auditing

Each and every event category also has subcategories.

Legacy Windows auditing...

Demonstration

In this section, let's go ahead and see how we can use built-in Windows monitoring and audit capabilities. In order to do these configurations, you need to have domain administrator or enterprise administrator privileges.

Reviewing events

Event Viewer can simply be opened by running eventvwr.msc. The same MMC can also be used to connect to a remote computer using the Connect to Another Computer... option, as highlighted in the following screenshot:

Figure 19.4: Review events on another computer

We can simplify this by creating server groups in Server Manager. Server groups allow us to group systems running similar server roles or acting as part of a distributed system.

Before we go ahead and create server groups, we need to take note of the following information:

1. We need an account that has administrator privileges for all the member servers to create and use server groups.
2. We must enable Windows Remote Management (WinRM...

Setting up event subscriptions

Event Viewer contains lots of different event entries. There can be several thousand events per day. Even if every event provides some useful information, we do not need to go through each and every one when we are troubleshooting a particular application or performing a service audit. There are specific events relevant to each server role, application, service, and system component.

On some occasions, when we're auditing or troubleshooting, we need to review events on multiple computers. Event Viewer only allows us to connect to one computer at a given time. It can be a local or a remote computer. Event subscriptions allow us to collect event logs from remote computers and review them on one console.

Before we configure event subscriptions, we need to perform the following steps:

1. Enable WinRM.
2. Add a collector computer account to the Event Log Readers group.

Configuration steps for the aforementioned tasks are...

Security event logs from domain controllers

In order to collect security logs from remote domain controllers, we need to add a network service account to the channel access permissions of the security event log.

This is because the WinRM service is running under the network service account. This can be done by running the following code:

wevtutil sl security /ca:'O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)'

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20) contains READ permission settings for network service account (A;;0x1;;;). In the preceding code, the SID value for the network service account is (S-1-5-20), and the channel access value is (O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)). Once all this is done, after a few minutes, we can see the Forwarded Events.

Enabling advanced security audit policies

As we have seen previously, for successful auditing, we need to have a SACL configured for the relevant AD objects. If there is no SACL entry, no events will be generated against that object. In order to configure the SACL, we need Domain Admin or Enterprise Admin privileges. To add a SACL entry, perform the following steps:

1. Open AD Users and Computers.
2. Click on View | Advanced Features.
3. Right-click on the OU or the object that you'd like to enable auditing for. Then click on Properties. In my example, I am using the root container, as I wish to enable it globally.
4. Click on the Security tab and then on Advanced.
5. Click on the Auditing tab and then click on the Add button to add a new security principle to the SACL. In our scenario, I am using Everyone as I'd like to audit everything.
6. For Type, I have selected the Success event type. Also, I've applied it to This object and all descendant...

Enforcing advanced auditing

Before Windows Server 2008, there were nine main auditing categories and subcategories. Those still continue to appear under Windows Server 2022. It is recommended not to mix them up, and only use advanced auditing instead. We can enforce the system to only accept advanced auditing policy settings if legacy audit policy settings are applied to the same category.

This can be done by enabling the Group Policy setting under Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options | Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings.

Reviewing events with PowerShell

We also can use PowerShell commands to review event logs or filter events from local and remote computers without any additional service configurations. Get-EventLog is the primary cmdlet we can use for this task, as shown in the following example:

Get-EventLog -List

The previous command will list the details about the log files in your local system, including the log file name, max log file size, and number of entries.

Get-EventLog -LogName 'Directory Service' | fl

The previous command will list all the events under the Directory Service log file. We can also limit the number of events we need to list. As an example, if we only need to list the latest 5 events from the Directory Service log file, we can use the following command:

Get-EventLog -Newest 5 -LogName 'Directory Service'

We can further filter it down by listing events according to entry type, as shown in the following example:

Get-EventLog...

Microsoft Defender for Identity

In several places in this book, I have talked about why we need the Zero-Trust approach to security. Zero-Trust is not a product or service it is a mindset. We need to understand the importance of this approach and implement relevant controls where ever possible. Especially with the COVID-19 pandemic, the word "Zero-Trust" is resounding in the tech industry, and this completely makes sense due to the following reasons:

1. Today, IT security is getting more and more complex. Security is no longer someone's job alone. Everyone has a role to play when it comes to IT security. We have more and more devices connecting to corporate networks and data coming from remote locations. Attacks are also getting more and more sophisticated.
2. The "perimeter defense" security strategy is no longer working. We have data and applications running on on-prem as well as in the cloud. Users are connecting to these services from everywhere...

What is Microsoft Defender for Identity?

In the previous two editions of this book, this section was allocated to Microsoft Advanced Threat Analytics (ATA). This is an on-prem platform to help us protect our identity infrastructure from advanced targeted attacks by automatically analyzing, learning, and identifying normal and abnormal behavior (from users, devices, and resources). Microsoft also had a cloud version of it called Azure Advanced Threat Protection (Azure ATP). This cloud service has now been renamed Defender for Identity. Microsoft ATA mainstream support ended on January 12, 2021, so going forward, users only can use the cloud-based Defender for Identity service.

When we consider a typical attack kill chain, we can identify four main areas to protect:

1. Applications
2. Endpoints
3. Identity
4. Data

Microsoft offers security solutions to protect all these areas:

1. Applications – Microsoft Defender for Office 365, Microsoft...

Defender for Identity benefits

Defender for Identity has the following key capabilities that help to streamline SecOps operations:

1. Proactive – Detect vulnerabilities proactively and prevent attacks before they happen.
2. Efficient – Automatic analysis and automatic response help SecOps teams to allocate their time to investigating critical issues.
3. Prioritize – By reducing false positives, Defender for Identity helps SecOps teams to prioritize spending their time on dealing with the real issues.

When it comes to identity protection, Microsoft Defender for Identity focuses on four main deliverables.

Prevent

Defender for Identity helps SecOps teams to identify hidden vulnerabilities in their environments. These are present mostly due to misconfiguration of services/products and a lack of system updates.

The Defender for Identity security posture assessment can detect vulnerabilities such as:

• Exposing credentials...

Azure AD Connect Health

In the previous chapter, we learned what Azure AD Connect is and how it works in a hybrid Azure AD environment. Azure AD Connect is responsible for synchronization between Azure AD and on-prem AD. Therefore, it is important to monitor the health of the Azure AD Connect service to make sure it is running as expected. In a given computer infrastructure, only one Azure AD Connect instance can be active at a given time, so this puts more pressure on the health of the service. The Azure AD Connect service is a Windows service, so there are many tools on the market that can monitor the status of the service. But even if the service is up and running, it doesn't mean synchronization is healthy.

Azure AD Connect Health is a service that comes with Azure AD Premium to monitor the health of Azure AD Connect. Azure AD Connect Health can monitor the following types of sync errors:

• Duplicate attributes
• Data mismatches
• Data validation failures...

Prerequisites

We need to meet the following prerequisites to use Azure AD Connect Health:

• An Azure AD Premium subscription.
• Relevant Azure AD Connect Health agents installed on target computers.
• Allow outgoing TCP 443 & 5671 traffic to Azure endpoints from the target servers (for a complete list of URLs, see https://bit.ly/3FK3BdP)
• PowerShell 5.0 or above installed on the target computers.
• Federal Information Processing Standards (FIPS) should be disabled.

Configuration

In this section, we are going to look at Azure AD Connect Health in action. In my demonstration environment, I have the latest version of Azure AD Connect installed.

Azure AD Connect Health (sync) comes as a part of it, as shown in the following screenshot:

Figure 19.20: Azure AD Connect health services

But I'd like to install Azure AD Connect Health Agent for AD DS to gather additional insights from my on-prem AD environment. In order to do that, perform the following steps:

1. Log in to the target computer as the Domain Admin/Enterprise Admin.
2. Go to the Azure portal at https://portal.azure.com and log in as a global administrator.
3. Then go to Azure Active Directory | Azure AD Connect and click on Azure AD Connect Health, as shown in the following screenshot:

   

   Figure 19.21: Azure AD Connect Health access

4. In the new window, click on Download Azure AD Connect Health Agent for AD DS, as shown in the following...

Summary

Continuous monitoring and auditing are a must for identity infrastructures to identify potential security threats and maintain a healthy environment. There are a lot of tools and methods out there to do this, but the success of these solutions depends on the accuracy of detection, the way it presents data, and how it helps in identifying the root cause.

In this chapter, we started by looking at Windows' built-in tools and methods that can be used to monitor and audit AD environments. First, we started with GUI tools and then moved to PowerShell-based auditing. Then we looked at Microsoft Defender for Identity and how it can help to identify security threats in the infrastructure that cannot be detected using traditional tools and methods. Last but not least, we also learned how Azure AD Connect Health can help to monitor the synchronization health of the Azure AD hybrid environment.

After a long journey, we are now reaching the end of this book. In the final chapter...