Related Topics: | ||
In order for a user to access a Synthesis database, he/she must have a valid user account in the database. This topic describes how users with the "Manage users and logins" permission can create and manage user accounts in the database via the Manage Repository Security window.
The Manage Repository Security window may be displayed when you create a new enterprise database, when you enable login security for a standard database, or when you choose File > Manage Repository > Authorized Users.
This topic includes the following sections:
In the Manage Repository Security window, the Users tab displays a list of the user accounts that have been created in the current database. Note that:
In non-secure databases, the software automatically creates an account for anyone who opens the database file. All accounts have full administrative permissions in the database, and the accounts cannot be deactivated or deleted. In addition, any user can create new accounts for users who have not yet accessed the database. This is useful when you need to send action notification e-mails to those users from within the database.
To enable the security settings for this type of repository, click the Apply Login Security button that will be displayed in the lower left corner of the window.
In secure databases, you will need to create a user account for everyone who needs access to the database. Use the Add, Edit or Delete buttons below the table to manage the user accounts. When you create or edit a user account, the User Login and Contact Information window will appear, allowing you to enter/edit contact details, add the user to security groups and activate/deactivate the account.
To export the data currently displayed in the table to an Excel spreadsheet, click the Send to Excel button. You will be prompted to specify the pathname/filename for a new Excel file.
You can also import user accounts from Microsoft Active Directory® by clicking the Active Directory button. This opens the Import Users from Active Directory window, which allows you to search for user accounts that have been defined in the Active Directory and choose one or more to import as new user accounts in the Synthesis database.
In secure databases, the user account must meet the following requirements in order to have access to the database:
The user account must be in active status. An inactive user account cannot be used to access the database unless an authorized user makes the account active again. To display only the user accounts that are currently active, select the Show active users only check box, which is at the lower left side of the window. If the check box is cleared, the table will include both active and inactive user accounts.
Note that if the account has been used to log in to the database at least once, deleting the account will make it inactive and the same username cannot be used again in the database. This is because the username may be associated with existing analysis information. Alternatively, if the user account has never been used, you can delete the record from the database and you will be able to create another user account with the same username in the future if desired.
The user account must be assigned to at least one security group. (The next section describes how to use security groups.)
For SQL Server databases: The username must be associated with a "SQL Server Login" that allows the database platform to recognize the user and give access to the application database. If you create a user account that is not recognized by SQL Server, the user will not be able to log in to the database. See SQL Server Logins or Using Impersonation.
Synthesis-enabled applications use Windows authentication to identify the user; therefore, the user must be logged in to a computer that uses the same domain/username that is defined in the user account. If the user needs to connect to a database from a different domain, you can set up an alternative login that will allow the user to access the database without Windows authentication.
Throughout this help file, we use the phrase authorized users to indicate functionality that may be restricted based on specific security permissions. Security permissions allow you to control how users access and use the database. In Synthesis repositories, a set of permissions is known as a security group. Note that:
In non-secure databases, all users with access to the *.rsrp file have full permissions to the database; therefore, the concept of security groups does not apply to this type of database.
In secure databases, each user may have different permissions based on the security group(s) that have been assigned to the user account.
In the Manage Repository Security window, the Security Groups tab displays a list of all the security groups that have been created in the database. The user who created the database automatically belongs to the Admin group, and has full user and administrative permissions. The Admin group cannot be deleted or have its permissions modified; therefore, its window cannot be opened from the Security Groups tab. To assign or remove a user account from this group, open the User Login and Contact Information window and select or clear the “Admin” check box.
By default, the software also includes three additional predefined security groups. Depending on your organization’s specific needs, you may choose to make adjustments to the default security groups or replace them with new groups See Repository-level vs. Project-Level Security.
Use the Add, Edit or Delete buttons below the table to manage the security groups. When you add or edit a security group, you can assign the permissions for the security group as well as select the database users that belong to each group. In addition:
When you do not assign a user account to a security group, the account will have no access to the database; however, users with access to the database can send action notification e-mails to that account from within the database.
You can assign a user account to more than one security group.
For permissions that apply throughout the repository (e.g., the ability to manage users and logins), if the permission is granted in any of the security groups assigned to the user’s account, he/she will have that permission throughout the repository.
For project-level permissions (e.g., the ability to create/edit project items), it depends on the type of security assigned to the project.
If the project has repository-level security, the user will have all of the project-level permissions that have been granted from any of the security groups that are assigned to the user’s account.
If the project has project-level security, the user will have only the project-level permissions that have been granted via the security group(s) that are assigned to the project and also assigned to that user's account.
Note: To avoid unintended consequences, if you choose to implement different levels of access for different projects, it is generally recommended to assign project-level security for all projects in the database.
The following table provides a summary of the permissions that can be granted in the database. If the permission is application-specific, the affected application(s) are identified in the name.
You can edit the permissions of a security group even when a user associated with that security group is currently logged in to the database; however, the changes will not take effect until the user closes the database and reconnects to it.
Note: Project owners have certain permissions that are equivalent to having the "Manage all projects" permission, but only for the projects that they own. For example, project owners can view private projects and lock/unlock projects, but only if they own those particular projects.
Basic permissions throughout repository |
|
Create and own private projects | Allows you to create projects that, in a secure database, are accessible only to you and to users with the "Manage all projects" permission. In a non-secure database, the project will be designated as "private" but it will still be accessible to all database users. Note that if you remove this permission from a security group, the users in that group who own private projects in the repository will no longer have "owner" permissions for the existing projects. You can assign a new owner to each affected project via the Manage Projects window. |
Create and own public projects | Allows you to create projects that may be accessible to any database user (depending on the project security setting). Note that if you remove this permission from a security group, the users in that group who own public projects in the repository will no longer have "owner" permissions for the existing projects. You can assign a new owner to each affected project via the Manage Projects window. |
Create portal messages | Allows you to create and send messages to other users via the Messages page in My Portal. |
Basic permissions at project level |
|
Read | Allows you to view but not edit any of the analyses in a given project. You can perform tasks that do not modify the data (e.g., calculate metrics in a Quick Calculation Pad, export data, etc.). |
Create/edit project items | Allows you to create and edit items in a given project, such as folios in Weibull++/ALTA, diagrams in BlockSim, system hierarchy items in Xfmea/RCM++, and the like. |
Create/edit/delete own resources | Allows you to use the Resource Manager to manage the resources (e.g., models, URDs, etc.) that you have created in a given project. This permission will be assigned automatically when the "Create/edit project items" permission is assigned. |
Advanced permissions at project level |
|
Delete project items | Allows you to delete any item in a given project (e.g., folios in Weibull++/ALTA, diagrams in BlockSim, system hierarchy items in Xfmea/RCM++, and the like). This permission cannot be assigned unless the "Create/edit project items" permission is also assigned. |
Create/edit/delete all resources | Allows you to use the Resource Manager to manage all resources available in a given project. |
Set project security | Allows you to control user access within a given project. This includes the ability to access the Security page in the Project Properties window and to set Item Permissions for any item in the project. |
Edit project properties | Allows you to use the Project Properties window to edit the project name, description, category and other settings of a given project. |
Lock or check out project |
Allows you to:
|
Create project baselines | Allows you to create or restore baselines for a given project, which are exact replicas of the project at a particular point in time (i.e., backups). |
Delete project | Allows you to delete a given project. |
Manage change logs in Xfmea/RCM++ | Allows you to enable and manage change logs within a given project. Change logs can be created for FMEAs and DVP&R analyses in Xfmea and RCM++. |
Approve change logs in Xfmea/RCM++ | Allows you to implement electronic approval tracking for change logs within a given project. Change logs can be created for FMEAs and DVP&R analyses in Xfmea and RCM++. |
Administrative permissions throughout repository |
|
Manage all projects | Grants you all of the basic and advanced project-level permissions for all public and private projects in the repository. It also allows you to use the Manage Projects window to view and edit settings of all projects in the database. |
Manage users and logins |
Allows you to:
|
Manage e-mail notifications |
Allows you to:
|
Manage profiles and templates in Xfmea/RCM++ |
This permission is available only in enterprise databases. It allows you to:
|
Manage other repository settings |
Allows you to:
|
Approve actions |
Allows you to review and approve actions, which are Synthesis resources that allow you to track progress made in a project. |
Manage all portal messages | Allows you to edit or delete all messages you sent and messages addressed to you via the Messages page in My Portal. |
© 1992-2013. ReliaSoft Corporation. ALL RIGHTS RESERVED.