On Fri, March 29, 2013 22:25, Dmitri Pal wrote:
> 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-s
>>>>>>>>>> ingl 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?
>
>

https://fedorahosted.org/freeipa/ticket/3546



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

Reply via email to