Session work 2026-05-04: Grabb Leap calendar fix, Dataforth lobby phone VLAN, IMC printer + VPN

- Grabb & Durando: investigated and resolved Svetlana Larionova's Leap-to-M365 calendar OAuth consent issue (Graph-side report + session log). Syncro #32245.
- Dataforth: lobby phone (ext 201) was offline due to D1-Server-Room port 1 being on the wrong VLAN; reconfigured to VLAN 100, phone re-provisioned and registered. Session log + PROJECT_STATE update. Syncro #32246.
- Instrumental Music Center: Station 2 receipt printer reconnect + VPN install on Manda's machine. Syncro #32247.
- Memory: generalized the Syncro blank-contact rule (was Cascades-only) and added the labor-type rule (never use "Prepaid project labor") per Winter's 2026-05-04 corrections.
- Gitignored `.claude/tmp/` so per-session helper scripts don't sneak in.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-04 13:51:42 -07:00
parent d9812f75cd
commit b6eb59e8ed
11 changed files with 531 additions and 1 deletions

View File

@@ -47,6 +47,7 @@ Session manager was being developed for SAGE-SQL deployment — see `clients/dat
| Date | By | Change | Status |
|------|-----|--------|--------|
| 2026-05-04 | Howard | Lobby phone offline — D1-Server-Room port 1 reconfigured to VLAN 100. Syncro #32246. Phone registered after TFTP + SIP handshake. See `session-logs/2026-05-04-lobby-phone-vlan-fix.md`. | COMPLETE |
| 2026-04-14 | Mike | Session log: follow-up work on datasheet pipeline | COMPLETE |
| 2026-04-13 | Mike | Session log: pipeline verification | COMPLETE |
| 2026-04-12 | Mike | SCMVAS/SCMHVAS pipeline deployed to production | DEPLOYED |

View File

@@ -0,0 +1,69 @@
# Dataforth — Account Status Check
**Date:** 2026-05-03 (UTC)
**Tenant:** Dataforth Corporation (`dataforth.com`, `7dfa3ce8-c496-4b51-ab8d-bd3dcd78b584`)
**Tool:** ComputerGuru Security Investigator (App ID `bfbc12a4-f0dd-4e12-b06d-997e7271e10c`) — Graph read-only
**Scope:** Status lookup only (enabled / licensed / last sign-in / object type). No remediation.
**Operator:** Howard Enos
## Summary
- 1 of 4 addresses is an **active licensed user** (`jantar@`).
- 1 of 4 is an **active distribution list** (`sales@`) routing to 3 employees.
- 2 of 4 (`dchapman@`, `dhenderson@`) **do not exist** anywhere in the directory — no user, no group, no contact, no alias, not in the 30-day soft-delete recycle bin.
## Results
| Address | Object type | Enabled | Licensed | Last sign-in (interactive) | Notes |
|---|---|---|---|---|---|
| `sales@dataforth.com` | Mail-enabled distribution list ("Sales") | Active | n/a | n/a | Members: ltobey@, ghaubner@, tdean@ |
| `jantar@dataforth.com` | User — Jacque Antar | Yes | 1 license | 2026-04-20 17:44 UTC (~13d ago) | Primary SMTP confirmed |
| `dchapman@dataforth.com` | **Does not exist** | — | — | — | Not a user, group, contact, or alias; not in soft-delete |
| `dhenderson@dataforth.com` | **Does not exist** | — | — | — | Not a user, group, contact, or alias; not in soft-delete |
## What "does not exist" means here
For `dchapman@` and `dhenderson@` we checked, against the live tenant:
1. `/users` filtered on `mail` and `proxyAddresses/any(p: p eq 'smtp:<addr>')` — 0 results. Rules out the address being a primary SMTP, a UPN, or a secondary alias on any mailbox.
2. `/groups` same filter — 0 results. Rules out distribution lists and M365 groups.
3. `/directory/deletedItems/microsoft.graph.user` — 0 results. The user object was not soft-deleted in the past 30 days (so not recoverable via the standard restore path).
4. `/contacts` (beta, org-level mail contacts) — 0 results.
If mail to these addresses is bouncing now, that is consistent — the tenant has no recipient with that smtp address. If mail to these addresses was being delivered historically and we need to know when they were removed, that requires a unified audit log search (`auditLogs/directoryAudits` with `activityDisplayName eq 'Delete user'`) over a longer window — say so and I can run it.
## Per-address detail
### sales@dataforth.com — Distribution List
- Group ID: `6dd5ec2b-c220-49bf-bd00-8d4d123914e7`
- mail-enabled, security-disabled, classic DL (no `groupTypes`)
- Proxy addresses: `SMTP:sales@dataforth.com`, `smtp:sales1@dataforthcom.onmicrosoft.com`
- Members (3): Logan Tobey (`ltobey@`), Georg Haubner (`ghaubner@`), Theresa Dean (`tdean@`)
### jantar@dataforth.com — Jacque Antar
- `accountEnabled`: true
- 1 assigned license
- Last interactive sign-in: 2026-04-20 17:44:45 UTC
- Proxy addresses: `SMTP:jantar@dataforth.com`, `smtp:jantar@dataforthcom.onmicrosoft.com`
### dchapman@dataforth.com — not found
- All four directory queries returned 0.
### dhenderson@dataforth.com — not found
- All four directory queries returned 0.
## Data artifacts
Raw JSON in `/tmp/remediation-tool/7dfa3ce8-c496-4b51-ab8d-bd3dcd78b584/account-active/`:
- `sales@dataforth.com-users.json`, `sales@dataforth.com-groups.json`
- `jantar@dataforth.com-users.json`, `jantar@dataforth.com-groups.json`
- `dchapman@dataforth.com-users.json`, `dchapman@dataforth.com-groups.json`, `dchapman@dataforth.com-deleted.json`, `dchapman@dataforth.com-orgcontact.json`
- `dhenderson@dataforth.com-users.json`, `dhenderson@dataforth.com-groups.json`, `dhenderson@dataforth.com-deleted.json`, `dhenderson@dataforth.com-orgcontact.json`
## Operational note
PyJWT + cryptography are not installed on HOWARD-HOME, so `get-token.sh` cert-auth (the new default) failed silently and the secret-auth fallback was used (`REMEDIATION_AUTH=secret`). Token issuance still works either way; cert-auth is preferred per the recent migration. Fix on this machine:
```bash
py -m pip install PyJWT cryptography
```

View File

@@ -0,0 +1,139 @@
# Dataforth — Account & Mailbox Check: jantar@dataforth.com
**Date:** 2026-05-03 (UTC)
**Tenant:** Dataforth Corporation (`dataforth.com`, `7dfa3ce8-c496-4b51-ab8d-bd3dcd78b584`)
**Subject:** Jacque Antar (UPN `jantar@dataforth.com`, object id `daa60027-be31-47a5-87af-d728499a9cc4`)
**Trigger:** Email surfaced on a paid dark-web ID monitoring report.
**Tool:** ComputerGuru Security Investigator (Graph read-only) — App ID `bfbc12a4-f0dd-4e12-b06d-997e7271e10c`
**Operator:** Howard Enos
**Scope:** Read-only. No remediation taken.
## Summary
- **MFA is ENABLED and IS being enforced.** Per-user MFA state = `enforced`. Last 30 days of sign-ins all show `MFA requirement satisfied by claim in the token`. Non-interactive sign-ins (Outlook, Teams, etc.) all report `authenticationRequirement: multiFactorAuthentication`.
- **MFA method registered: SMS only** to `+1 520-245-6929`. No Authenticator app, no FIDO key. SMS is the weakest second factor (SIM-swap, SS7).
- **Mailbox is clean of obvious breach indicators.** No suspicious inbox rules, no auto-forwarding visible in Graph, no foreign sign-ins, no mass-mail patterns in sent items, no flagged risk detections. Sent items match her accounting role.
- **Posture gaps to fix (separate from breach response):**
1. All 3 Conditional Access policies on this tenant are in **report-only** mode (`enabledForReportingButNotEnforced`) — including "Require MFA", "Block Legacy Authentication", and "Block Foreign Sign-Ins". The only thing enforcing MFA today is the deprecated per-user MFA toggle. Microsoft has been pushing tenants off per-user MFA for years.
2. She has **OAuth grants for legacy email scopes** (IMAP, EWS, EAS) to "Apple Internet Accounts" and "eM Client". These are legitimate clients she uses, but they're protocol-level paths that the disabled "Block Legacy Auth" CA policy would close.
3. **All 30d sign-ins originate from `67.206.163.122` (Salt Lake City, UT, CenturyLink residential).** Dataforth is Tucson. Either she's remote-working from SLC, uses a VPN exiting there, or this is persistent unauthorized access. **Confirm with her / Mike.** Same IP for 30 days = same workstation, not impersonation churn — but that workstation might or might not be hers.
## Target details
| Field | Value |
|---|---|
| UPN | jantar@dataforth.com |
| Object ID | daa60027-be31-47a5-87af-d728499a9cc4 |
| Display name | Jacque Antar |
| Account enabled | true |
| Created | 2023-12-07 |
| Last password change | **2026-03-09** (~55 days ago) |
| Assigned licenses | 1 |
## MFA — enabled and enforced?
**Enabled: YES.** Per-user MFA legacy endpoint returned `perUserMfaState: enforced`. Registration report: `isMfaCapable: true, isMfaRegistered: true`.
**Enforced at sign-in: YES.** Evidence:
- All 8 interactive sign-ins (last 30d) ended successfully with `additionalDetails: "MFA requirement satisfied by claim in the token"`. That string only appears when Entra evaluated MFA and it was satisfied (either by fresh challenge or by an MFA-claim in the cached refresh token).
- Non-interactive sign-ins (10 sampled from 2026-05-02 alone — Outlook, Edge, OfficeHome, WeveAgave, etc.) all show `authenticationRequirement: "multiFactorAuthentication"`.
**Methods registered:** `mobilePhone` only (SMS to `+1 520-245-6929`). `defaultMfaMethod: null`, `userPreferredMethodForSecondaryAuthentication: sms`.
**Caveat — what's enforcing the MFA:**
- It is the legacy **per-user MFA "enforced"** flag, not Conditional Access. All 3 CA policies on this tenant are in `enabledForReportingButNotEnforced`:
- `ACG - Require MFA for All Users` — report-only
- `ACG - Block Legacy Authentication` — report-only
- `ACG - Block Foreign Sign-Ins` — report-only
- Security Defaults: disabled.
- This works today, but Microsoft is sunsetting per-user MFA. The CA policies should be flipped to "On".
**Recommendation for Jacque specifically:**
1. Have her register Microsoft Authenticator (push/TOTP) as her primary, demote SMS to fallback. Self-service: https://aka.ms/mfasetup
2. Treat SMS-only as a known posture gap until Authenticator is added.
## Per-check findings
### 1. Inbox rules (Graph v1.0)
- 1 rule, **disabled**. Moves messages whose header contains `X-Inky-Graymail: True` to a folder, then stops processing. This is a normal Inky-anti-phishing graymail filter. **Not suspicious.**
### 2. Mailbox settings (Graph)
- Auto-reply: disabled. Time zone US Mountain. Locale en-US. **Nothing flagged.**
### 3. Exchange REST (hidden rules / mailbox permissions / SendAs / Get-Mailbox)
- **NOT CHECKED.** Exchange admin endpoint returned **HTTP 401** for the Security Investigator SP on this tenant. The "Exchange Administrator" directory role is not assigned to that SP in Dataforth. This is a known gap from the per-tenant onboarding step.
- To enable: a tenant Global Admin assigns the Exchange Administrator role to the `ComputerGuru Security Investigator` service principal in this tenant's Entra Roles blade (or run `bash .claude/skills/remediation-tool/scripts/onboard-tenant.sh dataforth.com` if cert auth works on this machine). Without it we can't see hidden inbox rules, delegates, SendAs, or the canonical `ForwardingAddress / ForwardingSmtpAddress / DeliverToMailboxAndForward` mailbox flags.
- The Graph-side mailbox settings show no forwarding flag (`automaticRepliesSetting.status: disabled`) but Graph cannot see the Exchange-only forwarding fields.
### 4. OAuth consents + app role assignments
- **2 user-consented OAuth grants** (both consented by her, scope = legacy email):
| Resource | Client ID | Scopes |
|---|---|---|
| Office 365 Exchange Online | `85e650f8-5eec-4523-a9ef-fc1a031fb1d6` | `openid offline_access EAS.AccessAsUser.All` (Apple Internet Accounts — EAS) |
| Office 365 Exchange Online | `25db1c08-f5a0-4f6c-bbdd-a738689b1587` | `IMAP.AccessAsUser.All EWS.AccessAsUser.All offline_access email openid` (eM Client) |
- **2 app role assignments** under her account:
- "Apple Internet Accounts" (assigned 2024-04-02)
- "eM Client" (assigned 2024-08-26)
- Both consistent with a Mac user running Apple Mail + a Windows/Mac user running eM Client. **Legitimate clients**, but they consume legacy auth scopes (IMAP / EWS / EAS) that bypass modern auth challenges. The disabled "Block Legacy Auth" CA policy would normally block these.
### 5. Authentication methods
- 2 methods on record:
- `passwordAuthenticationMethod` (last set 2026-03-09)
- `phoneAuthenticationMethod` mobile, `+1 520-245-6929`
- No `microsoftAuthenticatorAuthenticationMethod`, no FIDO2, no Windows Hello, no software OATH token.
### 6. Sign-ins (last 30 days, interactive)
- 8 successful sign-ins. **All 8 from `67.206.163.122` (Salt Lake City, UT, CenturyLink-issued residential).** No failures, no foreign-geo, no legacy-auth client app types in this set.
- App: mostly "Dime Client" (`a2760c41-63c9-42b5-8d58-bfa1fd9e2eb3` — Microsoft first-party app, used by some web client surfaces) + one "One Outlook Web".
- Risk level: `hidden` (Identity Protection not licensed).
- **Action:** confirm with Jacque or Mike that the SLC IP is hers (remote work, VPN, etc.). If not, treat as compromise.
### 7. Directory audits (last 30 days, target = jantar)
- 5 events, all benign:
- 3 × "Update user" by Microsoft Substrate Management (Microsoft system process, automatic profile maintenance)
- 2 × "Add member to group" on 2026-04-06 by `dcenter@dataforth.com` (admin activity)
- **No password resets, no auth-method changes, no role grants, no app consents by anyone other than her.**
### 8. Risky users / risk detections
- **HTTP 403 Forbidden** — `"Your tenant is not licensed for this feature."` Identity Protection requires Entra ID P2; Dataforth's SKUs (O365 Business Premium, Business Standard, Exchange Standard) include P1 only. **Not checkable on this tenant.**
### 9. Sent items (last 25)
- Normal accounting/AP work: Patricia at `times-biz.com` (external bookkeeper), AMoreno + sabreu at `crestins.com` (insurance broker), Paychex contacts (`nknippel@`, `cknoll@`), internal Dataforth (`Kellynwackerly@`, `tdean@`, `dcenter@`, `ghaubner@`, `ofest@`, `ltobey@`, `shipping@`), various vendor reply-thread subjects ("Sales Invoice", "Statement", "JE to correct AP issue", "Commissions", "ACH", "Bank", "PER1 and PIN1").
- **No blast patterns, no unusual external recipients, no obvious phishing or BEC payloads.** Subject lines and recipient mix consistent with her finance role.
### 10. Deleted items (last 25 visible)
- Only 3 items: 1 promotional email (`info-az-specialists.com@shared1.ccsend.com`), 2 self-sent items (probably saved-then-discarded drafts). Low count likely indicates Deleted Items is being emptied regularly or auto-purged by retention. **Not flagged**, but anomalous low count means a mailbox-level audit log search would be needed if you want to see what was deleted earlier.
## Suspicious items pulled from above
- **All 30d sign-ins from a single Salt Lake City residential IP** (Dataforth is Tucson). Not a breach indicator on its own — the IP is consistent for 30 days, suggesting one persistent client. **Confirm with Jacque or Mike whether she works from SLC / uses a VPN there.**
- **Two OAuth grants to legacy-auth third-party email clients** (eM Client, Apple Mail). These are legitimate apps but they keep IMAP/EWS/EAS sessions alive that the dormant "Block Legacy Auth" CA policy would otherwise close. Ask whether she still uses both clients.
## Gaps — checks not completed
| Gap | Reason | Fix |
|---|---|---|
| Hidden inbox rules, delegates, SendAs, mailbox forwarding fields | Exchange Admin role not assigned to Security Investigator SP in this tenant (HTTP 401) | Tenant Global Admin: assign "Exchange Administrator" to SP `bfbc12a4-...` in Entra Roles. Or run `onboard-tenant.sh dataforth.com` after fixing PyJWT on operator workstation. |
| Identity Protection (riskyUsers, riskDetections) | Tenant not licensed for AAD/Entra ID P2 | Out of scope — would require license upgrade for ~$9/user/mo. |
## Next actions
1. **Confirm SLC sign-in IP with Mike or Jacque** — is `67.206.163.122` her? (single highest-value question)
2. **Have Jacque add Microsoft Authenticator** as MFA method, demote SMS to backup. Self-service: https://aka.ms/mfasetup. Could be done in 2 minutes during her next phone call with us.
3. **Force a password reset** as a precaution given the dark-web hit (separate `/remediation-tool remediate jantar@dataforth.com password-reset` would do it after explicit YES — currently NOT executed).
4. **Tenant-level posture (separate engagement, discuss with Mike before doing):**
- Flip the 3 ACG CA policies from report-only to On.
- Assign Exchange Administrator to the Security Investigator SP so we can see hidden rules / forwarding on future investigations.
- Decide whether eM Client / Apple Mail (legacy-auth scopes) are still needed — if yes, those users will need an exemption when "Block Legacy Auth" is enforced.
## Data artifacts
Raw JSON in `/tmp/remediation-tool/7dfa3ce8-c496-4b51-ab8d-bd3dcd78b584/user-breach/jantar_dataforth_com/`:
- `00_user.json`, `01_inbox_rules_graph.json`, `02_mailbox_settings.json`
- `04a_oauth_grants.json`, `04b_app_role_assignments.json`
- `05_auth_methods.json`, `06_signins.json`, `07_dir_audits.json`
- `08a_risky_user.json` (403 — not licensed), `08b_risk_detections.json` (403)
- `09_sent.json`, `10_deleted.json`
- `mfa_perUserState.json`, `mfa_regDetails.json`, `ca_policies.json`, `secdef.json`
- `03a_InboxRule_hidden.json` / `03d_Mailbox.json` are EMPTY (Exchange 401)

View File

@@ -0,0 +1,68 @@
# Dataforth — Lobby Phone Offline (VLAN/Switch Port Fix)
**Date (UTC):** 2026-05-04
**Tech:** Howard Enos
**Time onsite:** 0.5 hours
**Syncro ticket:** #32246 (`109836123`), invoice #67558 (`1650188916`)
## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home (driving the PBX remotely via Tailscale)
- **Role:** tech
## Summary
Lobby visitor phone (Cisco SPA502G, ext 201) had been offline — no dial tone, dialing extensions did nothing, displayed an incorrect date/time. Root cause: the lobby drop's switch port had been on the wrong VLAN, isolating the phone from the PBX. Fix was reconfiguring D1-Server-Room port 1 to VLAN 100. Phone immediately TFTP-pulled fresh provisioning and registered.
## Diagnosis path
1. **Phone state:** screen showed normal idle, but no dial tone. Dialing an extension just returned to home screen with no tone, ringback, or error. Wrong date/time on display — strong clue that the phone hadn't reached NTP for a while.
2. **PBX-side check** (driven from Howard-Home over Tailscale via SSH to `192.168.100.2` with vault creds):
- `pjsip show endpoint 201``Unavailable`, no contact, AOR but no registration.
- **Zero traffic from the phone's last known IP `192.168.100.235`** in the last 2 hours of TFTP/SIP logs.
- PBX could not ping `.235`; ARP "who-has" requests went unanswered.
- SIP secret in `pjsip.auth.conf` for ext 201 matched the secret in the per-MAC TFTP config `spa58bfea1158b4.xml` — so credentials were not the issue.
3. **VLAN test:** Howard plugged his laptop into the same lobby wall jack. Laptop received `192.168.0.53` (Unifi UDM main LAN). Meanwhile, the phone — after a factory reset to clear cached state — landed on `192.168.1.235` via LLDP-MED voice tagging onto Unifi's default voice VLAN (`192.168.1.0/24`). Neither matches the production voice/PBX VLAN, which is `192.168.100.0/24`.
4. **Cable trace:** Howard followed the lobby drop back to the **D1-Server-Room switch, port 1**. That port was not configured for VLAN 100.
## Network topology learned
| Subnet | Used for |
|---|---|
| `192.168.0.0/24` | Unifi main LAN (UDM is at `192.168.0.254`) |
| `192.168.1.0/24` | Unifi default voice VLAN (LLDP-MED) — NOT used for production phones in this office |
| `192.168.6.0/24` | OpenVPN management range (per UDM config) |
| `192.168.100.0/24` | **Production voice/PBX VLAN** — PBX on `.196` (and `.2` aliased), all production phones |
| `10.208.107.116/30` | PBX `ens224` secondary interface |
Working office phones live on `192.168.100.x` directly. The Unifi-default voice VLAN (`192.168.1.x`) is not wired to anything that can reach the PBX.
## Fix
Reconfigured **D1-Server-Room port 1** to VLAN 100. After replug:
- Phone DHCP'd `192.168.100.235`.
- TFTP fetched `/spa502G.cfg` (12:29:40 PDT) and per-MAC `/spa58bfea1158b4.xml` (12:30:40 PDT).
- SIP REGISTER → 401 Unauthorized → REGISTER (auth) → 200 OK at 12:31:42 PDT.
- `pjsip show endpoint 201``In use`, contact `201/sip:201@192.168.100.235:5060` Avail, RTT 22ms.
- NTP sync brought date/time current.
## Recommendation for Mike / Dataforth IT
- **Audit other Unifi-managed switch ports** for voice drops to ensure they all stay tagged on VLAN 100. A port that reverts to defaults will silently isolate any phone plugged into it (untagged main LAN for laptops, LLDP-MED voice tag onto `192.168.1.x` for phones — neither reaches the PBX). The wrong date/time is the canary; check that on phones that have been complained about.
- **D1-Server-Room port 1** should stay tagged on VLAN 100. If config drifts, the lobby phone goes silent again.
## Tools / accounts touched
- SSH to PBX (`sangoma@192.168.100.2`) via Tailscale + paramiko (vault creds).
- No production config changes on the PBX itself (read-only diagnostics there).
- Switch port config change: D1-Server-Room port 1 → VLAN 100 (changed from whatever it was before — not captured; assumed default Unifi profile).
## Tools `not` touched
- UDM controller (`192.168.0.254`) — has 2FA push enabled and was not accessed during this work. The switch port change was made by Howard via direct switch access.
## Artifacts
- TFTP config file confirmed correct: `/tftpboot/spa58bfea1158b4.xml` on PBX (mtime 2026-04-23 — was already current; no FreePBX-side change needed).
- pjsip auth password matches XML password (md5 hash form `4b57418f0a921fbce9d1bee10b6084e5`).