Craig White wrote:
I'm not sure why, but most of the time, the (target = ..) clause is not necessary. acis have subtree scope - they apply to the entry containing the aci and all children and decendents of that entry. So if the following aci is in the entry dc=clsurvey,dc=com, you don't need the (target....) clause.On Sun, 2005-12-04 at 17:44 -0500, Jeff Clowser wrote:Craig White wrote:First, a comment on this: Does user craig really want user jennifer to see his "personal" addressbooks? Typically, "personal" addressbooks are only visible by the person that owns them. I know I'm questioning your requirements rather than telling you how to implement what you want, but thought I'd ask :)I have personal address books...each user would have one - i.e. ou=AddressBook,uid=craig,ou=People,dc=azapple,dc=com ou=AddressBook,uid=jennifer,ou=People,dc=azapple,dc=com and my thinking is that each person can read/write/delete/etc. their own address book, authenticated users can read and anonymous is denied.---- finally got through my initial setup to work on these issues and can reply back. Most of my setups are for my clients and they do have workgroups where they would possibly need to share address books. So I generally have company wide address books and personal address books and permit at least some sharing of the personal address books. In addition, since the typical address book clients that people would use (Outlook/Thunderbird) are incapable of creating/editing entries, it requires some other application that some of the people are less than eager to use which means that the maintenance of them falls to their underlings ----My guess is that at the top of your tree, you have an aci that allows anonymous to see stuff (probably something like anonymous can read/search all but userpassword, etc). Aci's at the top are inherited "down the tree", so they are visible because of that, not because of your new aci's. It's usually hard to create a deny aci for a lower branch of the tree that works without breaking something else, and I always try to avoid deny aci's (because they always take precedence and can never be overridden by any allow aci's, causing some potentially unexpected results).Thus I created 3 rules and they aren't working because an unauthenticated/anonymous bind still can view them...---- Yeah you are correct on all these accounts. Obviously the default rule is always to not allow whatever isn't expressly permitted and yes, there was the default anonymous allow rule that played into it. What I did discover was if I attached the following ACI to ou=AddressBook,dc=clsurvey,dc=com it doesn't work but if I attach it to dc=clsurvey,dc=com it does work.
(targetattr = "*") (target = "ldap:///*,ou=AddressBook,dc=clsurvey,dc=com";) (version 3.0;acl "AddressBook Administrator"; allow (all) (userdn = "ldap:///uid=Administrator,ou=People,ou=Accounts,dc=clsurvey,dc=com";) ;) Thanks Craig -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
