Working with Groups
LiquidFiles features a flexible group based configuration. Most user configurable settings are in fact setup on a per group basis.
You can reach the groups configuration in Admin → Groups in the web interface. The basic overview screen will look something like this:
A couple of things to note about Groups in LiquidFiles:
- You can add as many groups as you need.
- You cannot delete any of the default groups, but you don't have to use them if you don't want to.
- All Users needs to belong to a group.
- Users will be assigned to groups automatically if they don't already belong to a group.
- The group assignment works from top to bottom as the groups are listed in this page.
- The easiest way to see what group a user will/would belong to is to use the test user function at the bottom of this page (not covered in this screenshot).
The following groups are available as default in LiquidFiles:
|Sysadmins||The Sysadmins groups is for System Administrators. System Administrators can administer all aspects of the LiquidFiles system.|
|Domain Admins||Domain Admins are only available if you add domains, and only for domains other than the default domain. It's the highest level administrator for a domain, that can change anything except things that affect the system itself (ip addresses, ...).|
|Admins||The Admins group is for Administrators, that should be able to administer normal user activity in the LiquidFiles system, but does not have access to system administration functions like changing ip addresses, hostname, certificates and other system administrator functions.||User Admins||The User Admins group is for Administrators, that should be able to administer only user's accounts, but does not have access to any other LF's settings and system administration functions like changing ip addresses, hostname, certificates and other system administrator functions.|
|Local Users||The Local Users group is the default group for your local users. Local Users can send and receive files to and from anyone.|
|External Users||The External Users group is for external users that should be able to send files back to your local users.|
|Receive Only||The Receive Only group is for users that will only download files, i.e. that only has the capability to login an download files sent to them.|
The default use case with LiquidFiles is that you have all your local users being able to send files any external user, like an extension to your email system. And similar with email, there's very seldom any restrictions to who can email whom.
Using groups, LiquidFiles has the ability of far more granular control than that though.
The settings available in each group include:
|Max File Size||1000 Mb||The max combined file size in each message (should possibly be more accurately be called max message size).|
|Default Message Expiration||30 days||All messages in LiquidFiles has an expiration date. This is the default value for users in this group. This value must be equal to or lower than the max message expiration.|
|Max Message Expiration||180 days||The longest message expiration the user in this group can set. The maximum max expiration date you can set is 10 years (3650 days).|
|Users can change expiration||True||If set to false, all messages sent from users in this group will have the default expiration date set. The option to set expiration date will also be removed on the compose page.|
|User can change expires after||True||In addition to the expiration date, it is also possible to limit downloads to a certain number of times. If set to false, users in this group won't be able to set the expires after limit.|
|Max Expires After||-||If set, this is the maximum expires after value that users in this group can set.|
|Delete inactive Users after||-||If set, inactive users will be deleted if they haven't logged in for this many days. Please note that when users are deleted, all messages they have sent, all attachments, message and download log, user dropbox configuration and api keys, ... for that user will be deleted as well.|
|Limit Networks||-||If set, users can only login from these specified ip addresses or networks.|
|Users can change message permission||True||If disabled, all messages sent for users in this group will be sent using the default message permission and the option to set message permission will not be visible in the compose page.|
|Default Message Permission||Only Specified Recipients||The default permission for messages for users in this group.|
|Available permissions||All||If any permission setting is unselected, users in this group will not be able to select this permission setting in the compose page.|
|Default copy to myself||True||If unselected, users will not automatically be copied on messages they send.|
|Users can change copy to myself||True||If unselected, users will not be able to change the setting and all messages will use the default setting if they should receive a copy on each message.|
|Limit Recipient Domains||-||If set, users in this group can only send messages to users in these listed email domains.|
|Can send to local users||True||By default, all users can send to users that are, or would be, in the local users group. (Please see the section on automatic group assignment for more information on users that would be in the local users group)|
|Limit Extensions||-||If set, users in this group can only send files with these listed file extensions (like: doc, xls, png, zip). Please note that you can only set either limit extensions or blocked extensions in each group.|
|Blocked Extensions||exe, vbs, pif, scr, bat, cmd, com, cpl||Users in this group cannot send files with these file extensions. Please note that you can only set either limit extensions or blocked extensions in each group.|
|Match LDAP Groups||-||If a user belongs to any of these LDAP groups, assign the user to this group. Please see the section on automatic group assignment for more information on how users are assigned to groups.|
|Match Domains||-||If a user has an email address in any of these listed email domains, assign the user to this group. Please see the section on automatic group assignment for more information on how users are assigned to groups.|
|Users have access to the API||True for local users||If enabled, users in this group can use the API when sending files. This include any plugins available with LiquidFiles or any custom API integrations.|
|Size Override||10 Mb||This is a hint sent to the Outlook plugin (and other functions can use this as well as needed) as to how big attachments should automatically be sent using LiquidFiles instead of the standard channel.|
|Users are permitted to change Size Override||True||If disabled, users will not be able to change this setting in the Outlook plugin.|
|Enable Send Folders in the Outlook plugin||True||If disabled, the function to send folders in the Outlook plugin will be disabled.|
|Enable Secure Send in the Outlook plugin||True||If disabled, users in this group will not be able to use the Secure Send feature in the Outlook plugin.|
|Custom Settings||-||If you build your own API integration and wish to have different settings for different groups, you can set those settings here. The easiest is probably to use a simple key/value pair like: enable_feature=true, or max_something=20, but anything you enter here will be added to the API response message.|
|Users in this group has access to User Filedrops with Random URLs||True||If enabled, users in this group will be able to use the User Filedrop function with randomized URLs.|
|Users in this group has access to User Filedrops with email URLs||True||If enabled, users in this group will be able to use the User Filedrop function with email URLs.|
|Filedrop Permission||Only Specified Recipient||Files sent with User Filedrops for users in this group will have this permission setting.|
|Filedrop Expiration||14 days||When messages expires after they have been sent using the User Filedrop for users in this group.|
|Filedrop Max Size||250 Mb||The maximum combined file size when someone send files using the User Filedrop for users in this group.|
|Users in this group have access to File Requests||True||If enabled, users in this group can send File Requests. If disabled, this function will be removed from the compose page.|
|File Request Permission||Only Specified Recipients||When a File Request is responded to, who has permission to download the files.|
|File Request Expiration||14 days||The time the File Request recipient has to respond to a File Request.|
|File Request Expire Download||14 days||The time when files sent using a File Request will expire from the system.|
|Sysadmin||False||If selected, users in this group will have Sysadmin privileges.|
|Admin||False||If selected, users in this group will have Admin privileges. Sysadmins are automatically admins.|
|External||False||If users in this group should be treated as External users or not. External users are not counted towards your license users but have restrictions. Please see the license section for information on External Users and restrictions.|
|Disable Sending||False||If users in this group should be able to send files or not.|
|Users in this group can invite other users||True||If disabled, the function to invite users will be disabled for users in this group and the button will be removed from the compose page.|
As you can see, there are many options available to set for users in the group configuration. The defaults are sensible so you should not have to change too many settings to get started, but will allow for great flexibility if your requirements dictates that.
Enabling Filedrop and File Requests
In order to enable Filedrops and File Requests, neither the "External" or "Sending Disabled" can be ticked for users in that group.
On the surface, it may seem that Sending Disabled would just disable sending and that a Filedrop would be a "receive" function that would still be possible to enable. But what happens is actually that with a Filedrop, the external user sending the file is actually sending the file "on behalf of" the owner of the Filedrop. By disable sending of files, it is therefore not possible to send "on behalf of" that user.
The exact same logic applies to File Requests. The files are sent "on behalf of" the sender of the File Request so this user needs to be permitted to send files.
Automatic Assignment of Users
LiquidFiles is built to be self administrating as far as possible. When it comes to user management, the easiest way to deal with users is to divide users into groups and use automatic group assignments to assign users into different groups.
When assigning users, users are matched in the following order:
- If the user is found in LDAP and has a group that match any of the listed LDAP groups, assign the user to that group. If the user belongs to several groups, the user will be assigned to the first listed group.
- If the user is found in LDAP but does not belong to any of the listed LDAP groups, assign the user to the default group for LDAP users.
- If a user already exist on the LiquidFiles system (Admin → Users), use the group configuration already assigned.
- If the user in not found in LDAP and has an email address that match any of the listed matched email domains, assign the user to that group. If the user has an email address that match several domains, assign the user to the first listed group.
- If the user is not found in LDAP and does not have an email address that match any of the listed email domains, assign the user to the default group for non-ldap users.
If we look at an example system (https://liquidfiles.springfield.com), we can see the following Admin → Groups configuration:
The configuration in this example would be:
- There's no automatic assignment of Sysadmins.
- Users in the LDAP/AD group "LiquidFiles Admins" will be automatically assigned to the Admins Group.
- Next is the "Partners" group, which is quite interesting. Users in the LDAP/AD Group "Accounting" will be automatically assigned to this group, together with users with an email domain @auditors.com. Also, since it's listed above the Local Users Group, LDAP/AD Users in both the Accounting and LiqudiFiles Users LDAP/AD group will be assigned to the Partners group.
- Local Users are automatically assigned from the LDAP/AD Group LiquidFiles users.
- External Users can only send to the email domains @powerplant.com and @springfield.com.
- Nothing really to note about the Receive Only group.
- The Default Group for LDAP and SSO Users is "Receive Only". This means that users who login with LDAP or SSO and belong to the LDAP Groups Accounting, LiquidFiles Admins and LiquidFiles Users will be assigned to their respective group, anyone else who logs in with LDAP or SSO will be assigned to the Receive Only Group.
- Anyone else who logs in will be assigned to the "External Users" Group.
If you have a lot of groups with lots of matching going on, it can quickly become difficult to get a complete overview exactly what will happen. In order to make testing this easier, there's a User Test function at the bottom of the Admin → Groups page.
By entering whatever the user would type on the login page, you can test what would happen.
Here are a couple of examples:
Here we can see that: firstname.lastname@example.org, is an already existing user in the local users group.
If anyone with an email address in the domain: @auditors.com, they would be assigned to the "Partners" group.
In this case the email address does not match any existing user and does not match any existing email domain, they would be assigned to the default group for non-ldap users: External Users.
And so on. Please make sure that you test thoroughly so that all users are assigned to the correct groups.
When it comes to licensing with LiquidFiles, the basic principle is:
In the LiquidFiles group configuration, you can see different groups and which groups are enabled as local users. Any user in a group that's been labeled a local user will require a license.
For groups that you create yourself, you can select if you want the group to be for local or non-local/external users.
- can access Messages and Filedrops with themselves as recipients or with permission Local Users.
- can send Messages (if enabled)
- can use FileLinks (if enabled)
- can use Filedrop (if enabled)
- can use File Requests (if enabled)
- Requires license
- can access Messages with themselves as recipients.
- can send Messages (if enabled) to existing Local Users and specified recipient domains (in the Message Settings tab).
- Non-local users can never send files to any recipient in their own domain.
- Does not require a license.
Also, please note:
- If yourcompany.com is listed as a limited recipient domain for external users, email@example.com cannot belong to any group that is listed as external.
- Whatever configuration you make, if firstname.lastname@example.org is in a group as an external user, they will never be able to send files to email@example.com.
The latter is important if you want to setup a partner collaboration group with LiquidFiles. You can for instance configure a group of users like "Finance" which includes people from the "Finance Users" LDAP group, and matches users from the domain: ourauditors.com and ouraccountants.com. The users from ourauditors.com and ouraccountants.com, while strictly speaking are external to the organisation, cannot be "external" in LiquidFiles if you want them to collaborate, i.e. have the ability to send files to each other in LiquidFiles. In this case you will need licenses to cover the users from ourauditors.com and ouraccountants.com for this group as well.
If you don't want them to collaborate and only have the ability to send files to you but not each other, you can treat them as any other external user and you won't need licenses for them.
Common Use Cases
Here are some of the more common use cases, and how you would configure them in LiquidFiles.
All external users should be able to send files to ourcompany.com
To make sure that all external users can send files to specified domains, regardless if there are users configured or not:
- In the External Users group, add ourcompany.com (and any other internal domain) to the limit recipient domains.
Some internal users should only be allowed to send to other internal users
The easiest way to set this up is to:
- Add a new internal group: Restricted Local Users
- Set the limit domains to your internal domains: company.com, sistercompany.com
- Optionally set the Limit Networks to your internal network(s): 10.0.0.0/8
- Create an LDAP group: Restricted LiquidFiles Users
- Configure the LiquidFiles LDAP group match to: Restricted LiquidFiles Users
Local users authenticated with LDAP should only be able to login from internal addresses
The easiest way to set this up is to:
- Change the Local Users group to limit internal networks to your network(s): 10.0.0.0/8