wtbt Super Contributor.
Super Contributor.
1159 views

Rights administration

Hi!
Don't know if this is the right place for this question, but anyway:
We have an eDir with ~20 k users in a single ou "Users". While keeping them there I would like a means to pick subsets of these (we can call it "Groups") and then let one particular user in the ou=Users see and perhaps modify the members of this subset. This particular user might or might not be a member of the subset. Normally users in the ou=Users should not be able to see each other at all, which is the way things are now.
My first idea was of course to set up dynamic groups and populate them with simple LDAP selections. The dynamic groups work fine but alas, rights to this group obviously mean rights to the MEMBERS of the group.
Next idea was to create orinary static groups and populate them by croning LDAP scripts. But then it appears that rights to a static group does not mean rights to the group members either.
This eDir is used by several external srvices which is why we want to keep the ou structure flat. I just thought that giving a person browse rights to a group would have the same effect as giving browse rights to an ou, but this is apparently not the case.
All I want is to hand out the right to see and maybe modify properties of the students to the few persons that are in charge of them.
Is there another way to accomplish this except creating an ou structure?

/Bengt
Labels (1)
0 Likes
6 Replies
wtbt Super Contributor.
Super Contributor.

Re: Rights administration

Sorry, something went a bit wrong. I mean:
"rights to this group obviously doesn't mean rights to the MEMBERS of the group" (no way to edit posts?)

/Bengt
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Rights administration

On 02/26/2016 05:26 AM, wtbt wrote:
>
> Sorry, something went a bit wrong. I mean:
> "rights to this group obviously *doesn't *mean rights to the MEMBERS of
> the group" (no way to edit posts?)


Editing posts can be done for up to ten minutes; it appears you were
outside that window, but no worries.

Giving something rights to any object means rights to that object only;
the subtree/Inherit flag/checkbox means the rights apply recursively to
child objects. Groups have no children as, like users, they are leaf
objects. Containers have child objects, which is why subtree/Inherit
works there. I can see how t may seem that groups have children since
they have members, but at the end of the day a member is just an attribute
value with its own rules that have no bearing on rights.

What you should be able to do, with static groups at least (not sure on
dynamic groups, bu maybe those too) is to set your special user to be
security equivalent to the group, and then give the group object the
rights to the specific child objects. For example if your group objects
was given Browse rights to each user in that ou=users container, and then
your special user was set security equal to that group, the user would
have all of the rights of the group (i.e. the ability to see the specific
users in that ou=users container).

You could do this with the standard eDirectory tools, or you could do it
all via LDAP; the attribute on the Group and special-user side (in LDAP
format) are securityEquals (special user object, value referring to the
group's DN) and equivalentToMe (group object, value referring to the
special user's DN); the attributes on the ou=users objects would just be
an ACL giving whatever rights to the group on whichever user objects, so
it'd look something like this for browse rights:


dn: cn=oneUser,ou=users,o=novell,dc=org
changetype: modify
add: acl
acl: 1#subtree#cn=someGroup,ou=group,o=novell,dc=org#[Entry Rights]


Run the LDIF above for every user you want the group to be able to see,
and therefore any objects security-equal to that group to see. I have not
tested this myself, but I think it should work. If dynamic groups handle
rights (again, not sure.... check docs or wait for others to confirm one
way or another) then that would be nice, but since we're dealing with ACLs
and giving rights to the users dynamically-found, I'm skeptical.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
wtbt Super Contributor.
Super Contributor.

Re: Rights administration

I'm not entrely sure I get your suggestions right but all I can achieve so far is either my "special user" sees ALL users in ou=Users or none. Can't make the special user see any subset and only that. I actually never thought that much about it before, never had a situation like this before. I just sort of took for granted that groups would work both ways. I mean, can't be so unusual to want to give limited rights to selected pesons to a small subset of the organisations users, e.g. "local admin" role, where it would be impractical to accomplish this by creating a very very fine-grained ou structure and perhaps move the accounts aruond a lot.
In our old environment we used exactly that solution but as things move on a group solution seems more apropriate.
We do have IDM so probably this will be the way to go.

/Bengt
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Rights administration

Could you explain what you tried, using which specific steps?

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
wtbt Super Contributor.
Super Contributor.

Re: Rights administration

Thanks a lot for your help!
What I tried was this, approximately:
Pick one user "TestStaff1" among the ~20k user objects in ou=users,o=portal
Create group "REB" in ou=groups,o=portal
Populate REB with ~50 random user objects from ou=users,o=portal
Assigning browse and compare for group REB on ou=users,o=portal
Make TestStaff1 security equivalent to me in properties on group REB
TestStaff1 can now see all users in ou=users
Seems to me like a logical result. I am not enirely sure I completely understood your description, though.
Obviously, giving the same rights individually to each member of group REB instead, and not give the group REB rights to anything would work. This would, however, mean a totally colossal administration. It wouldn't be very troublesome to select the users that are members of REB and create a ldif file to assign rights to these members individually for TestStaff1. Still, this wouldn't be a viable way to work. Particularly un-assigning rights when a user moves from one place to another could easily be missed.
I believe that the way to go here is setting up an IDM null driver that checks memberships of specified groups and assigns rights to the member objects idividually - and un-assigns the rights when user leaves the group.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Rights administration

On Fri, 26 Feb 2016 11:36:03 +0000, wtbt wrote:

> Hi!
> Don't know if this is the right place for this question, but anyway: We
> have an eDir with ~20 k users in a single ou "Users". While keeping them
> there I would like a means to pick subsets of these (we can call it
> "Groups") and then let one particular user in the ou=Users see and
> perhaps modify the members of this subset. This particular user might or
> might not be a member of the subset. Normally users in the ou=Users
> should not be able to see each other at all, which is the way things are
> now.


You would have to set the appropriate ACLs on the objects to be managed.
That would be relatively easy to do with IDM using a Null driver to hold
your business logic.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.microfocus.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.