Hi, yes, the implemantation makes sense: you cannot base the decision to use an aci on an attribute that does not yet exist. But on the other hand I think your use case also makes sense, but if I understand it correctly is what you want is: - allow a user to modify or delete an entry only if the ipatokenowner attr matches the user - allow a user to add an entry only if it sets the ipatokenowner to itself. This kind of restiction should be handled by the targattrfilter part in the target definition, saying that only spefiic values can be used for an attribute. Unfortunately this target clause cannnot handle things like: "targattrfilters="add=ipatokenowner:USERDN" and I don't see how easily this would be implemented. Now, do we want to allow some "I know what I'm doing" flag or do we want to relax the interpratation of userattr for adding entries, I don't know, and we will not have a decision in this year, but I'd support your request to handle it somehow. So could you create a ticket for an enhancement ? Regards, Ludwig On 12/20/2013 11:31 PM, Nathaniel McCallum wrote:

Hi Nathaniel, 389-ds-base-1.3.2.10-1 is available from the Fedora 20 Testing and Rawhide repositories, which contains the fix for Ticket 47653 - Need a way to allow users to create entries assigned to themselves. (Please see also http://directory.fedoraproject.org/wiki/Releases/1.3.2.10) If you could try the bits and give a karma / feedback on https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.10-1.fc20, we'd greatly appreciate it. Thanks, --noriko Nathaniel McCallum wrote: