On Fri, May 18, 2012 at 1:52 PM, Rich Megginson <[email protected]> wrote: > On 05/18/2012 11:46 AM, Dan Scott wrote: >> >> On Fri, May 18, 2012 at 12:38 PM, Rich Megginson<[email protected]> >> wrote: >>> >>> On 05/18/2012 10:31 AM, Dan Scott wrote: >>>> >>>> On Fri, May 18, 2012 at 12:21 PM, Rich Megginson<[email protected]> >>>> wrote: >>>>> >>>>> On 05/18/2012 10:06 AM, Dan Scott wrote: >>>>>> >>>>>> On Fri, May 18, 2012 at 10:29 AM, Rich Megginson<[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> On 05/18/2012 08:13 AM, Dan Scott wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden<[email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Rich Megginson wrote: >>>>>>>>>> >>>>>>>>>> On 05/02/2012 07:36 PM, Ian Levesque wrote: >>>>>>>>>>> >>>>>>>>>>> On May 2, 2012, at 6:48 PM, Rich Megginson wrote: >>>>>>>>>>> >>>>>>>>>>>>> Is there any way to expose the nsDS5ReplicationAgreement >>>>>>>>>>>>> objectClass >>>>>>>>>>>>> to a less privileged account; i.e., an account solely designed >>>>>>>>>>>>> to >>>>>>>>>>>>> check replication status? >>>>>>>>>>>> >>>>>>>>>>>> You also need to expose the RUV tombstone entry at the base of >>>>>>>>>>>> each >>>>>>>>>>>> suffix. >>>>>>>>>>> >>>>>>>>>>> Good to know, thanks. I haven't messed with ACIs on 389ds/IPA >>>>>>>>>>> before; >>>>>>>>>>> any pointers? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Ian >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control.html >>>>>>>>> >>>>>>>>> >>>>>>>>> We already have some delegated permissions for replication but none >>>>>>>>> granting >>>>>>>>> only read access. Off the cuff, something like this might work: >>>>>>>>> >>>>>>>>> dn: cn="$SUFFIX",cn=mapping tree,cn=config >>>>>>>>> changetype: modify >>>>>>>>> add: aci >>>>>>>>> aci: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement))")(version >>>>>>>>> 3.0; aci "permission:Read Replication Agreements"; allow (read, >>>>>>>>> search, >>>>>>>>> compare) groupdn = "ldap:///cn=Read Replication >>>>>>>>> Agreements,cn=permissions,cn=pbac,$SUFFIX";) >>>>>>>>> >>>>>>>>> dn: cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX >>>>>>>>> changetype: add >>>>>>>>> objectClass: top >>>>>>>>> objectClass: groupofnames >>>>>>>>> objectClass: ipapermission >>>>>>>>> cn: Read Replication Agreements >>>>>>>>> ipapermissiontype: SYSTEM >>>>>>>>> >>>>>>>>> Note that you'll need to replace $SUFFIX with your base dn >>>>>>>>> (dc=example,dc=com). >>>>>>>>> >>>>>>>>> This is untested so YMMV. If you find that it works and is useful >>>>>>>>> please >>>>>>>>> let >>>>>>>>> us know, maybe we can add this for everyone to enjoy :-) >>>>>>>> >>>>>>>> Is it safe to allow anonymous access to read this attribute? I added >>>>>>>> the following ACI: >>>>>>>> >>>>>>>> dn: cn="$SUFFIX",cn=mapping tree,cn=config >>>>>>>> changetype: modify >>>>>>>> add: aci >>>>>>>> aci: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement))")(version >>>>>>>> 3.0; aci "permission:Read Replication Agreements"; allow (read, >>>>>>>> search, compare) groupdn = "ldap:///anyone";;) >>>>>>> >>>>>>> >>>>>>> It would be better to restrict the list of attributes to only those >>>>>>> needed >>>>>>> by the app e.g. (targetattr="foo || bar || baz || ...") >>>>>> >>>>>> OK, thanks. I had a look through the available data and I think these >>>>>> would be best: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> nsDS5ReplicaHost||nsds5replicaLastUpdateStatus||nsds5replicaLastUpdateStart||nsds5replicaLastUpdateEnd||nsds5replicaLastInitStart||nsds5replicaLastInitEnd||nsds5replicaUpdateInProgress >>>>>> >>>>>>>> And I can now get the replication status using an anonymous bind. I >>>>>>>> also modified the nagios perl script to make an anonymous bind and >>>>>>>> check the replication status - it's working OK. >>>>>>>> >>>>>>>> I don't know if the aci should be a standard feature, option to >>>>>>>> enable, or just to provide the ldif for anyone who wants it. >>>>>>> >>>>>>> >>>>>>> Sure. If you think it should be a standard feature, just file a >>>>>>> ticket. >>>>>> >>>>>> OK, will do, once I've figured out a few more things. I want to enable >>>>>> this for the PKI-CA directory too. I changed the dn to "dn: >>>>>> cn="o=ipaca",cn=mapping tree,cn=config" and added this to my server on >>>>>> port 7389. Using targetattr=*, everything works fine, but when I >>>>>> restrict it to the list of attributes above, I don't get any results. >>>>>> Is there another attribute I need to add? >>>>> >>>>> >>>>> Not sure why it would be any different for CA replication . . . >>>> >>>> Sorry, I wasn't clear. The difference isn't between CA and main, it's >>>> between restricting to (targetattr="nsDS5ReplicaHost||.....) and >>>> (targetattr=*). If I add the targetattr=* to the CA dirsrv, it works >>>> fine. Neither work when I restrict to particular attributes. >>> >>> >>> If you look at the access log it should tell you which attributes it is >>> searching for. >> >> Nothing shows up in the log. Does it show failed access attempts by >> default? > > Yes. The access log is buffered, so it may take a while for the request to > show up.
Ahh, OK thanks. The request is: [18/May/2012:13:59:02 -0400] conn=10516 fd=86 slot=86 connection from 192.168.1.202 to 192.168.1.201 [18/May/2012:13:59:02 -0400] conn=10516 op=0 BIND dn="" method=128 version=3 [18/May/2012:13:59:02 -0400] conn=10516 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="" [18/May/2012:13:59:02 -0400] conn=10516 op=1 SRCH base="cn=config" scope=2 filter="(objectClass=nsDS5ReplicationAgreement)" attrs=ALL [18/May/2012:13:59:02 -0400] conn=10516 op=1 RESULT err=0 tag=101 nentries=0 etime=0 [18/May/2012:13:59:02 -0400] conn=10516 op=-1 fd=86 closed - B1 If I search for 'ALL' attrs, but only have permission for some. Will I get no results? Or only those I have permission to read? _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
