Manage permissions and rights

Seitenanfang  Eine Seite zurück  Eine Seite vor

After you have created and allocated all groups and users you can now assign them to the categories and records (e.g. passwords) and issue unlockings. Unlockings and rights are available in all arrays of Password Safe (folders, passwords, TAN management, tasks, messages, documents).

 

mu_menu_rights

 

Create a new folder or use an already existing folder. In the example we use the folder "Internet". Click on the folder with your right mouse button and choose the menu item "sharing and security" in the context menu.

 

mu_folder_rights_initial

 

Now you see the tab "Permission" with the dedicated users and groups in the upper array and the dedicated permissions in the below array.

 

The account "administrator" and the group "administrators" is assigned by default to every record. Those can not be deleted for safety reasons because the administrator must have permanent access to all records to exclude the possibility that passwords are no longer dedicated to anybody and therefore get lost..

 

Click on a user or a group, so you can see the dedicated rights. The rights apply to the displayed folder "Internet".

 

Via the pushbutton "Add" you can allocate further groups or also single users and give away individual rights on this folder.

 

mu_add_group mu_add_user

 

Via the pushbuttons in the toolbar you can switch between groups and users. A search within these groups and users is also possible. Highlight individual or several objects for the multiple selection to quickly allocate several groups or users.

 

If you added a group or a user click on it in the list to set the permissions in the below array.

 

mu_folder_rights_edit

 

At a newly allocated group there are no permissions assigned as a start. Now enter the rights for this group.

 

mu_folder_rights_edit2

 

Therefore you can assign individual rights to every group and every user. Even if a user is part of a group but should even so have individual rights compared to the others in the group, you can add the user and allocate these individual rights which then take precedence over the group rights.

 

The same possibility of privilege allocation you also have at the password records itself. Just click on the record in the password list with your right mouse button and choose "unlockings and rights". Then again these settings take precedence over the ones of the folder.

 

To save the changes click on the pushbutton "OK".

 

Inheritance of rights

One of the outstanding functions of the right management is the inheritance of rights. With this you can define privileges for a superior folder and alienate them to all sub folders and records. So you can save a lot of time because not every folder and every record has to be changed manually if the structure of rights changes.

 

If you start a new record (e.g. a password) in a folder the rights of the folder will be automatically passed on to the record. Therefore no new allocation has to be made, except you intend individual settings for this new record.

 

After you have added groups or users or changed a right when clicking on "Ok" the dialogue for the inheritance of rights appears automatically.

 

mu_inherit_rights

 

Now choose one of the following opportunities:

 

Not alienate rights

All permissions and rights will not be passed on, therefore they only apply to the current folder.

 

Pass on rights to subordinate objects, hitherto existing rights will completely drop away

All permissions and rights will be passed on. However before the inheritance all individual permissions and rights of the subordinated objects will be deleted so that only the setting applies that you have just carried out for the folder.

 

Pass on rights to subordinated objects, not available permissions and changes will be passed on, no groups or users will be deleted.

All changes of permissions and rights will be passed on to the subordinated objects. Not available rights will also be passed on. But individual settings of the subordinated objects remain preserved (e.g. if further users exist in a subordinated folder or record). No users or groups will be deleted. If you have deleted permissions you have to do it separately for the subordinated objects or choose the second option.

 

Which kind of inheritance of rights makes suggestive and should be used?

This very much depends on what your intentions are. The most secure option is the third one. So individual rights of subordinated folders and records definitely remain preserved. If you do not know how your colleagues have managed the subordinated data you can not pass on the rights.

 

Deactivate inheritance of rights

The inheritance of rights can be deactivated globally or per folder. At this however only the manual descent will be deactivated after the change of permissions. But if you start a new record in a folder still the rights of the folder will be passed on to the record.

 

Asking for rights

If a user has no rights on a certain array he receives an advice. Here the user has the possibility to directly make application for the rights. Hereupon the administrator or rather the bearer of rights receives a task so he/she can decide if he/she grants the user the requested privilege.

 

access_denied

 

Ask for rights

Here it is determined who can give access or the right on the required record. All groups/users that are responsible for it will be given notice per task.

 

Notify administrator

The administrator receives the task to give the requested right.

 

If a record should be shared the administrator can directly give the permissions for this record via the received task by clicking on the pushbutton "edit" inside of the task.

 

Right templates

Via the management of right templates you can define how for example rights can be given away on records and folders by default. At this you can also distinguish between root rights and normal record rights. The configuration is made via the database settings.

 

mu_rv_config

 

Users can ask for missing rights

If this setting is active the user can ask for missing rights. See Manage permissions and rights.

 

Administrator and administrator group can be deleted in the permissions

It is possible to completely delete the administrator and the administrator group from the permissions. Hereby also completely private passwords/records are possible. Consequently the administrator has no longer access. Please also notice that without an administrator in a permission no logbook entries will be written for that record.

 

Pass on changes of permissions to subordinated folders and records

If this setting is deactivated the question of inheritance will no longer be displayed and changes of permissions will no longer be passed on to subordinated folders and records. The automatic inheritance to a new record is not concerned by this and is still carried out.

 

Template for root folder

Is required to define the folder rights in the root (highest level for folders). If no template is deposited here every user can start a folder in the root.

 

Template for records

This template only applies if no inheritance of rights is carried out to the record. As an example we can name the bank because it is not allocated to any folder but exists overall. This is exactly when this template takes effect. If no template is deposited the administrator and the administrator group will be added in addition to the user that receives full access.

 

The configuration in the database settings is only available if the user has the right "... can manage users and groups". Generally it is suggestive to possibly only give this right to the administrator.

 

Furthermore you can also save right templates and that way easily apply them to other further records. That way comprehensive permissions can be easily assigned to different folders and records.

 

mu_rv_load

 

To do so you set the permissions as desired and then click on templates -> save. A new window opens in which you can enter a new name and a description for the new template. On the second tab "permission" all permissions have already been taken over, if you do not want to change anything more you can now save the template.

 

mu_rv_edit

 

If you now want to assign the template to another folder or record so choose in that templates -> load. Now you receive a choice of all templates and can load the the template with a double click on the accordant entry. All previous permissions will be overwritten in doing so.

 

mu_rv_choose

 

Right templates for private folders and records

If you do not want the administrator to see personal passwords of a colleague you can also apply a right template to a folder. Hereby all newly started folders and records will be started exactly with this right template. You only have to delete the administrator in the right template and only give the user the accordant rights for his/her folders and records.

 

You can deposit this in the folder properties in the tab "Extended".

 

mu_rv_private

 

As soon as a right template for the folder is active only these rights from the right template apply to subordinated new folders and records. Even an administrator could not add any records here if he is not contained in the right template.

 

Private and public records (user choice)

With the new Version 5.5 you can also allow you users to easily create personal passwords. The user can decide if the new password  can only be accessed by himself/herself or if it is a public password and therefore the normal folder inheritance of rights applies.

 

How to activate personal passwords:

 

Go into the database settings -> right management.
Activate the option "users can choose between private and public records".
Go into the right management assign to all or only certain users the right "users can choose between private and public records".
Go into the folder properties in which you want to allow private records and choose one of the three options under "private and public records".
If a user now creates a new password in that folder, according to the setting he/she will be asked when saving if he/she wants to create a private or public password.

 

mu_rv_private2