ASD ISM 1830 Central logging of security events for Microsoft AD infrastructure servers
What it says
Security-relevant events for Microsoft AD DS domain controllers, Microsoft AD CS servers, Microsoft AD FS servers and Microsoft Entra Connect servers are centrally logged.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSecurity-relevant events from AD DS domain controllers, AD CS, AD FS and Entra Connect servers are forwarded to a central log store so identity-related activity can be seen and investigated in one place.
This control requires that the security-relevant events produced by four types of Microsoft identity servers are collected into a central logging location rather than being left on each server. The servers in scope are Microsoft Active Directory Domain Services (AD DS) domain controllers, Microsoft Active Directory Certificate Services (AD CS) servers, Microsoft Active Directory Federation Services (AD FS) servers and Microsoft Entra Connect servers. These systems sit at the heart of an organisation's identity infrastructure. Domain controllers authenticate users and hold the credentials for the whole domain, AD CS issues the certificates that machines and people use to prove who they are, AD FS brokers sign-in to federated applications, and Entra Connect synchronises on-premises identities and password hashes to the cloud. An attacker who gains a foothold on any of them can forge credentials, mint certificates, impersonate users or pivot into Microsoft 365 and other cloud services. Because these servers are such high-value targets, the events they generate (logons, privilege use, account and group changes, certificate issuance, federation token activity, synchronisation activity, and changes to the servers themselves) are the evidence an organisation needs to notice an intrusion. If those events stay only on the server, a capable attacker can clear or tamper with them, and defenders have to log on to each box to piece together what happened. Central logging moves a copy of the events off the server as they occur, so they are preserved, can be correlated across the whole identity estate, and can be monitored by the people responsible for detecting and responding to cyber security incidents.
Free. Save your status, tasks and notes.
Why it matters
Without central logging of security-relevant events from these servers, an attacker who compromises a domain controller, certificate authority, federation server or Entra Connect server can operate with little chance of detection and can delete or alter the local event logs to remove evidence. Investigations become slow and incomplete because logs must be gathered server by server after the fact, gaps appear when servers are rebuilt or logs roll over, and activity spanning several identity components cannot be correlated. The organisation may only discover a domain-wide compromise, rogue certificate issuance or a tampered cloud synchronisation long after the damage is done, undermining incident response and any assurance that identity systems remain trustworthy.
How to implement
The identity or directory services team documents the complete list of Microsoft AD DS domain controllers, AD CS servers, AD FS servers and Entra Connect servers, including any in secondary sites or disaster recovery environments, and records this inventory as the authoritative scope for central logging.
The security operations or logging team configures a central log collection platform (for example a SIEM or a Windows Event Forwarding collector feeding a log store) and registers each in-scope server as a source, using a forwarding agent or event subscription that ships security-relevant events off the server as they are generated.
System administrators apply and verify an audit policy on each server class so the security-relevant events for that role are actually produced: directory, account, group, logon and privilege events on domain controllers; certificate issuance, revocation and template changes on AD CS; sign-in and token issuance events on AD FS; and synchronisation and service configuration events on Entra Connect.
The logging team builds the server inventory into the build or provisioning process, so that any new or rebuilt domain controller, AD CS, AD FS or Entra Connect server is enrolled in central log forwarding before it is placed into service, and decommissioned servers are retired from the source list.
The security operations team sets up health monitoring on the central platform that alerts when any in-scope server stops sending events or its event volume drops unexpectedly, and assigns an owner to investigate and restore forwarding within an agreed time.
Keep it running
Day to day, the organisation needs to know that every in-scope server is actually sending its security-relevant events to the central log store. Maintain an authoritative inventory of AD DS domain controllers, AD CS servers, AD FS servers and Entra Connect servers, and reconcile it against the list of sources reporting into the central logging platform on a regular basis so that new, rebuilt or replaced servers do not silently drop out.
Watch for forwarding failures. Monitor for sources that stop reporting, agents or subscriptions that fail, and unusual drops in event volume, and treat these as operational faults to be fixed promptly rather than tolerated. Ensure the audit policy on each server class continues to generate the events that matter for that role (for example directory service, account management and logon events on domain controllers, certificate issuance and template changes on AD CS, token issuance and sign-in events on AD FS, and synchronisation and service configuration events on Entra Connect), and re-check this after patches, upgrades or migrations.
Keep the central logging configuration under change control so that changes to collection scope, filters or destinations are reviewed, and make sure the people who monitor and investigate security incidents have ongoing access to the collected events. Periodically confirm that logs from each server type are searchable in the central platform and cover the expected time range.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the inventory of Microsoft AD DS domain controllers, AD CS servers, AD FS servers and Entra Connect servers, together with the list of log sources configured in the central logging platform.
Look at
Compare the two lists server by server and check that every in-scope server of each of the four types appears as an active source in the central platform.
Good evidence
Every server in the inventory is present as a central logging source, and there are no in-scope servers of any of the four types that are missing or marked inactive.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the configuration that forwards events from each server type to the central platform, such as Windows Event Forwarding subscriptions, agent configuration or group policy settings.
Look at
Check that the configuration captures security-relevant events for each role and that it is applied consistently across all servers of that type rather than to a sample.
Good evidence
Forwarding is defined centrally and applied to all domain controllers, AD CS, AD FS and Entra Connect servers, and it includes the security-relevant event categories appropriate to each role.
- Check 3 of 5What an auditor asks for
Ask for
Ask to see the central logging platform and request a live search for recent security-relevant events from one server of each of the four types.
Look at
Confirm that events from each server type are arriving, are recent, and can be identified by originating server and event type.
Good evidence
Current security-relevant events from a domain controller, an AD CS server, an AD FS server and an Entra Connect server are all visible in the central platform within the expected delay.
- Check 4 of 5What an auditor asks for
Ask for
Ask for evidence of how the organisation detects when an in-scope server stops forwarding events, such as health alerts, source status reports or missing-source dashboards.
Look at
Look at whether a monitoring mechanism exists, whether it covers all four server types, and how recent forwarding failures were handled.
Good evidence
Forwarding failures raise an alert to a named owner, and records show that failures have been identified and resolved rather than left unnoticed.
- Check 5 of 5What an auditor asks for
Ask for
Ask how newly built or rebuilt identity servers are enrolled in central logging and how decommissioned servers are removed from the source list.
Look at
Review the build or change process and check a recent example of a new or rebuilt domain controller, AD CS, AD FS or Entra Connect server to see when it started reporting centrally.
Good evidence
Enrolment in central logging is a standard step in the build process, and recent examples show new servers reporting centrally from the time they entered service.
Mappings
Closest match in ASD Essential Eight: E8-RA-ML2.6, Privileged access events are centrally logged., which this control covers in full and more.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.15.
ISM-1830 requires centrally logging security-relevant events specifically from Microsoft AD DS domain controllers, AD CS, AD FS and Entra Connect servers. ISO/IEC 27001:2022 Annex A 8.15 is broader, requiring organisations to produce, store, protect and analyse logs of relevant activities and events across information systems generally. ISM-1830 is a prescriptive, identity-infrastructure-specific implementation pattern that would partially satisfy Annex A 8.15 for that subset of systems but not for the wider environment.
This control supports A.8.16.
ISM-1830 requires that security-relevant events on Microsoft AD-related servers are centrally logged. Annex A 8.16 requires monitoring of networks, systems and applications for anomalous behaviour and taking appropriate actions. Centralised AD server logging under ISM-1830 directly strengthens the ability to detect identity-related anomalies (e.g. suspicious authentication and directory changes), but Annex A 8.16 also covers monitoring/response activities beyond log collection.
ASD Essential Eight: 5 mappings
This control is broader than E8-RA-ML2.6.
ISM-1830 requires security-relevant events for Microsoft AD DS domain controllers, AD CS CA servers, AD FS servers and Microsoft Entra Connect servers to be centrally logged. E8-RA-ML2.6 requires privileged access events to be centrally logged, which is a broader event category that would include privileged actions occurring on AD servers as well as on other systems. ISM-1830 is more technology-specific (Microsoft identity infrastructure) but does not limit itself only to privileged access events.
This control partially overlaps E8-MF-ML2.7.
ISM-1830 requires security-relevant events for Microsoft AD DS, AD CS, AD FS and Entra Connect servers to be centrally logged. E8-MF-ML2.7 requires event logs to be protected from unauthorised modification and deletion, which applies to logs generally, including centralised logs collected from AD servers. ISM-1830 is about ensuring the right AD server event sources are centrally collected, while E8-MF-ML2.7 is about integrity/retention protection regardless of source.
This control supports E8-AC-ML3.4.
E8-AC-ML3.4 requires organisations to analyse event logs from non-internet-facing servers in a timely manner to detect cyber security events. ISM-1830 ensures security-relevant events for key identity infrastructure (AD DS/CS/FS and Entra Connect) are centrally logged, which are commonly non-internet-facing servers and high-value detection sources. Central logging per ISM-1830 is a practical prerequisite to reliably performing the timely analysis expected by E8-AC-ML3.4 at scale, although E8-AC-ML3.4 applies to non-internet-facing servers beyond these specific AD components.
This control supports E8-AH-ML2.15.
ISM-1830 centralises security-relevant events from core Microsoft identity services (AD DS/CS/FS and Entra Connect) so identity activity can be investigated in one place. E8-AH-ML2.15 is supported by ISM-1830 because centralising these identity logs makes timely analysis and incident identification more feasible and complete. ISM-1830 is about log forwarding/aggregation for a defined server set, whereas E8-AH-ML2.15 is about the operational process of analysing events to identify incidents.
- E8-MF-ML3.4Analyse event logs from non-internet-facing servers timely to detect security eventsSupports
This control supports E8-MF-ML3.4.
E8-MF-ML3.4 requires timely analysis of event logs from non-internet-facing servers to detect cyber security events. ISM-1830 ensures security-relevant events from AD-related servers are centrally logged, which provides the log availability and aggregation needed to perform consistent analysis at scale. E8-MF-ML3.4 focuses on analysis, while ISM-1830 focuses on log collection/centralisation for a specific server set.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.