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
alternateMobileset to Howard's number (520-585-1310) after Howard confirmed sign-in worked, rather than reverting to the prior 520-331-5551. - Used
sops setfor 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 asPATCHand it succeeded (204). - Vault
git pushwas rejected (remote ahead); resolved withgit pull --rebasethen push. bashreadonly-variable error usingUIDfor the user object id; renamed toOID.
Configuration Changes
- NURSESTATION-PC (Cascades, RMM agent): removed registry value
localadmin(was0) underHKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList. localadmin remains enabled and in Administrators (unchanged). - Vault
clients/cascades-tucson/m365-sysadmin.sops.yaml: updatedcredentials.passwordto Mike's current value; rewrotenoteswith 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), id304f941e-3594-4705-b8e6-ee676297df11, single membersysadmin@. - Authentication Methods policy: Voice method
statesetdisabled→enabled,includeTargetsscoped to group304f941e-…(wasall_users). sysadmin@alternateMobilephone method (b6332ec1-7057-4abe-9331-3d72feddfe41) changed from +1 520-331-5551 to +1 520-585-1310.
- Created security group "MFA - Voice Call Scoped (sysadmin)" (
Credentials & Secrets
sysadmin@cascadestucson.com(Global Admin "Computer Guru Support", object id471b13dc-3cf8-416b-a132-f5f3bc8d1cc8): password rotated by Mike 2026-06-04, now vaulted atclients/cascades-tucson/m365-sysadmin.sops.yaml(credentials.password). Value not reproduced here; retrieve viavault.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 idf5a89784-834f-47b1-82e2-7e3e9dd337ff(Windows, online), client "Cascades of Tucson". - M365 tenant
cascadestucson.com= tenant id207fa277-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 andgrep -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
alternateMobilenumber +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 idb6332ec1-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-DeviceTestcarries 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 syncedSG-Caregivers(Graph 400 on cloud member into on-prem-synced group), so the test group is the vehicle. - Device group
Cascades - Caregiver Devicesis 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@(groupSG-Intune-Enrollment) rather than All, per the "only caregiver devices" requirement.
Problems Encountered
- Adding the cloud test account to
SG-Caregiversfailed (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).
UIDis 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, deviceIde16c4af5-cb0e-49e1-90be-674a216f5e9c) taggedextensionAttribute1=CSCCaregiverDevice; stale 2020 Workplace record (cb70bcab-efb8-4a60-859b-f35ab041f808) deleted. - Intune device configs (assigned to Cascades - Caregiver Devices):
CSC - Caregiver Idle Lock 5min(id7ef2d5da-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 existing8b8d9222(SG-Caregivers). - NURSESTATION local registry (on-device, by Howard):
HKLM\SOFTWARE\Policies\Microsoft\PassportForWork\Enabled=0to 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.comso 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 blocke35614e1-...; compliance-blockede985e2-...; sign-in-freq7d491c7a-.... - ALIS app
d5108493-cba8-4f08-90b6-1bb0bc09eb2a; admin-consent grantreTK4etbykSC1ENMm9g1rTplOyzgVClCofKDVRrn-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).