History |
Making FirstClass secure
In FirstClass, security is implemented through the following five layers:
• user IDs and encrypted passwords
• privileges
• Directory filtering
• memberships
• permissions.
In addition, you can create rules in users' Mailboxes to control junk or sensitive mail.
User IDs and passwords
All registered FirstClass users log in via their designated user ID and password. Server access will be denied if either are invalid. User IDs and passwords are set on the User Information form. The password field on the User Information form always displays ••••••••, making even the User Information form secure. Further password security is configured on the Group Privileges form, on which the administrator sets the site policies for passwords. If a user enters the wrong password on three consecutive attempts, the account login is locked for one minute.
Restricting what strings users can choose as passwords
If you want to prohibit the use of certain strings in passwords, you can create a list of these strings in a blocked passwords file. Password string restriction is done on a group basis.
To restrict password strings for a group, create a text file named with the group name and the extension .!pw (for example, All Users.!pw). List the prohibited strings in this format:
location string
Location is 0, 1, or 2, where:
0 = the password contains the string
1 = the password starts with the string
2 = the password is an exact match for the string.
Put a space between the location and the string. Create one line for each string.
When done, upload the file to the Groups folder on the administrator's Desktop. The icon and subject will be automatically set.
To force FirstClass to search this file when a user in this group tries to create a password, tick the "Apply additional restrictions" checkbox on the Passwords tab of the Group Privileges form.
Enforcement of password compliance
 Doesn't apply to gateway accounts.If a user's password doesn't meet the password restrictions set at the user group level, they are asked to change their password when they try to log in. If the user ignores the Change Password form, they are prevented from doing anything until they change their password. If the user dismisses the form, they are logged off.
Forcing passwords to expire immediately
You can force an individual (or all individuals in a group) to change their password the next time they log in by forcing their current password to expire immediately.
To do this for an individual, tick the "Expired" checkbox on the User Information tab of the User Info form.
To do this for a group, tick the "Set passwords to expire today" checkbox on the Passwords tab of the Group Privileges form.
Privileges
Privileges allow you to control all user and user group capabilities with respect to FirstClass server activities. There are 46 different privileges in FirstClass. Privileges are set for groups of users on the Group Privileges form, and are overridden at the user level on the User Information form.
Directory filtering
Directory filtering allows the administrator to control what people can see in your FirstClass Directory. When no Directory filtering is used, anyone added to any group can see all the entries in the Directory. If users can’t see things, it makes it a lot harder for them to post to them. Filters let us make sure users only see names they are able to post to, or at least be aware of.
You can control how much of your system can be viewed in the Directory in several ways:
• You can make a user account, conference, or public mail list unlisted.
Only users with the View Unlisted privilege can see unlisted users in the Directory.
• You can allow members of user groups to view only selected user groups, conference groups, or conferences in the Directory using the Group Privileges form.
• You can allow specific individual users to view selected user user groups, conference groups, or conferences in the Directory using the User Information form.
• You can create unpublished conferences which will not be listed in the Directory, not even the administrator's Directory. These conferences are secure and cannot receive mail unless the message is created from within the conference.
By default the Directory is unrestricted for all standard groups with the exception of the Unauthenticated Users group. This group cannot see any Directory entries as long as the "Allow unauthenticated Directory access" checkbox is cleared on the Advanced Web & File form.
Creating Directory filters
You can filter the Directory at the user group level, or at the user level. We recommend setting Directory filters for user groups instead of individual users since this gives you more uniformity in your system and makes it easier to administer. Set Directory filters at the user level for special privileges only.
To set Directory filters at the group level, use the Directory tab on the Group Privileges form.
To set Directory filters at the user level, use the Directory tab on the User Information form.
Memberships
If a container such as a conference or public calendar is not available on a user's Desktop or within any other containers the user has access to, they can't access this container.
Granting a membership to the container puts a link to it on the user's Desktop. Permissions are set to define what type/level of access the user will have.
Permissions
In most organizations it is necessary to control access to sensitive information. It may be appropriate for a particular group of users to have exclusive access to this information, while, for another group limited access to the information would suffice, and for other groups, no access at all. This reality is the basis for the concept of permissions in FirstClass.
There are 17 levels of permission to choose from and 9 preset access levels based on combinations of these individual permissions.
Mail rules
The administrator can also create rules inside users’ Mailboxes, even if they do not have the mail rules privilege turned on.
In an education environment students may not be given the email privilege in order to stop them from addressing mail to individuals. Still, they are able to receive personal mail. In this situation the administrator could create a mail rule that silently deletes all Internet mail, or all mail this has been marked as spam.
In a business scenario, this would be useful in an environment where users deal with sensitive material, such as in legal or ethical matters. All mail users receive could be redirected or copied to archive conferences and saved for a set number of years. If a piece of mail was needed as evidence but had been deleted by the user, the archives would contain all incoming and/or outbound mail from the user’s Mailbox.
To create a rule in a user's Mailbox:
1 Log in as administrator.
2 Use the List Directory to find the user.
3 Select the user and click Desktop.
4 Choose Collaborate > Rules to open the user's Rules folder.
An example of how FirstClass security works
A user, Bob, belongs to the Sales user group. His privileges include allowing him to use private mail, share conferences and share calendars. He can see all employees in the Directory and can therefore address mail to them. In the Directory, he can also see all conferences and calendars belonging to the Sales container template. If he tries to address mail to the Development conference, he can't do it, even if he enters the name exactly as it appears in the Directory.
In the Sales Projections conference (one of the member conferences of the Sales container template), the permissions are set up so all members of the Sales team can read the conference, but only the Sales Manager can post messages. Bob wants to respond to a message in the conference, but when he replies, the message will only address to the original sender (the Sales Manager). Bob tries everything he can think of to route his message to the conference, but he simply isn't allowed. The only way he could do this would be to obtain his manager's user ID and password and log in as her (but then Bob wouldn't have a job anymore).
So using groups to configure privileges, Directory filtering, and permissions, on top of the inherent security of encrypted passwords passing over a secure protocol for user logins, makes for a secure system.
| ||