On 03/29/2013 02:59 PM, Sigbjorn Lie wrote:
>
>
> On Fri, March 29, 2013 19:10, Dmitri Pal wrote:
>> On 03/28/2013 05:11 AM, Petr Spacek wrote:
>>
>>> On 28.3.2013 09:38, Philipp Richter wrote:
>>>
>>>> Am 26.03.2013 um 16:55 schrieb Rob Crittenden <rcrit...@redhat.com>:
>>>>
>>>>
>>>>> 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-singl
>>>>>>>>> e/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.
>>>>>
>>>> In our current ldap implementation (openldap) there are some
>>>> attributes which are implicitly set. I think these are 
>>>> creation/modification time and creator's
>>>> name. So if these attributes would exist in ipa one could set up 
>>>> automember rules based on the
>>>>  creators name.
>>>>
>>>> Is there a way to switch such attributes on?
>>>>
>>> creatorsname is present, but is not returned from search if you didn't 
>>> require it explicitly:
>>>
>>> $ ldapsearch -Y GSSAPI 'creatorsname'
>>> [...]
>>> creatorsname: uid=admin,cn=users,cn=accounts,dc=example,dc=com
>>>
>>>
>> So does that mean that automembership plugin can be configured to place
>> users into the right groups based on the value of this attribute? That would 
>> be really awesome!
>>
>>
> It looks like that works just fine! I've been looking for a solution for this 
> too! Awesome! :)
>
> ipa automember-add-condition usergroupname 
> --inclusive-regex="uid=creatorusername.*"
> --key=creatorsname --type=group
> --------------------------------
> Added condition(s) to "usergroupname"
> --------------------------------
>   Automember Rule: usergroupname
>   Inclusive Regex: creatorsname=uid=creatorusername.*
>
>
> # ipa user-add atest2
> ---snip---
>
> # ipa group-show usergroupname
>   Group name: usergroupname
>   Description: Created by creatorsname
>   Member users: atest2
>
>
> Is there any reason not to use the creatorsname attribute? Is there a reason 
> it does not exist as
> a selectable key in the webui?


I do not see a reason.
Seems like a valid use case
Can you please create an RFE ticket?

>
>
>
> Rgds,
> Siggi
>
>
>


-- 
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