Maybe I am the only one, but I have struggled twice with this topic and so I thought that I would write this short article to make sure I remember the correct workflow and hopefully help someone else out too.
Sometimes You Just Want to Say “Stay Out”
There are times when you may want to refuse access to a specific user or user group. In my case, this is usually for a specific sub-group of users where the parent group is allowed access. To be honest, there are many reasons and some may be just to appease over-cautious administrators, customers, etc.
Most Restrictive Rights Always Take Precedence
Whatever the reason, the rule of Business Objects security is always that “the most restrictive rights always take precedence”. Knowing this, some choose to deny access explicitly, even though it was never granted in the first place, just to be sure that now and in the future that user/group does not get access.
Adding the Users or Groups
In our example we will use a folder, but this translates to any object, top-level rights, or even applications. Of course, you will want to log in to the Central Management Console (CMC) using an account that is a member of the “Administrators” group. Locate your object, we are using the “BOT Expenses” folder I created for this example. By default when I select the “User Security” option from the right-click drop-down menu on the folder I see this:
By default my environment denies access to the “Everyone” group. This is done by editing the top-level folder security in advance.
Next we need to select “Add Principal” and choose the groups to whom we want to deny access.
Assign Security – What? Why? I Want to Deny not Assign!
Click the “Add and Assign Security” button and you will see the following page:
Now here is where I was getting confused. At first I was looking for an Access Level called “No Access”, this was the BO XI R2 in me. Then I thought well, maybe it is implicit here and all I have to do is “Save” and be done. I clicked “Apply” and the screen just re-drew itself, making no changes. Then I clicked “OK” and I saw this message:
Click “OK” here just returned me to the screen depicted in the first screenshot above and erased all of the “principals”. Thank you CMC, I love you too.
So How Do You Make It Work?
OK, I will just tell you how to make it work. Return back to this screen:
Now either click the “Remove Access” button or manually un-check the boxes next to “Inherit From Parent Folder” and “Inherit From Parent Group”. Either action results in the same result. Now click “OK” and you will still get this prompt:
But this is “OK” this time… so click “OK”.
Successfully Explicitly Denying Security Access in Business Objects XI 3.1
Now you should see the groups that you select with the most desired access level of “No Access”.
Congratulations, to you if you figured this out on your own and can remember this less-than-intuitive CMC security workflow. Once you look at the removing inheritance aspect it makes sense, but it still seems like there should have been an access level called “No Access”. Perhaps, an overly cautious Business Objects XI 3.1 administrator would create a custom access level that has everything explicitly denied and call this one “No Access”, unless Business Objects XI reserves that name in which case you could call it “No Access – Thanks to BusinessObjectsTips.com!”. That would be a great name for sure.
Please read Marshall’s important note below for additional explanation.
Important Note: This does not explicitly deny anything. This sets everything to “not specified.”
In my installation, I did in fact create a CAL that explicitly denied every single right. I did this because we use a “recycle bin” group where we drop our disabled users while we determine whether or not they should actually be deleted. In R2, I discovered that I would frequently end up with users in the “recycle bin” who had been re-enabled, but not re-assigned. However, because the “recycle bin” was just No Access, it wasn’t actually restricting anything. Now, the user has to be both enabled and removed from the recycle bin before they can do anything.
As another note, the principal will only continue to show up in the list of principals if you are explicitly breaking inheritance with this change. If you give a group rights to a folder, then later go back and remove all rights, that group will simply disappear from the list of principals.
Hey Marshall, thanks for keeping me straight. You make excellent points. I like your “recycle bin” group idea. In my recent case I needed to ensure that members of a particular group could not touch certain folders that they didn’t even yet have access to (through any other group). I found that the only way to accomplish without screwing up their other access, was to do the above. Now I am wondering if this really is as rock-solid a solution as I had hoped.
Marshall, no offense but your article is wrong in a number of places.
1. If you set the everyone group to have ‘No access’ at the top level then your users will not be able to see any of the folders. V3 and 3.1 went back to the old ‘v5/6 Supervisor’ option of forcing users to have at least ‘View’ access on a top level folder before they could ‘see’ anything beneath it. This is completely different from v2 of BOXI.
2. In v2.0, 2.1, 3.0 and 3.1 the rule is “the least restrictive” applies. The rule you specified was true for every version before XI.
You can easily test this out by setting the top level folder setting to ‘Everyone – No Access’ and then , say, ‘Sales – Full Control’. If we had a user , bob, who is in the ‘Everyone’ group (as is always the case for every user in the entire deployment) and also in Sales then there is a conflict of permissions. Is it ‘No Access’ or is it ‘Full Control’? The answer is ‘Full Control’.
Brian,
Thanks for the information.
I have been struggling with a re-design of a BO Security deployment. I was trying to set Everyone to No Access for top-level folders and have been trouble-shooting why I was unable to grant access at any other folder level.
This explains it. But I must agree I don’t know why BO would use this logic for top-level folders. It seems it would be much better to use no access at the top level and then only grant access to those folders a user group needs.
Also, I find it surprising that such a major change in security access rules is not documented and pointed out in BO’s documentation. Maybe it’s in the what’s new section, but I cannot find this section. I know I read it a year or so ago before I started using XI R3.
Since this isn’t documented, maybe this is actually an oversight (bug) on SAP BO’s part. I wonder if they will change this back again with a future release?
Thanks again.
If possible use only Custom Access Level (CAL) definitions.
The way I solved the dilemma to allow access to normal folders but not subfolders was to create two CALs. One grants access to the folder (and by inheritance to all subfolders that might lurk beyond it). Then another CAL that explicitely denies access to a specific subfolder.
CAL One is applied to the folder itself and inheritance is working.
CAL Two is applied to the sub folder and also keeps inheritance working.
The effect is that a user under both these CALs has access to the folder and its subfolders except the one (and its sub folders) where access is denied.
This also works for folders where users can run reports but in sub folders shall only view. Explicitely denying the rights to run/schedule reports and refresh data reverts rights back to View level only (I don’t use any of the predefined standards as they can be too coarse) so that my users now can run reports as they like in the standard folder but only view contents in the folder below, where the automated distributions are kept.
Knut, thanks. This is very insightful and helpful.
Thanks for pointing out that we miss “No Access” Access level.
Is anyone have inforamation about, how to find list of all user with their groups and privileges
Hi Laxman, what you seek can only be obtained using the Business Objects SDK or some third-party tool developed using the SDK. I don’t have any to recommend, sorry.
Thanks Julian for reply.
I am new to CMCApplication,
I have question, that how to assign rights to user on particular webi folder . My requirement is, he can view and refresh reports contained in that folder.
Hi!
We have the vs XI 3.1 of BO.
In Instance Manager, we need that some users ( not administrators), cam edit and instance, to change destination, notification, etc…
But only administrators can see the Opcion of Notification and Reeschedule in Infoview.
It’s that correct or we need some task plus??
Thanks.
Hi Tony, in BO XI 3.1 there are options to specifically enable the management of schedules and instances (look in the “General” section. You might consider creating a Custom Access Level for this, so you can easily refine it until you get it working. I think once you have this all granted (to user on the objects) you may be good to go.
Hi all, after creating access level in user security it shows administrators and everyone by default, i would like to add another user group which created, by clicking add principals nothing is showning in my cmc. whereas i checked other system it shows available user/groups….
why it is not showing in my system. Please help
thanks, karthik
Hi Karthik, when you attempt this are you using the “Administrator” user?
Hi,
Can you please let me know how can i restrict the user to edit the reports(Folders>ABC_Report>Right Click View>Edit, This edit options is available next to refresh button)
Thanks,
Gaurav
Hi,
I am trying to create user group for our Help desk team with certain restrictions. I need to restrict this group to only “Users and Groups” menu in the Central Management Console. The SAP refuses to help us. Does anybody know how to do that?
Hi there,
I have Custome Access Levels (CALs)and I thought I had it all figured out however users in writer groups as well as View & Refresh only groups and who also have access to View & Refresh only folders have permission to create a new doc in the View & Refresh only folders and I don’t want this. Explicitly denying “Create Document” in the View & Refresh CAL also prevents them from creating new docs in the Write folders where they should be able to create new docs. Any help would be appreciated.