Key points
- This process provides unified visibility into user authentication and activity across on-premises Active Directory and cloud-based Microsoft 365.
- You must first configure and enable Group Policy audit policies on Domain Controllers to log successful and failed logon events.
- Centralizing logs from all Domain Controllers into a SIEM or collection server is essential for complete analysis and coverage.
- Correlating AD events with Microsoft Purview audit logs using common fields like UserPrincipalName and IP address reveals detailed, hybrid attack timelines.
- Analyzing these correlated logs helps detect threats like brute-force attacks, impossible travel scenarios, and compromised service accounts.
- Automated reporting on this activity is critical for demonstrating security diligence and compliance to auditors and stakeholders.
It’s highly recommended that you audit Domain Controller logons and Microsoft 365 audit log activities as part of your routine cybersecurity processes. Correlating these two data sources gives IT teams and managed service providers (MSPs) full visibility over authentication attempts in cloud and hybrid environments, helping with incident detection and investigations, as well as providing information used to prove compliance and respond to potential breaches.
This guide outlines how to audit login events from an Active Directory (AD) Domain Controller (DC), combine this information with activity data from Microsoft Purview, and generate reports for review and compliance.
What you need to audit Domain Controller logons with data from Microsoft 365 Purview
To audit logon events in cloud or hybrid environments where there are both Domain Controllers and activities logged in Microsoft Purview, you’ll need:
- An administrative account with Group Policy access to configure auditing policies
- A central repository to consolidate and store logs, such as Windows Event Forwarding (WEF)/Windows Event Collector (WEC) server, or security information and event management (SIEM) tools
- A list of critical DCs, privileged organizational units (OUs), and service accounts that should be actively guarded
- Access to Microsoft 365 Purview Audit Portal and Entra ID sign-in logs
- An approved change window for policy rollout and testing
Step 1: Configure Domain Controller audit policies
Use the Group Policy Management Console (GPMC) to enable Advanced Audit Policy.
- In GPMC, navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy
- Double-click on the Audit logon events policies to edit it, and check the Success and Failure checkboxes to capture both successful logins and attempted violations
- Run gpupdate /force or reboot to apply the change, then check that events 4624 (success) and 4625 (fail) are logged in the Event Viewer
Logon events are only generated on the Domain Controller for domain accounts. If you want to audit logins for standalone devices using local accounts, you’ll need to push this group policy setting and collect logs from endpoints using your remote monitoring and management (RMM) or mobile device management (MDM) solution.
Step 2: Centralize and retain authentication audit logs
Consolidate logs from all Domain Controllers in a central platform to ensure there are no coverage gaps when analyzing event data. This can be done using Windows Event Forwarding (WEF)/Windows Event Collector (WEC) server or SIEM tools. You can also leverage your automated RMM platform for log ingestion, analysis, and report generation across operating systems.
Set log retention times based on what is necessary for compliance with the data protection and privacy regulations that cover your organization and any parties you store information about.
Step 3: Enrich DC logs with Microsoft 365 Purview auditing data
By supplementing logon audit data from your Active Directory Domain Controllers with activities collected from Microsoft Purview, you can track suspicious user activity in more detail. This is done by correlating data, including UserPrincipalName, IP address, and other identifiers across cloud and on-premises logs to create hybrid timelines.
Step 4: Implement filters and find correlations
Use your analytics tools to identify recurring failed logins or logins from unexpected locations. You should also watch for unrealistic numbers of successful logins for an account that may indicate successful automated authentication attempts. For this to be effective, service accounts should be whitelisted to prevent false positives.
Step 5: Remediate and report suspicious logon activity
Automated remediation measures should be configured to automatically disable potentially compromised or stale accounts before an investigation can be initiated.
Prove diligence and compliance to stakeholders with automatically generated audit summaries that include metrics such as event volume, unique failures, mean time to investigate, and administrative actions taken (for example, tightening MFA/password policies and retiring stale accounts).
NinjaOne unifies, automates, and centralizes the reporting of AD audit logs
NinjaOne can be configured to automatically ingest logs from any source, including Windows Domain Controller logs, Microsoft 365 Purview events, and logs from third-party software, and analyze and summarize them into presentation-ready reports. Log data and reports can then be stored in access-controlled NinjaOne Documentation for long-term insights and for presentation to stakeholders during business reviews.
In addition to unifying logs and giving you the tools for full oversight over your tenants’ IT infrastructure, NinjaOne integrates industry-best MDM, RMM, helpdesk, and endpoint security. With all of your endpoint and infrastructure monitoring under one roof, you can ensure that the right technician is notified of any security or compliance issues so that they can be rectified immediately, with an audit-ready trail of what happened and how you remediated the issue.
