An Active Directory security assessment is a read of a domain's configuration at one point in time, compared against a set of controls, that reports where the domain falls short and what to do about each gap. It reads settings and memberships; it does not attack anything, and it changes nothing. A good one covers the directory, the domain controllers and the certificate services together, because attackers move between them.

Why does a point in time matter?

Active Directory changes every day. Accounts are created, groups gain members, a GPO is edited to fix one printer. An assessment is a dated record of how the domain stood on the day it was collected, and its value comes from that date:

  • It gives you a baseline to measure the next one against.
  • It shows whether a fix held, when you collect again after the change.
  • It is evidence for an auditor or an insurer that the review happened.

It is not monitoring. A setting changed the day after the collection is not in the report.

What should a good assessment cover?

Eight control areas cover most of what goes wrong.

Privileged identity. Who is in Domain Admins, Enterprise Admins, Schema Admins and the built-in operator groups, including through nested groups. Schema Admins is normally empty. Check the age of the krbtgt password, the account whose key signs every Kerberos ticket; many domains have never reset it since they were built. A reset is done twice, with time for replication and ticket lifetimes between the two.

Service accounts and Kerberoastable SPNs. Any user account with a service principal name can have a ticket requested for it by any domain user, and that ticket can be cracked offline. An account like that in an administrator group is the finding that matters most. The fix is a group managed service account, or a long random password and AES only.

Certificate services. Active Directory Certificate Services is often installed once and forgotten. The misconfigurations were catalogued as ESC1 to ESC8 in SpecterOps' 2021 paper "Certified Pre-Owned", and later research has added more. ESC1, a template that lets the requester name any user in the certificate, can turn an ordinary account into a domain administrator.

Protocols. SMBv1 still enabled, NTLM still accepted where Kerberos would do, LDAP signing and channel binding not enforced on the domain controllers, and old TLS versions on servers.

GPO and SYSVOL hygiene. Group Policy Preferences passwords left in SYSVOL from before 2014, scripts that hold credentials, GPOs that ordinary users can edit, and SYSVOL still replicated by FRS instead of DFSR.

Trusts and functional level. Trusts with SID filtering off or without selective authentication, trusts to domains that no longer exist, and a domain or forest functional level kept low for controllers that were retired long ago.

Password policy. The default domain policy's length and lockout settings, fine-grained password policies and whom they apply to, and accounts with "password never expires" or no password required.

Host configuration on the controllers. The Print Spooler service running on domain controllers, update age, SMB signing, the audit policy, and anything installed on a controller that should not be there.

What do the free tools do well?

Start with the free ones. They are good, and many administrators run them first.

  • PingCastle, now part of Netwrix, produces a fast health check of a domain as one HTML report, scored across stale objects, privileged accounts, trusts and anomalies, with each rule explained. Its licence lets you run it for free as long as you do not derive revenue from it, so a company may assess its own domain; including it in a paid service for other organizations needs a commercial licence.
  • Purple Knight, from Semperis, is free and checks Active Directory, Entra ID and Okta against a published set of indicators of exposure and indicators of compromise, with a short explanation and remediation guidance for each.
  • Microsoft's own tools cover parts of the picture: the Best Practices Analyzer for the AD DS role, dcdiag and repadmin for controller health, and, if you license Defender for Identity, its security posture assessments, listed under the recommended actions of Secure Score in the Microsoft Defender portal.

Where these stop is usually the same place: they report, and the rest of the work is yours. Turning a finding into an agreed change, writing it up for someone outside IT, and proving the fix held all happen outside the tool.

What should the report contain?

Whatever tool you use, each finding should carry four things:

  1. Evidence. The account, the template, the GPO or the registry value that failed, as collected, so an administrator can check it without running anything.
  2. A severity that a reader can follow, with the reason for it.
  3. A fix specific enough to act on, including what to check before you make it.
  4. A rescan. A second collection after the changes, by the same rules, that shows which findings are closed.

A report should also say what it could not read. A setting the tool failed to collect is not a pass, and a report that counts it as one gives false comfort.

How often should you run it?

Quarterly suits most domains: often enough to catch drift, rarely enough that the fixes from the last one are done. Also run it before and after a migration, after a change of administrators or service provider, and after any incident. Collect again after each round of fixes; that rescan is what closes a finding.

Would you rather have it assessed and written up for you?

If you would rather not stitch the tools and the write-up together yourself, GlacierPoint Scan assesses Active Directory, Windows hosts and Microsoft 365 against more than two hundred controls, read-only, and gives you an executive brief for leadership and a technical report for IT.