claudetools/clients/glaztech/reports/2026-06-05-least-privilege-db-migration-scope.md

Glaztech — Least-Privilege DB Login Migration: Full Scope

Status: DRAFT v0.3 — PARKED pending full network recon (see §11). Grok + Gemini reviewed; live RMM recon (§11) materially changed the picture — §1-§3 are too optimistic and must be reconciled before execution. · Date: 2026-06-05 Owner: ACG · Ticket: #32378 (Waiting on Customer) · Coord todo: aebaf751 Source of truth: clients/glaztech/reports/2026-06-03-website-security-assessment.md (C0, C0-Extended, H6, and the "Sequencing the least-privilege DB migration" callout)

Objective: stop the internet-facing website (D:\web\glaztech_4, IIS site glaztech_new, server WWW 192.168.8.72 / 65.113.52.88) from connecting to GTI-INV-SQL (192.168.8.62,3436) as the sysadmin login tom, replacing it with a least-privilege login — without taking the live payment site or the card-charging engine down.

---

1. The central constraint that shapes everything: GTIware co-residency

The website's Web.config tom connection is shared, in the same IIS worker process, with the GTIware card-on-file engine DLLs (gt_auto_process_2020.dll, glaztech_utilities_2020.dll in D:\web\glaztech_4\Bin\). Those DLLs carry no connection strings of their own — they use the website's tom connection — and they legitimately need cc_file / cof_payments_header (card tables) to write and charge saved cards.

Consequence: a true least-privilege website login (with DENY on cc_file) cannot be applied while the card engine shares that connection — it would break auto-billing. Per assessment item 22, "you cannot safely swap only the website's connection string while the engine shares the same process and config."

This forces a two-phase migration:

