Question

Mirroring client resets auditing

Audit Trail Version 9 Version 8 Version 10 Administration

Updated January 20, 2016

asked on January 18, 2016

I am coping an established client in LFAC in order to create (paste), a new client with the same security, attributes and auditing options. When I paste the new profile in LFAC, the auditing options change from 'Group Membership' to 'Selected events' with none of the events selected. Consequently, I have clients performing tasks in the repository without benefit of a proper audit entry. This has been noted in Laserfiche 10 Administration Console version 10.0.0.900 and previous released versions.

Two things. With over 700 clients in a repository (some active and some inactive), is there a quick way to identify which active accounts are set to 'Group membership' and which ones are not? Maybe an SQL?

Second, if I set an audit event in the 'Everyone' account, how will that affect the 'Group' auditing which may or may not have that event checked?

1 0

Answer

SELECTED ANSWER

replied on January 19, 2016

I've filed a bug about the copy and paste of users.

Information about what is audited for whom can be found in the account_security table. If the auditmask column is NULL, that's "group membership". Users set to use their own masks, with no events audited, will have a value of 0.

If these are all repository users, you can join to the trustee table on the SID to get names of affected trustees. If there are directory users involved also, you might try account_cache.

As usual, we don't support direct updates to the SQL data. In particular, in this case there are some system users that are set up with auditmask of 0 (to keep them from spamming the audit log), and they should stay that way.

As for your second question, "Everyone" is treated as a group like any other. If a user is being audited based on group membership, the server will audit any event that is audited for any group they are a member of.

0 0

Replies

replied on January 20, 2016

Thanks for the reply Andrew.

So you are stating while the bug exists the most effective way to ensure everyone's actions are captured in the audit DB is to set the appropriate audit events on the auditing tab for 'Everyone'.

0 0

replied on January 20, 2016

Setting up a mask on "Everyone" will not help you in the case you describe, because user-specific audit settings override any from groups. You will still need to find the affected users and change them back to audit-by-group-membership.

0 0

You are not allowed to follow up in this post.

Question

Question

Mirroring client resets auditing

Answer

Replies

Sign in to reply to this post.