wwtools/mxaccesscli/2026-05-03-user-attribution-investigation.md

User-attribution investigation — pick-up notes

Started: 2026-05-03 · Last updated: 2026-05-04 · Status: open

Goal

Get the Historian's Events.User_Name / Events.User_Account columns to reflect the authenticated user (dohertj2) on Alarm.Acknowledged rows when an ack is issued via mxa write <alarm>.AckMsg. Anonymous writes (no --username) should remain NULL.

What's been tried

Each row's Alarm.Acknowledged User_Name/User_Account field is the result we cared about.

#	Galaxy security	Advise variant on ack	Write variant on ack	auth_user_id	User_Name	Notes
1	eNone	Advise	Write	1	DefaultUser	Galaxy in Free-Access mode mapped every action onto DefaultUser. Even bad password / unknown user resolved to userId=1.
2	eNone	Advise (explicit, after wiring AdviseSupervisory for anonymous)	Write	1	DefaultUser	Advise-variant routing landed but galaxy still mapped to DefaultUser.
3	eOSUserBased (no role)	Advise	Write	1	NULL	Mode flip removed the DefaultUser over-attribution. dohertj2 not yet attributed because user wasn't in any role.
4	eOSUserBased + ArchestraUsers role	Advise	Write	1	NULL	After role assignment. Auth proven to validate (bad password throws ArgumentException — fixed in MxSession.Authenticate to surface as auth_user_id=0). Still no User_Name.
5	same	Advise	Write (with --client <hostname>)	1	NULL	User_NodeName flowed from --client (now DESKTOP-6JL3KKO); confirms --client is just a workstation tag, not a security primitive.
6	same	Advise	WriteSecured (--secured, single-user)	1	NULL	WriteSecured(currentUserId=verifierUserId=1, value) succeeded with MxCategoryOk but did not change attribution. Conclusion: User_Name population is not gated on Write vs WriteSecured.

Current state of the code

• mxa write accepts --username/--domain/--password → AuthenticateUser → userId for Write / WriteSecured.
• mxa write accepts --secured (single-user Secured) and --verifier-username/--verifier-domain/--verifier-password (two-user Verified Write).
• Advise variant routes by user: Advise when authenticated, AdviseSupervisory when anonymous. See docs/usage.md.
• MxSession.Authenticate catches ArgumentException from the proxy and normalizes to userId=0 → CLI emits clean authentication-failed envelope, exit 1.

Current state of the galaxy (ZB)

