Question

List of all access rights settings for a user

Laserfiche Self-Hosted Security Version 10

Updated April 9, 2024

asked on April 5, 2024

Does anyone know a way to get a list of access-rights settings for a given user?

Note that this is different from the report generated by the web client in Laserfiche 10 when you click on "More actions/Reports/User Effective Access Rights Report" because we aren't looking for an exhaustive list of every folder in the repository--we just want the settings that granted the user their access rights.

For example, a repository might have 100,000 folders, and the user might have access to 10,000 of those, but all of the user's accesses might have been granted with one setting on a parent node in the folder tree. It's that one setting that we're looking for.

The reason for our interest is that we have more service accounts than we need, and we would like to consolidate them to save user licenses. To do that we would need to create a new user account and give that account all the access rights of two or more existing accounts.

Note that we're currently on version 10 but have started a project to migrate to 11.

0 0

Answer

SELECTED ANSWER

replied on April 5, 2024

Hi Tim!

You can do an advanced search to see everywhere rights were explicitly set for a given account. Note that it will only be if it's on that account; if they are a member of groups, you'll need to search for those groups separately (or OR several of these searches together):

{LFACE:trustee = "Name"}

If it's a domain account, be sure to include the domain in the name area, like {LFACE:trustee = "DOMAIN\Name"}

3 0

Replies

replied on April 5, 2024

The reason for our interest is that we have more service accounts than we need, and we would like to consolidate them to save user licenses.

Service accounts for what? If they're used by other Laserfiche applications like Forms, Workflow, Import Agent, Audit Trail, etc. to connect to a repository, they don't need a named user license. Connections made from those Laserfiche applications have a special property that applies a built-in license to the session (easiest way to think about it, anyway). If you've granted any such accounts a named user license, you can remove their licenses without issue.

From a security perspective, it's generally better to have more repository service accounts with more granularly scoped permissions (least/lesser privilege) than fewer more permissive ones. I typically make one per Laserfiche application, per repository.

2 0

replied on April 7, 2024

Hi Sam, thank you for the very helpful information. Does that also apply to identities that are used for repository access by SDK applications? Can I also remove the LF licenses used by these?

0 0

replied on April 8, 2024 • Show version history

That only applies to Laserfiche applications; SDK applications do require licenses to connect to a repository.

3 0

replied on April 8, 2024

Confirming Jason's response is correct. Laserfiche's own 1st party applications have service account session licensing built in, other integrations broadly do not.

The only other place that may be true is some official Partner integrations from the Laserfiche Solution Marketplace. I don't know offhand, but that's the only other context in which I can see us providing built-in service account session licensing.

Anything you've built yourself with the SDK definitely does not.

3 0

replied on April 5, 2024

When you look at a user in the repository Admin console, there is a tab where you can see the groups to which that user belongs; this isn't "comprehensive" because the groups can be members of other groups, but it is closer to the data you're trying to obtain and would at the very least provide breadcrumbs for you to follow to figure out what all is being inherited.

Another factor to consider is that if you're using LFDS users/groups there is the potential for things to be configured or inherited at the directory server level, so it can get more complicated depending on how your repository/environment was set up.

For example, most of our users are configured at the repository level using Windows accounts, so their groups can be inherited from repository groups, or more commonly, AD groups that are attached to repository groups.

Additionally, we moved all of our service accounts into LFDS so we can reuse the same accounts across multiple repositories, and we also leverage LFDS Groups in instances where we want to reuse a group across multiple repositories.

The challenge would be if you have any "explicit" permissions configured, for example, if 99% percent of their access was handled with groups but one folder was set with explicit permissions, that wouldn't be as easy to spot (we avoid granting direct/explicit permissions whenever possible and instead set everything up with Repository groups, which we can then link to AD groups, LFDS groups, or individual users which makes management a lot easier).

1 0

View 1 previous reply

replied on April 8, 2024

Re:

Additionally, we moved all of our service accounts into LFDS so we can reuse the same accounts across multiple repositories.

Does this include your Workflow service accounts? Our current "leading" practice is to always have Workflow service accounts be repository users. We discovered that in WF an LFDS login takes ~2s vs a pure repository login (nearly instantaneous). For smaller, frequently run workflows where the activities only took a few hundred milliseconds to 1-2s, this meant that most of the overall execution time was in the login call.

Makes a huge difference for anything like a migration processing workflows doing metadata assignment and filing on every document coming in. Also makes a difference for anything semi-user interactive. The performance benefits far outweigh the overhead of a few extra service accounts in almost all cases.

Give it a spin in one of your test environments. Run a small workflow with an LFDS service account, and then again with a repository service account.

2 0

replied on April 8, 2024 • Show version history

Interesting, we do use LFDS accounts for many of our workflow service accounts; however, I've never noticed any issues with workflow performance.

I checked the history for a few of our high-volume workflows and I'm not seeing anything that is taking quite that long.

For example, one workflow with Find Entry, Assign Field Values, Retrieve Field Values, and Rename Entry is averaging between 300 and 600ms.

I'll have to do some testing to see what happens with a repository account, but I don't seem to be seeing the same delay.

1 0

replied on April 8, 2024

It may be that in the migration use case where it was most noticeable, we had tens of thousands of workflows queued up and bogged down LFDS with so many auth requests that its average response time to them slowed down to the 1-2s range. In normal circumstance, repo auth should still be at least a little faster.

1 0

replied on April 9, 2024

It would make sense that LFDS authentication would be a bit slower, and that a large number of concurrent requests would have a more noticeable impact.

With the volume we get in workflow we've been running multiple servers for a long time, and I designed a lot of the heavy workflows to run in batches even before we started using LFDS accounts so it's possible we just don't see much of an impact since we were already doing a lot to limit concurrent activity.

1 0

You are not allowed to follow up in this post.

Question

Question

List of all access rights settings for a user

Answer

Replies

Sign in to reply to this post.