top of page

CDI Blog

Could Your Laserfiche Repository Security Use a Tune-Up?

When it comes to Laserfiche Security, it is essential for repository access to be configured correctly for users to perform their tasks. This article discusses several steps that can be taken to optimize the overall effectiveness of your Laserfiche content security.

Laserfiche Security best practice suggests it is helpful to concentrate on keeping the all-around infrastructure simple. It is recommended to work from the repository root folders largest toward the smallest document level and fine-tune, as needed.

Where to Begin?

Here are some simple tips to get you started:

  • Begin by logically configuring your users and groups as if you are setting up the repository from scratch; if you have an existing system, you will want to run a security report to understand the current security situation.

  • Determine feature rights, privileges, and entry access rights.

  • Determine what security features are needed.

  • Test and correct as necessary.

Groups Vs. Users

There are benefits to setting Laserfiche Security at the group level as opposed to the user level. The users will inherit security from the group. Group configuration advantages include:

  • Easy setup and low maintenance going forward

  • Increased consistency

  • Laserfiche repository groups can collect a variety of users

  • Useful for Windows/LDAP groups that don’t align with Laserfiche use cases perfectly

  • Helpful for testing

When creating groups, consider the types of users that you have and how you want to group or separate users for security purposes. Groups are often set based on roles or department. In some circumstances, users will need to have security set at the user level; examples include:

  • Personal folders

  • Folders with special security needs

  • Distribution of privileges

Core Security

When administrators are configuring security for the repository, three questions are commonly asked.

1. Who - Which users and groups have access?

It is important to remember that users inherit access from groups they belong to, and in a well-designed repository, most security is set at the group level. Additionally, many security settings for a single user are combined.

2. What - What can they do?

The individual access rights determine what operations are possible. Examples:

Browse – See but not open folders and documents

Read – Open folders and documents viewing contents and metadata

Modify contents – Make changes

Additionally, the permitted or prevented actions are specified with the following settings:

Allow - users can perform the action

Deny - user is prevented from performing an action

Blank - user can perform the action if they have inherited the right from higher in the tree; if not, they can’t

3. Where – What portion of the repository will the rights will be applied to?

It’s worth noting that every document and folder does not need separate security rights applied. The best practice uses inheritance propagate rights downward and scope to allow administrators to determine how far to propagate the right.

Repository relevant security that all administrators need to be aware of include:

Entry Access Rights – Refers to direct access to documents and folders within the repository. When configuring entry access rights, it is beneficial to plan and determine the configure setup that requires the least amount of manual configurations.

Recommended best practices for setting entry access rights include:

  • Establish rights on folders, not documents

  • Configure your repository to take advantage of inheritance

  • Use scope to determine how far down the tree the rights should extend

  • Keep configurations to a minimum

Feature Rights – Tools available to specific user or groups;, giving administrators the ability to allow or deny actions across the entire repository. Users are required to have both the relevant feature right and the appropriate access right to perform the actions.

Privileges – Privileges grant administrative power; granting a wide-range of abilities. These privileges can override other security when the user is granted the Manage Entry

Access Privilege, which allows the user to browse the entire repository. Privileges are not required for standard tasks such as filing, viewing, and modifying documents.

Security Deployment Considerations

While User access is a critical component of effective security administration, securing your network environment and automation factors is also key. Cover the basics by locking down and encrypting file in Windows, you will want to include: formatting

  • Volume locations

  • Databases

  • Search index files

Another important component is ensuring secure communications between components.

Using other supplemental methods to help support your security plan include supplemental security items like:

  • Security tags - Referred to as point security and is used to “hide” a document. Access to a document with a tag applied is only available to users that are granted access to the tag. The tag follows a document through the repository and overrules other security including privileges.

  • Template access rights - Administrators can deny Read access for a template to hide the template or hide its fields on entries with that template even if those fields have individually been given Read access. Fields that appear outside of the template on an entry are not affected. Template access rights are often used for user convenience (showing only relevant templates).

  • Field access rights - The Write Metadata entry access right controls who can edit fields on specific documents. However, field and template access rights can be used to make exceptions for specific fields or templates.

  • Volume security - Volumes store copious amounts of information including images, text, and electronic files on the hard drive. Volume rights control access to those components of a document. The default security settings are usually enough but can be adjusted if the need exists.

Test, Test, Test

Finally, as security measures are being configured, test your progress.

Setting up security by Groups is very useful for testing. Additionally, testing as you implement helps verify that your ‘broad strokes’ approach worked properly before handling exception cases, and will help you pinpoint any security features that maybe misconfigured. Remember that access rights take effect immediately and everything else requires a logout/login.

If you want to see the security configuration at any point, run a security report. These reports allow for easy spot checking and rights reports, which are great for troubleshooting or auditing purposes. This can be an extremely useful tool to help administrators understand a repository that they have just inherited.

In summary, a comprehensive look at your current security practices or implementation plan will help you identify and address any issues, allowing you to achieve a Laserfiche system that operates with top notch security.

Final key takeaways include:

  • Leverage scope and inheritance for simplicity

  • Work from largest to smallest

  • Set general rights and increasing granularity

  • Start small, test and then expand

  • Use the fewest number of features to do what is needed

We hope you have enjoyed this article. If you need assistance configuring your Laserfiche system security, please contact the CDI Support Team.

176 views0 comments


news, knowledge, updates, tips & tricks, and more >
bottom of page