Active Directory extended monitoring

This Dynatrace extension is a companion to the Active Directory services monitoring extension and provides an extended set of AD metrics, obtained through dedicated PowerShell cmdlets. This extension is not intended to work alone - it should be activated as a companion to the Active Directory services monitoring extension.

This is intended for users, who: Want to enhance the Active Directory services monitoring already implemented, with additional metrics that characterize:

• AD replication status
• DHCP server status and performance
• System-dependent services status like time synchronization, volume health and network adapter health
• LDAP BIND performance, ATQ thread usage, FSMO consistency, AD database disk usage

Enhance Active Directory services monitoring with advanced metrics.

Start with activating the Active Directory services monitoring extension. Then activate this extension, as it is intended to enhance the the Active Directory services monitoring.

When enabling this extension, you will be prompted for

• User name and password to a Windows account
  • Able to logon locally
  • The account requires KEY_READ permission to read registry keys from HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
  • The account requires permission to locally execute PowerShell cmdlets on the AD server
  • If collecting DHCP scope metrics, the user must be part of the DHCP Users group
  • Note that the account doesn't have to be the local account on an AD server. It can be domain account, but it requires local server privileges (registry key read, PS cmdlet run).
• API token to the Dynatrace tenant on which the extension is activated
  • API token requires the settings.write, settings.read and entities.read scope
  • You need to prepare this token on your Dynatrace tenant (Settings > Integrations > Access tokens) and copy-paste this token into the extension configuration

This extension is intended to work locally on the AD server. It executes:

• PowerShell cmdlets, locally, to access Windows registry and specific AD metrics available only through PowerShell. Several of these metrics map to metrics available through commonly used DCDIAG tool.
• API calls against the OS Service Monitoring, to report AD services availability
• Log ingestion of the AD services logs

The extension package contains:

• PowerShell snippets that retrieve metrics from the AD server
• Alert templates for time skew monitoring, database file space, ATQ thread usage and replication consistency
• Topology rules and screen definitions that weave this extension metrics into the entities managed by the Active Directory services monitoring extension
• Log ingest rules, applied on AD hosts monitored with this extension, which further enable alerting on AD services-related issues logged into Windows logs system
• Log processing rules, which enrich logs ingested with a field that flag AD-related context where content pertains to AD services
• Log event extraction rules, which scan logs ingested for AD-related context and trigger alerts when log information carries potential AD issue or error information

Log ingest configured by this extension By default, this extension sets up log ingestion rules on hosts where it is installed. AD services logs are used to generate events and further alert on service anomalies and malfunctions.

You can disable log ingestion with a settings toggle in the extension configuration screen. Note that this setting does not control any other log ingestion rules that might have been configured on hosts where this extension has been activated.

Following log ingestion rules are being set up by this extension:

• Windows Event Log
  • source is
    • Active Directory Web Services
    • DFS Replication
    • Directory Service
    • DNS Server
  • and log record level is in (ERROR WARN CRITICAL SEVERE)
• Windows Log
  • source is
    • Windows Application Log
    • Windows System Log,
    • Security

And the following events from each event provider.

|Event Provider|Event IDs|
|Microsoft-Windows-ADFS|102, 104, 111, 356, 385, 509, 546, 549, 1034, 1036|
|Microsoft-Windows-Directory-Services-SAM|12299, 16643|
|Microsoft-Windows-Time-Service|21, 34, 36|
|DNSAPI|11150, 11162, 11151, 11155, 11163, 11167, 11154, 11166, 11152, 11153, 11164, 11165|
|Microsoft-Windows-Kerberos-Key-Distribution-Center|6, 15, 17|
|Microsoft-Windows-Security-Auditing|1102, 4616, 4621, 4649, 4660, 4675, 4707, 4710, 4712, 4715, 4716, 4730, 4740, 4743, 4764, 4766, 4771, 4866, 4867, 4935, 5025, 5030, 5034, 5035, 5037, 5139, 5141, 5483, 5484, 6008, 6145|
|Microsoft-Windows-CertificationAuthority|0, 3, 5, 9, 16, 17, 19, 20, 21, 22, 23, 28, 33, 34, 35, 38, 39, 40, 42, 43, 44, 48, 49, 51, 59, 60, 63, 65, 74, 75, 78, 82, 83, 86, 87, 90, 92, 94, 95, 96, 98, 99, 100, 102, 106, 107, 130, 132|
|Microsoft-Windows-OnlineResponder|39, 60, 92|

• This extension is intended as a companion to the Active Directory services monitoring extension. with advanced metrics.
• Only on-premises Active Directory deployments are supported.
• Azure AD is not supported.
• Verified with Windows Server 2016, 2019 and 2022
• Required minimum PowerShell version on AD servers is 5.x and above

Q: What is the DDU Consumption of this extension?

A: The formula for DDU consumption of the extension is:

 ( 10
+ (17 * number of Domain Controllers)
+ (11 * number of DHCP servers)
+ ( 2 * number of LDAP instances)
 )  * 525.6 DDUs/year

Typical consumption for a single-domain AD server, hosting one DHCP server and one LDAP instance, amounts to 21,024 DDUs/year

DDU cost above does not include log lines ingested any possible Log events or Custom events triggered by the extension. For more information on this, please visit the DDU log event cost and DDU custom event cost pages.

Q: Does this extension collect KPIs available from DCDIAG?

A: All in all - equivalents of the DCDIAG KPIs are available in Dynatrace:

• NTDS Service - monitored through OneAgent OS Service Monitoring
• Services - monitored through OneAgent OS Service Monitoring
• Replications - similar data is available through parsing of the repadmin outputs, in this extension
• FSMO KnowsOfRoleHolders - can be found as part of the FSMO role holder ping/LDAP metrics
• Advertising - delivered by the FSMO role holder consistency metric

Q: Why do I need to provide separate credentials in this extension if OneAgent already runs under LocalSystem?

A: An account with additional permissions is required to run this extension due to the kind of metrics it collects. Although OneAgent typically runs as LocalSystem account, Python extensions run as LocalService. The LocalService account has the minimum privileges on the local computer which is why the extension requires an account with enough permissions to read a few registry keys and run cmdlets like repadmin and dcdiag.

Q: Why there is a need to grant KEY_READ permission to HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters?

A: KEY_READ permission to HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters is required to obtain following metrics:

active-directory.database.diskfree
active-directory.database.disk.total
active-directory.database.diskfree.total
active-directory.replication.consistency.status

Q: What is the Dynatrace API token used for?

A: API token is required to enable integration of the AD-related log ingestion and the OS service monitoring with OOTB host-level reporting. No metrics are ingested using the API token. API token is used to allow the services to be seen on the Dynatrace Host UA screen and the logs on the AD Instance UA screen.

Q: What do I need OS Service Monitoring for?

A: The extension utilizes the API token to add entries into the OneAgent's OS Service Monitoring. The OneAgent will ingest availibility metrics and alerts so you know when a critical service is down. In some cases log events can refer to the OS Service which emitted the event.

Q: Does the extension support Group Managed Service Accounts (gMSA)?

A: No the extension does not suport gMSA accounts. The extension can only use local or domain-joined accounts since gMSA accounts are not meant for interactive use. The extension works by impersonating the account provided in the monitoring configuration to execute commands in that user's security context. gMSA accounts cannot be impersonated and therefore aren't able to be used by the extension.