ACC-V payload not returning a useable Logged In User value

[JoeB21810898662]

We resolved the initial issue of ACC-V not returning any values for "logged_in_users" XML in Enhanced Discovery payloads by changing the Agent Client Collector service to run as "Local System".

Our issue now is that the value being returned is of the format firstnamelastname, and not the format of the UPN the credential actually being used for logging in first.last@domain.com.  This is causing issues because ACC-V output can't be matched to the servicenow users record, since the username in the servicenow users record is the UPN from our Azure tenant.

We can not seem to get this resolved with the internal ServiceNow support teams without them recommending that we request an enhancement.  Looking for guidance on how to address this seemingly very standard logon process.

[SamD93108872890]

Thanks Severin! Do you know if there is a way to force the ACC to grab username@domain.com from the windows devices? We are an AAD environment and that format exists in various places on our endpoints but I am not sure how to get the ACC to find it. That would allow us to match on that. Currently the ACC is just returning fname.lastname or firstnamelastname and the domain shows as WORKGROUP.

[Severin Launiau]

@SamD93108872890: good question; that's the tricky part. See the query embedded in the OOTB script. Because it's part of the official ACC plugins signed by ServiceNow, you can't modify it directly.

For your immediate needs, you can write a custom check and fetch the user from + domain from osquery, maybe retrieve the domain from that ntdomains table. From there, do a mapping using the instructions from Will, Benoit and Kim in KB1122613 (also covered in the webinar How to expand Agent Client Collector capabilities).

Down the road, it would be nice to see this feature OOTB as it was already implemented for SAM advanced metering. The property sn_acc_vis_content.assigned_to_user_order was designed to allow for multiple sources of the username, and maybe some custom self-service capability could be introduced using configuration data files. Feel free to post on the Ideas portal if that makes sense.

[dougw]

***I'm not who you were replying to....

Good suggestion, however I've gone down this path.  In my environment osquery hands back 6 domains, all child domains of our root domain, with nothing coming from logged_in_users that can be programmatically linked to any of the domains without, say, hardcoding something with the user's SID.

Looking in an OOTB ACC payload I see 3 things under assigned_to_users:  1) logged_in_users, which shows a plain username (smithj), 2) computer_system_username (snithj), and 3) ad_domain (fu.bar.net).   I'm not sure that the ad_domain is for the user and not the computer, and in an environment like mine a user from domain1 can log into a computer on domain2 (AD trusts, dontcha know)

A custom check is certainly what is needed here but coming up with a 100% solid solution in a challenging environment with multiple domains is going to be interesting.

Anyhow, your reply to the other person confirmed that i was on the right track with a custom check.

As far as a UPN format being OOTB, I'm surprised that isn't already the case.  Too bad i can't wait on it.