tegwick
30f0d27840
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a1346b-72a4-7d40-b8bd-8b8ca346cfa2
49 lines
3.3 KiB
Markdown
49 lines
3.3 KiB
Markdown
# Verify realm resolution and MFA
|
|
|
|
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
|
|
script prompts for the current pi-admin password and, after lookup succeeds,
|
|
a fresh TOTP/HOTP code including its token PIN if required. It never reads a
|
|
bootstrap bundle or Kubernetes Secret. No password, OTP or token belongs in
|
|
command arguments, logs or the receipt. Do not enable shell tracing.
|
|
|
|
`--realm` and `--resolver` select an approved lookup. `--pi-url` is restricted
|
|
to the canonical provider or a literal loopback target; the CLI requires HTTPS.
|
|
The shared transport verifies system trust and refuses redirects and ambient proxies. The old positional secrets-directory argument is
|
|
removed; `repair-realm-live.sh` now calls this interface and propagates failure.
|
|
|
|
Success requires all of these properties:
|
|
|
|
- pi-admin authenticates and the named realm binds the expected resolver;
|
|
- the resolver is LDAP and `TIMEOUT`, `CACHE_TIMEOUT`, and `SIZELIMIT` are
|
|
present non-negative integers;
|
|
- the exact username resolves through that resolver when queried by realm;
|
|
- `/validate/check` succeeds and identifies a TOTP/HOTP token. Passthrough,
|
|
static-password tokens, denied checks and missing token details fail.
|
|
|
|
Exit 0 means these properties passed; exit 1 means a failed phase; exit 2
|
|
means invalid usage or missing attendance. The sanitized JSON receipt carries
|
|
only result, phase and proof names. A successful OTP validation consumes a code
|
|
and may update token counters or authentication audit state. It does not
|
|
create or repair configuration. This proves the privacyIDEA leg; complete
|
|
KeyCape browser login, OIDC callback, enrollment and recovery remain separate
|
|
exercises. Deployment diagnostics remain in `verify-t04.sh` and `verify-t05.sh`.
|
|
|
|
The response shapes follow the provider's [realm API](https://privacyidea.readthedocs.io/en/stable/modules/api/realm.html),
|
|
[user API](https://privacyidea.readthedocs.io/en/stable/modules/api/user.html),
|
|
[resolver API](https://privacyidea.readthedocs.io/en/stable/modules/api/resolver.html)
|
|
and [validation API](https://privacyidea.readthedocs.io/en/stable/modules/api/validate.html).
|
|
If policy suppresses token details, the verifier cannot establish OTP proof and
|
|
fails; do not weaken that check to accept passthrough.
|
|
|
|
## Attended acceptance still required
|
|
|
|
On an approved scratch target, record the target revision and operator, retain
|
|
the resolver tuning configuration privately, then clear each tuning field in
|
|
turn. Run the verifier and retain each sanitized FAIL receipt. Restore the
|
|
fields and run with a fresh OTP; retain the PASS receipt. Restore the target
|
|
configuration even if any step fails. Do not break the production resolver to
|
|
perform this test. The automated HTTP fixture demonstrates the same failure
|
|
and restoration sequence but does not satisfy this attended exercise.
|