Essbase Security Provisioning: Welcome To The Jungle

I am currently only about 1/3 as happy with Essbase as I usually am, and that is because of outsourcing. Yes, Essbase security has been outsourced to external authenticators - and it is an outsourcing job I have studiously avoided since day one. Although I can say without hesitation that I have done a couple migrations of Essbase native users over to MSAD, I am deep into the jungles of it now dealing with a non-trivial case with thousands of users, hundreds of groups, scores of cubes and a half dozen Essbase servers in multiple environments. Welcome to the Jungle.

There is a lot to be learned in such a situation and I have yet to learn it all or even enough to feel moderately dangerous. That is primarily because as of 9.3.1, MAXL has been emasculated and mastery of this most wonderful language is not enough to get you through the day. Instead, you must master a different kind of beast if you don't want to be clicking buttons in a Java Console for the rest of your life. That beast is CSSImport, a command line utility of sorts that allows you to modify the mind of Shared Services.

The problem is that the mind of Shared Services has only one portion of the information necessary and the mind of Essbase has another portion. Keeping track of which knows what is a small nightmare. That's because, no matter how complex it gets, at least you can go back to EAS and the Shared Service Console and click your way through. Dealing with it on a large scale is a large nightmare because you simply cannot.

Now being a geek is probably not the best way to approach this part of the Oracle stack, because to us geeks, things have to make logical sense and basically work. And if it doesn't you should be able to RTFineM and figure it out, and failing that check Google Groups or some such helpful place. But those  who know are apparently not saying, and most folks don't know. And so geek sweat. See it? All over my keyboard. But given my partial knowledge and desire to get *some* public information out there, I will endeavor to give a few pointers.

First of all, somewhere there is a master switch that tells EAS and Essbase to shut off half of its security brain and outsource such matters to Shared Services. I think this switch is irreversible, and probably after 9.3.1 it may not be an option.  The outsourced functions have to do with creating users, creating groups and populating groups with users and other groups. So the following line of MAXL, once that master switch has been switched, no longer works or makes any sense:

create or replace user joeblow as external;

instead you will do something like this:

#user
id,provider,login_name
joeblow,LDAP1,joeblow

And those three lines are stored in an input file. In addition to the input file, you need a configuration properties file and then you run a command something like this at the DOS prompt (or unix command line):

CSSImport.sh properties_file

So now you have let the Shared Services brain know that joe blow exists in the company LDAP named LDAP1. I would show you the properties file, but I don't want you to be daunted yet. The Shared Services brain knows, Essbase does not know. So Joe is only part way into the system.

Next, you need to enter Joe into a group. If you think the jungle is bad now, imagine what it would be like without groups. Believe me, you don't want to go there. The short way of understanding this is to make a hard and fast rule that you will only provision users to Essbase applications via groups. It makes organizational sense.

'Provision' is a ten dollar word for 'grant access', sorta. I say sorta because I think it rather does dual duty between granting access and granting recognition. But that may be due to a partial understanding on my part. Since there are two brains to think about, it's hard to know which brain sees what and which brain grants what. Here's what I'm talking about.

What I believe is the following. When you use external authentication:

1. Maxl cannot be used to create or delete users.
2. Maxl cannot be used to create or delete groups.
3. Maxl cannot be used to add members to groups or add groups to groups.
4. CSSImport can be used for all of the above.
5. When CSSImport is correctly used to import users and groups, Essbase cannot see them. EAS cannot see them either. So unless and untill a user does actually logon to Essbase, the user will not show up in EAS.

So this is a seeming paradox. You would think, now that Essbase has given up the right to create users, that as soon as Shared Services does create them, that they would send a little message over to Essbase and say 'Hey, lookee, new users!". But in fact, you can create users in Shared Services AND THEN CLICK THE SYNCHRONIZE BUTTON in EAS and Essbase still won't know who these users are or that they exist. Forget about giving the new users access to anything, Essbase itself still doesn't know that they exist.

Oh wait, check that, that was a bug (ya think) that was patched yesterday.

In our installation, we have a particular issue which is that there are multiple user directories. We have two MSADs. Unless you patch Shared Services, this situation breaks everything. Well not everything, but a whole lot of things that are almost impossible to troubleshoot. See?:

When two or more providers of the same type (LDAP, MSAD, etc.) are configured in the search order (for example, LDAP1 and LDAP2) and users from both of these providers are included in a Native Group that is provisioned to Essbase, only users from the last provider (i.e., LDAP2) are returned to Essbase.

