History |
Setting up groups and organizational units
About user groups
User groups give you a way to assign privileges, layouts and Desktop views to groups of users at once instead of having to configure each user uniquely. This allows greater control over your FirstClass system and makes global changes easy.
When you install your FirstClass server, there are three sets of groups defined in your network store (four if you have FirstClass Web Services installed):
• Standard Groups
• Configuration Groups
• Department Groups
• Domain Name Groups (specific to FirstClass Web Services).
These sets of groups already have groups created to help you get started in setting up your FirstClass environment. The Groups folder on the administrator's Desktop may look a little overwhelming at first glance, but is very easy to work in and customize once you are familiar with its structure and how individual groups fit into this structure.
 CautionNever create subfolders within the Groups folder. Groups in subfolders will not function.
Standard user groups
When you install your FirstClass server, it automatically creates several standard user groups. FirstClass automatically adds users to these groups as required. While not all of these groups are displayed in the User Groups section of the User Information form, users still belong to them based on eligibility. The following are the standard user groups and a list of users belonging to them.
 WarningDo not delete or rename any of the standard user groups. Deleting these groups can lead to unpredictable system behavior and system damage. If you delete one by mistake, recreate it immediately with exactly the same name and restart your server.
You will see additional standard groups if you have installed FirstClass Web Services.
The values set on the Group Privileges form for these groups override the values that are currently set for the user’s other groups and the System Profile. The privileges set for these groups can be overridden on users’ User Information forms.
For example, if you set a connection limit of Unlimited on the All Users Group Privileges form, but you want all autoregistered users to be limited to 30 minutes, set this value for the Autoregistered Users group on the User Limits tab of the Group Privileges form.
Keep in mind that anything you enter on a individual’s User Information form overrides all other settings.
Configuration groups
A set of configuration groups were installed by default when the server was installed (or upgraded). These groups are not integral to the server functioning, but they may be of use to you in administrating your site. They are simply groups that define the use some users make of your FirstClass system. They don't define their roles within the organization.
As an example, you may have five members in your IT department (organizational), but only two of these users are also subadministrators (additional configuration). The organizational classification of these five users is IT, and the extra duties of two of these users include subadministrator duties, which require additional configurations. Therefore, they are added to the Subadmin Users configuration group.
These groups were created to help administrators deal with some pretty common issues and configurations. Most sites use subadministrators, for instance. Making someone a member of the Subadmin Users group is a quick and simple way of giving the user all the tools and permissions needed to work as a subadministrator in just one step. Most of the default configuration groups are self-explanatory by their names, but you may decide to use them in a unique way, or create additional configuration groups to make system administration easier.
The default configuration groups are:
• High Disk Usage
• Help Desk
• Subadmin Users
• Suspended
• Webmasters
• Time zone groups
• RAD Developers
• DS Deleted
• DS Admin
• Voice users
• No Outbound Internet Mail
• Administration Resources
• Online Help Administration
• Online Help End Users.
You can add, delete, or rename configuration groups, but we suggest that you consider the defaults you see, as these reflect the most common requirement and requests received by FirstClass over the years. We also suggest you keep the Subadmin Users and Webmasters groups since they have been configured to contain all the tools and security required to perform these roles. If you don't use a subadministrator to help with FirstClass administration, or you don't use FirstClass Internet Services to connect to the Internet, leave these groups intact but don't add users to them.
Department groups
Department groups are used to organize people on your system into their functional areas. You may want to designate organizational unit levels for these groups.
Use group names that reflect the members of each group. A strong FirstClass site will have a group structure that closely resembles your company/school's organizational chart. For example, you might have some of the following groups in your organization:
You can delete or rename any group in this area. You can have as many as 600 user groups on your FirstClass system (more for MP sites).
When you install FirstClass for the first time, you can run a one-time script to change the preconfigured department group names. See the Start Here folder on the administrator's Desktop for information and instructions.
Domain name groups
Domain name groups are specific to FirstClass Web Services.
About organizational units
An organizational unit (OU) is, quite simply, just another way to use user groups to organize your system for easier identification of users and/or to allow duplicate Directory entries (applies to user names and conferences). OUs are not required in setting up your FirstClass system, but can play an important role in organization and security, especially in complex FirstClass systems with many users, locations, or branches.
 CautionDo not assign OUs to Standard groups.
 CDSIf you plan to use FirstClass Directory Services (FCDS) in LDAP mode, remember that you must make sure the user groups that are part of your organization's hierarchy are assigned to organizational units in a way that reflects your hierarchy.
