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.
December 22nd, 2009 at 2:42 pm
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.
December 30th, 2009 at 6:39 pm
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.
February 15th, 2010 at 5:35 pm
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’.