• Phase 1 (achievable now, ACG-drivable): remove the catastrophic rights — sysadmin/securityadmin/dbcreator, cross-office DB reach, *_archive, msdb/master, linked servers, and the xp_cmdshell OS-RCE path — while retaining the site's own-office DB access and cc_file/cof_payments_header (because the in-process engine still needs them). This alone collapses the worst of C0: SQLi can no longer reach OS-RCE, the domain-admin password in msdb, other offices' data, or the linked-server mesh.
• Phase 2 (gated on Tom's parallel GTIware decoupling — item 17/22): once the card engine runs off its own dedicated connection/host, DENY cc_file/cof_payments_header on the website login, completing true least-privilege.

Phase 1 delivers ~80% of the risk reduction without depending on Tom's code — it collapses the catastrophic chain (OS-RCE via xp_cmdshell, the cleartext domain-admin password in msdb, all other offices + archives, the linked-server pivot, raw web_security dumps). But be precise (both models): Phase 1 is "blast radius contained," NOT "cards safe." Because the web login still holds cc_file/cof_payments_header GRANT for the engine, a SQLi (C3) plus a guessed customer login still yields full PAN+CVV for the office this portal serves. That residual card exposure closes only in Phase 2 (DENY cc_file) after the GTIware decoupling — and ultimately in the tokenization/purge workstream (assessment items 16-17).

---

2. Pre-execution inventory (callout step 1 — MUST complete before any change)

Two inventories, both read-only. These are the gating tasks; do not draft the grant set until they're done.

2a. What objects the website actually touches (to build the GRANT set)

• Source-side: enumerate every table/view/stored-proc referenced by the site's SQL — the 948 parameterized calls + 59 concatenated statements. Grep the VB.NET source on the box (D:\web\glaztech_4, excluding Old_bin/Old_code) for SqlCommand, .CommandText, proc names, FROM/JOIN/INTO/UPDATE/EXEC targets; dedupe to an object list per database.
• DB-side cross-check: SQL Server Extended Events / Profiler trace on the tom login over a representative window (a full business day incl. an gt_auto_process run) to capture the actual object-access set empirically — catches dynamic SQL the static grep misses. (Read-only; trace metadata only.)

2b. Every consumer of the tom login (to plan the password rotation, callout step 5)

Rotating tom without updating every consumer in the same change window breaks live systems. Enumerate:

• Website Web.config connection strings (primary).
• In-process GTIware DLLs — confirmed users of the website connection.
• Server-side billing jobs: d:\sql_jobs\bin\gt_console_apps.exe (modes cp/is/oa/lo) run by SQL Agent — confirm whether it authenticates as tom or the Agent (domain-admin) account.
• SQL Agent jobs / job steps referencing tom (msdb.dbo.sysjobsteps).
• Linked servers whose remote-login mapping uses tom (sys.servers + sys.linked_logins).
• The second host \\192.168.0.147\web\glaztech_4 (same code tree — may hold its own tom Web.config).
• /webhooks + /webhooks1 (Samsara) apps — do they carry a tom connection?
• Any scheduled tasks / internal apps / Excel/Access ODBC DSNs using tom. Queries: sys.dm_exec_sessions/sys.dm_exec_connections filtered by login_name='tom' sampled over time; sys.linked_logins; msdb job-step scan.

---

3. Phase 1 — de-privilege (the achievable-now core)

3a. New login + grant/DENY matrix (draft — finalize after §2a)

Create a new SQL login (e.g. web_glaztech_app) — SQL auth, no server roles beyond public. Use a high-entropy but alphanumeric-only password (avoid ; ' = + " { }), vaulted — legacy VB.NET/GTIware connection-string parsing may mis-handle special characters and silently truncate/fail the string (Gemini).

Scope	Action
Own-office production DB(s) the site serves (glaz_prod, glaz_prod_tuc, etc. — per §2a)	GRANT EXECUTE on the site's procs + SELECT/INSERT/UPDATE on the specific tables/views it uses (least-priv, object-level, not db_owner)
cc_file, cof_payments_header (card tables)	Phase 1: GRANT (in-process engine needs them) → Phase 2: DENY after GTIware decoupling
web_security (passwords)	GRANT EXECUTE on get_web_accesslevel only; DENY direct SELECT on the table. Works via ownership chaining (proc reads the table on the caller's behalf; raw SELECT * FROM web_security injection blocked) — only if the proc is dbo-owned, has no dynamic SQL (EXEC(@sql)/sp_executesql) and no EXECUTE AS. Dynamic SQL runs under the caller and would hit the DENY. Scan the proc set (§2a) for dynamic SQL and explicitly GRANT any tables reached that way (both models).
Every other office's DB + all *_archive DBs	DENY (no cross-DB reach). But first confirm no legitimate view/proc/report joins current data with archive/other-office data — cross-DB ownership chaining is OFF by default, so such a join will hard-break under the DENY. The §2a trace must surface cross-DB dependencies (Gemini).
master, msdb, model	DENY; no xp_cmdshell (login isn't sysadmin, so it can't enable/run it). Do NOT DENY tempdb — public must keep local #temp creation, which legacy procs/the engine likely use; a tempdb DENY breaks them on swap. (Watch for ##global temp / physical tempdb tables in legacy code — those would still fail.) (both models)
Linked servers (all 7)	No grants. Do NOT assume non-sysadmin = blocked — audit sys.servers + sys.linked_logins for a catch-all "connections made using this security context" mapping to a remote sa/sysadmin; the new login would silently inherit those rights on the remote box. Set the per-login mapping to "Not be made" and test from the new login during the window. (both models)
Server roles	none (public only) — removes sysadmin/securityadmin/dbcreator reach

Net Phase-1 effect: a SQLi via quo() now executes as a constrained login — no OS RCE, no msdb domain-admin password, no other-office/archive data, no linked-server pivot, no raw password-table dump. Card tables remain reachable only because the co-resident engine requires them (closed in Phase 2).

3b. Sequence (callout steps 2-4)

1. Create web_glaztech_app + apply the grant/DENY matrix (no impact yet — nothing uses it).
2. Staged Web.config swap to the new login, in a maintenance window, with SQL + app error monitoring live (SQL error log, IIS/app logs, the new failed-login logging if available). Watch a full cycle including an gt_auto_process run.
3. Any missing object permission surfaces as a SQL error → grant it (re-validate §2a) or roll back.
4. Once proven in production across a representative window, revoke sysadmin/securityadmin/dbcreator from tom (only after confirming no other consumer needs those rights — §2b).

Connection-pool note (Gemini): both the swap (step 2) and the rollback must include an IIS app-pool recycle. A Web.config edit alone does not flush ADO.NET's existing pooled tom connections — lingering pooled connections can mask the new login's failures or cause inconsistent behavior. Recycle on every connection-string change so the worker opens fresh connections under the intended login.

Both website and engine move at once: the in-process GTIware DLLs read the same Web.config, so the swap moves the website and the card engine to web_glaztech_app simultaneously. Phase 1's cc_file/cof_payments_header GRANT (and every other engine-touched object found in §2a) must be in place before the swap, or auto-billing fails the instant the pool recycles. (First confirm the DLLs truly source the string from Web.config and don't hardcode tom — §2b / Q in §8.)

3c. Rollback

Single-step, fast: revert the Web.config connection string to tom and recycle the app pool (required to flush the pool — see note above). Keep tom intact and unchanged until Phase 1 is proven — do not demote/rotate tom until step 4/5. Take a Web.config backup before each edit (those backups still contain the old plaintext tom password — pair this work with E1 so they aren't world-readable).

---

4. tom password rotation (callout step 5 — removes the plaintext sysadmin cred)

Corrected per Gemini's push-back (the earlier draft was self-contradictory). Because the in-process card engine reads the same Web.config, the Phase 1 swap vacates tom entirely from the IIS worker — both the website and the engine are now on web_glaztech_app. So rotation is NOT gated on Phase 2 or the engine; it is gated only on the external tom consumers from §2b (the .147 host, SQL Agent jobs, gt_console_apps.exe, ODBC/Excel DSNs, linked-server remote mappings).

Sequence: after Phase 1 is proven AND §2b is complete, rotate tom's password and update every external consumer in the same change window. (If §2b reveals the engine does not in fact read Web.config but hardcodes/uses a separate tom string, then §1's shared-connection premise is wrong and the whole plan needs revisiting — so confirming the DLLs' connection source in §2b is a hard prerequisite, not a detail.)

---

5. Phase 2 — remove card-table access (gated on GTIware decoupling)

Dependency: Tom's parallel GTIware workstream (assessment items 17 + 22) gives the card engine its own dedicated low-privilege connection/host. Then: DENY cc_file, cof_payments_header on web_glaztech_app; re-validate the website (which per assessment stores no cards itself) still functions; confirm auto-billing runs on the engine's own login.

---

6. Environment, change window, testing gates

• No staging assumed (H1 — dev tooling + source on the live box). Plan a maintenance window with immediate rollback, or stand up a minimal validation copy first. No in-place hotfixes without a rollback path.
• Validate per the assessment's testing gates: DB-login change reverts via Web.config; per-page validation that queries still return correct results after the swap; confirm gt_auto_process auto-charge still runs on the new login.
• Take a backup-first posture on any object whose permissions change; never touch tom until the replacement is proven.

7. Risks & mitigations

Risk	Mitigation
Missed object permission → site error after swap	Empirical XEvents trace (§2a) + live error monitoring during the staged swap + one-step rollback
Card engine breaks (loses cc_file)	Phase 1 retains cc_file; removal only in Phase 2 after decoupling
Rotating tom breaks an un-inventoried consumer	Full §2b inventory + same-window update; defer rotation if any consumer is unresolved
No staging → prod-only change	Maintenance window + immediate Web.config rollback; backups
corp DB cc_file "Invalid object name" anomaly	Resolve before finalizing grants (open follow-up)
Second host 192.168.0.147 has its own tom Web.config	Include in §2b; migrate/rotate in the same window
Legit cross-DB join (current × archive/other-office) hard-breaks under DENY	Surface cross-DB dependencies in the §2a trace before applying the DENYs
Dynamic SQL in a proc breaks ownership chaining → hits DENY	Scan procs for EXEC/sp_executesql; GRANT tables they reach dynamically
ADO.NET pool not flushed → stale tom connections mask failures	App-pool recycle on every connection-string change (swap and rollback)
Connection-string parser chokes on special chars in the new password	Alphanumeric-only high-entropy password for the interim login
tempdb DENY breaks #temp creation	Do not DENY tempdb; public keeps local temp; watch ##global/physical tempdb use
Linked-server catch-all mapping to remote sa	Audit sys.linked_logins; set "Not be made" for the new login; test
gt_console_apps.exe (server-side charging) opens its own tom connection	Confirm in §2b; if so it's an external consumer for the rotation window

8. Open questions for Tom / Steve

1. Confirm the website reads web_security only via get_web_accesslevel (so we can DENY direct table SELECT).
2. Does gt_auto_process re-submit CVV at charge time? (affects the parallel CVV purge, not this migration, but same window).
3. Will GTIware get its own DB connection/host (Phase 2 prerequisite)? Timeline?
4. Is there any test/validation environment, or is the maintenance-window-on-prod path required?
5. Authoritative list of tom consumers beyond the website (jobs, the .147 host, Samsara webhooks, ODBC DSNs)?

9. Effort / sequencing summary

• Inventory (§2): read-only; ~prerequisite, do first.
• Phase 1 (§3): ACG-drivable with client sign-off + a maintenance window; the high-value de-sysadmin step. Reversible.
• tom rotation (§4): after Phase 1 proven + consumer inventory complete.
• Phase 2 (§5): gated on Tom's GTIware decoupling (parallel workstream).

---

10. Independent review (Grok 4.3 + Gemini 3 Pro, 2026-06-05)

Both models reviewed this scope and the underlying assessment independently and CONCUR with the two-phase approach, the grant/DENY matrix, and the inventory-first / prove-before-touching-tom posture. They agreed on every correction now folded in above:

• Two-phase keeping cc_file in Phase 1 is required (not just safer) given the in-process engine; no safer pure-interim exists without moving the engine first.
• Do not DENY tempdb (breaks #temp); don't assume non-sysadmin blocks linked servers (audit catch-all mappings); dynamic SQL in procs breaks ownership chaining (scan + GRANT); the empirical XEvents trace is the true gate.
• Confirmed: losing sysadmin reliably removes xp_cmdshell; DB-level DENY overrides role GRANTs; the web_security EXECUTE-only + DENY pattern works via ownership chaining (dbo-owned, no dynamic SQL, no EXECUTE AS).
• Gemini's unique catches: the §4 rotation-gating contradiction (now fixed — tom is vacated from the worker at the Phase 1 swap, so rotation gates on external consumers only); the ADO.NET pool flush / app-pool recycle requirement on swap and rollback; the alphanumeric-only password to avoid legacy connection-string parser failures; cross-DB-join breakage under DENY.
• Grok's unique catches: don't overstate Phase 1 ("contained," not "cards safe" — served-office cards still exposed via SQLi until Phase 2); proc-level grep for cc_file before the Phase 2 DENY; confirm gt_console_apps.exe's connection source; pair the swap with E1 (old tom password lingers in Web.config backups).

No disagreement between the two models on any material point — a strong signal the plan is sound, contingent on the §2 inventories.

---

11. Recon findings (live, via GuruRMM read-only, 2026-06-05) — MATERIAL changes

Read-only SQL + Web.config recon (no data modified) corrected several core assumptions. These supersede parts of §1-§3 and must be reconciled before any execution.

Topology — centralized now; per-site SQL was the OLD layout

• GTI-INV-SQL (at the "INV - Involta" colo, 192.168.8.62) runs multiple instances: a default instance (SQL 2008 R2 / 10.50, EOL) with only qqest + ReportServer + system; the named instance GTI-INV-SQL\GTISQL on port 3436 (SQL 2012 / 11.0, EOL) holding all office data (~57 DBs: glaz_prod_<office>, _archive, _web for alb/boi/brl/corp/den/elp/phx/shp/slc/tuc + PDF stores + gti_samsara + qqest); and a third instance on 192.168.8.62,3430.
• The per-site-SQL memory matches the OLD topology — the commented-out Web.config strings show per-office ports/instances (glaz,3430 tuc … glaz,3439 brl, sql1,3436, sql3,3430). It has since been consolidated onto the single :3436 instance with per-office databases.
• The "mesh" = a handful of linked servers on :3436 (192.168.0.54; 192.168.0.55 = Sage mas_gti; 192.168.8.52 + .212 = backups; 192.168.8.62,3430; GLAZ\TIMEFORCE), all data-access enabled. On the default instance every linked-login maps (default-all) → tom — tom is the cross-system credential. NOT one-SQL-per-office.

The website's TRUE footprint (Web.config, ~15 active connection strings — all user id=tom, all on :3436 unless noted)

The site is not single-office. As sysadmin tom it legitimately connects to:

• All 10 offices' production DBs (glaz_prod, glaz_prod_phx/_slc/_elp/_den/_alb/_boi/_brl/_shp/_corp) + PDF stores (glaz_pdf, glaz_pdf_corp)
• Sage accounting — mas_gti @ 192.168.0.55,55181 (DIRECT connection, not just linked)
• Payroll — qqest via glaz\timeforce
• msdb — glaztech_jobs → 192.168.8.62,3436/msdb (the DB holding the cleartext domain-admin password + Agent jobs)
• Uses the operational glaz_prod_* DBs directly — NOT the _web databases (no _web simplification).

Implications — §1-§3 are too optimistic

• §3's "scope to own-office DB; DENY other offices/archives/msdb/accounting/payroll" is contradicted — the app legitimately uses all of them. A least-privilege login can't DENY what the app connects to.
• Phase 1's blast-radius win shrinks: removing sysadmin still kills xp_cmdshell RCE + arbitrary-instance control, but the new login would still legitimately reach all offices, accounting, payroll, and msdb — most of the estate. Retaining msdb means the cleartext domain-admin password in sysjobsteps stays reachable unless E2 (rotate it) is done first — so E2 is now a hard prerequisite, and we must learn WHAT the website does in msdb.
• The durable fix is architectural (assessment items 16-17, 22): separate the website's data + decouple — as-built the website is a cross-office hub wired to accounting + payroll + msdb under one sysadmin credential, so a "clean least-privilege login" barely exists.
• EOL SQL (2008 R2 + 2012) adds platform risk and limits options.

Recon limits / still needed

• SYSTEM (the agent) is sysadmin on the default instance but NOT on :3436 — the authoritative tom-role / sysadmin-login / linked-login map on :3436 needs the tom credential (or a sysadmin Windows login).
• Full network recon PENDING — Mike is enrolling the site servers in RMM to confirm no per-site SQL remains and map how accounting/payroll/backups/the 0.x + 8.x subnets fit together.
• The §2a object-inventory (XEvents trace) is even more important given the multi-DB, cross-server footprint.

---

v0.3 — Grok + Gemini corrections incorporated (§10); live RMM recon findings added (§11). PARKED by Mike 2026-06-05: the migration is larger than the assessment framed (website is a multi-office + accounting + payroll + msdb hub on one sysadmin credential), and a real network recon is needed to understand how the infrastructure fits together before this can be safely executed. Also still pending Tom/Steve answers to §8. Whole web-app remediation remains parked on #32378.