Dmitri Pal wrote:
On 03/26/2013 11:55 AM, Rob Crittenden wrote:
Petr Spacek wrote:
On 26.3.2013 15:10, Rob Crittenden wrote:
Philipp Richter wrote:
On 03/26/2013 12:39 AM, Dmitri Pal wrote:
I am trying to do the following:
We have some branch offices at different locations. We want to use
one ipa-server with replicas in each branch office. Each branch
office should have it's own set of administrators who should be able
to create/modify/delete users for its own branch but should not be
allowed to change users from other branches.
every member of admin-at should be forced to create/modify/delete
only users in branch-at. The same applies for admin-us/branch-us.
at first, i thought of a combination of (a) new role(s), with
write/delete permissions set for the branch-at group, as well as an
automember rule but it seems there is no way to filter for the
creator of an entry, which would be needed for the group
membership..
am i missing anything?
>
This might help
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#delegating-users
Yes, I read the whole document but as far as I understand delegates
are
only helpful for editing existing records. I want admins of one branch
to be able the also create users, but only in the assigned branch.
Currently we use standard openldap with different ou's for the
branches.
Each branch admin has full ldap permissions for it's own ou-subtree.
IPA uses a flat DIT so here is no way to control adding users in a
given
branch office.
The most you'd be able to do is delegae management (delete/modify) a
subset of
users who are members of a group that represents that branch office.
Any new
users added would need to be added to the appropriate branch group
by the
admin adding them.
This sounds like big deficiency to me...
Is it possible to hack automember plugin to enforce some group
assignment based on creator's group/name as proposed above? It should
allow users to prepare some hand crafted ACIs, I guess.
(Sorry, I don't have any knowledge about automember internals :-)
Using automember doesn't prevent an admin from adding a user outside
of the branch. It would just automatically assign that new user to the
correct branch based on the automember rules AND assuming that the
admin that added the user included the right information for the rules.
ACIs control add at the subtree level, so for us it is a binary.
Either you can add users or you can't.
I think Petr was suggesting to be able to add new factor into the
auto-member configuration. If the admin that adds a user has some
property than the user needs to be automatically placed into a specific
group. And admin would have ACIs against that group.
Isn't what should happen to support the use case with the flat tree we have?
The problem is we can't constrain a user from adding a user to the wrong
branch. Once in the wrong branch, a delegated admin would have no way of
administering it.
There are two kinds of access controls, attribute-level (read, write,
search) and entry-level (delete, add). So it is very possible to add an
entry with attributes you aren't later allowed to modify.
rob
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
