Same product. Different first question.
You need SQL Server on Kerberos and you do not own AD.
Sense reads the instance, the port, and the service account from the machine you already administer. The plan is data you can read. If you cannot write to AD, the hand-off is a setspn script the AD team can review and run. The proof stage reads auth_scheme back so you know it worked.
SQL Always On scenario →- you care about
- Always On listeners, FCI cluster names, SSAS instance names, SSRS custom URL headers, linked-server delegation.
You own the attribute and you are the one who gets the script.
Everything that would write to AD is ShouldProcess-gated and preflighted for rights and duplicates. Windows-owned SPNs are audited, never written. The forest audit gives you three counts, not one, and the unreached list is yours to chase.
What it will not do →- you care about
- Duplicates after account migrations, renames that left orphans, delegation entries pointing at nothing, hosts nobody can reach.
You need findings you can defend, and a coverage number you can trust.
Six read-only audits: delegation in three forms, duplicates, encryption types, keytab drift. Each finding carries the AD evidence it was read from. Coverage is reported as audited-clean, audited-findings, unreached, and a non-zero unreached count is not a clean report.
Audit suite →- you care about
- Unconstrained delegation, RC4-only posture after KB5021131, RBCD grants nobody reviewed, stale keytabs after a password reset.