SysFlint AD

Multi-Domain and Forest-Wide Auditing

Estates that grew by acquisition rarely have one domain. They have three, with different OU conventions, a trust nobody fully documented, and an answer to "how many privileged accounts do we have" that takes a week to assemble because it has to be assembled three times and then reconciled.

Get it freeProduct overview

How this is normally done

Enumerate the domains, loop, and hope the results line up:

Loop the forest, one domain at a time
$forest = Get-ADForest

foreach ($domain in $forest.Domains) {
    $dc = (Get-ADDomainController -DomainName $domain -Discover).HostName[0]

    Get-ADUser -Server $dc -Filter { Enabled -eq $false } -Properties LastLogonDate |
        Select-Object @{ N = 'Domain'; E = { $domain } },
                      Name, SamAccountName, LastLogonDate
}

Where it stops being enough

  • Credentials differ per domain when trusts are one-way or selective.
  • Different OU conventions mean the merged CSV needs manual normalizing before it means anything.
  • Foreign security principals — a user from domain A inside a group in domain B — show up as raw SIDs.
  • Every downstream report has to repeat the same reconciliation work.

What SysFlint AD does instead

One pass over the forest, one report, with the cross-domain details resolved rather than left as SIDs.

  • Enumerates every domain in the forest and runs the same checks consistently across all of them.
  • One consolidated report, with per-domain breakdowns kept intact underneath the totals.
  • Resolves foreign security principals to real accounts, so cross-domain privileged membership is legible.
  • Per-domain credentials where trusts require them.
  • The same scheduling and history apply forest-wide, not per domain.

Frequently asked questions

Does it work across a forest trust?
It audits every domain within a forest by default. Auditing a second forest across a trust is a matter of supplying credentials that can read it.
Do I need to install it in every domain?
No. One installation on one domain-joined machine reads the forest, provided it has network reachability and read rights to the domain controllers involved.
What about read-only domain controllers?
RODCs answer read queries, which is all this tool performs. Where an attribute is not present on an RODC, it reads from a writable domain controller instead.

Related features

Related use cases

Get SysFlint AD

Free, forever. No license keys, no per-user pricing, no seat counts, no trial timer.

Get it freeSee what free includes