Groups & Restrictions FAQ

Version 2.34.0 changed how groups and restrictions work in Hudu:

• A default group must be designated.
• All users must be in a group. Note: this does not apply to admins or super admins, as they cannot be in groups.
• Users can be added to multiple groups.
• Administrators have more options to customize and bulk manage group permissions.

Below are answers to common questions about these changes and about setting group permissions.

FAQ

Q: What happens if I did not have a default group designated prior to 2.34.0?

A: If you did not have a default group designated prior to 2.34.0, Hudu automatically created one called Default Group that does not have any access to companies or to the Central KB. You can change this by designating a different group as the default group if needed. Once you have designated a default group, you can delete the one Hudu created.

Q: What happened to users who were not in a group prior to 2.34.0?

A: If you had any users who were not in a group prior to 2.34.0, Hudu automatically created a group called Previously Ungrouped Users and added all of those users to it. This group has the same access they had previously as ungrouped users. You can leave them in that group, or you can work your way through that group member list and move them to other groups as needed. You can delete this group at any time, as long as the users are in at least one other group.

Q: Is the Previously ungrouped portal users group the same as Previously Ungrouped Users? (v2.47.0 required)

A: No. They're separate groups created by different updates, and they work in opposite ways.

• Previously Ungrouped Users was created in 2.34.0 for technicians who weren't in a group. It keeps the access those users already had.
• Previously ungrouped portal users was created in 2.47.0 for existing portal users. It has access to no companies, no asset layouts, and no core tools, and it keeps blocking access even if a user is also in another group.

Add each user in Previously ungrouped portal users to the groups they need, remove them from that group, then delete the group once it's empty.

Q: Did anything change with how password folders work?

A: No. Password folders still work the same, but what you can do with them has changed, since you can now add users to multiple groups. For example, Joe is a member of Tech Group 1, Tech Group 2, and Tech Group 3. You create a password folder that only Tech Group 3 can see. Even though Joe is in other groups that haven't been given access to this folder, he is also in the group that was granted access, so Joe can see this password folder.

Q: When should I use allow list?

A: Allow list means the group will only have access to the companies you specifically list. It is the most restrictive method for controlling company access. You may want to use this list for your default group, or if you typically want to restrict users in your instance from accessing companies as much as possible. If you create a new company in Hudu, a group using allow list would automatically not have access to that company unless you add that company to the group's allowed companies list in the group's settings.

Q: When should I use deny list?

A: Deny list means the group will have access to any companies unless you have specifically denied the company. This is a less restrictive option than allow list. If you create a new company in Hudu, a group using deny list would automatically have access to that company unless you manually add that company to the group's denied companies list in the group's settings.

Q: When should I put users in multiple groups?

A: Multiple groups are most useful when you want to create combinations of different permissions for users within the same instance.

Example 1:

An MSP has 10 employees and the following needs:

• 2 of them should not be able to view company passwords.
• All 10 should not view TestCo.
• 1 should not view AtlasCo.
• Otherwise, they should be able to view everything.

One way to handle this would be to:

• Create a group named NoTestCo Group in deny mode, so all users in it can access all companies unless otherwise specified. Deny that group access to TestCo and add all 10 users to it.
• Create a group named NoAtlasCo Group in deny mode, so all users in it can access all companies unless otherwise specified. Deny that group access to AtlasCo and add the 1 user to it.
• Create a group named NoPasswordView Group in deny mode, so all users in it can access all companies unless otherwise specified. Do not specify any companies. On the Access tab, turn off Passwords. Add the 2 users to it.

Multiple groups are also helpful when it comes to password folders.

Example 2:

• User A is part of a Technicians group and a Super Technicians group.
• User B is part of a Technicians group.
• There is a password folder named High Security Passwords.
• There is a password folder named All Techs Passwords.
• Super Technicians group is given access to view the High Security Passwords folder.
• Technicians group and Super Technicians group are given access to view the All Techs Passwords folder.

Results:

• User A (member of Technicians group and Super Technicians group) is ALLOWED to see High Security Passwords.
• User B (member of Technicians group) is NOT allowed to see High Security Passwords.
• User A is ALLOWED to see All Techs Passwords.
• User B is ALLOWED to see All Techs Passwords.

Q: What happens if a user is in groups with conflicting permissions?

A: If a user is in multiple groups with conflicting allow/deny permissions, Hudu defaults to the deny permission.

For example, a user belongs to:

1. Group A (Deny List): Denies access to companies X and Y
2. Group B (Allow List): Allows access to companies Y and Z
3. Group C (Deny List): Denies access to company W

Result:

• User cannot access companies W, X, and Y (denied by Groups A and C)
• User can access company Z (allowed by Group B)
• User cannot access any other companies (due to Allow List default for mixed group types)

Password folders work differently, since you cannot explicitly deny a group access to a password folder. (You can inherently deny a group access to a password folder by granting access to the folder to specific groups.) This means it is impossible to have conflicting allow/deny permissions for a password folder.

Q: Can I set group permissions for KB folders, specific passwords, and KB articles?

A: Yes.

• KB folders: as of version 2.46, root-level KB folders in the Central KB or a client's KB can be restricted to specific security groups. Open the folder's Edit Folder panel and choose who can view it. Subfolders always inherit the root folder's permission, and only admins and super admins can set or change folder permissions.
• Individual passwords and KB articles: open the item, select More Options, then Change Permissions, and choose which security groups to restrict.
• Password folders: manage group access to password folders in Admin → Password Folders.