Skip to main content
Mitratech Success Center

Log-in to Management Studio and Change Password

This chapter describes how to log in to Management Studio and change the password. Start up the Management Studio application.

To Log in:

  1. Enter the user name and password you have been given.
    image
  2. If available and if required, from the drop-down list, select your required server. (For more information about configuring multiple server options, see “Connecting to a Different Server)
  3. Next, you should change your default password. Click on File, then select Change Password.
    image

Note: You must have Permissions configured to allow you to change your own password. If your Permissions are not set to allow you to change your password, the Change Password menu option will be dimmed and unavailable. See “Users and Groups” and “Permissions Inheritance” for more information.

  1. Enter your current password, a new password in the Password box and re-type the new password in the Confirm password box. Click Ok.
    image

Note: Password policies are defined by your DataStore®DSX administrator. See “Password Requirements” for information on setting up a password policy

Passwords which do not adhere to the configured password policy are invalid and will result in the following message being displayed

image

Create Groups, Roles and Users

Users can belong to Groups and Groups can belong to other Groups. For example, the Group Development can be set as a member of the Group Slough Office. In other words, the Group Slough Office is the Parent of the Group Development.

Users and Groups can be assigned a Role. For example, a Role can be created and named Administrator which is configured to Allow all privileges to members. There can be Users in several different Groups, each with the Role Administrator. Alternatively, there can be a Group which contains the Users who have all privileges and the Group can be a member of the Role Administrator.

Permissions Inheritance

Permissions inheritance refers to the settings of Allow, Deny or Not Set for Users, Roles and Groups.

Permissions for a particular User, Role or Group are tri-state:

  • Allow: Gives the item permission to administer that area of functionality.
  • Deny: Refuses the item permission to administer that area of functionality.
  • Not Set: Allows the item to inherit their permissions from a Parent.

Calculating Permissions

The list of operations which can be Allowed or Denied for a User are described in:

Table 148, “Terminology: Group Permissions
Table 150, “Terminology: Role Permissions
Table 152, “Terminology: User Permissions

When calculating a User’s permission for a particular operation, the following order is followed:

  1. Check for Explicit User Allow/Deny.
  2. Check For Explicit User Role(s) Deny.
  3. Check For Explicit User Role(s) Allow.
  4. Check For Explicit Group(s) Deny.
  5. Check For Explicit Group(s) Allow.
  6. Check For Explicit Group(s) Role Deny.
  7. Check For Explicit Group(s) Role Allow.
  8. Steps 4 to 7 are repeated for Parents of the Parent groups (until there are no more Parent groups) and if no explicit permissions are found, then Deny.

See “Set Permissions: Users, Groups and Roles” and see “Set Permissions: Multiple Groups with Conflicting Settings” for examples.

Access Control Lists Inheritance

Access Control List inheritance refers to the settings of Allow, Deny or Inherited for Users, Roles and Groups so they can access Data Definitions, Users, Roles and Groups.

Permissions for a particular User, Role or Group are tri-state:

  • Allow: Gives the item permission to administer that area of functionality.
  • Deny: Refuses the item permission to administer that area of functionality.
  • Inherited: Allows the item to inherit their permissions from a Parent.
  • Was this article helpful?