How do I read my Active Directory scan results?
This article explains how to read the Result Information field in Active Directory (AD) findings and how to validate findings before and after remediation. The field format varies depending on the type of finding, and this article walks through each format with examples.
What is the Result Information field?
Each AD finding contains several fields - severity, CVSS score, impact, and solution. These fields are consistent across all customers. The Result Information field is different: it identifies the specific objects in your environment that triggered the rule, such as accounts, Domain Controllers, Group Policy Objects (GPOs), certificate templates, and DNS zones.
The format follows a consistent pattern:
- A one-line description of what was found.
- A column header in parentheses indicating what data is shown.
- One row per affected object.
The columns differ depending on the finding type. The sections below explain how to read each format.
How do I find the Result Information field?
In the scan report
- Click Assessments > Scans.
- Click on the finished Active Directory scan.
- Click View results.
- Click PDF.
- View results under every HID in the report.
In All Vulnerabilities view
- Click Vulnerabilities > All vulnerabilities.
- In the search field, enter "AD -" to filter all Active Directory vulnerabilities.
- Click on a vulnerability to open the side panel.
- Click Assets in the side panel.
- View results.
Findings are baselines - not CVEs
AD assessments evaluate your Active Directory configuration against hardening baselines published by Microsoft, the Center for Internet Security (CIS), and the security research community. A finding indicates a deviation from that baseline. In some cases this is a directly exploitable attack path, in others a weakened but tolerable condition.
For this reason, AD findings rarely carry a CVE - the underlying issue is a configuration state, not a versioned software vulnerability. Read the severity set by the rule in the context of your own environment, and set the final priority based on that.
For a recommended order to work through your findings, read this article:
How do I prioritize my Active Directory findings?
Result formats
Host list
Example finding: AD - Domain-Joined Computers Running Windows Server 2012/R2 (End-of-Life)
Domain-joined hosts running Windows Server 2012/R2 (Host):
- WIN-LEGACY-01$
One entry per affected host. Each row identifies a machine that must be migrated, retired, or enrolled in Microsoft Extended Security Updates. The trailing $ confirms the entry is a computer account rather than a user account.
GPO content
Example finding: AD - Plaintext Passwords in Group Policy Preferences
GPO Preferences contain plaintext passwords (GPO | User | Encrypted):
- Legacy-Service-Policy | svc-deploy | cpassword present (decryptable)
The GPO column identifies the policy object that must be edited. The User column identifies the account whose credentials are exposed and must be rotated. Each row represents one credential that must be removed from SYSVOL and reset.
Account list with attributes
Example finding: AD - Privileged Service Accounts with Old Passwords Are Kerberoastable
Kerberoastable privileged service accounts (User | Groups | SPNs):
- svc-app01 | Domain Administrators, Administrators | http/app01.corp.example.com
- svc-sql01 | Domain Administrators, Administrators | MSSQLSvc/sql01.corp.example.com:1433
Each row links the account to the group membership that makes it privileged and the Service Principal Name (SPN) that makes it Kerberoastable. The recommended remediation is conversion to a Group Managed Service Account (gMSA) so that the password is rotated automatically.
Account DN list
Example finding: AD - User Accounts with Password Set to Never Expire
User accounts with PASSWORD_NEVER_EXPIRES set (DN):
- CN=svc-legacy,CN=Users,DC=corp,DC=example,DC=com
- CN=Administrator,CN=Users,DC=corp,DC=example,DC=com
- CN=Guest,CN=Users,DC=corp,DC=example,DC=com
The full distinguished name (DN) is provided so entries can be used directly in PowerShell or Active Directory Users and Computers (ADUC). The presence of the built-in Administrator and Guest accounts is common but should be reviewed. Built-in accounts should either be disabled or maintained with a rotated, monitored password.
Certificate template
Example finding: AD - Auth Template Allows Enrollee-Supplied Subject (ESC1)
Certificate templates allowing user-supplied subject/SAN with low-privilege enroll (ESC1):
- WebServerEnrollment
One entry per misconfigured template. Active Directory Certificate Services (ADCS) findings typically return short lists with significant impact. A single ESC1-vulnerable template enables Domain Admin impersonation by any principal permitted to enroll.
DNS zone
Example finding: AD - Authenticated Users Can Create DNS Records in AD-Integrated Zones
DNS zones where Authenticated Users can create child records (Zone):
- corp.example.com
- internal.example.com
- _msdcs.corp.example.com
Each row identifies a zone access control list (ACL) that must be corrected.
_msdcs zones require immediate attention
Write access to an _msdcs zone enables hijacking of Domain Controller records, not only generic name resolution. Prioritize any finding that includes _msdcs entries.
Long account lists
Example finding: AD - High Percentage of Enabled Privileged Accounts Are Inactive
Inactive privileged accounts (User | SID):
- svc-legacy-da | S-1-5-21-1111111111-2222222222-3333333333-1156
- admin-archive-25 | S-1-5-21-1111111111-2222222222-3333333333-4448
- ... [approximately 100 rows]
When a list contains a large number of rows, prioritize by group membership and well-known Relative Identifier (RID). The following should be addressed first:
- RID 500 - Administrator
- RID 502 - krbtgt
- RID 512 - Domain Admins
- Named administrative accounts
Bulk archival entries are typically a cleanup activity rather than incident response.
Which findings should I validate before acting?
Some findings rely on AD attributes that can be out of date. Check these before you schedule remediation:
- End-of-life operating system findings are based on the operatingSystem attribute on the AD object. Decommissioned hosts whose AD records were not cleaned up still appear, even if the host no longer exists. Confirm that the host is online and running the reported operating system before you plan an upgrade.
- Inactive account findings are based on lastLogonTimestamp, which replicates approximately every 14 days. Recently created accounts may briefly appear stale until replication catches up.
- "Administrator logged on a DC" reports any logon by the built-in Administrator account (RID 500) in the last 35 days, of any type and from any location. If you scan with this account, the scan itself triggers the finding.
No AD findings usually means the scan did not complete
A scan that returns no AD findings is almost never a clean domain. Check the info results listed below.
If your scan returns no AD findings, check these info results. If they are missing, add the HIDs to your scan profile:
- HID-2-1-33740 (SMB Login) - shows whether the login succeeded.
- HID-2-1-5320777 (Active Directory collector) - shows the collector status. "Host is not a Domain Controller" means the scan account has no remote registry access.
How do I dismiss a finding?
To dismiss a finding, use the Ignore workflow in Security Center. Add a documented reason and an expiry date so that the audit trail is preserved across scans.
How to ignore or disable vulnerabilities.
When can I re-run the scan after remediation?
A finding is cleared when it no longer appears in the next scan, or when its status changes to Fixed.
Some checks depend on replicated attributes, such as password changes, group membership changes, and operating system updates. For these, wait at least one full Active Directory replication cycle before you scan again. This is typically 15 minutes within a site and longer across sites.