We have a security model that has 100 AD groups with differing access levels! Access levels are also set on other groups specified within the CMC. Could this model effectively be modified to run off 1 AD group (simply provides access to BO) and then all security done within the CMC itself, rather than by multiple AD groups? What is the advantage of having security set on so many AD groups? Surely it’s simpler to have 1. Thanks.
BOE 4.2
frank35 
(BOB member since 2005-08-25)
In my environment, I have a number of BO groups that I assign access to. I then add my AD groups as children of the BO groups. This way, I’m not assigning access for AD groups directly, and I can add and remove AD groups from my BO group as needed.
So in your case you could have a small number of BO groups set up that define the access needed, and then split up your 100 AD groups into one or more of the BO groups.
If your AD groups don’t really align to the BO groups, then you could add individual AD users to the BO groups. Not ideal, but it would work.
joepeters 
(BOB member since 2002-08-29)
Thanks Joe. What we really need to do is reduce the amount of AD groups to the point of having 1 AD group for company-wide BO access and then all access is granted/denied using BO groups only. I don’t see the need for so many AD groups - obviously users would still need to be added to the relevant group, be it AD or BO, but at least it reduces the AD overhead. Does that sound feasible? Thanks.
frank35 (BOB member since 2005-08-25)
Yes, that’s what I meant above, but I could have been clearer… You can have just a single mapped AD group which grants no access by itself. You’d then join individual users to BO groups that do grant access.
That single AD group could have access to minimal, common content, so that everyone has access to some stuff. Then the BO groups grant access to content that is group-specific.
joepeters (BOB member since 2002-08-29)
O I do feel your concern. “my” CMC has lots of groups, lots of external user groups ( Novel eDirectory LDAP groups, but the difference with ActiveDirectory is minimal)
Yes, the users need to be managed “somewhere”.
And yes, ONE single AD (or LDAP group holding “all users who have access” IS something you want.
In fact, we have two of such groups: LDAP “active BI users” and LDAP “suspended BI users” ),
both mapped into the BI security (and immediately made MEMBER of two CMC groups)
These 2 CMC groups then either get “no access” for the disabled users, or “very basic access” for the general “this group contains all active users” one.
They allow for “importing the users”, setting defaults and … for DISABLED users : to NOT lose their inboxes/personalfolders unless we ae sure those won’t be needed)
We too have MANY AD (LDAP) groups mapped in, which makes for a really flexible system within BI.
CMC groups are assigned (custom) access levels to
This makes a very fleible access possible, and assigning the access to actual users can be OUTSOURCED to tools who manage LDAP (or ActiveDirectory) groups.
I forget how AD names it, but it might be part of the “policy” system.
Novell provides a system “RBPM” (Role Based Program? Management?) which essentially does this :
Those “resources” - within eDirectory - are simple LDAP groups, very few per object inside BI, but quite a lot.
The LDAP (AD) groups are then mapped into BI, and moved to (member of) the CMC access grops.
So for every secured FOLDER, we need 3 (nested) CMC groups
For every universe we invented 2 groups (nested as well) :
Over time, we got to some 80+ secured folders (so x3 = 240+ folder groups),
and (data silo’s! Not everything moved to datawarehouse yet) roughly 40 universes too (x2 = 80 “resource” groups)
It’s hard to track when a folder isn’t any more, so we 'd like to find those and then disable the access … cannot be decided ICT-side, of ourse.
So yes, this makes for LOTS of AD groups (well LDAP), but both Novell eDirectory and MS AD have tools to “group” those resources into “roles” or “policies”.
Then a team that provides user management can handle the access from outside BI.
And in our case: that team “user management” uses those same procedure (via the business units managing their staff through rol based management) for a lot of other applications too :
That way, having “many” LDAP groups in the eDirectory (or AD groups inside MS AD) is not a problem in itself,
and instead of making usermanagemrnt difficult, it makes it easier.
Of course, you need to activate (in the CMC - Authentication tab - LDAP connector) the scheduled update of these groups.
(For our “hundreds” of groups, CLICKING update returns the screen in under 20 seconds, the scheduled update doesn’t need the GUI … and runs at least every hour WITH an alert on fail)
Of course, if you 're alon, managing BI through the CMC (no third-party layer on top),
BUT
I would surely AVOID setting security directly on the LDAP groups.
The security uses “CMC groups only”, and the LDAP group giving “write access to folder P” is made a MEMBER of the CMC group giving (only) that right.
This way, every resource group in LDAP gives exactly ONE access level to exactly one (tree of object(s)
The GROUPING into roles/policies is done in eDirectory/ActiveDrectory, and users are handled there only.
Well no, occasionally we DO use “Enterprise” users, without LDAP alias.
But those are only needed for testing or managerial tasks.
An example are users PROMOD/PROMOT/PROMOP in resp dev/UAT/prod. These are technically just users for connections inside promotion objects.
RensH 
(BOB member since 2007-06-18)