Page two looks clean
Active Directory answers every search with at most 1,000 objects. Whoever does not page on checks the first 1,000 accounts and takes the rest for clean. Why a hardening report has to say what it did not see, and what that means for score, maturity and the BSI module APP.2.2.
A domain controller has a politeness limit. It is called MaxPageSize, sits in the LDAP policy and has defaulted to 1,000 since Windows 2000. Every search that would match more objects gets the first 1,000 and a result code that many tools do not evaluate.
A tool that does not read page by page therefore checks the first 1,000 accounts of a domain and reports for the rest: nothing. And everyone reads "nothing" as "clean".
The pattern behind the limit
The 1,000 are only the most vivid example of a question that sits in every audit tool: what happens to what could not be read? A read account without rights to the LAPS attributes sees no LAPS coverage. A search that stops at the object limit does not see the second half of the service accounts. A report that does not know the certificate authority sees no ESC weakness.
In all three cases there are two answers. The convenient one: no finding, green. The right one: not assessable, and visibly so.
How the module handles it
The directory security module in isidaten always reads Active Directory page by page. A run that did not read an area to the end counts as incomplete: it writes new findings but closes none, because a finding does not disappear just because the directory was not read to the end. An attribute the read account could not see on any object makes the check "not assessable", and that counts neither as passed nor as failed.
The same rule applies one level up. A domain consists of five areas: what is readable in the directory via LDAP, and four families LDAP does not see, the states of the domain controllers, the certificate authority, the access control lists and the group policies. Coverage is therefore not a traffic light but a map: basic, partial, complete. As long as a family is missing, the interface shows neither maturity nor score for it.
No score on half a basis
This is the uncomfortable part. A risk score from the LDAP checks alone would be a number without the domain controllers, without the certificate authority, without the ACLs. It would look good and be worth nothing. So score and maturity exist only from coverage "partial" upwards, and there is no aggregate across directories with mixed coverage. The widget instead answers the question that comes first: how much has been checked at all.
Where the four families come from
For the four families LDAP does not see, the isidaten agent on the domain controller delivers facts: registry values from an allowlist with fixed paths, service states, RPC filters, the audit policy, the configuration partition of the certificate authority, the decoded access entries of the tier-0 objects, the security templates from SYSVOL. It delivers states, not secrets: a password in group policy preferences is reported as presence plus file name, the value is never read.
Assessment happens on the server. That is not a side note but the reason a new check rule needs no agent release. 18 rules for the domain controllers, 16 for the certificate authority from ESC1 to ESC16, 14 for the access control lists, 14 for the group policies, plus 24 LDAP checks of its own.
The module requires the analysis, not the grade
APP.2.2 requires in A23 the regular analysis of permissions and the attack paths that follow from them. The module’s standards overview says per requirement what evidences it: evidenced, open, partially checked, not checked, not covered. The last line is there on purpose. Red Forest, virtualised domain controllers or the secure channel cannot be checked with directory data and need an organisational review. A tool that drops that line claims a completeness it does not have.
The question to ask
How many accounts does your domain have, and how many of them did the last hardening report read?
If the second number is missing, you do not know whether page two was clean or merely unread.
Sources
Microsoft, LDAP policies in Active Directory (MaxPageSize, default 1,000). BSI IT-Grundschutz-Kompendium, module APP.2.2 Active Directory Domain Services, 2023 edition, requirement A23 (German). BSI IT-Grundschutz, module ORP.4 identity and access management (German). ISO/IEC 27001:2022, A.5.15, A.5.16, A.5.18.
Questions about this update?
Talk to us – we are happy to show you this feature in a demo.