Skip to content

LPM for AD CA collection - #1310

Open
tay-caliguiri wants to merge 2 commits into
devfrom
naa-adca-lpm-doc
Open

LPM for AD CA collection#1310
tay-caliguiri wants to merge 2 commits into
devfrom
naa-adca-lpm-doc

Conversation

@tay-caliguiri

Copy link
Copy Markdown
Contributor

No description provided.

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Documentation PR Review

Editorial Review

docs/accessanalyzer/12.0/requirements/activedirectory/target/access.md

  • Structure/Consistency — Line 230: The job path is written as 7.Certificate Authority > Collection > AD_CACollection, but every comparable collection job in this document uses a numbered Collection node — for example 5.Domains > 0.Collection > AD_DomainControllers (line 169) and 6.Activity > 0.Collection > AD_ActivityCollection (line 221). If the UI node is actually 0.Collection, this path is missing the 0. prefix and will not match what the reader sees in the product. Suggested fix: confirm the exact node name and align it with the established pattern, e.g. 7.Certificate Authority > 0.Collection > AD_CACollection.

  • Completeness — Lines 240–241: The info admonition tells the reader to "escalate incrementally (Read, then Enroll, then Officer, then Manage CA)," but these Certification Authority permission levels are introduced here without explanation. The requirements list above only mentions a single "Read permission," so a newer user has no reference point for what Enroll, Officer, or Manage CA grant or where to set them. Suggested fix: briefly note that these are the standard Certification Authority security roles assigned on the same Certification Authority console Security tab referenced in the requirements list, so the reader knows where to apply each level.

  • Completeness — Lines 240–243: The escalation guidance triggers on the job failing to collect "Certification Authority security, registry, or enrollment agent data," but the reader is not told which escalation step corresponds to which data type. This leaves the reader guessing how far up the ladder to go for a given failure. Suggested fix: if the mapping is known, indicate which permission level unlocks each data category (for example, which level enables enrollment agent data), or state that the reader should stop at the lowest level that resolves their specific failure.

Summary

3 editorial suggestions across 1 file. Vale and Dale issues are auto-fixed separately.


What to do next:

Comment @claude on this PR followed by your instructions to get help:

  • @claude fix all issues — fix all editorial issues
  • @claude help improve the flow of this document — get writing assistance
  • @claude explain the voice issues — understand why something was flagged

You can ask Claude anything about the review or about Netwrix writing standards.

Automated fixes are only available for branches in this repository, not forks.

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Auto-Fix Summary

14 issues fixed, 5 skipped across 1 files

Category Fixes
Contractions 7
Plurals 1
Substitutions 1
Dale: passive-voice 2
Dale: positional-references 1
Dale: wordiness 2
Skipped (needs manual review) Reason

| docs/accessanalyzer/12.0/requirements/activedirectory/target/access.md:24 — Dale: passive-voice | 'domain controllers to be scanned' — making it active would change who performs the scan; meaning ambiguous. |
| docs/accessanalyzer/12.0/requirements/activedirectory/target/access.md:64 — Dale: passive-voice | 'The following firewall ports are needed:' — an active rewrite ('Open the following ports') would alter the meaning of a requirements intro. |
| docs/accessanalyzer/12.0/requirements/activedirectory/target/access.md:190 — Dale: wordiness | 'just requiring access added to the winreg key' is awkward, but the intended relationship between the Lsa and winreg keys is ambiguous; a rewrite risks changing meaning. |
| docs/accessanalyzer/12.0/requirements/activedirectory/target/access.md:203 — Dale: wordiness | 'just requiring access added to the winreg key' is awkward, but the intended meaning is ambiguous; a rewrite risks changing meaning. |
| docs/accessanalyzer/12.0/requirements/activedirectory/target/access.md:114 — Dale: passive-voice | 'which must be configured at the Domain level' has no natural active subject without adding assumptions. |

Ask @claude on this PR if you'd like an explanation of any fix.

@tay-caliguiri tay-caliguiri added the access-analyzer This change or issue involves Access Analyzer. label Aug 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

access-analyzer This change or issue involves Access Analyzer.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants