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:
- Maxl cannot be used to create or delete users.
- Maxl cannot be used to create or delete groups.
- Maxl cannot be used to add members to groups or add groups to groups.
- CSSImport can be used for all of the above.
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.