That broke a whole lot of things for us, and only just now are we beginning to see the light.  I will continue this series as I get closer to hacking through this jungle once and for all.

Comments

[Cameron Lackpour]

Have you tried the MaxL command
alter system resync sss?

There are also versions of this at the app and user level, e.g.,
alter application sync user user-name/group group-name/all_users_groups

and

alter user sync security with all application

I have to say I haven't personally used these functions but they're documented in the Fine Manuals you referred to.

Or do they not work?

Regards,

Cameron Lackpour

[Cobb]

It sounds simple until you try it. We've had issues with MSAD availability today which has complicated matters once more. Here's an example of what slows things down:

I've got a group with 3000 users in it from two different MSADs. I'm trying to replicate that on a new server. If there is one, just one, user that cannot be found when you update the group, then the entire update of the group fails. You have no idea how many of the users are no good until you run it 3000 times. There are no 'rejects'.

It doesn't matter what's actually IN the MSADs, what matters is what Shared Services SEES. There is no way to tell, in advance, what Shared Services can or cannot validate with regard to populating user groups.

My shortcut has been to run the import multiple times and generate a blacklist (manually) of all rejected users, recreate my import list minus the blacklisted users and try again. I did this for two hours until I realized that I could potentially be running this script forever.

I reran an export of the users to see if perhaps I could do an outer join and find the excluded users, and it turns out that Shared Services only recognized 96 Native Directory users. So all this time MSAD might have been down, but running the batch tools CSSImport and CSSValidate give you no idea about such things.

[Cobb]

Sanjay Roy says a bunch at Network54
This discourse is only valid when we have externalized ESSBASE security to Shared Services.
These are the following steps (works consistently in HYS 9.2.0.1, 9.2.0.3 and 9.3.0.1)
Case 1 :
If we are using the Native Directory for storing the user/group credentials
1a) Create the user in Native DIrectory (Using Web Console)
1b) Run the MAXL "create user type external ;" (Step 1a is needed for this to work)
(
what this will do is
- create the user is ESSBASE (create entry in the $ARBORPATH/bin/essbase.sec file) and
- give the user "Server Access" provisioning in Shared Services.
)
1c) grant the user application/filter access (use grant command). This will also update the application provisioning in Shared Services.
1d) This is required if and only if the user security/application needs to be refreshed.
alter user sync security with all application ;
OR
alter application sync user ;
The 4 steps also creates the relevant provisioning in Shared Services as well and syncs them with the essbase.sec file.

So, MAXL sets up security in ESSBASE as well as set the security in the Shared Services repository.
You can also use alter system resync sss;
- to refresh all the security from Shared Services repository to ESSBASE.

When we delete the registered application in Shared Services all the security related to the ESSBASE application is lost.
Also if the $ARBORPATH/bin/essbase.sec file is dropped or corrupted, SHared Services cannot sync the entries in the repository with the $ARBORPATH/bin/essbase.sec file and hence cannot refresh. In that case the ESSBASE agent will not start as CSS authentication will fail.

For groups in native directory, i have seen in 9.3.0.1, that running the MAXL
create group type external;
creates the group (yes, it creates the group) in the Native-directory (if the same group does not exist in any other user-directory registered with Shared Services).And it also does the same provisioning in Shared Services as discussed for the user. The MAXLs will be the same except for the fact that you need to substitute the keyword user with group.

Case 2 :
If we are using the another external LDAP (SunOne, MSAD) for storing the user/group credentials.
2a. The user/group needs to be created in the external LDAP.
2b) Run the MAXL "create user type external ;" (Step 2a is needed for this to work)
If the use does not exist in the Native-LDAP or any of the external LDAPs registered with Shared Services, it will throw error. In case of groups as I said, if it does not find the group in any of the external LDAPs registered with Shared Services, it will create the group in Native Directory.
Follow 1(c) and 1(d).

And as said, MAXL sets up security in ESSBASE as well as set the security in the Shared Services repository.
Hope this helps

[buy viagra]

I have a print titled "Jungle Ruler" by artist John Pitre. It
appears to have been a water color originally, but I am not certain of
that. It is blue. It is numbered 106 out of 250 and is 23" X 35" in
size.

[meghana]

I get a lot of great information here and this is what I am searching for. Thank you for your sharing. I have bookmark this page for my future reference. Search aws openings in hyderabad.