Need help with administering content

[Ashwyn2601]

Hi Gurus,

The version that I am working on is 11.0.
The business requirements are as such that they want to provide the admin (System Admin) access to all users - basically, they should be able to create datasources, create, delete, modify reports, etc all on their own.

However, at the same time, they want the users to be able to modify such objects only for their groups. They should not be able to delete other users' contents.

My experience tells me that providing admin access gives them full right to modify and edit the access permissions at their will. So, how do I restrict a group of users from deleting/modifying other users data while providing them the admin access at the same time.

Any suggestions will be appreciated highly.

[MFGF]

Hi Gurus,

The version that I am working on is 11.0.
The business requirements are as such that they want to provide the admin (System Admin) access to all users - basically, they should be able to create datasources, create, delete, modify reports, etc all on their own.

However, at the same time, they want the users to be able to modify such objects only for their groups. They should not be able to delete other users' contents.

My experience tells me that providing admin access gives them full right to modify and edit the access permissions at their will. So, how do I restrict a group of users from deleting/modifying other users data while providing them the admin access at the same time.

Any suggestions will be appreciated highly.

Hi,

You can create your own custom role and grant it Execute and Traverse privileges for all the capabilities you want it to have. The elephant in the room here is licensing. If you go ahead with making all users Administrators, you need to make sure that every user has an Administrator license - which could be very expensive if you are using a named-user license model.

Cheers!

MF.

[Ashwyn2601]

Hi MFGF,

Thanks for your suggestions. We created a separate group and replicated the Sys Admin permissions (Directory Administrators, Report Administrators, etc) and added the capabilities wherever it was required.
We did quite a bit of testing and we were able to provide the users with Admin console access where they can create the datasources (but no access to system, dispatcher and services tab, etc) and also allow them to view and access the content administration console within Configuration tab.

However, now we need to check on how to ensure that the users can edit/delete/create reports only specific to their groups.

The problem lies in the fact that we have provided all the above created test groups - Directory admin/ Serve admin/ Report admin, etc rights as stated above - Hence, they are still able to view others' data and modify at will.

If you have any suggestions, please feel free to let us know.

Thanks once again for the approach that your provided us.

[bdbits]

I have to reiterate what MFGF said about licensing. Just because you created your own role and gave it admin permissions does not mean that IBM is going to consider their license requirement as anything but a System Admin. If you are ever audited, it could get very expensive indeed.

Like most any product, admins will have access to everything. This is by design.

What business requirement is driving this? Can it be accomplished another way, maybe using external data capabilities?

[Ashwyn2601]

This was just for our POC environment and we were able to get what business required of us.

We removed Everyone from Sys admin and created a group and added "Everyone" to it.
Also, now certain permissions were added to the newly created group like Dir admins, Report Admins, etc.
The same group was also added by navigating to the Dir Admins, Report Admins and adding them in there.

Now, certain capabilities were added like administration like data source connections and other details that were required.

For securing the content, we (as admins) created folders and gave permission to the folder only to the specific business AD user group.