Active Directory security assessment

What the assessment is

MagenX reads Active Directory through the interfaces the directory already exposes to an ordinary domain reader: LDAP and ADWS queries, the Get-AD cmdlets, the ACLs on directory objects, and Group Policy. It runs 255 checks in 34 categories, writes nothing, resets nothing, requests no Kerberos ticket and runs no code on any host. Every finding names the objects behind it and comes with a remediation your team can review before anything changes.

The directory is read alongside three other layers, the network, the FortiGate policy and Microsoft Entra ID, and the four are correlated on the identities and addresses they share. That correlation is what turns a medium finding about one machine account into a route to Domain Admin, and it is the part a directory-only tool cannot do.

What is examined, by category

The categories below are the ones the collector emits, with the number of distinct checks in each. The count is recomputed from the collector before every publication of this page.

ACL Security (26 checks): dangerous access control entries on the domain root, on AdminSDHolder and on organisational units; who can read or write confidential attributes such as LAPS passwords and group managed service account secrets; every result grouped by the principal that holds the right, not by the object it holds it on
Domain Config (20) and Operational Risk (18): the settings of the domain itself, password policy, functional levels, the recycle bin and tombstone lifetime, trusts and domain controllers, and the operational risks around them
AD CS Escalation (14 checks): certificate templates, enrolment rights and PKI objects, checked for the escalation paths they open without ever enrolling a certificate
Privileged Access (18), Tier 0 (7) and Shadow Admins (8): who holds privilege, which tier zero accounts and servers are missing the protection they need, and who can reach Domain Admin through an operator group, DnsAdmins or a directory sync account without ever appearing in it
Cross-Domain (11) and Trust Security (4): trust direction, SID filtering, and the routes that cross a domain boundary
Threat Detection (11): recent changes to privileged objects, attribute anomalies, indicators of compromise, canary accounts and the lateral movement surface; Security Logging (6): whether the audit subcategories, PowerShell logging and event forwarding that would record an attack are actually configured
Credential Exposure (11): passwords and secrets that sit where a reader can find them, in directory attributes, in Unix password attributes hashed with broken algorithms, and hard-coded in Group Policy scripts; Kerberos (7) and NTLM Security (4): accounts with a service principal name and a weak encryption policy, accounts that do not require pre-authentication, the age of the krbtgt password, and where NTLM is still permitted
LAPS (9), LAPS Permissions (3) and LAPS Tier Violations (5): whether local administrator passwords are managed, which computers lack one, who can read them, and where a lower tier can read a higher tier's
Delegation (4): unconstrained, constrained and resource-based delegation, read from the account attributes
Account Hygiene (8) and Account Lifecycle (3): users and computers stale for ninety days, passwords that never expire or are not required, reversible encryption, and the Pre-Windows 2000 Compatible Access group
GPO Security (4), Delegated Managed Service Accounts (7), Backup & Recovery (8), Auth Policies (10), Shadow IT (4), OS Hygiene (4) and the rest of the 34

The rule every finding obeys

A read that fails is never reported as a clean result. A group membership query can throw when the group holds a foreign security principal; an ACL read can be refused; a domain controller can time out. When that happens MagenX emits a finding that says the read failed and names the error, and scores it as unassessed. It never writes "0 members" or "no dangerous ACLs" over a question it could not answer. The precedent that made this a rule was the Pre-Windows 2000 group, where a swallowed error produced a reassuring zero on exactly the estate where the group held Authenticated Users.

The second rule is about confidence. When a value comes from what a Group Policy Object sets, MagenX marks it Inferred, because the directory knows the policy and cannot see the machine. The chip on every finding card tells your team exactly what kind of evidence they are acting on.

Two examples of what precision changes

An account with a service principal name is reported as Kerberoastable, and a second finding singles out the accounts that still allow RC4, the cipher that makes offline cracking cheapest. MagenX reads both from the account itself and never requests a ticket, because requesting it is the attack.

An access control entry on AdminSDHolder propagates to every protected account within the hour. A principal holding GenericAll or WriteDACL there is a domain administrator in effect and will appear in no privileged group. MagenX reports that principal as a shadow administrator and draws the path, because a membership audit will never show it.

From a finding to a closed task

Every finding has its own link, tied to the finding itself, so it survives the next scan and drops straight into a ticket. Assign it to a person or a group with a due date, and every scan shows how many of the affected objects are fixed until the task is confirmed closed. A fix is a measured change, never a disappearance.

With scheduled scans, MagenX keeps a running history of what changed between them: a new member of Domain Admins, a computer joined by a user account instead of a build service, resource-based delegation newly granted on a computer. When the directory records who made a change, the report names them.

Several domains in one assessment

A single scan can carry several domains. Each additional domain is scored on its own tab from its own findings, and the primary domain's headline score excludes them by design, so a weak child domain cannot hide inside a strong parent's number. Principals are matched across domains under both of the names a domain has, the DNS name and the NetBIOS name, because access control entries carry one and account rows carry the other.

What it does not do

MagenX assesses the directory; it does not attack it. It does not spray passwords, request service tickets, replicate the directory, forge tickets, relay NTLM or run an ingestor that authenticates as a user. It does not read the configuration of workstations or member servers; it reads what the directory and Group Policy say about them, and marks the difference. It does not change anything: the remediation on a finding is text and, where one applies, a script the owner can read and download, and MagenX never runs it.

FAQ

What permissions does the assessment need?

Ordinary domain read access. A few checks need more only where an organisation has restricted normal directory reads, and the finding for such a check says that the read was refused rather than reporting a clean result. Scans can run as the logged-in user or as a dedicated service account.

Can it assess more than one domain?

Yes. Additional domains are read in the same scan, each with its own tab and its own score, and MagenX reports the trust paths and cross-domain exposure between them.

How is this different from an attack path graph built by an ingestor?

Two ways. The graph is built from directory reads alone, so nothing runs as a user on any of your hosts. And any route can be checked against your firewall policy, step by step, to see which steps the network actually permits.

How often should it run?

Nightly, weekly or twice daily on a schedule. The change history is built from the scans already scheduled, so the resolution of the history is the scan interval. A weekly scan gives a weekly history.

Does the assessment touch domain controllers?

MagenX only reads from them. It installs no software on a domain controller and runs no code there, and MagenX itself goes on a member server.