TM1 Forum

Hello everyone,

How can I allow users (e.g. dataAdmins) to change the security settings for cubes+dimensions+applications (the mapping to user groups).
Unfortunately with ADMIN oder SECURITY ADMIN rights they can create/delete users which is prohibited.

Thanks for your help!

From their docs they were specifically designed to work with the hard break between data and security. This was their reaction to SOX segregation (though not a very good one) and giving you a way to break it does not fit with the controls they were putting in place.

*** I have not tested any of this just putting down thoughts*****

You could try adding the person to another group that has access to the security cubes, but I am almost certain that you will hit the issue that much like ADMIN the settings override everything.

***************************************************************************

You can design TI processes for these specific security-related tasks and allow your users to run those. You could pass the details to the processes through parameters, control cubes, flat files etc and have the TI produce the expected result based on these details. Don't forget to grant security access to the TI processes from the context menu.

If you give your Data Admins read access to the TI processes they will only be able to run and review them without the ability of changing any code, which means they will be restricted to using whatever toolset you create for them. You can also create a nice control screen with buttons for each TI etc if you wish so. I hope you get the concept.

talan wrote:How can I allow users (e.g. dataAdmins) to change the security settings for cubes+dimensions+applications (the mapping to user groups).
Unfortunately with ADMIN oder SECURITY ADMIN rights they can create/delete users which is prohibited.

I've done this for one of my servers in a vastly different timezone for a country with the need to frequently change access rights. To implement, I built a replica of the }ElementSecurity cube for my primary access control dimension (department) and wrote rules linking it to the real }ElementSecurity cube. I gave the head of staff there access to the replica cube and a process which runs a SecurityRefresh (it also runs hourly in case he forgets to run it after updating security). There shouldn't be any reason you can't do the same for the }ClientGroups cube. In this case, it might make sense to limit the rules to a subset of relationships (e.g. lock out the ability for the user to assign users to the ADMIN and SecurityAdmin groups).

Matt