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?

>
> rob
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to