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 <[email protected]>: >> >>> 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. >> >> 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! -- 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 [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
