sync: auto-sync from GURU-BEAST-ROG at 2026-07-10 17:45:57

Author: Mike Swanson
Machine: GURU-BEAST-ROG
Timestamp: 2026-07-10 17:45:57
This commit is contained in:
2026-07-10 17:46:47 -07:00
parent c72048d4d7
commit 285687d48d
2 changed files with 125 additions and 14 deletions

View File

@@ -0,0 +1,100 @@
# Session Log — Goldstein: ASUS-2024 -> DALLAS RDP completion + Sheldon local account
## User
- **Executed by:** ClaudeTools Discord Bot (GURU-BEAST-ROG)
- **Requested by:** Mike Swanson (@azcomputerguru, via Discord) - admin
- **Role:** automation (acting on the requester's behalf)
## Session Summary
Follow-up to Howard's #32490 work (DALLAS Home->Pro upgrade + RDP enablement, 2026-07-07). Mike
reported via Discord (thread 1525291727911653530) that Sheldon Goldstein's staff couldn't RDP from
ASUS-2024 to DALLAS because DALLAS was signed in with a Microsoft account — MSA + Windows Hello PIN
blocks RDP password logon under NLA.
Verified connectivity first via GuruRMM: ASUS-2024 (Goldstein/Dallas site, traveling laptop,
currently in Phoenix on 192.168.0.200 Wi-Fi) reached DALLAS 192.168.1.226:3389 with
TcpTestSucceeded=True over the OpenVPN Connect tunnel Mike and Howard set up earlier the same day.
Network path confirmed good; the blocker was purely MSA authentication.
With Mike's go-ahead, dispatched two RMM commands: (1) on DALLAS, set
`HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PasswordLess\Device\DevicePasswordLessBuildVersion=0`
to allow Microsoft-account password sign-in (re-verified fDenyTSConnections=0, TermService running);
(2) on ASUS-2024, created `C:\Users\Public\Desktop\RDP DALLAS.rdp` (full address 192.168.1.226,
username hint, prompt for credentials, NLA-compatible).
Mike then superseded the MSA-password route: he used **Profwiz to migrate Michelle's
Microsoft-account profile on DALLAS to a local account `Sheldon`** and created a matching `Sheldon`
local account on GS-BACKUP so its SMB shares authenticate with the same credentials. Password set
to never expire on both machines. Bot vaulted the credential and updated the Goldstein wiki article
(endpoints, access, patterns, history).
## Key Decisions
- **Verified connectivity before touching auth** — a single Test-NetConnection from ASUS-2024 proved
the new OpenVPN tunnel carried 3389 fine, isolating the problem to MSA/NLA authentication.
- **Local-account migration (Profwiz) chosen over the MSA-password dance** — Mike's call; avoids the
fragile "type the MSA password once to cache it" prerequisite and any future Hello/passwordless
regressions. The registry fix remains in place but is superseded (harmless).
- **Matching `Sheldon` account on GS-BACKUP** — same username/password means Windows SMB auth to the
Tucson share box works without stored-credential juggling.
- **Password never expires on both** — deliberate for an unattended RDP target; noted in vault entry.
## Problems Encountered
- **DALLAS agent hostname is `Dallas` (not `DALLAS`)** in GuruRMM — exact-match jq filter missed it
on first resolve; found via client-scoped listing.
- None otherwise; both RMM dispatches exited 0 (stderr contained only benign CLIXML progress noise).
## Configuration Changes
- **DALLAS:** `DevicePasswordLessBuildVersion=0` (HKLM ...\PasswordLess\Device) via RMM cmd
136e69fd. By Mike (manual): profile migrated MSA -> local `Sheldon` via Profwiz; password never
expires.
- **GS-BACKUP:** local account `Sheldon` created (matches DALLAS, for SMB shares); password never
expires. (By Mike, manual.)
- **ASUS-2024:** `C:\Users\Public\Desktop\RDP DALLAS.rdp` created via RMM cmd cb533e62.
- **Repo:** `wiki/clients/goldstein.md` updated (endpoints table, Access, Patterns, History,
sources/last_compiled).
## Credentials & Secrets
- **Vault:** `clients/goldstein/windows-sheldon-local.sops.yaml` — local Windows account `Sheldon`,
password `Gerdrude788!`, valid on DALLAS and GS-BACKUP, never expires. Documented use: RDP from
ASUS-2024 (over OpenVPN) to DALLAS; SMB share auth on GS-BACKUP. Created + verified this session.
- Referenced (not modified): `clients/goldstein/openvpn-remote-access.sops.yaml`.
## Infrastructure & Servers
- **DALLAS** — 192.168.1.226; agent `36c7bbc8-504f-4b4a-8995-3b3e5cdc0f02` (hostname `Dallas` in RMM);
RDP host 3389/NLA; primary logon now `DALLAS\Sheldon`.
- **ASUS-2024** — agent `f50b17c1-a711-4e80-89c2-03cb630f5622`; traveling laptop, seen in Phoenix
(192.168.0.200 Wi-Fi); OpenVPN Connect DCO adapter to Goldstein network; reaches DALLAS 3389.
- **GS-Backup (Tucson)** — agent `4f52ef22-89ae-4124-a2b4-d339aaf42f53`; hosts SMB shares; new local
`Sheldon` account.
- DalRes10 (Tucson) offline at time of session.
## Commands & Outputs
- Recon (ASUS-2024, cmd cdbeeddd): IPv4 list + `Test-NetConnection 192.168.1.226 -Port 3389` ->
`TcpTestSucceeded=True` (via OpenVPN, from Phoenix).
- DALLAS (cmd 136e69fd): `DevicePasswordLessBuildVersion=0`, `fDenyTSConnections=0 TermService=Running`.
- ASUS-2024 (cmd cb533e62): `Created C:\Users\Public\Desktop\RDP DALLAS.rdp (129 bytes)`.
- All dispatched via `ps-encoded.sh` (quote-safe); alerts posted to #dev-alerts.
## Pending / Incomplete Tasks
- **User click-test:** Sheldon/staff to RDP from ASUS-2024 as `DALLAS\Sheldon` and confirm the
migrated profile looks right (desktop, files, Outlook). Not yet human-verified.
- **Syncro:** Mike did not request a ticket; #32490 already invoiced/closed. Open question whether
today's work (VPN + this) gets billed separately — Mike/Winter to decide.
- Prior open items stand: DALLAS Windows updates + reboot pending; no backup agent on DALLAS.
## Reference Information
- Discord thread: 1525291727911653530 (#botmagic, Mike).
- RMM command IDs: cdbeeddd (recon), 136e69fd (registry), cb533e62 (shortcut).
- Vault: `clients/goldstein/windows-sheldon-local.sops.yaml`.
- Prior logs: `clients/goldstein/session-logs/2026-07/2026-07-07-howard-dallas-rdp-pro-upgrade.md`,
`2026-07-06-howard-dallas-rmm-onboard.md`.
- Wiki: `wiki/clients/goldstein.md`.