Craig White wrote: >On Sun, 2005-12-04 at 17:44 -0500, Jeff Clowser wrote: > > >>Craig White wrote: >> >> >> >>>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. >>> >>> >>> >>> >>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 :) >> >> >---- >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 >---- > > >>>Thus I created 3 rules and they aren't working because an >>>unauthenticated/anonymous bind still can view them... >>> >>> >>> >>> >>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). >> >> >---- >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. > > 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. >(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 at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20051211/d000ccec/attachment.bin
