[Freeipa-users] User admins for different groups

[Rob Crittenden]

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