3 min read

Audit Microsoft ADCS services using Microsoft Sentinel

Audit Microsoft ADCS services using Microsoft Sentinel
Audit Active Directory Certificate Services using Microsoft Sentinel

This blog post shows you how to enable and configure Active Directory Certificate Service's advanced auditing and how to collect and send them to Microsoft Sentinel. By default, logging is not enabled, and you may miss important insights from your environment.

Please remember that you need to carry out the same activities on all your ADCS servers.

What do you need?

  • Azure Log Analytics workspace
  • Microsoft Sentinel
  • Azure Arc connect server

You may be wondering why do I need Azure Arc for ADCS auditing? In this case, I assume you don’t forward all the security events using Defender for Cloud or Microsoft Sentinel. If you use the Defender for Cloud or Security Events connector in Sentinel, then you have four different configuration options:

  • None
  • Minimal
  • Common
  • All Events

If you are using Common events, then it only takes around 150 different events from the security log. If it comes down to the ADCS service, then different ADCS event IDs are not included in the “Common” package. Of course, you can set your Security Events connector or Defender for Cloud to forward all logs, but I don’t want to do that. Azure Arc and the Azure Monitoring Agent allow me to define my own Data Collector Rules and collect the events I need.

ADCS auditing

The first step is ensuring auditing is enabled on your ADCS servers.

Run the auditpol command and ensure that “Certificate Services” and “Registry” advanced auditing are enabled.

auditpol /get /category:*
Auditpol output

You can configure advanced auditing settings using the auditpol /set command or Group Policy.

Auditpol command

auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

Group Policy

Group Policy Settings

The next step is to enable auditing through the ACS snap-in. To do that, follow the steps on your ADCS server:

  • Open Server Manager
  • Select Tools -> Certification Authority
  • Right-click your CA name and choose properties
  • Select Auditing
  • Enable the auditing settings you need
    • Back up and restore the CA database
    • Change CA configuration
    • Change CA security settings
    • Issue and manage certificate requests
    • Revoke certificates and publish CRLs
    • Store and retrieve archived keys
    • Start and stop ADCS service
ADCS Auditing Settings

The next step is to enable the certificate template changes using the certutil command:

certutil –setreg policy\EditFlags +EDITF_AUDITCERTTEMPLATELOAD

Because some changes can be done directly through the registry, we need to enable registry auditing. To do that, we need to do this:

  • Open Regedit on your ADCS server
  • Browse the following key
    • *HKLM:\System\CurrentControlSet\Services\CertSvc\Configuration*
  • Right-click Configuration and choose Permissions
  • Click Advanced
  • Choose Auditing and click Add
  • Set the principal to Authenticated Users and configure the following permissions
    • Set Value
    • Create SubKey
    • Delete
    • Write DAC
    • Write Owner
    • Read Control
ADCS Registry Auditing Settings

Reboot your server and verify the changes. After the reboot, you should see different event IDs in your Security logs.

Now that we have the ADCS auditing up and running, we can continue with the Azure Arc and Sentinel.

Azure Arc configuration

For Azure Arc configuration, follow this guide - Connect hybrid machine with Azure Arc enabled servers - Azure Arc | Microsoft Docs

Microsoft Sentinel

Now that you have Azure Arc up and running, we can continue with the Data Collection Rules. In Microsoft Sentinel, we have a new connector called Windows Security Events. This connector allows us to define custom log policies for Azure Arc-enabled servers. In the Data Collector Rules, you need to specify the XPATH queries.

Security!*[System[(EventID=4882 or EventID=4899)]]

You can test your XPATH queries using the Get-WinEvent PowerShell cmdlet.