azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from HOWARD-HOME at 2026-06-05 12:18:49

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-05 12:18:49
This commit is contained in:
Howard Enos
2026-06-05 12:18:57 -07:00
parent 08e194f592
commit ef23753956
2 changed files with 29 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
clients/cascades-tucson/session-logs/2026-06-05-session.md
View File

@@ -128,3 +128,31 @@ Test attempts: pilot.test authenticated fine but ALIS was blocked by Conditional
- 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).
---
## Update: 12:17 MST — Core test PROVEN; enrollment blocked on Intune license provisioning
### Result
**The caregiver restricted-access model is proven end-to-end on a desktop.** pilot.test signed into NURSESTATION-PC, and **ALIS opened via Microsoft SSO**, with the lockdown holding (off-network blocked, only allow-listed device passes). That was the goal.
### How ALIS finally passed
First attempts threw CA **AADSTS53003** (allow-list block) even though NURSESTATION was tagged `CSCCaregiverDevice`, on a trusted IP (184.191.143.62), with the device claim flowing correctly (deviceId e16c4af5, Azure AD joined, valid PRT). Root cause: **device extensionAttribute changes take a long time (>70 min here) to propagate into CA's device-filter cache.** Fix: added NURSESTATION's **intrinsic deviceId directly to the allow-list rule** (policy changes propagate in minutes; deviceId isn't subject to the attribute cache) — ALIS then worked immediately. **Takeaway:** for the small caregiver device set, matching by **deviceId** in the allow-list is the reliable, lag-free lever; the `extensionAttribute1` tag is fine but slow to take effect.
### Open blocker: Intune enrollment (license provisioning)
NURSESTATION is Entra-joined but won't Intune-enroll. Walked it down with `dsregcmd /status`: device healthy, AzureAdPrt YES, but **`MdmUrl` blank**. Confirmed MDM user scope = Some -> `SG-Intune-Enrollment` (correct) and devices@ is a member (correct). **Actual root cause:** the **Intune service plan on the enrolling account is not provisioned** — `INTUNE_A: PendingInput` on both newly-licensed accounts (devices@ AND pilot.test), while established users (Megan) are fine. A device cannot enroll through an account whose Intune plan isn't active. Re-kicked the Business Premium license on devices@ (remove + re-add; first re-add 409'd and was retried to 200 — confirmed SPB back on the account). `INTUNE_A` still `PendingInput` immediately after — provisioning takes time. Re-check in 20-30 min.
### Windows Hello prompt (still showing)
The "set up Windows Hello" prompt persisted on pilot.test despite the local reg key (`PassportForWork\Enabled=0`) and reboots — I was wrong that a reboot would fix it. Fact: **tenant WHfB enrollment policy = `notConfigured`**, so Windows applies its default (WHfB ON) on Entra-joined devices, and the generic reg key doesn't reliably override it. The clean, scoped fix is the **Intune disable-Hello profile** (already built, assigned to Cascades - Caregiver Devices) — which applies once the device is Intune-enrolled. The prompt is dismissible, so it didn't block the test. Tenant WHfB left untouched so office users keep PIN + Authenticator (their offsite 2FA preserved).
### Config changes (live)
- Allow-list policy `1b7fd025` rule now: `(device.displayName -startsWith "CSC-") -or (device.extensionAttribute1 -eq "CSCCaregiverDevice") -or (device.deviceId -eq "e16c4af5-cb0e-49e1-90be-674a216f5e9c")` (mode exclude).
- devices@ Business Premium license removed + re-added (kick Intune provisioning). SPB confirmed re-present.
### Pending (updated)
- [ ] Re-check `devices@` `INTUNE_A` -> Success (re-check ~20-30 min after 12:17 MST). Once Success: reboot NURSESTATION -> auto-enrolls -> disable-Hello + idle-lock apply.
- [ ] If still `PendingInput` after a while: tenant new-license Intune activation issue (both new accounts affected) — may need more time / MS support; does NOT block the working caregiver access.
- [ ] After enrollment: drop the local WHfB reg hack; build Shared PC Mode in portal (assign to Cascades - Caregiver Devices).
- [ ] Howard: confirm pilot.test ALIS staff Email = `pilot.test@cascadestucson.com` (ALIS resolved it this session, so likely set).
- [ ] Promote rule set to `SG-Caregivers` (all 38 + Feller/Nyanzunda); for devices, prefer **deviceId matching** in the allow-list (reliable) — collect the 6 caregiver-device deviceIds. Then disable compliance-block + clean up test artifacts (pilot.test, test group).
- [ ] LESSON: check Intune license provisioning (`INTUNE_A = Success`) before troubleshooting enrollment; CA device-filter extensionAttribute changes lag (use deviceId for immediacy).