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

Question

Question

Recursive access rights report

asked on November 20, 2020

I need a way to generate a complete report of access rights for all folders, subfolders and documents in a repository, similar to the reported functionality of the "Permissions Report" tool at https://www.laserfiche.com/solutionexchange/report-access-rights-for-an-entry-or-set-of-entries.

This tool from 2007 is now almost old enough to enroll in high school, so I am hoping that this functionality is either built in or available in a more modern utility.

Specifically, for all folders, subfolders and documents, I want to list:

1) Any folder or document with explicit (non-inherited) permissions 

2) User/group, permissions and scope

3) Any subfolders with inheritance disabled

The built-in access rights reports that I could find only report on effective user permissions for one or more users against a single folder. They don't list explicit permissions, groups, scope, or inheritance and they offer no way to report on subfolders.

1 0

Replies

replied on February 18, 2021

I put together a workflow with scripts to generate this report and it worked quite well. I've attached it here for reference; a few notes:

  1. I had to make the extension .txt in order to upload; just drop that off so it's a WFX
  2. It searches for all folders with security explicitly assigned. I ran a slightly different version of the WF for documents, but you can include docs by updating the search syntax.
  3. A script gets the info about each right assigned and then adds that as a line for the table output.
  4. I did not include any distinction between group and user, but you can probably add that.
  5. I ended up using tabs as my delimiters due to some folder names having commas.
  6. For my final result, I ended up importing to XLSX so I can sort across multiple columns and highlight rights as green (allowed) or red (denied)

 

I hope this helps.

 

3 0
replied on March 3, 2021

Thank you Pieter. I'll check this out!

0 0
replied on March 3, 2021

It appears that your WFX includes an unmodified ConnectionProfile attribute from your workflow designer. I don't know how this works, and the data appears to be AES encrypted, but I still don't know if it's a good idea to share it publicly, in case it contains authentication information.

1 0
replied on March 4, 2021

Thanks, Andrew. I made a point of making the connection profile for a Test repository and an admin account with a password we wouldn't actually use in production. I also cleared out the history section of the XML. Hopefully I got everything, but yeah, a little awkward to share workflow files.

1 0
replied on November 24, 2020

Hi Andrew,

I'm interested in your use case for that kind of complete access right report. Understanding the problem you're trying to solve can help guide future reporting enhancements. Who is the audience and what would they do with it? For large repositories, the output of such a report could easily be hundreds of millions of rows.

I concur there is a difference in functionality between the older Access Rights Report tool you mentioned and the new web client Security Reports. Those are, to the best of my knowledge, the available official options though.

0 0
replied on February 16, 2021

Hi Sam-

I'll chime in on this one with a use case I have right now. We have a subsidiary that we're converting from an old United system to Rio. They've been using shared LF user accounts and we're going to convert them to use AD accounts with LF groups; the LF groups will more or less replicate the existing LF users.

So, we need to see/know where those LF user accounts were given permissions so that we can give the same permissions to our new LF groups.

This process is being combined with some other work, like splitting the company in two and reducing how much information is shared between them, so we also need it as an audit that can be reviewed and changed.

1 0
replied on February 16, 2021

Hi Samuel,

Specifically, we are implementing SAML authentication on our repository. Due to the way Laserfiche implements SAML, a new SAML user object must be created to replace each existing LFDS user. This means we have to recreate all group membership and folder access rights. In order to be sure permissions have been assigned correctly, I need a report of the permissions granted to the LFDS users that I can compare with one of the permissions granted to the SAML users.

 

But beyond my specific use case, the ability to report on which data is accessible by which users seems like a fairly standard and necessary feature for any document management system. How is a customer able to verify that access permissions are applied as intended? How could we be sure that an unauthorized user had not been accidentally or maliciously granted access to a sensitive folder deep in a folder hierarchy?

0 0
replied on March 3, 2021

Samuel, I would also argue that in most cases, such a report should not be especially large, since it would only contain entries for permissions that are explicitly applied or where permission inheritance is blocked. I presume that it is not common for customers to build repositories with hundreds of millions of explicit permission settings, but if they do, then it doesn't seem to me that any kind of permission report would be very useful to them.

Instead, I'd argue that best practice would have most admins assign permissions to a top-level folder and apply these to all subfolders through inheritance. They would then customize the permissions at specific subfolders by granting additional permissions or by disabling inheritance and configuring entirely different permission settings.

Since most files and folders should inherit permissions from their parent object, the report only needs to indicate where permissions differ. The permissions for every other object can be deduced based on the permissions set at the parent. This is how the utility worked that I referenced, and I argue that the same functionality should be included in the current product.

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

Sign in to reply to this post.