PingCastle Active Directory Assessment Guide: Scoring and Reducing AD Risk

Active Directory accumulates risk quietly, through stale accounts, weak protocols left enabled for one legacy system, over-delegated service accounts and trusts nobody remembers creating, and most organisations only see the full picture when an attacker or an auditor shows it to them. PingCastle is an assessment tool that collects Active Directory configuration with ordinary read access, scores the risk across four categories and produces a report with findings and remediation guidance. This guide explains what PingCastle checks, how its scoring works, how to run it safely and repeatably, how to turn findings into a hardening programme, and how it compares with attack path tools. It complements the BloodHound and Active Directory Attack Path Guide and is written for identity engineers, AD administrators and security teams. Features were checked against the Netwrix PingCastle 4.0 documentation, the PingCastle rules list and the project repository on 27 October 2026.

Key takeaways

• A standard user is enough. A health check usually needs only a domain user account with no special privileges, which is why attackers can gather the same view and why defenders should run it first.
• The score is the worst category, not the average. Each of the four categories (Stale Objects, Privileged Accounts, Trusts, Anomalies) scores up to 100 and the overall score is the highest of the four, so one weak area defines the domain's risk.
• Rules carry points and references. Each rule shows its points and maps to MITRE ATT&CK techniques or mitigations and ANSSI checks, which helps prioritise and justify fixes.
• Licensing depends on use. The open source edition is under the Non-Profit Open Software License 3.0: free for internal use, including by contracted IT providers, but a commercial licence is needed to sell PingCastle-based services.
• Trend it, do not run it once. The methodology suggests a weekly health check and a target for reducing the score; consolidation reports track many domains over time.

What the tool does

PingCastle was created as a free AD assessment tool and was acquired by Netwrix in 2024; it now covers Active Directory and, since version 3.4 added Microsoft Graph components, Entra ID. The repository banner showed version 4.0.0.27 on the check date. It is a Windows C# application run from the command line or an interactive menu.

• Targets: --server accepts a domain controller name, a domain, a forest wildcard such as *.domain.local, or * for all reachable domains; reports for other domains can be generated over existing trusts.
• Detail level: --level takes Full, Normal (default) or Light; Full keeps every finding in the XML, which you want for remediation tracking.
• Privileged mode: --privileged improves accuracy for a few rules, for example reading certificate authority enrolment ACLs for the AD CS template rules A-CertTempCustomSubject (ESC1) and A-CertTempAnyPurpose (ESC2), and checking domain controller hotfixes for S-Vuln-MS14-068 and S-Vuln-MS17_010.
• Outputs: an HTML report for people, with findings and remediation guidance, and an XML report for consolidation and automation; a Hilbert map shows the IP address space.

The risk model

Rule points take several forms: a flat value if present (for example 5 or 15), a value per discovery, tiers by count (S-C-Inactive scores 30, 20 or 5 depending on how many inactive computers exist) and informative rules worth 0. Read your own report's rule text rather than memorising IDs, because rules are added and revised between releases.

Defender use cases

For the fixes themselves, see the Active Directory and Entra ID Hardening Guide, the AD CS Security Guide, the Active Directory Trusts and SID Filtering Guide and the NTLM Deprecation and Elimination Guide.

Where identity fits

PingCastle is an identity posture tool at heart, and many of its highest-value findings concern non-human identities: service accounts in privileged groups, accounts with Kerberos delegation, computer and domain controller accounts whose passwords have not changed, and accounts with old passwords that never expire. Use the export mode and the findings to build an inventory of service and computer accounts with privilege, assign an owner to each, and move suitable ones to group managed service accounts. See the Service Account Security Guide, the Group Managed Service Accounts (gMSA) Guide and the Kerberos Delegation Security Guide.

Deployment and safe use

1. Get authorisation: record approval from the AD owner and security leadership, and the scope (domains, forests, tenant). Running it on domains you do not own, or as a paid service under the open source licence, is not permitted.
2. Tell the SOC: a health check performs broad LDAP and other queries that resemble attacker reconnaissance (T1087.002 Domain Account discovery); notify the SOC with the host, account and time window so it is not escalated, and so genuine reconnaissance from elsewhere is not dismissed.
3. Use a named account: run from a managed admin workstation with a dedicated, named low-privilege account; use --privileged only when you need the AD CS and hotfix checks and with an approved privileged session.
4. Verify the binary: download from the official site or repository, verify its signature or hash, and record the version in the report archive.
5. Protect the reports: HTML and XML reports list privileged accounts, weak configurations and trust paths; they are an attacker's map. Store them in an access-controlled location and share summaries rather than full reports.
6. Schedule and trend: run weekly or after major changes with --level Full, keep the XML, and consolidate with Conso to show trends.
7. Pilot remediation: test each fix (for example banning NTLMv1 or enforcing pre-authentication) in audit or on a pilot OU first, and document how to roll back.

Detection and hardening value

Turning findings into a programme

1. Fix the category that sets the score: because the overall score is the highest category, start there.
2. Prioritise by attack path: rules on privileged accounts, delegation, AD CS and Kerberos weaknesses usually come before cosmetic stale-object findings.
3. Remove dead weight: disable and then delete inactive users and computers after an agreed grace period.
4. Retire legacy protocols: plan NTLMv1, LM and old trust protocol removal with application owners.
5. Re-run and record: the rule disappearing from the next report is the evidence of closure.

Framework mapping

Measuring the capability

• Overall and category scores: per domain, trended weekly, with a reduction target agreed with leadership.
• Critical findings open: count of findings in privileged accounts and anomalies older than 30 days.
• Stale object count: inactive users and computers, trending down.
• Coverage: percentage of domains and forests assessed in the last 30 days (the methodology's level 1 scope).
• Privileged non-human accounts: number of service accounts in privileged groups, with owners assigned.

Common failure patterns

• Chasing the number: teams fix easy, low-point findings to move the score while a delegation or AD CS path to domain admin stays open.
• One-off assessments: the report is produced for an audit and never re-run, so drift returns.
• Reports left on file shares: a detailed map of weaknesses is readable by every user.
• Unannounced scans: the SOC raises an incident, or worse, learns to ignore AD reconnaissance alerts.
• Breaking applications: NTLMv1 or pre-authentication changes made domain-wide without a pilot cause outages and get rolled back permanently.

Alternatives

A small organisation with one domain can run the open source edition monthly and work through the report; large organisations with many forests benefit from consolidation and scheduled runs, and should pair PingCastle with attack path analysis and continuous monitoring. See the Active Directory Security Monitoring and Event IDs Guide.

Practitioner checklist

• Obtain written authorisation and confirm the open source licence fits your use.
• Notify the SOC before each run with source host, account and time window.
• Run --healthcheck --level Full against every domain in scope and keep the XML.
• Use --privileged only when AD CS and hotfix checks are needed.
• Store reports in an access-controlled location.
• Prioritise the highest-scoring category and attack-path findings first.
• Pilot each remediation and record rollback steps.
• Inventory privileged service and computer accounts from the findings and assign owners.
• Re-run weekly and trend scores with Conso.

Standards and references

• Netwrix: PingCastle 4.0 User Guide
• PingCastle: Health check rules list
• PingCastle: Methodology
• GitHub: netwrix/pingcastle repository
• PingCastle: Project site
• MITRE ATT&CK: AS-REP Roasting
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: BloodHound and Active Directory Attack Path Guide · Active Directory and Entra ID Hardening Guide · Top 10 Active Directory Security Risks · Service Account Security Guide