<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The ACIs are defined inside the underlaying Directory Server. See<br>
details and syntax are here<br>
<a href="http://directory.fedoraproject.org/wiki/Howto:AccessControl" target="_blank">http://directory.fedoraproject.org/wiki/Howto:AccessControl</a><br>
The ACIs as you see can be group based. One does not need a hierarchical<br>
"ou" user structure in the DS for ACIs  - just groups. So all the users<br>
live in one container without any hierarchy.  All the hierarchy can be<br>
accomplished by creating a combination of nested groups. Groups live in<br>
another container but on the same level. This is what we mean by "flat<br>
tree".<br>
<br></blockquote><div><br></div><div>well, problem is that I want project managers to be able to create customers within ou=customers...how 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.</div>
<div><br></div><div>Thanks,</div><div>Brian LaMere</div>
</div>