docs(index): Auth 0.2.1 published -- AD referral fix + NAM group findings
CLAUDE.md: feed now carries 0.2.1; record the referral defect and that every app is still exposed until it bumps off 0.1.5 (a functional fix, not housekeeping), plus the new tools/LdapProbe. ldap_setup.md: findings from probing the live NAM directory -- - LDAPS 636, StartTLS 389 and plain 389 all connect on both DCs. The only TLS chain error is UntrustedRoot, so installing zimmer-rootca is sufficient; the RSA 1024-bit key is rejected only by OpenSSL at SECLEVEL=2, i.e. Debian .NET containers, not by macOS or Windows hosts. - The UG_WW_* Wonderware group convention, 39 groups enumerated directory-wide. This partly overturns this doc's earlier "no group->role convention exists" claim: that was true of Ignition, which was the only source audited, and false of the domain. Three shapes with a consistent role suffix (ADMIN, RO, OPERATOR, ENGINEER, SUPERVISOR, TESTER) across environment and site axes. - A proposed mapping onto CANONICAL-ROLES, with the three gaps left open rather than guessed: SUPERVISOR/TESTER have no canonical equivalent, nothing maps to Deployer, and the DEV/QA/PROD axis is orthogonal to role so it must ride in the per-project scope payload or the role set triples. - The referral defect and its fix.
This commit is contained in:
Joseph Doherty
@@ -141,7 +141,7 @@ each project's **code-verified current state**, and the **gaps** between. See
|
||||
|
||||
| Component | Status | Goal | Design | Implementation |
|
||||
|---|---|---|---|---|
|
||||
| Auth (login / identity / authz) | Adopted (**feed now carries `0.2.0`**; all four apps still pin `0.1.5` = `0.1.4` + the SQLitePCLRaw transitive security pin; merged to **local default** main/master + **pushed to origin** (gitea)). **`0.2.0` (2026-08-10) adds LDAP backup-DC sticky failover** — see the Auth narrative below; app pin-bump is a follow-up. | Shared `ZB.MOM.WW.Auth` lib | [`components/auth/`](components/auth/) | [`ZB.MOM.WW.Auth/`](ZB.MOM.WW.Auth/) |
|
||||
| Auth (login / identity / authz) | Adopted (**feed now carries `0.2.1`**; all four apps still pin `0.1.5` = `0.1.4` + the SQLitePCLRaw transitive security pin; merged to **local default** main/master + **pushed to origin** (gitea)). **`0.2.0` (2026-08-10) adds LDAP backup-DC sticky failover**, **`0.2.1` (2026-08-12) fixes a defect that broke AD logins outright** — an AD continuation referral escaped `NovellLdapConnection.Search`, so any `SearchBase` at a domain root failed every login as `ServiceAccountBindFailed` against a perfectly healthy directory. Live-proven against `DC=nam,DC=zimmer,DC=com`. **Every app is still exposed until it bumps** — see the Auth narrative below; app pin-bump is a follow-up. | Shared `ZB.MOM.WW.Auth` lib | [`components/auth/`](components/auth/) | [`ZB.MOM.WW.Auth/`](ZB.MOM.WW.Auth/) |
|
||||
| UI Theme (layout / tokens / components) | Adopted (feed `0.2.0`–`0.4.1`). **`0.4.0` (2026-08-11) upstreamed the Bootstrap `.btn`/`.btn-sm` sizing block** that all **five** consumers had independently written into their own stylesheets (Bootstrap hard-codes `--bs-btn-font-size: 1rem`, oversized against the kit's 0.9rem body) — sized by `--bs-btn-*` variable override **only**, never by redeclaring box properties, because `.btn-group`'s seam/radius machinery reads those same variables and a literal `font-size` at equal specificity silently flattens `.btn-sm` into a padding-only difference (a real defect found in mxgw's local copy). Same release added the `rail-btn-block` full-width rail-foot modifier; **`0.4.1` fixes it** — 0.4.0 shipped `width: auto`, which fills for an `<a>` but shrink-wraps a `<button>` (measured 114px short in the same rail), now `calc(100% - 1.2rem)` to clear `.rail-btn`'s side margins. **Consumers are five, not four** — the ignitionoee router joined. **All five consumers are on `0.4.1` and all five are PUSHED** (2026-08-11): ignitionoee `main @ 38aa5c1`, OtOpcUa `master @ e82881c1`, mxgw `main @ 0a9715d`. The two whose sweeps were not deploy-ready pushed to **branches**, deliberately leaving their default branch untouched: HistorianGateway `dashboard-ui-sweep-theme-0.4.1 @ df7b879` (`main` stays `e9c31da`) and ScadaBridge `ui/central-ui-cleanup-sweep @ 9e243493` (`main` was then `b6f383a2`). **ScadaBridge's caveat is now CLOSED and its sweep is merged, deployed and live** (2026-08-11): the branch landed on `main`, and the two follow-ups `d14e0ee4` + `3eb7df74` fixed exactly the four detail-modal surfaces the caveat named — the modal is now gated on **user intent (the held id)**, never on the row still resolving, so a background refresh that drops the row leaves it mounted and says why the summary is missing instead of unmounting the subtree and disposing Close's own handler mid-click. That disposal *was* the intermittent `GetRequiredEventBindingEntry`, and `NotificationReportDetailModalTests.Modal_StaysOpen_WhenItsRowLeavesThePage` now pins it. **Deployed to wonder-app-vd03: OtOpcUa `e82881c1`, and ScadaBridge `3eb7df74` (2026-08-11 — theme.css/layout.css/nav-state.js served from `_content/ZB.MOM.WW.Theme` and referenced by the pages; all six changed routes 200). HistorianGateway is still `e9c31da` = 0.3.1 — its 0.4.1 remains on the branch.** **On bump, TRIM the local `.btn` block, don't delete it** — four of the five were pure sizing, but mxgw's also carried `border-radius`/`font-weight`/`white-space` that a blind delete would have dropped. | Shared `ZB.MOM.WW.Theme` RCL | [`components/ui-theme/`](components/ui-theme/) | [`ZB.MOM.WW.Theme/`](ZB.MOM.WW.Theme/) |
|
||||
| Health (readiness / liveness / active-node) | **Adopted** (feed carries `0.1.0`–`0.3.0`, current lib version **`0.3.0`**; **all 4 apps** reference it + wire `MapZbHealth`). **`0.2.0` (2026-07-24)** added an optional per-entry `data` object to the canonical health JSON and made `AkkaClusterHealthCheck` publish its cluster view (`leader`/`selfAddress`/`selfRoles`/`memberCount`/`unreachableCount`) — additive, so pre-0.2.0 payloads still parse. **`0.2.1` (2026-07-24) is a behaviour fix with a live consumer impact:** the active tier now returns **Unhealthy (503)** on a role-member-but-not-leader node instead of `Degraded`, which the spec maps to 200. The old value made `/health/active` answer 200 on *every* node, so it could not distinguish active from standby over HTTP at all — and OtOpcUa's Traefik routes the admin UI by exactly this probe, so its leader-pinning had silently never worked ([`lmxopcua#494`](https://gitea.dohertylan.com/dohertj2/lmxopcua/issues/494)). **`0.3.0` (2026-07-24) finished that fix and ENDED a family-wide duplication.** 0.2.1 made the tier a real 503 but still selected by `RoleLeader`; on a rebuilt rig the two orderings diverge live (akka leader `central-1`, oldest admin `central-2` — the singleton host), so it would have pinned Traefik to the node *not* hosting the work. **Leadership is address-ordered (host, then port) and has no relationship to time; singleton placement is age-ordered.** They agree on a freshly-formed cluster — which is why single-node and happy-path tests never caught it — and diverge permanently after any restart. Both Akka apps had already discovered this independently and each written a private replacement rather than use the shared check (ScadaBridge `OldestNodeActiveHealthCheck`, OtOpcUa `ClusterPrimaryHealthCheck`), so the package's entire active-node surface had **zero consumers — not unused but avoided, twice, for the same reason.** 0.3.0 promotes those two into one `ClusterActiveNode` primitive (oldest `Up` member, optional role scope, plus an ordered role-preference so a fused node answers for the role its singletons are pinned to); `ActiveNodeHealthCheck` and `AkkaActiveNodeGate` both delegate to it, and results now carry `activeRole`/`selfAddress`/`activeNode` in the 0.2.0 `data` object so a **standby reports who IS active**. Two further behaviour changes: a node holding **none** of the preferred roles is now **Unhealthy**, not Healthy — the old "not applicable ⇒ Healthy" is exactly what made the tier answer 200 everywhere, and the case is reachable (OtOpcUa's `RoleParser` admits `dev`-only and `cluster-`only nodes); and identity compares `UniqueAddress`, so a node restarted on the same host:port is correctly a different member. **Both apps migrated and their private copies deleted** — OtOpcUa (`feat/health-0.3.0-active-node` @ `88adec04`) also routes `RedundancyStateActor.SelectOldestUpMemberOfRole` through the shared primitive, so the tier and the OPC UA `ServiceLevel` 250/240 split cannot drift; ScadaBridge (`feat/site-node-health` @ `5d4853a1`) routes `ActiveNodeEvaluator` through it, unifying the S&F delivery gate, the heartbeat `IsActive` stamp, the inbound-API gate and the health tier on one rule. ScadaBridge keeps `SitePairActiveNodeHealthCheck` deliberately — it is a thin adapter over the site's own role-scoped `IClusterNodeProvider` (itself now backed by the shared rule), not a second copy of it. mxgw/HistorianGateway have no Akka cluster and are unaffected. **Both app branches are MERGED and PUSHED** (verified 2026-08-07): OtOpcUa `88adec04` is on `origin/master`; ScadaBridge merged via `b3dc17a5` (2026-07-24) on `origin/main`, private-copy deletions included. | Shared `ZB.MOM.WW.Health` lib | [`components/health/`](components/health/) | [`ZB.MOM.WW.Health/`](ZB.MOM.WW.Health/) |
|
||||
| Observability (metrics / traces / logs) | **Adopted** (libs `0.1.0`, on the feed; **all 4 apps** call `AddZbTelemetry`; `AddZbSerilog` in all but ScadaBridge, which keeps its own factory by design) | Shared `ZB.MOM.WW.Telemetry` lib + `.Serilog` | [`components/observability/`](components/observability/) | [`ZB.MOM.WW.Telemetry/`](ZB.MOM.WW.Telemetry/) |
|
||||
@@ -171,6 +171,9 @@ canonical-six role vocabulary (with ScadaBridge's accepted auditor/admin SoD col
|
||||
Build/test from `ZB.MOM.WW.Auth/`: `dotnet test`. Consumer matrix: OtOpcUa → Abstractions+Ldap+AspNetCore;
|
||||
MxAccessGateway & ScadaBridge → all four (ApiKeys not used by OtOpcUa).
|
||||
**`0.1.4` (2026-07-09, archreview G-2):** optional `ApiKeyRecord.ExpiresUtc` (nullable = never-expires), `ApiKeyFailure.KeyExpired`, `ApiKeyVerifier` expiry enforcement (inclusive, injected clock), a `CreateKeyAsync(expiresUtc)` overload, and a SQLite **schema v3** additive `expires_utc` column (idempotent `ALTER`; donor v2 DBs upgrade in place, no key invalidated). **All four Auth pkgs published to the Gitea feed at `0.1.4`** (2026-07-09). **HistorianGateway adopted the expiry surface at `0.1.4`** — `apikey create --expires` + dashboard Expires column (Task-10 done). **`0.1.5` (2026-07-18)** is `0.1.4` plus the `SQLitePCLRaw.lib.e_sqlite3 2.1.12` transitive security pin (GHSA-2m69-gcr7-jv3q), no API change; all four apps now pin it (see consumer pins above). **`0.2.0` (2026-08-10) — LDAP backup-DC sticky failover** (plan `docs/plans/2026-08-10-ldap-backup-dc-failover.md`, design `…-design.md`; **4 pkgs published to the feed, restore-verified**; family `Directory.Build.props` now `0.2.0`): one additive `LdapOptions.FallbackServers` list (`"host"` or `"host:port"`, empty default = failover off, single-endpoint behaviour byte-unchanged) makes `LdapAuthService` walk an ordered endpoint list (primary + fallbacks) on **system-side failures only** — connect/TLS, service-account bind, or search. A user-side answer from a healthy directory (`Success`/`UserNotFound`/`AmbiguousUser`/`BadCredentials`/`GroupLookupFailed`) is **final and never retried elsewhere** (re-asking a second DC about a rejected password would multiply one bad-password event into several against the account lockout policy). Endpoint preference is **sticky** — the last endpoint that gave *any* authoritative answer (success **or** a user-side failure) is tried first next time — so a primary outage costs its connect timeout once, not per login; an exhausted walk leaves the preference untouched. Fail-closed contract preserved per-endpoint; boot validation rejects a malformed `FallbackServers` entry naming the field; optional `ILogger<LdapAuthService>` emits a Warning per failed hop (endpoint + stage, no secrets) and an Information on sticky change; wired via `AddZbLdapAuth` (`GetService`, so logging is optional). Motivation: the ZB production directory is NAM AD with two DCs. Unit suite covers the walk/stickiness (14 tests) + env-gated live GLAuth failover test (`ZB_LDAP_IT=1`). **No `Abstractions` contract change beyond the new option; no `LdapAuthFailure` enum change.** App adoption (pin bump to `0.2.0` + authoring `FallbackServers`) is a follow-up.
|
||||
**`0.2.1` (2026-08-12) — AD continuation referrals no longer fail the search** (**4 pkgs published to the feed, restore-verified**; the assembly restored *from the feed* carries the fix and `0.2.0` does not — checked as a positive control, not by trusting the push). Active Directory answers **any search based at a domain root** with continuation references (to `CN=Configuration`, `DC=ForestDnsZones`, …). With referral following disabled — the default, and what we want, since chasing one would re-bind somewhere we never authenticated — Novell surfaces each by throwing `LdapReferralException` from `Next()`. That escaped `NovellLdapConnection.Search`, and `LdapAuthService` maps a failed search to `ServiceAccountBindFailed`, so **every login against `SearchBase = DC=nam,DC=zimmer,DC=com` failed system-side on both DCs while the directory, the credentials and the service account were all healthy** — ~546 ms, identical on each endpoint, so failover could not help either. Found by the new `tools/LdapProbe` (below) and live-proven fixed against the ZB NAM domain root. The search loop now skips referrals (`ReadEntries(ILdapSearchResults)`, extracted so it is unit-testable through the Novell seam without a live directory) and continues; a 1000-referral cap guards a client that throws without advancing, since that would spin forever inside a fail-closed auth path. **Non-referral faults still propagate** — swallowing those would turn "the directory is broken" into "no such user", which is the wrong answer to give about someone's credentials. 7 new tests (`NovellSearchReferralTests`), **6 verified red against the pre-fix code**, the seventh being the non-referral control that must stay green; suite 257 pass / 2 skip / 0 fail. **No `Abstractions` change; no config change.** **Consumer impact: an app on `0.1.5` cannot authenticate against an AD domain root at all**, so the pin bump is a functional fix, not housekeeping — and it is a four-minor jump that also lands `0.2.0`'s `FallbackServers`.
|
||||
|
||||
**`tools/LdapProbe`** (`ldapprobe`, not packable, outside the Auth solution) is the diagnostic that found the above: it drives the **real** `LdapAuthService` so its verdict is what the four apps produce, then separately queries the directory for what the library cannot report — full group DNs, **nested** groups via `LDAP_MATCHING_RULE_IN_CHAIN`, the **primary group** (which AD omits from `memberOf`, so it can never be a role group), group type (security vs distribution), decoded `userAccountControl`, referral counts, and the TLS chain with key sizes. `--list-groups '<pat>'` enumerates every group in the directory matching a pattern, which a membership dump structurally cannot do. Findings recorded in [`ldap_setup.md`](ldap_setup.md), including the **`UG_WW_*` Wonderware group convention (39 groups)** that partly overturns that doc's earlier "no group→role convention exists" claim — it was true of Ignition, false of the domain.
|
||||
|
||||
The UI-theme component is fully populated: a normalized [`spec`](components/ui-theme/spec/SPEC.md),
|
||||
a [`design-tokens`](components/ui-theme/spec/DESIGN-TOKENS.md) reference, a
|
||||
|
||||
+202
@@ -55,6 +55,12 @@ existing pattern) or define new AD groups deliberately; standard AD attributes
|
||||
(`memberOf`, filter `(&(objectClass=group)(member={0}))`) are available if we
|
||||
choose to.
|
||||
|
||||
> **Superseded in part (2026-08-12).** The statement above is correct *about Ignition*,
|
||||
> which was the only source audited. It is wrong as a claim about the domain: a
|
||||
> `UG_WW_*` Wonderware group convention does exist, already scoped by environment and
|
||||
> site — see [`UG_WW_*`](#ug_ww_--an-existing-wonderware-group-convention-observed-2026-08-12).
|
||||
> Read that before choosing an authorization design.
|
||||
|
||||
## Behavioral notes from the working config
|
||||
|
||||
- Users are **populated on demand**: a local record is created on first
|
||||
@@ -102,3 +108,199 @@ Implications for new .NET services:
|
||||
- Hostnames resolve from the dev network: nam1 = `10.201.216.2`,
|
||||
nam2 = `10.201.138.78`.
|
||||
|
||||
## Probe tool
|
||||
|
||||
[`tools/LdapProbe`](tools/LdapProbe/) (`ldapprobe`) tests these settings interactively and
|
||||
dumps a user's group membership. It drives the real `ZB.MOM.WW.Auth.Ldap` library, so its
|
||||
verdict is what the four apps will produce, and separately queries the directory for the
|
||||
things the library cannot report — nested groups, the primary group, group types and
|
||||
referral behaviour.
|
||||
|
||||
```bash
|
||||
dotnet run --project tools/LdapProbe -- --insecure --self-bind <sAMAccountName>
|
||||
dotnet run --project tools/LdapProbe -- --sweep --insecure # connectivity only
|
||||
```
|
||||
|
||||
### Re-verified 2026-08-12 (from the dev Mac, via ldapprobe `--sweep`)
|
||||
|
||||
All six endpoint/transport combinations connect: **LDAPS 636, StartTLS 389 and plain 389
|
||||
on both DCs** (~210–235 ms TLS, ~32 ms plaintext).
|
||||
|
||||
Two refinements to the TLS notes above, from the actual chain a .NET client sees:
|
||||
|
||||
- The only validation error is **`UntrustedRoot`** — `SslPolicyErrors` is
|
||||
`RemoteCertificateChainErrors`, and both the leaf and `zimmer-issueca1` report `ok`.
|
||||
So **installing `zimmer-rootca` is sufficient** to make LDAPS work without any
|
||||
validation bypass.
|
||||
- **.NET on macOS accepts the RSA 1024-bit key.** The weak-key rejection is specific to
|
||||
OpenSSL at `SECLEVEL=2`, i.e. Debian-based .NET *containers* — it is not a
|
||||
cross-platform blocker, and a Windows host is unaffected too. That matters because
|
||||
three of the four apps deploy to Windows on `wonder-app-vd03`, where this hazard does
|
||||
not apply at all; only containerized deployments need the SECLEVEL workaround or a
|
||||
reissued 2048-bit cert.
|
||||
|
||||
Cert observed on nam1: `CN=USWAP-VDC-NAM1.nam.zimmer.com`, SAN matches, sha256RSA,
|
||||
valid 2026-03-20 → 2027-03-20, chain `leaf ← zimmer-issueca1 ← zimmer-rootca`.
|
||||
|
||||
### `UG_WW_*` — an existing Wonderware group convention (observed 2026-08-12)
|
||||
|
||||
**This partly overturns the "Groups / roles" section above.** That section is accurate
|
||||
about *Ignition* — it ignores AD groups and assigns roles per-user. But the Wonderware
|
||||
estate does have a group convention, and it is already environment- and site-scoped.
|
||||
|
||||
**Full directory inventory, 39 groups** — enumerated 2026-08-12 with
|
||||
`ldapprobe -g 'UG_WW_*'` against `DC=nam,DC=zimmer,DC=com` (not one account's membership;
|
||||
16 of these are held by nobody on the probing account). **Every one is a `universal
|
||||
security` group** — exactly the shape `ZB.MOM.WW.Auth.Ldap` consumes, with no nesting
|
||||
problem and no distribution-group trap. Member counts are as observed.
|
||||
|
||||
**Platform, environment-scoped** — one set per `DEV`/`QA`/`PROD`:
|
||||
|
||||
| Group | Members | Notes |
|
||||
|---|--:|---|
|
||||
| `UG_WW_APP_ADMIN_{DEV,QA,PROD}` | 7 / 6 / 5 | Application Server admin |
|
||||
| `UG_WW_APP_IDE_{DEV,QA,PROD}` | 6 / 6 / 4 | ArchestrA IDE — Galaxy authoring |
|
||||
| `UG_WW_APP_IDE_RO_{DEV,QA,PROD}` | 2 / 1 / 1 | **read-only** IDE tier |
|
||||
| `UG_WW_HIST_ADMIN_{DEV,QA,PROD}` | 7 / 6 / 4 | Historian admin |
|
||||
| `UG_WW_CITRIX_{DEV,QA}` | 6 / 12 | Citrix access; no PROD group exists |
|
||||
| `UG_WW_BTMGR_BE_{QA,PROD}` | 3 / 5 | Batch Manager, plant BE |
|
||||
| `UG_WW_BTMGR_MC_{QA,PROD}` | 2 / 5 | Batch Manager, plant MC |
|
||||
| `UG_WW_BTMGR_RO_{QA,PROD}` | **EMPTY** / 4 | read-only Batch Manager |
|
||||
|
||||
**Site admin** — `UG_WW_SITE_ADMIN_<SITE>`, 6 members each, sites
|
||||
`BER GAL PAR PON SHN WN0A WW05 WW19`.
|
||||
|
||||
**Plant-floor, per site and area** — this is the tier with real operator populations:
|
||||
|
||||
| Group | Members |
|
||||
|---|--:|
|
||||
| `UG_WW_B19_SMS_OPERATOR` | 34 |
|
||||
| `UG_WW_B19_SMS_TESTER` | 13 |
|
||||
| `UG_WW_B19_VitE_ENGINEER` | 4 |
|
||||
| `UG_WW_B19_VitE_OPERATOR` | 10 |
|
||||
| `UG_WW_PON_PRESS_ENGINEER` | 14 |
|
||||
| `UG_WW_PON_PRESS_OPERATOR` | 21 |
|
||||
| `UG_WW_WN_ARCOM_OPERATOR` | 5 |
|
||||
| `UG_WW_WN_ARCOMXL_OPERATOR` | 2 |
|
||||
| `UG_WW_WN_SOLAR_OPERATOR` | 10 |
|
||||
| `UG_WW_WN_STERIS_OPERATOR` | 5 |
|
||||
| `UG_WW_WN_STERIS_SUPERVISOR` | 6 |
|
||||
|
||||
Decoded convention — three shapes, and a consistent **role suffix**:
|
||||
|
||||
```
|
||||
UG_WW_<FUNCTION>[_RO]_<ENV> APP_ADMIN | APP_IDE | HIST_ADMIN | BTMGR | CITRIX
|
||||
UG_WW_SITE_ADMIN_<SITE> BER GAL PAR PON SHN WN0A WW05 WW19
|
||||
UG_WW_<SITE>_<AREA>_<ROLE> sites B19 PON WN; roles below
|
||||
```
|
||||
|
||||
Role suffixes in use: `ADMIN`, `RO` (read-only), `OPERATOR`, `ENGINEER`, `SUPERVISOR`,
|
||||
`TESTER`.
|
||||
|
||||
### Mapping onto the canonical role set
|
||||
|
||||
The suffixes line up closely with
|
||||
[`CANONICAL-ROLES.md`](components/auth/spec/CANONICAL-ROLES.md), so
|
||||
`IGroupRoleMapper<CanonicalRole>` can map onto this rather than inventing a parallel scheme:
|
||||
|
||||
| AD suffix / family | Canonical role | Rationale |
|
||||
|---|---|---|
|
||||
| `_RO_` | **Viewer** | `OBSERVE` only |
|
||||
| `_OPERATOR` | **Operator** | `OBSERVE` + `OPERATE` |
|
||||
| `_ENGINEER` | **Engineer** | adds `TUNE` |
|
||||
| `APP_IDE_*` | **Designer** | the ArchestrA IDE *is* the authoring surface — `AUTHOR` |
|
||||
| `APP_ADMIN_*`, `SITE_ADMIN_*` | **Administrator** | |
|
||||
| `HIST_ADMIN_*` | **Administrator**, historian-scoped | |
|
||||
| `_SUPERVISOR`, `_TESTER` | **undecided** | see below |
|
||||
|
||||
Three gaps to settle before this is a design rather than a sketch:
|
||||
|
||||
- **`_SUPERVISOR` and `_TESTER` have no obvious canonical equivalent.** `SUPERVISOR` sits
|
||||
above `OPERATOR` but whether it means `TUNE` (⇒ Engineer) or approval authority is not
|
||||
derivable from the name. `TESTER` appears only in QA context. Ask the owners; do not guess.
|
||||
- **Nothing maps to `Deployer`.** The canonical set separates `DEPLOY` from `AUTHOR`; this
|
||||
directory does not. In practice `APP_ADMIN` holds deploy rights, which collapses the
|
||||
separation — the same accepted SoD collapse ScadaBridge already carries.
|
||||
- The environment axis (`DEV`/`QA`/`PROD`) is **orthogonal to role** and has no
|
||||
representation in `CanonicalRole`. It has to ride in the per-project scope payload, not
|
||||
the role — otherwise the role set multiplies by three.
|
||||
|
||||
**Caveats:**
|
||||
|
||||
- Group **container placement is inconsistent** (`OU=Universal,OU=Groups,OU=Warsaw`,
|
||||
`OU=Groups,OU=Warsaw`, and `OU=Groups` at the domain root). Harmless for
|
||||
`memberOf`-based authorization — only the *user* search base matters — but any
|
||||
group-enumeration search must be based at the domain root.
|
||||
- `UG_WW_BTMGR_RO_QA` is **empty**. Mapping a role to it grants nobody anything today.
|
||||
- Descriptions are ServiceNow ticket ids (`TASK0638550` etc.), so these groups are
|
||||
**provisioned by ticket** — requesting new ones has an established process, and the
|
||||
ticket id is the audit trail for why a group exists.
|
||||
- No group here is specific to OPC UA, ScadaBridge or this family; they describe the
|
||||
existing Wonderware estate. Reusing them means accepting their semantics.
|
||||
|
||||
### Library defect: a domain-root search base failed on AD referrals — FIXED in Auth `0.2.1`
|
||||
|
||||
**Found and fixed 2026-08-12.** All four Auth packages are **published to the Gitea feed at
|
||||
`0.2.1`** and restore-verified from a scratch consumer (the assembly restored *from the
|
||||
feed* carries the fix; `0.2.0` does not). **The four apps still pin `0.1.5`, so nothing is
|
||||
fixed for them until each bumps** — a pin bump is the remaining step, and until it happens
|
||||
every app still fails a domain-root search with `ServiceAccountBindFailed`.
|
||||
|
||||
Authenticating with `SearchBase = DC=nam,DC=zimmer,DC=com` fails on **both DCs** with
|
||||
`ServiceAccountBindFailed` in ~546 ms. It is not connectivity, not the service account,
|
||||
and not failover — both endpoints fail identically at the `search` stage:
|
||||
|
||||
```
|
||||
! LDAP endpoint uswap-vdc-nam1.nam.zimmer.com:636 failed system-side at search
|
||||
! LDAP endpoint uswap-vdc-nam2.nam.zimmer.com:636 failed system-side at search
|
||||
✗ FAILED — ServiceAccountBindFailed
|
||||
```
|
||||
|
||||
Cause: AD returns a **continuation referral** for a search based at the domain root, and
|
||||
`NovellLdapConnection.Search` (in `ZB.MOM.WW.Auth.Ldap`) iterates `results.Next()` without
|
||||
catching `LdapReferralException`. The exception escapes the search stage, and
|
||||
`LdapAuthService` maps it to the system-side bucket. The identical search from ldapprobe's
|
||||
own `RawDirectory.Search`, which catches and counts referrals, succeeds against the same
|
||||
base — which is what isolates it to the library rather than the directory.
|
||||
|
||||
**The fix (`0.2.1`):** `NovellLdapConnection.Search` now delegates to an internal
|
||||
`ReadEntries(ILdapSearchResults)` that catches `LdapReferralException` — and any
|
||||
`LdapException` carrying `ResultCode == Referral` — inside the result loop and continues.
|
||||
A continuation reference is a pointer to another naming context, never a statement that
|
||||
this search failed, so skipping it returns exactly the entries in the naming context we
|
||||
bound to. A referral counter caps the loop at 1000 as a spin guard, since a client that
|
||||
threw without advancing would otherwise hang inside a fail-closed auth path.
|
||||
|
||||
Non-referral faults still propagate untouched — swallowing those would turn "the directory
|
||||
is broken" into "no such user", which is the wrong thing to say about someone's
|
||||
credentials. Covered by `NovellSearchReferralTests` (7 tests through the
|
||||
`ILdapSearchResults` seam, so no live directory is needed; 6 of the 7 verified red against
|
||||
the pre-fix code, the seventh being the non-referral control).
|
||||
|
||||
**Until `0.2.1` is adopted**, the only workaround is to narrow `SearchBase` below the
|
||||
domain root — a landmine, because the base must contain every user who will ever log in
|
||||
and a user in another OU silently gets `UserNotFound`. Do **not** use the container
|
||||
ldapprobe's auto-retry reports: that is the *test user's own* OU (e.g.
|
||||
`OU=Office Users,OU=Warsaw,…`), not a production value.
|
||||
|
||||
This also constrained group *enumeration*: `UG_WW_*` groups are spread across three
|
||||
containers including the domain root, so a full group listing hit the same referral.
|
||||
ldapprobe's `--list-groups` carries its own referral-tolerant reader and was never
|
||||
affected.
|
||||
|
||||
### The zero-group rule is still the risk
|
||||
|
||||
`ZB.MOM.WW.Auth.Ldap` refuses a **zero-group** login: a user whose password verifies but
|
||||
whose `memberOf` is empty comes back as `GroupLookupFailed`, not success. The `UG_WW_*`
|
||||
finding above makes this less likely for Wonderware-estate staff, but it is not disproven
|
||||
— the account probed held 176 groups, which is not representative. **Test a real operator
|
||||
or service account before designing around this.** Two further traps the probe checks for
|
||||
explicitly:
|
||||
|
||||
- **the primary group is invisible.** AD omits it from `memberOf`, so a user whose only
|
||||
membership is `Domain Users` can never satisfy the library's rule.
|
||||
- **nested groups are invisible.** The library reads `memberOf`, which holds direct edges
|
||||
only — mapping a role to a group the users reach *through* another group would grant
|
||||
nobody anything. The probe resolves the transitive set separately and flags the
|
||||
difference.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user