From 205bddb3b8ee0cb111a96e8fbce76c6311d38f32 Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Thu, 13 Aug 2026 15:01:15 -0400 Subject: [PATCH] docs(plan): flag ignitionoee LDAP as ON HOLD -- needs new UG_WW_* groups minted first --- docs/plans/2026-08-13-vd03-nam-ldap-cutover.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/plans/2026-08-13-vd03-nam-ldap-cutover.md b/docs/plans/2026-08-13-vd03-nam-ldap-cutover.md index f2eab76..3bb8093 100644 --- a/docs/plans/2026-08-13-vd03-nam-ldap-cutover.md +++ b/docs/plans/2026-08-13-vd03-nam-ldap-cutover.md @@ -24,6 +24,12 @@ Out of scope: windev's OtOpcUa/mxgw instances, the QA pair (VQ03/VQ04 — do it follow-on once VD03 has soaked; QA is where the 2-node/failover behaviour actually gets exercised), and OtOpcUa's OPC UA data plane (API-key auth since Gitea #520). +> ⚠️ **ignitionoee (router): LDAP setup ON HOLD** — explicit decision 2026-08-13. Its role +> vocabulary is not the canonical set (its admin role is literally `"Admin"`, not +> `"Administrator"`), so no existing `UG_WW_*` group maps onto it — a NAM cutover there +> would first require **minting new AD groups**. Do not wire its LDAP as part of this plan +> or its follow-ons; it keeps its current auth until the groups exist and are decided. + ## The target LDAP block (identical shape in all four apps) ```jsonc @@ -251,3 +257,5 @@ Phase 1's redeploys are independent and should NOT be rolled back for an auth pr glauth-redundant pair (uncommitted working-tree change, independent of this plan). - ldap_mapping.md is still untracked in scadaproj — commit it when its DECIDE items settle; this plan depends on its §4 tables. +- ignitionoee LDAP: **held** (see the Scope flag) until new `UG_WW_*` groups matching its + role vocabulary are minted and mapped — a group-creation request, not a config task.