Using secured Planning cubes with Monitoring Server

The PPS Planning Server has the ability to define complex cube security as part of developing a model. Once these have been published to Analysis Services as a cube they can be analyzed using the capabilities of the Monitoring Server. However, by default the Monitoring Server will not take advantage of the security you have developed in your planning cube. The reason is that the roles defined by the Planning Server in Analysis Services are based on Active Directory users. By default the Monitoring Server sites always connects as the application pool identity and therefore all of the users will see the data for that user instead of what they permissions they have been assigned. To utilize the cube security you have configured setup the Monitoring Servers capability to use Delegation. Delegation utilizes the cube security you defined by passing each users credentials through to AS. If configuring Delegation is not possible another alternative is to alter the way you define security in planning to take advantage of defining a Monitoring data source and manually specifying the roles. The alternative of using roles defined on a data source will most likely not be feasible if you need different security for each of your users but works well if groups of your users share the same data access requirements.

Configuring Kerberos Delegation

Support in Monitoring Server for Kerberos delegation in enabled by setting the Bpm.ConnectionPerUser property in the web.config file to true. Delegation provides an impersonation token from the currently authenticated user to any registered data source. This will result in all Monitoring users only seeing the data that the modeler intended them to see. However, you should be aware that this can be an issue for your monitoring deployment because in addition to the planning cube you will need to give each of your user’s access to other data source services as well. The other limitation of this deployment is that all of the caching is done for each individual user, effectively disabling caching for any content the user has not already viewed themselves.

Configuring Data Source role options

The other alternative is to define your model security based on groups of users that have similar data security needs. For example, if your business has sales and marketing teams that both need access to different sets of data. First create domain users for each of the groups, in this example domain\sales and domain\marketing. Assign security in your model to each of these domain users based on business needs. Deploy the model to AS and then use the Monitoring Server wizard to create a new AS data source. The deployed planning model will have added roles to the AS cube as part of deploying the model. Take a look at what roles were added for domain\sales and domain\marketing. Those roles will need to be specified in the data sources that you just created. The final step is to restrict the “reader” permission of each data source to the valid set of users. Once that is complete any reports created against those data sources will restrict what data a user is able to see. The biggest challenge of this deployment is defining groups of users based on data access needs and then making sure that the content being published for them corresponds to the correct users.