Let us create a couple of new roles to examine the behavior of the above mentioned best practices.
Create three roles as illustrated below.
Make sure that the current user (Administrator) is added to the Sales Denmark role only.
All three roles will be set up with different Default Child Permissions on the Database level and the recommended inherit permission on the cube level. On the database level we will try out the three different Default Child Permissions: None, Deny and Inherit for the three different roles.
Note: On a live running environment it is not recommended to make limitations on the top level, the database level, because it will cause more maintenance regarding the roles when adding new connections to TARGIT, because they could, by default(as specified in the role(s), be left out for all users of the affected roles. The recommended setting on this level is None and it is recommended to differentiate on the lower level(s).
Sales Denmark, Default Child Permission set to None on the database level.
Sales Germany set to Deny.
Sales UK set to Inherit.
Now, let us see what will happen when we add a new connection to the TARGIT solution, by enabling the Sales demo cube again. By enabling this connection we will see the different effects of the different Default Child Permissions in the three different roles.
Enable the connection to the Sales demo cube.
In TARGIT Management client we can now see the results of the added/enabled connection in the various roles.
The Denmark role:
The Germany role:
The UK role:
Now, since the current user (Administrator) is added to the Sales Denmark role only, we will see in the TARGIT client that this user only has access to the cubes from the Adventure Works data warehouse – not the newly added Sales database.
If we add this user to the Sales UK role too, the user will gain access to the Sales database.
But if we furthermore add the user to the Sales Germany role, access to the Sales database will be denied (overriding any other permission in any other role)!