Brian LaMere wrote:

    The ACIs are defined inside the underlaying Directory Server. See
    details and syntax are here
    The ACIs as you see can be group based. One does not need a
    "ou" user structure in the DS for ACIs  - just groups. So all the
    live in one container without any hierarchy.  All the hierarchy can be
    accomplished by creating a combination of nested groups. Groups
    live in
    another container but on the same level. This is what we mean by "flat

well, problem is that I want project managers to be able to create customers within does a flat DIT allow otherwise unprivileged users the ability to create entries? Note that most of my directory won't be people or groups, but objects that define things that tools then access for monitoring, extending/expanding services, etc. I could always create aci's that allow particular groups to create entries with only a certain set of attributeTypes and objectclasses, but in some cases those customers should show up as valid users on a machine; "id customername" should respond with stuff. If the answer is that I'm not creative enough to imagine how to restrict based on something other than ACIs on an ou, then I suppose that's the answer ;) If that's the case then I'll just have to find the time to do an install, load my schema, and test to see if everything I want to happen can be made to happen, and everything I don't want to happen can be made to not happen.
389 access control is pretty powerful and flexible. There's usually a way to do what you want to do without having to resort to using subtrees (as in AD).

Brian LaMere

Freeipa-users mailing list

Freeipa-users mailing list

Reply via email to