I suppose being the newbie - I have to ask the obligatory ACI questions... ;-) 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. Thus I created 3 rules and they aren''t working because an unauthenticated/anonymous bind still can view them... These are the 3 rules (which are applied to ou=People with the expectation that each address book would inherit)... (targetattr = "*") (target "ldap:///ou=AddressBook,uid=*,ou=People,dc=azapple,dc=com") (version 3.0;acl "Personal Address Books Owner";allow (all)(userdn "ldap:///self");) (targetattr = "*") (target "ldap:///ou=AddressBook,uid=*,ou=People,dc=azapple,dc=com") (version 3.0;acl "Personal Address Books Non Owner";allow (read,compare,search)(userdn = "ldap:///all");) (targetattr = "") (target = "ldap:///ou=AddressBook,uid=*,ou=People, dc=azapple,dc=com") (version 3.0;acl "Personal Address Books";deny (all)(userdn = "ldap:///anyone");) are these supposed to be separate rules or combined into 1 rule? and lastly...despite the documentation, I can''t get ldapsearch to return the list of ACI''s... ./ldapsearch -h localhost -D ''cn=Directory Manager'' -w - ''(aci=*)'' whether I use the ldapsearch client from fedora-ds or the one from openldap-clients Craig
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 :)>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).>These are the 3 rules (which are applied to ou=People with the >expectation that each address book would inherit)... > >(targetattr = "*") (target >"ldap:///ou=AddressBook,uid=*,ou=People,dc=azapple,dc=com") (version >3.0;acl "Personal Address Books Owner";allow (all)(userdn >"ldap:///self");) > >Keep in mind that self applies to the entry that is binding (i.e. the users entry), not entries under it - i.e. you are defining what the user can do to their own records, not the entries under the ou=addressbook,... What I believe this is saying is that if the users entry is, say uid=craig,ou=addressbook,uid=something,ou=people,dc=azapple,dc=com, they can edit any part of their own entry, which is clearly not what you want. (you want uid=craig,ou=people,dc=azapple,dc=com to edit anything under ou=addressbook,uid=craig,...). So, since you are never binding as the addressbook entries themselves, the self rule doesn''t let you edit those entries.>(targetattr = "*") (target >"ldap:///ou=AddressBook,uid=*,ou=People,dc=azapple,dc=com") (version >3.0;acl "Personal Address Books Non Owner";allow >(read,compare,search)(userdn = "ldap:///all");) > >(targetattr = "") (target = "ldap:///ou=AddressBook,uid=*,ou=People, >dc=azapple,dc=com") (version 3.0;acl "Personal Address Books";deny >(all)(userdn = "ldap:///anyone");) > >OK - you have the deny rule, but you''re targetattribute is "", which means no target attributes are defined. The default rule (probably in dc=azapple,dc=com) probably allows to all but userpassword or such - anything it allows that this does not deny is allowed, so this effectively does nothing - you can make targetattr=*, but... hmm - I never use deny, so I''m not sure if this will deny everyone (i.e. not just anonymous users, but _all_ users, irregardless how or if they are bound - like I said, deny can do unexpected things if you don''t understand it really well).>are these supposed to be separate rules or combined into 1 rule? > >Separate rules - to apply different things to different people (self, all, anyone) you have to have differnet rules.>and lastly...despite the documentation, I can''t get ldapsearch to return >the list of ACI''s... > >./ldapsearch -h localhost -D ''cn=Directory Manager'' -w - ''(aci=*)'' > >aci''s are operational attributes, which means you have to specifically ask for it - i.e.: ./ldapsearch -h localhost -D ''cn=Directory Manager'' -w - ''(aci=*)'' aci (note the aci added to the end.) A couple ways to do what you want: First, instead of putting the aci on the ou=people, put it on each ou=addressbook entry - i.e. something like: dn: ou=addressbook,uid=craig,ou=people,dc=azapple,dc=com ou: addressbook objectclass: top objectclass: organizationunit aci: (targetattr = "*") (version 3.0;acl "Personal Address Books Owner";allow (all)(userdn "ldap:///uid=craig,ou=people,dc=azapple,dc=com");) aci: (targetattr = "*") (version 3.0;acl "Personal Address Books Non Owner"; allow(read,compare,search)(userdn = "ldap:///all");) aci: (targetattr = "*") (version 3.0;acl "Personal Address Books";deny (all)(userdn = "ldap:///anyone");) You don''t need the target, because it defaults to the entry it''s on, which is what you want. I''m still not sure that the deny is gonna work right, but give it a try. Note that you have to define the allow (all) to be the dn of the user you want. You might be able to use ldap:///parent, but I think you would then have to bind as ou=addressbook,uid=craig... to create entries directly under ou=addressbook,uid=craig..., which you can''t do. Another way to do this is to create ou=addressbooks,dc=azapple,dc=com, or even a separate tree to hold personal address books (i.e. o=pab), then create something like ou=craig,ou=addressbook,dc=azapple,dc=com (or ou=craig,o=pab) to hold things in a separate place - in that way, you can remove default anonymous access from dc=azapple,dc=com, and set anonymous access as appropriate on ou=people..., ou=groups..., ou=addressbooks..., etc as you want them. It makes cleanup of everything associated with a user a little more disjointed maybe, but it''s a lot easier to manage/organize your aci''s this way. Might be able to use roles to make creating appropriate aci''s easier also. - Jeff
On Sun, 2005-12-04 at 17:44 -0500, Jeff Clowser wrote:> Craig White wrote: >> >and lastly...despite the documentation, I can''t get ldapsearch to return > >the list of ACI''s... > > > >./ldapsearch -h localhost -D ''cn=Directory Manager'' -w - ''(aci=*)'' > > > > > aci''s are operational attributes, which means you have to specifically > ask for it - i.e.: > > ./ldapsearch -h localhost -D ''cn=Directory Manager'' -w - ''(aci=*)'' aci > > (note the aci added to the end.)---- ok, I didn''t understand that in the documentation as the word aci was apparently wrapped to another line. Your example didn''t work but this did... ./ldapsearch -h localhost -b "dc=azapple,dc=com" \ -D ''cn=Directory Manager'' -w - ''(aci=*)'' aci I did have to have a base for the search. now I''m working through the answers that I got concerning the specific ACI''s and my Address Books - thanks Craig
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. (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
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@redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-users > >
On Sun, 2005-12-11 at 14:11 -0700, Richard Megginson wrote:> >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") > >;)---- If I remove the ''target'' phrase, the ACI takes on an entirely different meaning - that the dn can read and write anything inside of dc=clsurvey,dc=com and my interest was only that the dn can do anything inside the target itself. My point was simply that if I attached that same ACI to the target itself, it doesn''t work. If I attach it to dc=clsurvey,dc=com - it works. Thanks Craig