Log-in to Management Studio and Change Password
To Log in:
- Enter the user name and password you have been given.
- 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”)
- Next, you should change your default password. Click on File, then select Change Password.
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.
- Enter your current password, a new password in the Password box and re-type the new password in the Confirm password box. Click Ok.
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
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:
- Check for Explicit User Allow/Deny.
- Check For Explicit User Role(s) Deny.
- Check For Explicit User Role(s) Allow.
- Check For Explicit Group(s) Deny.
- Check For Explicit Group(s) Allow.
- Check For Explicit Group(s) Role Deny.
- Check For Explicit Group(s) Role Allow.
- 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.