When configuring your system from the administrator’s Desktop, OUs are defined on the Group Privileges form.
OUs are used to define a set of levels into which people on your system fit, but the OU does not determine the hierarchical role of the members. A user can be a member of several organizational units at any level.
The most user-specific organizational unit is the user’s Primary organizational unit. For instance, a user is an employee, a member of the management team and a member of the accounts payable department, all of which are defined as OUs in the company. The most user-specific OU for this individual is the department group (accounts payable). Therefore, this is the individual's primary OU.
The Primary OU can be (but does not need to be) a member of a larger OU, like an umbrella structure. OUs classify groups of users according to their role in the organization, not according to their levels.
NoteA user’s privileges and permissions are not inherited from one organizational unit to another. You must specifically assign the user to each group in the proper order on the User Information form.
NoteIf you use OUs for your system structure, all users must belong to at least one OU or permissions and privileges may not work as intended.
Example:
Husky Planes has the following divisions within its organization:
• employees
• management
• IT
• finance
• customers.
Management, IT, and finance are distinct departments within the company and each user belongs to one of them. Therefore, these groups will all be given the OU level of Department.
The customers group also fits this model since its members use Husky Planes’s FirstClass system and communicate with some Husky Planes employees. Therefore we will also give the customers group the OU level of Department.
Even though we decided that employees was a logical division in the company, we still haven’t given the employees group an OU level. Since this group contains most, but not all, of Husky Planes’s users and it contains members of other OUs (some, but not all the departments — customers are not employees, but they are a department on our system), we will choose the OU level of Company.
Directory listings for OUs
On the Group Privileges form, you can choose what information to list in the Directory. Choose Organization to display users' primary OU only, and choose Organizations to display all the OUs to which users belong.
 In this example, Joe Employee is not a member of any specific department so his Primary OU is Employee. Although Joe Manager and Joe IT are both employees (and members of the Employees OU), their Primary OUs are listed.
If a user belongs to two Primary OUs (management and finance for instance), the one listed closer to the top of the user groups list on the user’s User Information form will be the one that is displayed. In the following example, Joe IT is also a manager and is a member of the Management OU:
 In the Directory, Joe IT will be listed as IT, not Management.
 Conferences in organizational units
Conferences and conference groups created by the administrator on the administrator’s Desktop do not belong to an OU. However, administrators can set the conference or conference group OU using the FirstClass scripting.
A user's objects inherit the OU of his Primary OU. If you have given your users permission to share conferences or calendars, any conference or calendar a user creates will inherit his Primary organizational unit.
Organizational units and duplicate Directory entries
OUs allow you to have multiple Directory entries. If you select "Require unique names within this organizational unit" on the Group Privileges form, you can have two people with the exact same name in the Directory as long as they have different primary OUs. For instance, if you have a Lisa J. Smith on faculty, you can also have a Lisa J. Smith who is a student teacher. When you list the search for Lisa J. Smith in the Directory, you will see the following:
 You can't have duplicate names within the same organizational unit. If Lisa J. Smith is hired on full time, you will have to change her name in the Directory (Lisa Julie Smith, for instance).
NoteYou can never have duplicate User IDs.
Editing organizational unit levels
If you want to edit the names of the organizational units, or add more levels to better fit your organization, use FirstClass Designer.
The server reads the organizational unit as a number only. If you open the Group Privileges form using Designer and look at the organizational unit dropdown list, you will see that each level has a number beside it. You can edit the wording beside the number, or you can even edit the numbers. As well, you can add additional choices to this list. The numbers are merely a way for the server to read the written information. Valid numbers are between 0 and 800.
For more information about editing forms using Firstclass Designer, see the FirstClass Designer help under Customization Tools.
Creating a multitenant environment
The flexibility organizational units adds to your system is best seen when used in a multitenant environment. This is a configuration in which there is more than one independent system running on a single FirstClass server. These systems are entirely independent of one another, and users on one system can never see users on any other system in the Directory.
Example:
Husky Planes is starting a subsidiary company, Malamute Transport. Malamute Transport will use Husky Planes’s FirstClass system, however, management wants Malamute Transport to be its own independent entity. They do not want to share information, communication, or Directory listings between the two companies. While they will share a FirstClass system, they will be entirely separated from each other. The FirstClass administrator will use organizational units and Directory filtering to accomplish this as follows:
1 Make required changes to the groups folder.
• Do not change any of the Standard, Configuration, or Directory Filtering groups. Any settings or overrides set for these groups will apply to all applicable users on your system.
• In the Department groups section, create a new group called HP Users. This will be the master group to which you will add every Husky Planes user.
• Create a new conference group called HP Conferences and a new calendar group called HP Calendars. These will be the master groups to which you will add every conference and calendar respectively for Husky Planes.
• Rename all Department groups, Conference groups and Calendar groups to be specific to Husky Planes. For instance, rename Employee to HP Employee, and Finance to HP Finance. You may want to group all Husky Planes groups on one side of the Groups folder to make organization easier as your system grows.
At this point, the Groups folder will look something like this:
 2 Set the organizational unit levels of the HP groups.
