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

sync: auto-sync from HOWARD-HOME at 2026-07-09 11:00:18

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-07-09 11:00:18
This commit is contained in:
Howard Enos
2026-07-09 11:00:52 -07:00
parent 252d22048b
commit 9926e5f2cc
4 changed files with 155 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
clients/cascades-tucson/docs/cloud/caretaker-phones-only-list.md
View File

@@ -25,7 +25,7 @@ Transportation drivers, who do not get ALIS/M365 caregiver access at all.
| Ashli Atwood | a.atwood | D+P | TBD |
| Alejandra Vallejo | a.vallejo | new hire 7/1 | TBD |
| Barb Johnson | b.johnson | D+P | TBD |
| Charity Sika | b.sika | D+P | TBD |
| Charity Menle | c.menle | D+P | TBD |
| Cole Johnson | c.johnson | D+P | TBD |
| Celia Lassey | c.lassey | D+P | TBD |
| Espe Esperance | e.esperance | D+P | TBD |

142
clients/cascades-tucson/session-logs/2026-07/2026-07-09-howard-charity-menle-caregiver-rename.md Normal file
View File

@@ -0,0 +1,142 @@
# 2026-07-09 — Cascades of Tucson: Charity Sika -> Charity Menle caregiver rename (ALIS SSO)
## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech
---
## Session Summary
The request arrived as "Charity Menle needs an email setup for Cascades Tucson and be put in the caregivers group," with a follow-up clarifying the goal was to make ALIS SSO work for her. Before provisioning anything, the name was checked against the authoritative sources. "Menle" appeared nowhere — not in the ALIS roster (612 staff records pulled via the read-only API), not in AD, and not in any Cascades doc, roster, or CSV in the repo. The only Charity on record was Charity Sika, whose AD account `b.sika` already existed, was enabled, Business Premium licensed, and already a member of `SG-Caregivers`. The `b.` initial derives from her legal first name Bariffa, documented at `clients/cascades-tucson/scripts/create-caregiver-accounts.ps1:11`.
Rather than create an account, the identity conflict was raised with the user. He confirmed it was the same person, that she had legally changed her name, and that he had already updated the ALIS record himself. A re-read of ALIS staffId 309045 confirmed it: `Charity Menle`, `primaryEmail = c.menle@cascadestucson.com` (it had been `Bariffa Sika` with a null email earlier in the same session). Since ALIS SSO joins on **ALIS `Email` == Entra UPN**, and AD still carried `b.sika@cascadestucson.com`, the mismatch was the actual reason SSO would not resolve. The correct fix was a rename of the existing object, not a new account — a duplicate would have consumed a second Business Premium seat and left two AD objects competing for one ALIS staff record, the same failure that produced the `t.lassey-assiakoley` duplicate on the 7/1 reconcile.
A read-only pass on `b.sika` showed a clean object: empty `mail`, empty `proxyAddresses`, `PasswordExpired = False`, `PSO-Caregivers` applying, and `SG-Caregivers` as the only group. No collision existed on `c.menle` or `c.menle@cascadestucson.com`. The plan was previewed to the user (including the fact that her Windows/M365 login username would change while her password would not), and he approved.
The rename ran on CS-SERVER as a single PowerShell script via GuruRMM (`cmd:518f678e`, exit 0): `Set-ADUser` for `Surname`/`DisplayName`/`UserPrincipalName`/`EmailAddress` plus an explicit `proxyAddresses` add, then `Rename-ADObject` for the CN, then `Set-ADUser -SamAccountName`. `Start-ADSyncSyncCycle -PolicyType Delta` was invoked in the same script (the ADSync module is present on CS-SERVER, confirming Entra Connect runs there). The Entra export is asynchronous — the first Graph read still returned the old UPN, and the object only reflected the rename on a subsequent poll roughly 25 seconds later.
Post-change verification via the `remediation-tool` investigator tier confirmed the cloud object: `displayName = Charity Menle`, `userPrincipalName`/`mail` = `c.menle@cascadestucson.com`, `onPremisesSamAccountName = c.menle`, `accountEnabled = true`, `usageLocation = US`, license `SPB` intact, and `SG-Caregivers` (`8b8d9222`) membership unchanged. `proxyAddresses` carried `SMTP:c.menle@` (primary), `smtp:b.sika@` (alias), and the tenant `smtp:b.sika@NETORGFT4257522.onmicrosoft.com` routing alias that Entra Connect preserved on its own. The 6/29 open item ("Confirm Charity Sika (CSV) == Bariffa Sika (ALIS 309045)") was resolved and closed in the wiki.
---
## Key Decisions
- **Renamed the existing AD object instead of creating a new account**, against the literal wording of the request. A second account would duplicate the identity, consume a second Business Premium seat (SPB pool had only 4 free as of 7/1), and leave two AD objects competing for one ALIS staff record — the `t.lassey-assiakoley` failure mode. The user's own clarification ("just edit the sika bariffa account to match the new name") confirmed this reading.
- **Stopped and asked before writing** rather than provisioning on a name that matched nothing in ALIS, AD, or any repo doc. The discrepancy between "Menle" and the only on-record Charity (Sika) was too large to resolve by inference.
- **Set `proxyAddresses` explicitly** (`SMTP:c.menle@` primary + `smtp:b.sika@` alias) rather than relying on the UPN change to move the mailbox. These caregiver objects have an empty `proxyAddresses`, so Exchange Online derived primary SMTP from the UPN at provisioning; renaming the UPN alone is not a reliable way to move primary SMTP, and without the old address as an alias, inbound mail to `b.sika@` would bounce.
- **Changed `sAMAccountName` to `c.menle`** rather than leaving `b.sika`. The Cascades design is Windows login = email = M365/ALIS identity (one credential everywhere); leaving the old sAMAccountName would have defeated it.
- **Did not touch group, license, or password.** All three ride the unchanged object — `SG-Caregivers` membership, Business Premium, and `PSO-Caregivers` (never-expire) survive a rename. Re-adding any of them would have been a no-op at best.
- **Left ALIS alone.** The user explicitly took that side. Her ALIS record already reads `Charity Menle` / `c.menle@`, so no `--format update` .xls import was needed.
---
## Problems Encountered
- **`--json` is a global flag on the `alis` CLI, not a subcommand flag.** `alis.py staff --json` errored with `unrecognized arguments: --json`; the correct form is `alis.py --json staff`. Resolved by moving the flag before the subcommand.
- **Used `$UID` as a shell variable in a Bash tool script.** `UID` is readonly in bash, so the assignment failed (`readonly variable`) and the downstream Graph `licenseDetails` / `memberOf` calls silently ran against an empty user id, returning nothing. Resolved by renaming the variable to `OBJ`. Logged to `errorlog.md` via `log-skill-error.sh --friction`.
- **First Graph read after the delta sync still returned the old UPN**, which reads as a failed sync. It is not — `Start-ADSyncSyncCycle` returned `Success` and the Entra export is asynchronous. Resolved by polling the object by its stable objectId (`0dd5cb5d-…`) until the UPN flipped, which took roughly 25 seconds. Note the lookup had to be done by objectId or old UPN, since `GET /users/c.menle@…` 404s until the sync lands.
---
## Configuration Changes
**Live AD / Entra (CS-SERVER, `cascades.local`) — user object `cfa2d909-4cf2-46a5-8a1c-120602e2a2e2`:**
| Attribute | Before | After |
|---|---|---|
| `sAMAccountName` | `b.sika` | `c.menle` |
| `userPrincipalName` | `b.sika@cascadestucson.com` | `c.menle@cascadestucson.com` |
| `CN` / `Name` | `Charity Sika` | `Charity Menle` |
| `DisplayName` | (empty) | `Charity Menle` |
| `Surname` | `Sika` | `Menle` |
| `mail` | (empty) | `c.menle@cascadestucson.com` |
| `proxyAddresses` | (empty) | `SMTP:c.menle@cascadestucson.com`, `smtp:b.sika@cascadestucson.com` |
Unchanged: `GivenName` (`Charity`), `Enabled` (true), password, `SG-Caregivers` membership, Business Premium (`SPB`) license, `PSO-Caregivers` resultant policy, OU (`OU=Caregivers,OU=Departments,DC=cascades,DC=local`).
**Repo files modified:**
- `wiki/clients/cascades-tucson.md` — resolved the 6/29 "Confirm Charity Sika == Bariffa Sika" open item; added new subsection **"Caregiver name changes -- rename, never re-create"** documenting the procedure, the `proxyAddresses` gotcha, the async-sync gotcha, and the vault-key gotcha.
- `clients/cascades-tucson/docs/cloud/caretaker-phones-only-list.md` — roster row `Charity Sika | b.sika` -> `Charity Menle | c.menle`.
- `errorlog.md` — one `--friction` entry (bash `$UID` readonly).
---
## Credentials & Secrets
- **No credential was created, rotated, or changed.** Her password is unchanged by the rename.
- **Vault key gotcha:** Charity Menle's temp password remains filed under the OLD sAMAccountName key — `b.sika` in `clients/cascades-tucson/caregiver-temp-passwords-2026-06-30.sops.yaml`. Retrieve with `vault get` (NOT `get-field` — the keys contain dots). She now signs in as `c.menle` with that same password. The vault entry was deliberately not re-keyed.
- Tokens used this session: GuruRMM JWT via `.claude/scripts/rmm-auth.sh` (vault `infrastructure/gururmm-server.sops.yaml`); ALIS JWT via `clients/cascades-tucson/alis-api-howard-user.sops.yaml`; Graph token via `remediation-tool` `get-token.sh cascadestucson.com investigator`.
---
## Infrastructure & Servers
- **CS-SERVER** — `192.168.2.254` (SMB clients use `192.168.2.248`). DC / DNS / file server / Hyper-V host. GuruRMM agent `c39f1de7-d5b6-45ae-b132-e06977ab1713` (resolved live via `rmm-search.sh`, never hardcoded). **Confirmed this session: the `ADSync` module is present on CS-SERVER — Entra Connect runs here**, so `Start-ADSyncSyncCycle -PolicyType Delta` can be dispatched directly to this agent.
- **Tenant:** `cascadestucson.com`, routing domain `NETORGFT4257522.onmicrosoft.com`.
- **Entra objects:** user `0dd5cb5d-6143-4151-b4a7-6e37b3d071b0` (cloud), AD GUID `cfa2d909-4cf2-46a5-8a1c-120602e2a2e2`; group `SG-Caregivers` = `8b8d9222-5d71-419a-936d-56d895c6c332`.
- **ALIS:** communityId 622, staffId **309045** — now `Charity Menle`, `primaryEmail = c.menle@cascadestucson.com`, status Hired, jobRole `Certified Caregiver`, securityRoles `[Caregiver (Cascades)]`.
---
## Commands & Outputs
Resolve the agent (never hardcode the UUID):
```bash
bash .claude/scripts/rmm-search.sh cs-server -c cascades --json
# -> CS-SERVER c39f1de7-d5b6-45ae-b132-e06977ab1713 online
```
Read the ALIS roster (note `--json` is a GLOBAL flag, before the subcommand):
```bash
bash .claude/scripts/py.sh .claude/skills/alis/scripts/alis.py --json staff --limit 1000
```
The rename itself (dispatched to CS-SERVER as `powershell`, `cmd:518f678e`, exit 0):
```powershell
$u = Get-ADUser b.sika -Properties proxyAddresses
$g = $u.ObjectGUID
Set-ADUser -Identity $g -Surname "Menle" -DisplayName "Charity Menle" `
-UserPrincipalName "c.menle@cascadestucson.com" -EmailAddress "c.menle@cascadestucson.com" `
-Add @{proxyAddresses=@("SMTP:c.menle@cascadestucson.com","smtp:b.sika@cascadestucson.com")}
Rename-ADObject -Identity (Get-ADUser -Identity $g).DistinguishedName -NewName "Charity Menle"
Set-ADUser -Identity $g -SamAccountName "c.menle"
Import-Module ADSync; Start-ADSyncSyncCycle -PolicyType Delta # -> Result: Success
```
Post-sync Entra verification (poll by objectId — `GET /users/c.menle@…` 404s until the export lands):
```
displayName: Charity Menle | userPrincipalName: c.menle@cascadestucson.com
mail: c.menle@cascadestucson.com | onPremisesSamAccountName: c.menle
accountEnabled: true | usageLocation: US | license: SPB
proxyAddresses: smtp:b.sika@cascadestucson.com, SMTP:c.menle@cascadestucson.com,
smtp:b.sika@NETORGFT4257522.onmicrosoft.com
memberOf: SG-Caregivers 8b8d9222-5d71-419a-936d-56d895c6c332
```
Error encountered and its fix:
```
/usr/bin/bash: line 15: UID: readonly variable # $UID is reserved in bash -> use OBJ
alis: error: unrecognized arguments: --json # --json is a global flag: alis.py --json staff
```
---
## Pending / Incomplete Tasks
- **Howard (ALIS side, self-assigned):** disable ALIS-native 2FA for Charity Menle so "Sign in with Microsoft" completes silently on the shared Samsung phone. The Email=UPN join key is now satisfied on both sides.
- **Tell Charity her login username changed** to `c.menle` — her password did NOT change and is still vaulted under the `b.sika` key in `caregiver-temp-passwords-2026-06-30.sops.yaml`.
- **Not verified end-to-end:** actual phone SSO sign-in as `c.menle`. Everything upstream of it (UPN, license, group, PSO, ALIS email) is confirmed, but no sign-in was observed this session.
- Carried over, untouched this session: **Juan Andrade (`j.andrade`) offboards 2026-07-11** (disable + remove from `SG-Caregivers` + reclaim SPB); ALIS Email=UPN backfill for the remaining caregivers; ALIS records for the 3 new hires (Munezero, Cota, Robinson); Vallejo's ALIS Email=UPN; ALIS app timeout 20 -> 15 min; reboot NURSESTATION to activate the lockdown GPO.
---
## Reference Information
- GuruRMM command id: `518f678e-7f9f-42f9-b8e5-f0317a84ba36` (the rename, exit 0). Earlier read-only probes: `eb5855c9-…` (name search), plus one attribute read.
- `#dev-alerts` post: message_id `1524831396915314729`.
- Syncro customer ID **20149445**. No ticket was opened for this change.
- Prior art / why rename-not-recreate: `clients/cascades-tucson/reports/2026-07-01-caretaker-roster-update.md` (the `t.lassey-assiakoley` duplicate), and `clients/cascades-tucson/scripts/create-caregiver-accounts.ps1:11` (`b.sika -- Charity Sika (legal first name Bariffa drives the initial)`).
- Forced-change / `50126` phone-login rule and `PSO-Caregivers` rationale: `wiki/clients/cascades-tucson.md`, sections "Caregiver phone login -- forced-change-at-next-logon gotcha" and "Caregiver password expiry".
- New wiki section written this session: "Caregiver name changes -- rename, never re-create (Charity Menle, 2026-07-09)".