sync: auto-sync from HOWARD-HOME at 2026-06-17 17:49:01
Author: Howard Enos Machine: HOWARD-HOME Timestamp: 2026-06-17 17:49:01
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: Cascades-specific operational rules (folder redirect, security groups)
|
||||
description: Active rules for Cascades work — (1) folder redirection (fdeploy) needs subfolders pre-created before first logon or it caches a failure forever; recovery via fix-shell-redirect.ps1; (2) always ASK which security group(s) a new user goes into — never auto-derive from OU; (3) do NOT lock down the legacy Main\Company Web Docs\Accounting (Everyone:Full) folder — still in active use. Root-cause / incident detail in project_cascades_history.md.
|
||||
description: Active rules for Cascades work — (1) folder redirection (fdeploy) needs subfolders pre-created before first logon or it caches a failure forever; recovery via fix-shell-redirect.ps1; (2) always ASK which security group(s) a new user goes into — never auto-derive from OU; (3) do NOT lock down the legacy Main\Company Web Docs\Accounting (Everyone:Full) folder — still in active use; (4) NEVER apply a change to Cascades production infra (pfSense, UniFi controller, switches, DHCP) without discussing it and getting an explicit per-change go — investigate read-only / dry-run only until then. Root-cause / incident detail in project_cascades_history.md.
|
||||
type: feedback
|
||||
---
|
||||
|
||||
@@ -45,3 +45,13 @@ OU placement is mechanical (controls Entra Connect sync scope); group membership
|
||||
## 3. Do NOT lock down the legacy `Main\Company Web Docs\Accounting` folder
|
||||
|
||||
The accounting folder under the Synology-Drive-synced tree (`D:\Shares\Main\Company Web Docs\Accounting`, `Everyone:FullControl`) stays as-is — Howard confirmed 2026-06-10 the team is **still actively using it**. Do not scope/tighten its ACL or "clean it up" as a HIPAA hardening step, even though the wide-open Everyone:Full looks like an obvious target. The 2026-06-09 scan-to-folder build deliberately created a *separate* clean share (`\\CS-SERVER\AcctDept` → `D:\Shares\Accounting`) rather than reusing this folder; that is the lockdown story, and the legacy folder is intentionally left untouched.
|
||||
|
||||
---
|
||||
|
||||
## 4. NEVER change Cascades production infra without discussing it first
|
||||
|
||||
Do not apply ANY change to the Cascades production network — pfSense (firewall rules, DHCP, `ping-check`, service restarts, reboots), the UniFi controller (radio power/channel/min-RSSI/disable, WLAN/PPSK settings), switches, or DHCP scopes — until it has been **discussed and explicitly approved, per change**. Investigate **read-only / dry-run only** (e.g. `apply-radio` without `--apply`, `pfsense-ssh.sh audit`/read-only `run`) and present proposals; wait for an explicit go before any write.
|
||||
|
||||
**Why:** Howard set this explicitly 2026-06-17 during the Poly-phone-drop investigation — it's a live HIPAA assisted-living network (~780 clients, residents' medical/IoT devices) where a bad change has real patient-care and compliance impact, and changes need coordination (another session was concurrently doing radio work; Mike should be looped in on pfSense changes).
|
||||
|
||||
**How to apply:** dry-run/read-only by default; stage changes as reviewable proposals; one explicit approval per change, not a blanket one. Pair with the per-change confirmation already required for hard-to-reverse/outward-facing actions. Coordinate via the coord API when another session may touch the same gear. Note the per-room /28 segmentation is intentional HIPAA L2 isolation — do not "clean it up." See [[project_cascades]].
|
||||
|
||||
Reference in New Issue
Block a user