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

15 KiB

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 disabledenabled, 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\UserListlocaladmin = 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).