Setting	Value
MxSecurityModelType	eOSUserBased
IGalaxyUsers.Count	0 (read-only collection; doesn't reflect runtime logins via MxAccess)
IGalaxyRoles.Count	0 (same)
IGalaxyGroups.Count	0 (same)
Configured users (per IDE)	DESKTOP-6JL3KKO\dohertj2 assigned to ArchestraUsers
DevPlatform, DevAppEngine	deployed before the security mode change

Leading hypothesis (not yet tested)

The running aaEngine processes are still operating under the original eNone security context because galaxy security is compiled into the platform/engine deployment. New auth rules don't take effect for already-running engines until they are redeployed (or aaBootstrap is restarted).

This is consistent with:

• auth_user_id returning 1 on every successful authentication regardless of mode/user — the engine's runtime still treats authenticated calls as the legacy default operator.
• User_Name=NULL rather than dohertj2 — the engine has no way to map our session's userId onto its (stale) user table.
• IGalaxyUsers not populating from MxAccess logins — that's the design (population requires IDE-driven login activity), but it also means we can't verify enrollment from the CLI side.

Next step — pick up here

1. Undeploy + redeploy DevPlatform and below, then rerun the alarm sequence. Driving this through graccesscli:

   $CLI="c:/Users/dohertj2/Desktop/wwtools/graccesscli/src/ZB.MOM.WW.GRAccess.Cli/bin/x86/Debug/net48/ZB.MOM.WW.GRAccess.Cli.exe"
   $HOST=$env:COMPUTERNAME
   
   # Top-down undeploy (objects -> areas -> engine -> platform)
   & $CLI objects undeploy --galaxy ZB --node $HOST --names TestMachine_001  # cascades, see graccesscli docs
   & $CLI objects undeploy --galaxy ZB --node $HOST --names DevAppEngine
   & $CLI objects undeploy --galaxy ZB --node $HOST --names DevPlatform
   
   # Bottom-up redeploy
   & $CLI objects deploy --galaxy ZB --node $HOST --names DevPlatform
   & $CLI objects deploy --galaxy ZB --node $HOST --names DevAppEngine
   & $CLI objects deploy --galaxy ZB --node $HOST --names TestArea
   & $CLI objects deploy --galaxy ZB --node $HOST --names TestMachine_001
   

   (Confirm exact command surface via graccesscli objects deploy --help before running — undeploying a running engine drops live-data feeds.)

2. Re-run the alarm-attribution test (the same sequence used in run #6):

   $MXA="c:/Users/dohertj2/Desktop/wwtools/mxaccesscli/src/MxAccess.Cli/bin/x86/Release/net48/mxa.exe"
   $HOST=$env:COMPUTERNAME
   
   & $MXA write TestMachine_001.TestAlarm002 true --type bool --client $HOST -t 10
   & $MXA write TestMachine_001.TestAlarm002.AckMsg "post-redeploy ack" `
       --username dohertj2 --domain $HOST --password Sonamu89 `
       --secured --client $HOST -t 12 --llm-json
   & $MXA write TestMachine_001.TestAlarm002 false --type bool --client $HOST -t 10
   

3. Query the Historian (template):

   DECLARE @start datetime2 = DATEADD(minute, -3, GETDATE());
   DECLARE @end   datetime2 = GETDATE();
   SELECT EventTime, Type, Alarm_State, Comment,
          User_Name, User_Account, User_NodeName,
          LEFT(CAST(Alarm_ID AS varchar(40)), 8) AS id_short
   FROM Events
   WHERE Source_ConditionVariable = 'TestMachine_001.TestAlarm002'
     AND EventTime BETWEEN @start AND @end
   ORDER BY EventTime ASC;
   

4. Compare — does User_Name = dohertj2 (or User_Account = DESKTOP-6JL3KKO\dohertj2) on the Alarm.Acknowledged row?

Fallbacks if redeploy doesn't change anything

• Restart aaBootstrap. Heavier-handed but forces the entire ArchestrA stack to reload galaxy config. (Will interrupt the test alarm cycle on TestAlarm001.)
• Try a Verified Write (two-person), supplying both --username dohertj2 and --verifier-username dohertj2 (or two different OS users). The audit subsystem may only fully attribute Verified Writes.
• Check the attribute's security classification. TestAlarm002.AckMsg may be Free Access, in which case the engine doesn't need to verify the user and may discard the identity. Set the security classification to Operate (or stricter) on the template, redeploy, retest. Per aot/dev-guide/appendix-e-security-classifications.md, only stricter classifications enforce user identity in the audit.
• Sample a different attribute that we know other tools (Object Viewer, InTouch) record User_Name on. If those clients also produce NULL, the issue is system-wide (galaxy still misconfigured); if they record a user, the issue is specific to the MxAccess Write path.

Files touched in this investigation

• src/MxAccess.Cli/Mx/MxSession.cs — Authenticate catches ArgumentException.
• src/MxAccess.Cli/Mx/MxItem.cs — WriteSecured method.
• src/MxAccess.Cli/Commands/WriteCommand.cs — --username/--domain/--password, advise routing, --secured/--verifier-*.
• docs/usage.md — Authentication, Advise variant, userId is session-scoped sections.

Galaxy state

Alarm TestMachine_001.TestAlarm002 is cleared (ACK_RTN) at the close of run #6. No lingering active alarms. Other test attributes restored to their original values.