Files
claudetools/clients/cascades-tucson/session-logs/2026-06-05-session.md
Howard Enos 11c5ee075c sync: auto-sync from HOWARD-HOME at 2026-06-05 11:21:47
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-05 11:21:47
2026-06-05 11:21:58 -07:00

131 lines
15 KiB
Markdown

# Cascades of Tucson — Session Log 2026-06-05
## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech
## Session Summary
Two Cascades tasks handled via the GuruRMM agent fleet and the M365 remediation tool suite.
First, a request to "enable the localadmin account as a local administrator" on NURSESTATION-PC because it was not appearing on the login screen. Recon via RMM showed the account was already enabled and already a member of the local Administrators group (it had even logged in earlier the same day). The actual cause was a `SpecialAccounts\UserList` registry suppression entry (`localadmin = 0`) under the Winlogon key, which deliberately hides the account from the sign-in screen. Removed that entry; account will now appear in the user picker after the next sign-out/reboot. The enable/admin steps in the fix script were idempotent no-ops since both conditions were already true.
Second, vault hygiene plus an MFA change on the MSP break-glass Global Admin `sysadmin@cascadestucson.com`. Confirmed the vault entry (`clients/cascades-tucson/m365-sysadmin.sops.yaml`) had not been updated since 2026-04-24 and that the live account's `lastPasswordChangeDateTime` was 2026-06-04 — i.e. Mike rotated the password on 2026-06-04 and never vaulted it. Howard supplied Mike's current password; updated the vault entry's password field and rotation-history notes in place via `sops set` (no plaintext on disk), committed, and pushed (required a rebase — remote had advanced).
Third, added a code-delivery path for Howard on the same GA account. Reading the account's phone methods showed `mobile` (SMS, Mike's) and `alternateMobile` (voice-only) slots both occupied, and the tenant Authentication Methods policy had **Voice call disabled** — which is why sign-in only ever offered text or authenticator (both Mike's). To avoid a tenant-wide change, created a security group containing only `sysadmin@`, enabled the Voice method scoped to that group, and set the account's `alternateMobile` to Howard's number. A voice-call MFA option now appears at sign-in for that account only. All writes against the GA succeeded (no Privileged Auth Admin 403 materialized).
## Key Decisions
- Diagnosed the NURSESTATION-PC login-screen issue as a registry hide (`SpecialAccounts\UserList`) rather than an account-state problem, because recon proved the account was already enabled + admin. Fixed the actual cause instead of the stated symptom.
- Did NOT reset the live `sysadmin@` password. Earlier in the session a reset to the vaulted value was prepared, but Howard clarified Mike's 2026-06-04 change was intentional; the correct action was to vault Mike's current password, not revert the account.
- Scoped the Voice MFA method to a dedicated single-member security group rather than enabling it for `all_users`, keeping blast radius to the one account (Howard asked specifically whether it could be limited to that account).
- Left `alternateMobile` set to Howard's number (520-585-1310) after Howard confirmed sign-in worked, rather than reverting to the prior 520-331-5551.
- Used `sops set` for the vault field edits (password + notes) to avoid ever writing the decrypted file to disk.
## Problems Encountered
- RMM registry-recon command returned `interrupted` ("Agent restarted during execution") once on NURSESTATION-PC; re-ran and it completed.
- First fix-script dispatch returned an empty `command_id` (transient, around the agent restart). Re-dispatched and it succeeded.
- Group member-add returned 404 immediately after group creation (Entra replication lag); succeeded on retry after a short delay.
- Phone-method update first attempted with `PUT` (405 — "PUT is not supported in v1.0, use PATCH"); reissued as `PATCH` and it succeeded (204).
- Vault `git push` was rejected (remote ahead); resolved with `git pull --rebase` then push.
- `bash` readonly-variable error using `UID` for the user object id; renamed to `OID`.
## Configuration Changes
- **NURSESTATION-PC (Cascades, RMM agent):** removed registry value `localadmin` (was `0`) under `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList`. localadmin remains enabled and in Administrators (unchanged).
- **Vault `clients/cascades-tucson/m365-sysadmin.sops.yaml`:** updated `credentials.password` to Mike's current value; rewrote `notes` with a rotation-history block. Committed + pushed to the vault repo.
- **M365 tenant cascadestucson.com:**
- Created security group "MFA - Voice Call Scoped (sysadmin)" (`mfa-voicecall-scoped`), id `304f941e-3594-4705-b8e6-ee676297df11`, single member `sysadmin@`.
- Authentication Methods policy: Voice method `state` set `disabled``enabled`, `includeTargets` scoped to group `304f941e-…` (was `all_users`).
- `sysadmin@` `alternateMobile` phone method (`b6332ec1-7057-4abe-9331-3d72feddfe41`) changed from +1 520-331-5551 to +1 520-585-1310.
## Credentials & Secrets
- `sysadmin@cascadestucson.com` (Global Admin "Computer Guru Support", object id `471b13dc-3cf8-416b-a132-f5f3bc8d1cc8`): password rotated by Mike 2026-06-04, now vaulted at `clients/cascades-tucson/m365-sysadmin.sops.yaml` (`credentials.password`). Value not reproduced here; retrieve via `vault.sh get-field`.
- No new credentials created. Vault key auto-discovered by sops at `%APPDATA%\sops\age\keys.txt`.
## Infrastructure & Servers
- GuruRMM API: `http://172.16.3.30:3001`. NURSESTATION-PC agent id `f5a89784-834f-47b1-82e2-7e3e9dd337ff` (Windows, online), client "Cascades of Tucson".
- M365 tenant `cascadestucson.com` = tenant id `207fa277-e9d8-4eb7-ada1-1064d2221498`.
- Remediation app tiers used: `user-manager` (`64fac46b-8b44-41ad-93ee-7da03927576c`) for user/group/phone-method writes; `tenant-admin` (`709e6eed-0711-4875-9c44-2d3518c47063`) for the auth-methods policy PATCH.
- Account phone methods after change — mobile/SMS: +1 520-289-1912 (ready); alternateMobile/voice: +1 520-585-1310.
## Commands & Outputs
- RMM hidden-account discovery: `Get-Item HKLM:\...\Winlogon\SpecialAccounts\UserList``localadmin = 0` (the hide flag).
- RMM fix output: "Removed UserList hide entry for localadmin (was 0)" / "UserList hide entry now: ABSENT (will show on login screen)".
- Graph read of GA roles: `GET /users/{id}/memberOf/microsoft.graph.directoryRole` → "Global Administrator [62e90394-69f5-4237-9190-012177145e10]".
- Voice policy before: `{state: disabled, includeTargets:[all_users]}`; after PATCH: `{state: enabled, includeTargets:[group 304f941e-…]}`.
- Vault edit: `sops set <file> '["credentials"]["password"]' '"<value>"'` then verified round-trip and `grep -c 'ENC[' = 4` (still encrypted).
## Pending / Incomplete Tasks
- NURSESTATION-PC: localadmin will appear in the login picker only after the next sign-out/reboot. If a user is currently signed in, have them sign out to confirm.
- The previous `alternateMobile` number +1 520-331-5551 was overwritten — confirm with Mike that number did not need to remain on the account.
- Consider whether `sysadmin@` (shared break-glass GA) should move to per-admin Authenticator/FIDO2 rather than shared SMS/voice long-term (raised but not actioned).
- Voice MFA is now an available method for the single-member scoped group; if more admins should get voice MFA, add them to group `304f941e-…`.
## Reference Information
- Vault entry: `clients/cascades-tucson/m365-sysadmin.sops.yaml`.
- GA account object id: `471b13dc-3cf8-416b-a132-f5f3bc8d1cc8`; alternateMobile method id `b6332ec1-7057-4abe-9331-3d72feddfe41`.
- Scoped Voice group: `304f941e-3594-4705-b8e6-ee676297df11` ("MFA - Voice Call Scoped (sysadmin)").
- Graph: `/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Voice`.
- Remediation skill: `.claude/skills/remediation-tool/`; RMM skill: `.claude/commands/rmm` / `/rmm`.
---
## Update: 11:16 MST — Caregiver restricted-access test setup (pilot.test + NURSESTATION + Intune)
### Session Summary
Built the controlled test rig to validate the caregiver/medtech restricted-access design before promoting it to all caregivers, and began on-machine testing on NURSESTATION-PC. Goal: a test account with the exact caregiver rule set to prove "onsite + correct device = ALIS via SSO; offsite or wrong device = blocked" works on a desktop, then move real users in.
Created a user test group `SG-Caregivers-DeviceTest` and made it carry the FULL caregiver rule set (added it to the off-network block + sign-in-frequency policies, set the allow-list policy to enabled+scoped to it, and excluded it from the compliance block). Created cloud test account `pilot.test@cascadestucson.com` (Business Premium, in the test group); had to purge the old soft-deleted pilot.test from the recycle bin first to free the UPN. Created a STATIC device group `Cascades - Caregiver Devices` for Intune policy targeting (NURSESTATION only, added by hand, not dynamic — so it won't sweep in the laptops).
Howard un-joined NURSESTATION-PC from the domain and Entra-joined it (now Win11 25H2). Tagged its Entra device object `CSCCaregiverDevice`, added it to the device group, and deleted its stale 2020 Workplace device record. NURSESTATION is Entra-joined but NOT Intune-enrolled (MDM auto-enroll never fired; MDM user scope not set).
Test attempts: pilot.test authenticated fine but ALIS was blocked by Conditional Access (AADSTS53003) — the `CSC - Caregivers: allow-listed devices only` policy. Diagnosis: the device claim flowed correctly (deviceId e16c4af5, Azure AD joined, trusted IP 184.191.143.62) and the device IS tagged — so the block is device-tag propagation lag into CA's filter cache (15-60 min). Also resolved two first-sign-in prompts: Windows Hello (local registry workaround + Intune disable-Hello profile) and an "Authenticator" registration nudge (excluded the test group from the Authentication Methods registration campaign; confirmed risk-based MFA is inert because the tenant has no Identity Protection P2 license).
### Key Decisions
- Test group `SG-Caregivers-DeviceTest` carries the full rule set (not just the allow-list) so a member gets the exact caregiver experience; pilot.test couldn't be added to the synced `SG-Caregivers` (Graph 400 on cloud member into on-prem-synced group), so the test group is the vehicle.
- Device group `Cascades - Caregiver Devices` is STATIC (manual membership) per Howard — add machines one at a time as verified, no auto-sweep.
- Intune enrollment is OPTIONAL for the core test (allow-list runs off the device tag; Hello/Authenticator handled locally). Enrollment only needed for managed polish (Shared PC Mode, managed lock).
- Scoped MDM auto-enroll to `devices@` (group `SG-Intune-Enrollment`) rather than All, per the "only caregiver devices" requirement.
### Problems Encountered
- Adding the cloud test account to `SG-Caregivers` failed (HTTP 400 — group is on-prem synced). Worked around by putting the full rule set on the cloud test group instead.
- Intune Shared PC Mode (`windows10SharedPCConfiguration`) POST rejected twice (BadRequest "Invalid OData type") via Graph — deferred to the Intune portal (Shared multi-user device template).
- WHfB-disable as a deviceEnrollmentConfiguration returned 403 (intune-manager app lacks enrollment-config write) — used a device-scoped OMA-URI (`PassportForWork/.../UsePassportForWork=false`) instead, which succeeded.
- ALIS blocked (53003) on test sign-ins -> device-tag propagation lag into CA (not MFA, not managed-state). Deleted stale 2020 NURSESTATION Workplace record to remove device-resolution ambiguity.
- "Set up Authenticator" nag -> registration campaign excluded SG-Caregivers but not the test group; excluded the test group. Risk-based MFA confirmed non-functional (no P2 license).
- `UID` is a read-only bash variable (caused an earlier 404); use a different var name for GUIDs.
### Configuration Changes (Entra/Intune — live, no repo files)
- New group `SG-Caregivers-DeviceTest` (`db5849ec-242d-4b05-9d1b-940a830e7a60`, users) — added to off-network block (`e35614e1`) + sign-in-freq (`7d491c7a`) include; allow-list (`1b7fd025`) enabled + scoped to it (renamed "...(TEST GROUP)"); excluded from compliance-block (`ede985e2`).
- New group `Cascades - Caregiver Devices` (`02c6f698-f9f5-452f-8996-4ea43d976d0a`, static devices) — member: NURSESTATION-PC.
- New group `SG-Intune-Enrollment` (`13d94f6e-a255-4e4d-b275-5c73f2bc421c`, users) — member: devices@ (scoped MDM auto-enroll).
- New user `pilot.test@cascadestucson.com` (`d26e0e5a-2f99-4ea9-8d4e-40dc02016d05`), Business Premium, usageLocation US, in SG-Caregivers-DeviceTest. (Old soft-deleted pilot.test purged from recycle bin.)
- NURSESTATION-PC Entra device (`dd941398-7202-4280-8614-87e40b9a0442`, deviceId `e16c4af5-cb0e-49e1-90be-674a216f5e9c`) tagged `extensionAttribute1=CSCCaregiverDevice`; stale 2020 Workplace record (`cb70bcab-efb8-4a60-859b-f35ab041f808`) deleted.
- Intune device configs (assigned to Cascades - Caregiver Devices): `CSC - Caregiver Idle Lock 5min` (id `7ef2d5da-6b50-477c-accd-7dda3a34ba25`, OMA-URI MaxInactivityTimeDeviceLock=5); `CSC - Caregiver Devices - Disable Windows Hello` (OMA-URI PassportForWork UsePassportForWork=false). Shared PC Mode NOT created (portal pending).
- Registration campaign (`/policies/authenticationMethodsPolicy`) excludeTargets += `db5849ec` (test group), alongside existing `8b8d9222` (SG-Caregivers).
- NURSESTATION local registry (on-device, by Howard): `HKLM\SOFTWARE\Policies\Microsoft\PassportForWork\Enabled=0` to disable WHfB until Intune-managed.
### Credentials
- `pilot.test@cascadestucson.com` / `CareTest2026!` — TEST account, DELETE after testing. No force-change. Not vaulted (ephemeral).
### Pending / Incomplete Tasks
- [ ] Retry ALIS as pilot.test once device tag propagates (53003 should clear) — proves the core desktop test.
- [ ] Howard: set ALIS staff Email = `pilot.test@cascadestucson.com` so ALIS resolves it after CA passes.
- [ ] Portal: MDM user scope = Some -> `SG-Intune-Enrollment`; reboot NURSESTATION to auto-enroll into Intune.
- [ ] After enrollment: Intune profiles (disable-Hello, idle-lock) apply automatically; build Shared PC Mode in portal (assign to Cascades - Caregiver Devices); drop the local WHfB reg workaround.
- [ ] After validation: promote rule set to `SG-Caregivers` (all 38 + Feller/Nyanzunda) — point allow-list at SG-Caregivers, disable compliance-block, then clean up test artifacts (pilot.test, test group).
- [ ] Optional: hard-block Windows desktop logon offsite (disable cached logon) — not needed since caregiver devices stay onsite.
### Reference
- Allow-list policy `1b7fd025-1aad-47c8-9274-c32c3e0b163c`; off-network block `e35614e1-...`; compliance-block `ede985e2-...`; sign-in-freq `7d491c7a-...`.
- ALIS app `d5108493-cba8-4f08-90b6-1bb0bc09eb2a`; admin-consent grant `reTK4etbykSC1ENMm9g1rTplOyzgVClCofKDVRrn-ds`.
- devices@ `aaca80c6-861b-4294-8068-1033c68d7667`. Threat model confirmed with Howard: remote credential abuse (hacker / bad employee from home) — fully blocked by the off-network + device allow-list CA (stolen caregiver creds unusable off-site/off-device).