azcomputerguru/claudetools
1
0
Fork 0
Code Issues 58 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ab987bf9e1084e38814fc0413d993e184f470d4e
claudetools/clients/cascades-tucson/session-logs/2026-07/2026-07-09-howard-charity-menle-caregiver-rename.md
Howard Enos 9926e5f2cc sync: auto-sync from HOWARD-HOME at 2026-07-09 11:00:18 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-07-09 11:00:18
2026-07-09 11:01:24 -07:00

13 KiB
Raw Blame History

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 .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 .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):

$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)".
Reference in New Issue View Git Blame Copy Permalink