• Set the HP Users organizational unit level to Company.
• Set all other HP groups organizational unit levels to Division, Department, Group, or Team, as appropriate.
3 Set the unique domain names.
Husky Planes will have a different domain name than Malamute Transport. On the Services tab of the HP Users Group Privileges form, enter "huskyplanes.com" at "Domain name" (this is Husky Planes’s registered domain name). All the Internet aliases for members of this group will default to this domain name.
If you will not have separate domain names for your multiple tenants, do not enter the domain name here.
NotesIf a user is a member of multiple organizational units and more than one of them has a domain name, the domain name for the user’s Primary organizational unit will be used.
If you have multiple domain names, remember to include them on the Multiple Sites and Languages form.
4 Set up Directory filtering.
Do not set up Directory filtering for HP Users, HP Conferences and HP Calendars.
Set up Directory filtering using the Group Privileges form Directory tab for all other HP groups by selecting "Allow this group to view these groups" and entering HP Users, HP Conferences, and HP Calendars.
NoteYou can filter the Directory more if you like, but ensure these are listed first.
Some things to remember:
Ensure that any user added to the Husky Planes system is made a member of the HP Users group. List this directly after the class of user group on the User Groups/Directory tab of the User Information form.
Ensure that every conference on the Husky Planes system (and any conferences you add to the Husky Planes system later) is made a member of the HP Conferences conference group.
Ensure that every calendar on the Husky Planes system (and every calendar you add to the Husky Planes system later) is a member of the HP Calendars groups.
When a user creates a new conference, the user’s organizational unit is inherited to the conference, so the Directory filtering rules will be applied automatically.
5 Create a Department group structure for Malamute Transport using the same principles used for Husky Planes.
NotesPrecede all user, conference, and calendar groups, as well as all conferences and calendars with MT to distinguish them as being solely for Malamute Transport.
Set the MT Users organizational unit level to Company (like HP Users).
Set all other MT groups to logical organizational unit levels.
Remember to make all Malamute Transport users members MT Users, all Malamute Transport conferences members of MT Conferences, and all Malamute Transport calendars members of MT calendars.
The Husky Planes/Malamute Transport multi-tenant environment Groups folder looks like this when complete:
 No user configured as a member of HP Users can see any user in the MT Users group. All Husky Planes conferences and calendars are hidden from all Malamute Transport users, and vice versa. With the Directory partitioned in this way, they can function as two completely independent systems, apart from the server administration. Any tracking and billing can be done at the company level (or group, or user level), instead of at the All Users level, making this a true multitenant environment.
