Skip to content

Add unlock-a-user-without-admin-access page for AA26.1 - #1547

Open
tay-caliguiri wants to merge 3 commits into
devfrom
docs/aa26-unlock-user-no-admin-access
Open

tay-caliguiri wants to merge 3 commits into
devfrom
docs/aa26-unlock-user-no-admin-access

Conversation

@tay-caliguiri

Copy link
Copy Markdown
Contributor
  • Adds a new AA26.1 Settings subpage covering account recovery via Zitadel's API (kubectl + curl) for when every Admin and User admin is locked out and nobody can reach Settings > Users
  • Links to it from the existing "Unlock a User" section in users.md

Resolves https://netwrix.atlassian.net/browse/AA-873

Covers recovering a locked-out account directly through Zitadel when
every Admin and User admin is locked out and nobody can reach Settings
> Users. Linked from the existing Unlock a User section.

Generated with AI

Co-Authored-By: Claude Code <ai@netwrix.com>
Generated with AI

Co-Authored-By: Claude Code <ai@netwrix.com>
@github-actions

Copy link
Copy Markdown
Contributor

Documentation PR Review

Editorial Review

docs/accessanalyzer/26.1/settings/unlock-a-user-without-admin-access.md

  • Completeness — Lines 23–37: PAT is set in the first terminal, but every curl that uses $PAT runs in the second terminal, where the variable doesn't exist. A reader who follows the steps literally sends Authorization: Bearer with an empty token and gets a 401 on the lookup. Suggested fix: retrieve the token in the second terminal instead, and split step 1 — step 1: "Open a tunnel to Zitadel and leave it running: kubectl port-forward svc/zitadel 8085:8080 -n access-analyzer"; step 2: "In a second terminal on the same machine, get the Zitadel admin token: PAT=$(kubectl get secret iam-admin-pat -n access-analyzer -o jsonpath='{.data.pat}' | base64 -d)". Renumber the later steps and the "step 2" cross-references accordingly.
  • Completeness — Lines 9 and 26: the kubectl commands are shown without sudo, and the page never says the commands run as root. Everywhere else in this docset the root requirement is stated explicitly — install/rotate-the-tls-certificate.md line 9 and install/upgrade-to-a-new-version.md line 9 both say "The default kubeconfig at /etc/rancher/k3s/k3s.yaml is readable only by root, so without sudo, kubectl falls back to localhost:8080 and fails with 'connection refused'", and install/first-sign-in.md line 73 says "Run this command on the server as root." Without it, the reader's first command fails with a connection error that the page doesn't explain. Suggested fix: use sudo kubectl in both commands and add the same one-sentence explanation to Before You Start.
  • Structure — Lines 9–19: the prerequisites are split across two places. The kubectl access requirement sits in the overview, while Before You Start covers only the hostname. A reader checking whether they can do this at all has to read both. Suggested fix: keep the overview to what the page does and when to use it, and move the access requirement into Before You Start as the first item: "You need kubectl access to the cluster Access Analyzer is installed on, and root on the install host. You don't need a working Access Analyzer session."
  • Structure — Line 23: step 1 bundles two actions — retrieving the token and opening the tunnel — against the one-action-per-step rule in docs/CLAUDE.md. Suggested fix: split into separate steps, which also resolves the $PAT scoping problem above.
  • Structure — Line 72: the Remove a Lost Authenticator App section isn't signposted anywhere. The frontmatter description and the intro (lines 7–11) describe only unlocking, so a reader looking for the lost-authenticator fix has no reason to open a page titled "Unlock a User Without Admin Access." Suggested fix: add the second task to the description — "…and remove a lost authenticator app when the Users tab can't" — and add a line to the intro: "The same approach also removes an authenticator app a user has lost access to; see Remove a lost authenticator app." Also worth linking from the warning in users.md under Set Up an Authenticator App, which currently says only that someone must remove the app "on the server, outside the web app" without saying how.
  • Completeness — Line 74: "Remove it the same way, using the userId from step 2 above" assumes the reader has already read Before You Start and run steps 1 and 2. Anyone who arrives at this heading from search or a direct link has no hostname, no token, no tunnel, and no userId. Suggested fix: open the section with an explicit pointer — "Complete Before You Start, then run steps 1 and 2 above to open the tunnel, get the token, and find the account's userId. Then remove the authenticator app:".
  • Clarity — Line 9: "This talks to Zitadel…" has no antecedent. The preceding paragraph is about when not to use the page, so "This" points at nothing the reader can name. Suggested fix: "These steps talk to Zitadel, the identity provider behind Access Analyzer sign-in, directly with kubectl and curl instead of through the product API."
  • Clarity — Lines 23 and 30: step 1 says "Run both in the same terminal session," then the follow-up paragraph says "Run the remaining steps from the same machine, in a second terminal." The reader has to work out which commands belong to which terminal. Suggested fix: label the terminals in the step text instead — "In the first terminal, …" and "In a second terminal on the same machine, …" — and drop the "same terminal session" instruction.
  • Clarity — Line 7: "every Admin and User admin account has a lockout" doesn't match the wording used for this state elsewhere. users.md says "An account locks…" and "locked out." Suggested fix: "every Admin and User admin account is locked out".
  • Clarity — Line 15: the sentence carries four ideas at once — that you need the hostname, that Zitadel validates the Host header, the error text, and the FQDN definition. Suggested fix: split it. "You need the installed hostname to reach Zitadel. Zitadel validates the request's Host header against this value and rejects anything else with 'Instance not found,' even after the connection itself succeeds. The hostname is the Fully Qualified Domain Name (FQDN) you chose during installation, so it applies whether or not the host is domain-joined."
  • Structure — Line 4: sidebar_position: 3.5 is the only fractional value in this docset; every other page in settings/ uses an integer (1, 2, 3, 4, 5, 6). Docusaurus accepts the float, so this is a consistency call rather than a build problem. Suggested fix: set this page to 4 and bump single-sign-on.md, backups.md, and system-logs.md to 5, 6, and 7.

