Active Directory Scan

Each vulnerability section includes:

• What it means: a plain-language explanation of the risk

• What the scan checks: the specific conditions that trigger the alert

• Why the alert may persist: common partial fixes that are not enough

• How to diagnose: PowerShell commands to identify affected objects

• How to fix: step-by-step remediation

Prerequisites: All PowerShell commands require the ActiveDirectory module and should be run as a Domain Admin on a Domain Controller.

Import-Module ActiveDirectory

Remediation steps are grouped by PingCastle risk category:

• Anomalies

• Privileged accounts

• Stale objects

Frequently Asked Questions

The alert is still showing after I applied the fix. Why?

The AD Scan does not run periodically. After applying a fix, you need to run the script again for the alert to clear. If the alert persists after a new scan, the fix was likely partial. Refer to the "Why the alert may persist" section of the relevant vulnerability. Make sure that you read the details of the vulnerability within your report, it often contains details on the impacted assets.

Do I need Domain Admin rights to run the scan?

Some vulnerabilities (e.g., A-NoServicePolicy) require elevated permissions to read certain AD objects. Running the scan with a Domain Admin account ensures all objects are visible and avoids false alerts caused by insufficient permissions. If not possible, you can still run the script as a simple domain user, though some vulnerabilities may appear because of missing visibility on AD objects.

I fixed one vulnerability but a new one appeared. Is that normal?

Yes. Some fixes can reveal other issues. For example, installing LAPS (fixing A-LAPS-Not-Installed) may trigger A-LAPS-Joined-Computers if computer objects have improper permissions. This is expected: work through each alert in order of severity.