You are viewing limited content. For full access, please sign in.

Question

Question

Is Audit Trail disabled by default in new Cloud Systems?

asked on October 11

We had a customer that needed to make use of the audit trail in Cloud but found no events, then we found it was not enabled after checking the configure audit trail documentation.

They don't think it is very likely that someone with administrative access would have found and disabled it on purpose or by accident.

All the boxes below were unchecked on the Everyone user. Is this something need to be manually enabled for cloud systems. Often people don't know they need audit trail until something unexpected happens.

0 0

Answer

SELECTED ANSWER
replied on October 11

Was this repository migrated from self-hosted?

Shawn is correct, that is the default state for the repository. For repositories imported from a self-hosted installation, their audit settings pre-migration are preserved.

0 0
replied on October 14

I see, they did have an on-prem system at one time. It does not carry over audit information during the migration? Only the audit settings?

We should still be able to see when and who disabled the audit log if the Audit information Shawn mentioned below was migrated over. It seems the audit log always stores who disables/enables as well as any purge events in all cases.

0 0
replied on October 14

If there were audit logs, they were carried over to cloud during repository migration, but only events from the past 365 days are available for reporting in Laserfiche Cloud. This is assuming the repository was migrated to Laserfiche Cloud through the migration utility and not by other means (briefcase export/import, SDK, etc.)

From your description, it sounds like the audit settings were disabled more than 365 days ago, if they were ever on. Self-hosted repositories are created with auditing off.

1 0
replied on October 14

Ok got it, yes I think the on-prem system would be more than a year old.

0 0

Replies

replied on October 11

I can only speak from my experience with our client cloud environments and the Everyone user definitely has Auditing enabled by default for all event types with the exception of Search and View Entry.  Those two event types are not enabled by default as they generate a lot of audit log data very quickly for a relatively low risk event.

The good news for your particular issue is that even if it seems unlikely that an admin user would have made a change to the Everyone user, if they had it would have been recorded in Audit Trail. 

In Audit Trail if you set the Event Types to include Auditing > Change Audit Configuration for your Report Filter it will show any time the Audit Configuration has been altered. 

You can additionally set a column filter on the 'Request data' column to limit the returned events to only include items where Trustee name is equal to Everyone. 

You will likely have to set your date range to cast a wide net if this change occurred early in this environment lifetime.

 

3 0
replied on October 11 Show version history

Thanks for that insight. It seems maybe someone purged the audit logs here? And it purged even the purge event history? I just searched back 100,000 days and all I get back is the change made today to enable auditing. How can this be possible, how is there not even a login event or any other events in all of history until today when we enabled it.

 

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.