docs/accessanalyzer/26.1/settings/users.md

  • No issues found. The added cross-reference sits at the end of Unlock a User, after the normal procedure, which is where a reader who has just found that they can't reach the tab will look. Link text matches the target page title.

Summary

11 editorial suggestions across 2 files. 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

Copy link
Copy Markdown
Contributor

Auto-Fix Summary

5 issues fixed, 6 skipped across 2 files

Category Fixes
OnceUsage (rewrite) 1
WhetherOrNot (rewrite) 1
Dale: passive-voice 2
Dale: positional-references 1
Skipped (needs manual review) Reason
docs/accessanalyzer/26.1/settings/users.md:74 — Netwrix.FirstPerson False positive — the "I" is inside the literal UI label "I have copied this password" for a checkbox in the Password generated dialog. Rewriting it would misquote the product interface and break the reader's ability to match the instruction to the screen.
docs/accessanalyzer/26.1/settings/unlock-a-user-without-admin-access.md:15 — Dale: wordiness The trailing clause 'so it applies the same whether the host is domain-joined' reads as incomplete, but the intended technical claim is ambiguous; any rewrite risks changing the meaning.
docs/accessanalyzer/26.1/settings/unlock-a-user-without-admin-access.md:74 — Dale: xy-slop '...isn't locked out, but the Users tab has no action...' contrasts two different subjects rather than restating one subject in negative-positive form, so it is not the 'x is not y, x is z' pattern.
docs/accessanalyzer/26.1/settings/users.md:71 — Dale: passive-voice Passive wording appears inside a direct quotation of UI text; editing it would misquote the product.
docs/accessanalyzer/26.1/settings/users.md:171 — Dale: passive-voice Passive wording appears inside a direct quotation of UI text; editing it would misquote the product.
docs/accessanalyzer/26.1/settings/users.md:134 — Dale: xy-slop 'their directory governs passwords, not Access Analyzer' carries a needed contrast — dropping the negative half would lose the statement that Access Analyzer does not govern federated passwords.

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

@jth-nw
jth-nw deployed to development September 15, 2026 19:06 — with GitHub Actions Active
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants