tegwick
1da6e5457a
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
48 lines
3.1 KiB
Markdown
48 lines
3.1 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.
|
|
|
|
`--pi-url`, `--realm`, and `--resolver` select a different approved target.
|
|
The CLI requires HTTPS. 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.
|