claudetools/.claude/memory/project_cascades_network_segments.md

name, description, metadata

name	description	metadata
project_cascades_network_segments	Cascades of Tucson network segments + the CSC-ENT Wi-Fi SMB block that stalls NAS->CS-SERVER user migration	type project

Cascades of Tucson NAS->CS-SERVER share migration — network reality discovered 2026-06-25.

CS-SERVER (DC, RMM agent, Synology Drive sync target): IPs 192.168.2.248 (Ethernet) and 192.168.2.254 (Hyper-V vSwitch), both /22 = 192.168.0.0/22 (covers .0–.3.255). Domain CASCADES / cascades.local. SMB healthy — serves 13+ live sessions; shares under D:\Shares\<name> (Server, Management, Activities, Sales, etc.). Firewall SMB-In = Allow/Any.

Working SMB clients live on 10.0.20.x (routed, gw 10.0.20.1) and 192.168.3.x (on-link in the /22). Wi-Fi SSID for corporate = CSCNet.

Two Wi-Fi SSIDs (same AP family): CSC ENT = 192.168.2.0/24, gw 192.168.0.1, WPA2-PSK (old NAS-side); CSCNet = 10.0.20.0/24, gw 10.0.20.1, WPA3-SAE (newer corporate). DNS = pfSense 192.168.0.1. CSCNet PSK + CSC ENT PSK vaulted (clients/cascades-tucson/wifi-cscnet.sops.yaml, wifi-csc-ent.sops.yaml).

CORRECTION x2 (2026-06-26): the SMB problem is NOT CSC-ENT-vs-CSCNet AND NOT the AV. After a FULL removal of the Datto stack from CS-SERVER (DattoAV SDK + Datto RMM + Datto EDR — see below) and a reboot, error 67 persisted unchanged — so the AV minifilters (rtp1/rtp2/BdSentry) were a RED HERRING for SMB. More importantly, the SMB server is HEALTHY for domain/Kerberos clients: Get-SmbSession shows 7+ live SMB 3.1.1 sessions with open files (lauren, Sharon, Crystal @10.0.20.205, Megan, Ashley, chris) established AFTER the reboot. The failure is confined to workgroup/NTLM + loopback: Karen (DESKTOP-LPOPV30, workgroup) gets error 67 to EVERY share (IPC$, C$, a brand-new test share) even in her real user session with CORRECT creds, and Get-SmbConnection=none (the SMB session never negotiates; NO SMBServer/SMBClient event is logged -> failure is pre-SMB-negotiate, BAD_NET_NAME, not auth). NTLM restriction is NOT set (RestrictReceivingNTLMTraffic, LmCompatibilityLevel, NTLM Operational log all clear). Get-SmbServerConfiguration now works (NullSessionShares REG type was repaired prior session).

The AV was DattoAV, not GravityZone Bitdefender. It was the Datto EDR "Endpoint Protection SDK" under C:\Program Files\infocyte\agent\dattoav, managed by Datto RMM (CentraStage/CagService) + Datto EDR Agent (HUNTAgent/Infocyte HUNT). That is why removing from the GravityZone console did nothing. ALL Datto software was removed from CS-SERVER 2026-06-26 (services deleted, dirs/registry/drivers gone). Tenant azcomp4587; Cascades org 2d5ea96e-3228-461b-9c60-13ae464b61d8; CS-SERVER was already de-enrolled from EDR. Use the /datto-edr skill + msp-tools/datto-edr.sops.yaml.

RESOLVED (2026-06-26): there was NO CS-SERVER SMB problem. "Error 67" was a TEST-METHOD ARTIFACT. RMM-dispatched SMB client commands (net use/net view/Test-Path/Get-SmbConnection, even with context: user_session) FAIL with error 67 / RPC 1702 / "none" for KNOWN-GOOD targets too — proven: Karen's RMM test to her daily-use NAS (\\CASCADESDS) returned the same errors, and Crystal showed a live server-side session (5 open files) while RMM Get-SmbConnection on her box reported none. The agent-injected process lacks the user's real network-logon session. Validate SMB with server-side Get-SmbSession (showed 7 live users / 30 open files / new sessions forming) or a REAL INTERACTIVE test — never RMM-dispatched client cmds. Verified 2026-06-26: logging into CS-SERVER shares as CASCADES\karen.rossini interactively from another PC (John Trozzi/MAINTENANCE-PC) WORKED — account, password (vaulted), SG-IT-RW access, and the server are all fine. The original drive-map verify failure that started this whole investigation was the same RMM artifact. See errorlog friction entry rmm/smb-testing. Karen's only remaining real item: repoint her ALDocs shortcut on DESKTOP-LPOPV30 to \\CS-SERVER\Server\ALDocs and CONFIRM INTERACTIVELY (don't trust drive-map's RMM verify). NOTE: the prior-session move of Karen to CSCNet broke her NAS-by-name resolution — unrelated to the (non)issue.

Two more migration blockers found: (1) CSCNet is WPA3-SAE — older adapters (e.g. Intel AC 3165 on Meredith's ASSISTMAN-PC) cannot join it, so "move everyone to CSCNet" is blocked by hardware. (2) Security smell: workstations are WORKGROUP (local logins) and reach CS-SERVER by storing a DOMAIN credential — Meredith's PC stores cmdkey cs-server→administrator (her Y:/X:/E: are mapped as domain admin). Shares Server/Management = share ACL Authenticated Users:Full (NTFS gates real access). Fix: stop storing admin creds on user PCs; scope shares to groups.

Karen Rossini case (DESKTOP-LPOPV30, WORKGROUP, dual Wi-Fi): CASCADES\karen.rossini reset+vaulted (clients/cascades-tucson/karen-rossini.sops.yaml), added to SG-IT-RW, CS-SERVER cmdkey staged. She doesn't really use the Server folder (per Howard) so deprioritized. ALDocs is in \\CS-SERVER\Server\ALDocs. Repoint tooling = drive-map skill (but blocked by the CS-SERVER SMB instability above — fix that first).