Adding user groups/organizational units
In addition to the standard user groups, you can create your own user groups/organizational units to match the structure of your organization.
To add a user group or organizational unit:
1 Open the Groups folder on the administrator's Desktop.
2 Choose Admin > Add > User Group.
3 Type the name you want for this user group at "Group name".
4 Fill in the Group Privileges form.
CautionAll new groups must be created and reside in the Groups folder on the administrator’s Desktop. If you create the group anywhere else, it will not function properly. If you place groups within a folder in the Groups folder they will not function.
Deleting user groups/organizational units
To permanently delete a user group/organizational unit from your system:
1 Open the administrator's Directory by choosing Admin > List Directory.
2 At Search, select Other.
3 Click Search.
4 Select the group to be deleted.
5 Click the Delete button at the top of the form.
NoteThe group can be undeleted before audit runs.
To undelete a group:
1 Open the Groups Folder.
2 Choose View > Show Deleted Items.
3 Undelete the group.
About group privileges
Privileges dictate what users can do with FirstClass (the features to which they have access). You can customize user limits and privileges in the way that best fits your organization. You can set privileges once to satisfy all users, or you can set privileges at the group or user level for a more flexible system customized to the needs of each user or group of users. Privileges are an important security feature in FirstClass and, if used effectively with Directory filtering, can help you create a safe and worry-free collaborative environment.
While privileges and how they are set may seem complicated, they actually follow a few simple rules. First, let’s look at a User Information form and see how user groups are listed. Assuming a new system with no users added yet, we’ll look at the administrator’s account.
1 Choose Admin > List Directory.
2 Enter Admin in the Pattern field.
3 Select By Name at Search.
4 Select Regular Users.
5 Click Search.
6 Select the desired entry (administrator) and click Edit.
7 Select the User Groups tab.
You'll see that the administrator, by default, belongs to the Regular Users group. However, everyone who logs into your system is also a member of the All Users group.
Since everyone belongs to All Users, it’s simplest to set system wide privileges there. You can alternatively use the privileges and the Model Desktops of the class of user groups to control what users see. Since all users are either Regular or Remote, you can modify those groups to control features for everyone.
When FirstClass sets features for each user, it looks at the following items in the following order:
• the System Profile
• the All Users group
• the class of user group (Regular users or Remote users)
• the groups you have created and added the user to in the order in which they appear in the User Groups field
• the User Information form.
The key things to remember are:
• every setting in the User Information form overrides what was set before
• user defined groups override those groups that came before them.
Therefore, take care in the order in which you place your user groups. The tristate checkboxes on the user group indicate whether a setting has been changed or left as previously defined. The User Information form has two checkboxes, one is a tristate box used to change the setting, the other is a display only field indicating the current setting. From the User Information form, you can determine exactly what features each user has.
Setting the All Users group privilege defaults
Before you begin giving privileges and access to groups and users, set your defaults on the All Users form. These settings will be the default, or unchanged state, in the tristate boxes for all other groups.
1 Double-click All Users in the Groups folder.
2 Set all overall defaults you want to use for your system, based on your company or school’s needs, policies and security on the Group Privileges form.
CautionNever leave checkboxes on the All Users, All Conferences, or All Calendars forms in the unchanged (cross hatched) state. They must all be set to on (checked) or off (cleared).
Setting privileges for individual groups
To set privileges for a group:
1 Double-click the group for which you want to set privileges.
2 Fill in the Group Privileges form.
Combining privileges and permissions for added security
The following is an example of how you can use privileges and permissions to accommodate special security needs on your system.
To give users the ability to send internal email to other users, but not be able to send or receive Internet mail:
1 Enable Private Mail feature for the user group on the Features tab of the Group Privileges form.
2 Open the Internet Gateway form (in the Gateways & Services folder).
3 Click Permissions.
4 Enter the user group name at Who, and choose Disallowed at Access.
Privilege tips
Selecting "Edit preferences" gives all users the ability to change their personal preferences. You might want to disable this privilege for guest accounts to ensure the accounts are always left in the same state.
On the User Limits tab you set the defaults or overrides for Private mail expiry, Daily connection limit, Session inactivity limit and Disk space limit. All of these limits, except for Disk space limit were already set on the System Profile. The value of "Default" on the All Users Group Privileges form is the value that you set on the System Profile. Any value added to a Group Privileges form will override the System Profile for all users in that group.
On the Directory tab you can set system-wide Directory filtering. By default the Directory is unrestricted for all standard groups with the following exception:
the Unauthenticated Users group can not see any Directory items as long as "Allow unauthenticated Directory access" is not selected on the Advanced Web & File form.
Alternative approaches
Here are a couple of other ways to set up and configure the users on your system:
• You could ignore user groups entirely and modified each user’s User Information form individually.
 NoteThis would take more time and any usage changes would have to be made on an individual basis, instead of on an entire user group at once.
• You could create user accounts with names like Technical Questions and allow customers to write to them. This would mean giving customers Private mail privilege.
Optional method for small systems
If you have an extremely small system and want to build each user group’s (or individual user’s) privileges individually, clear every checkbox on every tab of the All Users Group Privileges form. All corresponding tristate boxes on any group form in the unchanged state (cross hatched) will default to the Off setting you set on the All Users form.
While this is a safer method than selecting all checkboxes and then having to clear unwanted checkboxes on the group forms, neither of these methods is recommended. This practice will result in a FirstClass system that is very difficult to monitor and administer as every user will have custom settings. This method may lead to problems as your system grows.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||