NK-WP-0054-T05: privacyIDEA resolver still bound as admin after step 8; fixed live, runbook check added

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 673304@bnt-lap001
Assistant-Session: 959b12c7-cf2e-440b-a60d-91229cc9e96e
This commit is contained in:
tegwick 2026-10-30 21:18:15 +01:00
parent 103c2c1505
commit 08087ec5ac
2 changed files with 17 additions and 2 deletions

View file

@ -36,5 +36,15 @@ UTC, agent (Claude Code) guiding. All receipts are value-free (`values_recorded:
4. Rollouts of identity-provisioner, KeyCape and LLDAP use `Recreate`: each had a short outage of
about 30 s.
5. **privacyIDEA resolver was still bound as `admin` (found 2026-10-30 evening).** After step 10
every OTP check failed: KeyCape logged `mfa_failed` (`openbao-admin`) and `mfa_check_error`
(`user-engine-portal`); privacyIDEA logged `LDAP Bind unsuccessful: invalidCredentials (49)` from
19:00:10 UTC, last successful lookup 18:49:30 UTC, step 10 at 18:53 UTC. Founder found Bind DN
`uid=admin,…` on `lldap-coulomb` in the privacyIDEA UI, set `uid=svc-privacyidea,…` with the custody
`LLDAP_SVC_PRIVACYIDEA_PASS`, and **Test LDAP Resolver** passed. No repository tool rewrites the
resolver, so step 8's apply most likely did not take effect; its OTP check passed only because the
old shared password was still valid. Runbook step 8 now requires the resolver Bind DN and test, and
step 10 a fresh OTP sign-in.
Closing condition still open: the restore drill on the first backup generation after this run
(NK-WP-0053 stages 2-5, T17/T19 under the new accounts).