# Valleywide (VWP)

## Infrastructure

### Servers

**VWP_ADSRVR (192.168.0.25)**
- Windows Server 2019 Standard (build 17763)
- Domain Controller for `vwp.local`
- SSH enabled (OpenSSH Server), key auth working for `vwp\guru`

**VWP-QBS (172.16.9.169)**
- Windows Server 2022 Standard
- Internal network only (172.16.9.0/24 reachable via VWP site VPN)
- Runs QuickBooks + **IIS with RD Gateway / RD Web Access** (`/RDWeb`, `/RDWeb/Pages`, `/RDWeb/Feed`, `/Rpc`, `/RpcWithCert`)
- WinRM available on 5985 (used for remote admin via Invoke-Command)

### Networks
- Internal: `172.16.9.0/24`
- One subnet also numbered `192.168.0.0/24` (conflicts with IMC's LAN if VPNs overlap — be careful switching contexts)

### Access
- **SSH to VWP_ADSRVR:** `ssh vwp\guru@192.168.0.25` (ed25519 key, added 2026-04-13)
- **Double-hop to VWP-QBS:** SSH won't forward Kerberos; use `Invoke-Command -ComputerName VWP-QBS -Credential $cred` with `vwp\sysadmin` PSCredential

## Security posture

### 2026-04-13 incident
RDWeb (`https://VWP-QBS/RDWeb/Pages/login.aspx`) was exposed to the public internet via UDM port forward. Distributed brute-force attack was in progress (multiple external IPs, ~6 POSTs/min, hitting usernames like `scanner`, `Guest`, etc.). This was discovered while investigating repeated `scanner` account lockouts (event 4740) which originally looked like a stale service credential.

**Actions taken:**
- UDM port forward removed (user action)
- IIS reset on VWP-QBS to drain in-flight attacker sessions
- Domain lockout policy restored (threshold 5, 16-min duration/window) after being temporarily disabled during diagnosis
- 30-day audit: **no successful external logons** — no compromise

### Current state
- RDWeb no longer reachable from public internet
- Internal access still works on port 443 from within 172.16.9.0/24
- Account lockout policy active

### Recommendations (outstanding)
- If RDWeb must be public again: deploy **IPBan** (https://github.com/DigitalRuby/IPBan) + firewall restriction to known client IPs
- Audit UDM for UPnP (prevents the server from re-punching its own hole)
- Consider 2FA / Conditional Access on any externally-reachable Windows service
- Rotate `scanner` AD account password (last set 2024-10-17) as hygiene

## 2026-04-16: RemoteApp over VPN (post-gateway) + RDS licensing fix

After the 2026-04-13 public RDWeb port-forward removal, users launching the QuickBooks RemoteApp via VPN hit `0x3000008` (RD Gateway unreachable) because the RDP manifest still routed through the gateway at the (now-firewalled) public IP.

### Changes made

1. **RDS Deployment** (on VWP-QBS, via Server Manager -> RDS -> Edit Deployment Properties -> RD Gateway) set to **"Do not use an RD Gateway server"**. New RDP manifests now write `gatewayusagemethod:i:0` and `full address:s:VWP-QBS.VWP.US` — direct connect, no gateway.

2. **UDM static DNS record** fixed typo `qwp-qbs.vwp.us` -> `vwp-qbs.vwp.us` (UniFi UI: Settings -> Routing -> DNS -> Static DNS Records), still pointing to `172.16.9.169`. Required because `vwp.us` is a real registered domain (resolves publicly to the website) but `vwp-qbs.vwp.us` is only valid internally. VPN clients receive DNS=192.168.4.1 (the UDM) via OpenVPN push, so this override is what lets them find the session host.

3. **RDS licensing configuration** (on VWP-QBS, via `Win32_TerminalServiceSetting` WMI):
   - Mode: Per User (LicensingType=4)
   - Specified license server: `vwp-qbs.vwp.us` (the same box — RDS-Licensing role was installed and activated but the RDSH was never pointed at it, so users hit "no license servers available")

### Rationale

- **No RD Gateway needed**: VWP users are either on-LAN or VPN-connected. OpenVPN pushes routes for 172.16.9.0/24, 192.168.0.0/24, 192.168.3.0/24. VPN -> LAN firewall policy is ACCEPT-all (`UBIOS_VPN_LAN_USER`). Gateway was only serving the public-access use case which is now intentionally closed.
- **DNS override avoids split-horizon complexity**: rather than pushing internal AD DNS (172.16.9.2) to VPN clients, we use the UDM's dnsmasq for both public and internal names, with overrides for the handful of internal FQDNs clients actually need.

### Current VPN / DNS topology

- OpenVPN server on UDM: pushes `192.168.4.0/24` to clients, routes for the three LAN subnets, DNS=192.168.4.1 (UDM)
- Site-to-site WireGuard peers visible on UDM (`wgsts1001`, `wgsts1003`, `wgsts1005`) — likely UniFi SiteMagic to ACG / other sites
- Static DNS records on UDM (as of 2026-04-16): `vwp-qbs.vwp.us` -> `172.16.9.169`

## RDS CAL purchase (outstanding)

VWP-QBS's RDS License Server is activated and running, but **has no real CALs installed** — only the Windows 2000-era `Built-in TS Per Device CAL` placeholder pack. Once grace period expires (or after the 2026-04-16 pointer fix re-triggers licensing logic), users will either get a fresh grace window or start seeing "license server has no licenses" errors.

**Action item:** purchase a pack of **Windows Server 2022 RDS Per User CALs** sized to the active user count (check VWP-QBS for distinct interactive logon count last 30d to size accurately). Install via `licmgr.msc` on VWP-QBS. Current licensing mode is Per User, matching this purchase path.

## Open items

- Confirm UPnP state on UDM (2026-04-13 recommendation — still not verified)
- Document intended RDWeb access pattern (who connects from where) — superseded partially by 2026-04-16 VPN-only decision, but formalize
- Add Valleywide entry to SOPS vault (SOPS vault now has `clients/vwp/*` entries: adsrvr, dc1, udm, xenserver, quickbooks-server-idrac — superseded)
- RDS CALs purchase (see above)
- Rotate `scanner` AD account password (carried from 2026-04-13)
