Close NK-WP-0034: verify-t06 proven FAIL-then-PASS on production
All checks were successful
CI Smoke / host-smoke (push) Successful in 2s
CI Smoke / container-smoke (push) Successful in 5s

Production lldap-coulomb lacked TIMEOUT/CACHE_TIMEOUT/SIZELIMIT since the
2026-08-27 unrepaired apply; the new verifier failed at resolver-tuning,
the repaired attended --apply restored them (DB readback confirmed), and
verify-t06 now passes all four proofs.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 299762@bnt-lap001
Assistant-Session: d3d3cea1-869c-44f1-be2a-3d6d3550e72e
This commit is contained in:
tegwick 2026-09-23 21:20:19 +02:00
parent a22203437b
commit 1da6e5457a
3 changed files with 43 additions and 4 deletions

View file

@ -1,6 +1,6 @@
# Verify realm resolution and MFA
Exercise status: unexercised against a real or scratch privacyIDEA target; simulated HTTP failure matrix passed 2026-09-05 by codex.
Exercise status: exercised on production 2026-09-23 by Bernd Worsch. It returned FAIL at `resolver-tuning` while the fields were missing, and PASS after the repaired resolver apply restored them (evidence in NK-WP-0034). The simulated HTTP failure matrix passed on 2026-09-05. Run it from your own terminal with `ssh -t`; the first prompt is **pi-admin** (`operators/privacyidea/pi-admin`), not the user being verified.
Run `bash sso-mfa/k8s/verify-t06.sh --user platform-root` from the repository
root in an attended terminal. Use an enrolled test user where possible. The

View file

@ -265,3 +265,7 @@ The 2026-09-11 identity-provisioner repair confirmed
Predecessor disposition follows the operator ruling above. T03 and T05 are
done, and the incident `KEYCAPE-EXPOSURE-20260823-01` is closed.
Follow-up the same day: the repaired `--apply` restored the resolver tuning
fields that the 2026-08-27 run had dropped. The receipt passed; see NK-WP-0034
for the details.

View file

@ -4,12 +4,12 @@ type: workplan
title: "Make the SSO/MFA verification actually verify"
domain: infotech
repo: net-kingdom
status: blocked
status: finished
flavor: implementation
owner: codex
topic_slug: infotech
created: "2026-08-28"
updated: "2026-09-05"
updated: "2026-09-23"
related:
- NK-WP-0033
- CUST-ADR-012
@ -47,7 +47,7 @@ is broken, which is worse than no check, because it is believed.
```task
id: NK-WP-0034-T01
status: wait
status: done
priority: high
state_hub_task_id: "9b5d8034-0ef1-53f9-ad4d-37de536bdc62"
```
@ -163,3 +163,38 @@ State Hub reconciliation was attempted with both the installed CLI and current
checkout. Full reconciliation remains pending because API queries/writes timed
out or returned connection-refused errors. Generated index/intake metadata was
reviewed; the source files remain authoritative.
## Attended acceptance — 2026-09-23 (T01 done)
T01's acceptance was demonstrated in both directions on production
privacyIDEA. The fields were **not** cleared on purpose: production had been
missing them since 2026-08-27. The operator was Bernd Worsch, using railiance01
checkout `6096c395`.
1. **FAIL, fields absent.** `verify-t06.sh --user platform-root` failed twice
(runs at 18:41:54 and 18:42:22 server time). The privacyIDEA audit shows
pi-admin auth, `GET /realm/` and `GET /resolver/lldap-coulomb` succeeding,
and no user lookup after them. That places the failure in the
`resolver-tuning` phase. The live `lldap-coulomb` config had 11 keys and
no `TIMEOUT`, `CACHE_TIMEOUT` or `SIZELIMIT`. The unrepaired
`reconcile-lldap-resolver-live.sh --apply` of 2026-08-27 (NK-WP-0033
defect 3) had dropped them, and the old T06 passed regardless.
2. **Restore.** With operator approval, the repaired
`reconcile-lldap-resolver-live.sh --apply --predecessor-unavailable` ran at
19:14:45 and made one resolver write. Before the write, every non-secret
value was confirmed identical to the declared body, and the bind value came
from `operators/lldap/admin` version 1. Receipt: `PASS: resolver lookup,
privacyIDEA MFA, predecessor denial=NOT-PROVEN, readiness, health,
cleanup=PASS`. A database readback shows `TIMEOUT=5`, `CACHE_TIMEOUT=120`
and `SIZELIMIT=500`, 14 keys in total.
3. **PASS, fields restored.** `verify-t06.sh --user platform-root` returned
`{"phase": "complete", "proofs": ["realm-binding", "resolver-tuning",
"known-user-lookup", "token-backed-mfa"], "result": "PASS"}`.
The scratch-target exercise planned earlier in the session is no longer
needed. The failure direction was observed on the real target, attributed
through the audit log, and reversed by the declared remediation.
Two runs in the same session failed at `authentication` because the wrong
pi-admin value was entered (audit: "Wrong credentials"). Neither was a
defect in the verifier.