2. Agenda Who is Secured What is Secured Logic and the Effective Permissions Guidelines and Best Practices

3. Microsoft Confidential 3

4. Permissions to Functions (Role Based Permissions) Permissions to Model Objects Permissions to Hierarchy Members DBA 4

5. Pre-req: users, groups and membership defined in AD  Add users and groups to MDS  Assign access to functions  Optional  Assign access to model components  Assign access to members  Edit user email profile Microsoft Confidential 5 Access levels

6.  Properties  Email format maintained in MDS  Email address maintained in MDS if a local user  Last Login Date updated by MDS  All other properties inherited from AD Microsoft Confidential6  Membership  Indicates groups to which the user belongs  Read-only – inherited from AD Active Directory MDS

7.  Properties  General group information  Read-only – inherited from Active Directory  Group types  LocalGroup  ActiveDirectoryGroup Microsoft Confidential7  Membership  Indicates users associated with selected group  Read-only – inherited from AD Active Directory

8. o Role based permissions o Assign access to one or more functions to a user or group Microsoft Confidential8

9. Selected group Lists all security assignments for the selected model Restrict assignments to a model Microsoft Confidential 9 Access location of selected security assignment o Attributes (Column) based permissions

10. o Assign member security for the selected version and hierarchy o Hierarchy (Row) Based Permissions Member security assignments for the selected group Members associated with the selected hierarchy Microsoft Confidential10

11. Order of Operations 1.Hierarchical inheritance is applied Permissions cascade down the hierarchy unless overwritten at a lower level 2.Security roles are combined across the user’s groups and the direct user permissions Group1 perms + … + Group N perms + User perms = User’s effective permissions 3.Intersect model and hierarchy member security Model permission and Member permission = Data element permission  Special cases:  Read or Update can’t override a higher level Deny (You can’t change what you can’t see)  Code and Name cannot be explicitly denied Model Object Inheritance Group / User Combination for Model Security Model / Member Intersection Hierarchy Member Inheritance Group / User Combination for Member Security

12. o Assigned permissions are inherited and cascade down the hierarchy from the closest ancestor o For overlapping hierarchies, the most restrictive permission wins; order of succession is as follows: 1.Deny 2.Read-only 3.Update 4.Unspecified o For overlapping groups permissions, the least restrictive permission wins  Examples 1.UpdateGroup1 + ReadGroup2 = UpdateUser’s Effective 2.DenyGroup1 + UpdateGroup2 = DenyUser’s Effective 3.UpdateGroup1 + ReadGroup2 + DenyUser = DenyUser’s Effective Microsoft Confidential 12

13. o Keep it simple o Outline the multiple roles and responsibilities to drive security req o Derive req for function, model and member security o Use Member security sensibly (single hierarchy recommended) o Keep it Minimal o Security function is typically reserved for a single system administrator o Typical end-user will be granted permission to the Explorer function only o Keep It Generic o Assign permissions to group security rather than users o User roles change over time o Easier to manage through lifecycle (layer of indirection) o Always review the resultant effective permissions Microsoft Confidential 13