Raised by @thedxt.
ESC5a (Vulnerable PKI Object Access Control) currently flags findings where the dangerous principal is the CA host's own computer account holding rights on its own CA object (\pKIEnrollmentService). This is normal, expected self-management: a CA host legitimately needs access to its own CA object, so these findings are false positives.
Expected behavior
When evaluating ESC5a conditions on a CA object, ACEs whose principal is the CA's own host computer account (e.g., \DOMAIN\CA-HOST01$) should be excluded from \DangerousEditor/\LowPrivilegeEditor\ evaluation.
Distinct from #3
#3 covers false positives from inherited, expected ACEs (Exchange, Entra Connect) on CA host objects. This issue covers the separate case where the principal is the CA host account itself acting on its own CA object.
Possible approaches
- Match \IdentityReference\ against the CA's host computer account (resolvable via the CA's \dNSHostName/host reference) and skip those ACEs during ESC5a evaluation.
- Alternatively, add the CA's own computer account to a per-CA safe-principal list during object enrichment (\Set-*\ pipeline), so the generic detection path never sees it.
Raised by @thedxt.
ESC5a (Vulnerable PKI Object Access Control) currently flags findings where the dangerous principal is the CA host's own computer account holding rights on its own CA object (\pKIEnrollmentService). This is normal, expected self-management: a CA host legitimately needs access to its own CA object, so these findings are false positives.
Expected behavior
When evaluating ESC5a conditions on a CA object, ACEs whose principal is the CA's own host computer account (e.g., \DOMAIN\CA-HOST01$) should be excluded from \DangerousEditor/\LowPrivilegeEditor\ evaluation.
Distinct from #3
#3 covers false positives from inherited, expected ACEs (Exchange, Entra Connect) on CA host objects. This issue covers the separate case where the principal is the CA host account itself acting on its own CA object.
Possible approaches