SAS EG - Audit client user ID

[ssomak]

Hi there! I have a problem with auditing client user ID. Let me first describe the process: 1.) I have a table with some information 2.) Business user can modify this table in SAS EG - update records, delete of insert new ones 3.) I want to log every change on this table To log changes, I decided to use audit tables: proc datasets lib=&lib. nolist; audit my_table; initiate; quit; And here comes my problem. When I open my audit table, I can see some 'technical' columns, for example _ATUSERID_ (which contains &SYSUSERID.). In my environent this variable is always the same - it is technical user that (I think) runs Workspace Server session. And here I would add information of "real' user, for example I would add a column that will contain &_CLIENTUSERID. And my question is: is it possible? Maybe I could do this by changing some config files? Many thanks in advance!!!

[Kurt_Bremser]

Who then is the "real" user? How do your users log on to the metadata server (when they start EG)?

[ssomak]

Hi!

Thank you for your reply.

Users have their own login. Let's say that there is user XYZ01 and he logs into SAS EG using this login and his password. Then, as I understand, SAS EG runs Workspace Server session, and the owner of this session is some technical user, let's say that his login is ZZZ01. And then, when I open my audit table, for all changes I see only technical user (ZZZ01) instead of users XYZ01, XYZ02 etc.

In other words, in my audit table there is &SYSUSERID. (he is the same for every EG session), and I would like to put to that table for example value of &_CLIENTUSERID...

[Kurt_Bremser]

So it looks that you either use a pooled workspace server or that all your metadata users point to the same OS account. You need to fix that, so that every user starts the workspace server session with their own userid.

[ssomak]

Ok, thank you very much. So I will talk to the admins and verify how it works and how it can be fixed.

Thanks

[ssomak]

Hi again!

I will post another question related to the topic, maybe someone knows it 🙂

I am just wondering if there is a possibility to somehow re-configure audit tables to log more information, like for example add column with CLIENTUSERID or something else (or just change SYSUSERID to CLIENTUSERID?

Thanks in advance!

[ssomak]

Hi there,

I would add that in my case all metadata users point to the same OS account. So the question is: can I make some workaround to log metadata user instead of OS user in audit tables? Or in general: can I somehow log what (metadata) user make change on a particular table?

Any help will be appreciated!

[Kurt_Bremser]

---

@ssomak wrote:
Hi there,

I would add that in my case all metadata users point to the same OS account.

---

There you have it. Fix that. Everybody who needs a workspace server MUST have their own OS account, period. Not because SAS, but common sense demands it. Your troubles with the audit trail are just one tiny foreshadowing of all the problems you'll have in the future.

[ssomak]

Hi again,

Thank you so much for your reply. So as I understand, the only one thing to audit "real" user (_CLIENTUSERID in my case) is to re-configure the whole environment.
It is such a pity that I cannot configure audit trial (for example change sysuserid to clientuserid) ... 😞

[Kurt_Bremser]

---

@ssomak wrote:
Hi again,

Thank you so much for your reply. So as I understand, the only one thing to audit "real" user (_CLIENTUSERID in my case) is to re-configure the whole environment.
It is such a pity that I cannot configure audit trial (for example change sysuserid to clientuserid) ... 😞

---

There's a very simple reason for that. The audit trail has to rely on the macro variable, and while &sysuserid is set by the SAS system at the initialization of any session, &_clientuserid is set only by some clients and not always there.

There are other reasons why usage of a generic user is considered, ahem, suboptimal. You cannot use any operating system tools for managing individual user workload (workload manager, filesystem quotas, ...), and the system itself has no means of tracking the "real" user behind any operation.

For something like the workspace server, usage of a common user is strictly forbidden in our company.