BOB: Business Objects Board
Not endorsed by or affiliated with SAP

Register | Login 

Want to sponsor BOB? 
Want to sponsor BOB? (Opens a new window)  

General Notice: Upcoming Events: BOBJ conference in Paris: Mar 28, PGHBOUG: Apr 4.

Security Rebuild


 
Search this topic... | Search CMC... | Search Box
Register or Login to Post    Forum Index -> Security and User Administration -> CMC  Previous TopicPrint TopicNext Topic
Author Message
frank35
Principal Member
Principal Member



Joined: 25 Aug 2005

Posts: 392
Location: London


flag
PostPosted: Thu Jan 10, 2019 9:27 am 
Post subject: Security Rebuild

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
Back to top
joepeters
Forum Fanatic
Forum Fanatic



Joined: 29 Aug 2002

Posts: 6521
Location: Connecticut, USA


flag
PostPosted: Thu Jan 10, 2019 12:33 pm 
Post subject: Re: Security Rebuild

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.
Back to top
frank35
Principal Member
Principal Member



Joined: 25 Aug 2005

Posts: 392
Location: London


flag
PostPosted: Fri Jan 11, 2019 4:30 am 
Post subject: Re: Security Rebuild

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.
Back to top
joepeters
Forum Fanatic
Forum Fanatic



Joined: 29 Aug 2002

Posts: 6521
Location: Connecticut, USA


flag
PostPosted: Fri Jan 11, 2019 7:31 am 
Post subject: Re: Security Rebuild

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.
Back to top
RensH
Principal Member
Principal Member



Joined: 18 Jun 2007
ASUG Icon
Posts: 145


flag
PostPosted: Sat Jan 12, 2019 2:15 pm 
Post subject: Re: Security Rebuild

frank35 wrote:
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


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
- document folders
- universe folders
- connections
- user groups
- applications (BI launchpad, WebIntelligence (and its interfaces: note that RichClient is assigned separately),

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 :
- create "roles" who give access to "resources"( business people ask IT user management to create the roles)
- manage users having these "role(s)" they need (business people add" their staff to the roles)

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
- just view what is inside
- edit douments inside the folder
- organise the folder creating subfolders)

For every universe we invented 2 groups (nested as well) :
- access the data returned by the oniverse's objects, but no direct access to those objects)
This allows the user to refresh the data in an existing document: "view on demand" is close.
- access the universe and its objects to create/modify queries
(to actually enable that, the universe "reporter" group in CMCgets access to web intelligence, of course,
but no extra LDAP (AD) group is needed for that: it's a logical implication of "give the right to create/modify queries"

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 <used> 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 :
- access to MS Exchange
- listing custom applications needed on user machines
- mobile access
- giving access to "intranet" (outsiders ona guest machine are quite limited)
- "extranet" (home work, BYOD, third parties ... )

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.

_________________
Transitioning to : XI 4.2 (SP3)
(Mostly WebI docs using universes, no voyager etc -yet- but (very few) dashboards )
LDAP eDirectory , repository on oracle.


Phasing out : BI 4.1 SP5 . Mostly Webi.
Phased out : BO-XI 3.1 SP6 . Mostly Webi.
Phased out : BO651, full clients. No Webi.
Back to top
Display posts from previous:   
Register or Login to Post    Forum Index -> Security and User Administration -> CMC  Previous TopicPrint TopicNext Topic
Page 1 of 1 All times are GMT - 5 Hours
 
Jump to:  

Index | About | FAQ | RAG | Privacy | Search |  Register |  Login 

Get community updates via Twitter:

Not endorsed by or affiliated with SAP
Powered by phpBB © phpBB Group
Generated in 0.0318 seconds using 17 queries. (SQL 0.0028 Parse 0.0009 Other 0.0282)
CCBot/2.0 (https://commoncrawl.org/faq/)
Hosted by ForumTopics.com | Terms of Service
phpBB Customizations by the phpBBDoctor.com
Shameless plug for MomentsOfLight.com Moments of Light Logo