On Fri, May 18, 2012 at 1:52 PM, Rich Megginson <rmegg...@redhat.com> wrote:
> On 05/18/2012 11:46 AM, Dan Scott wrote:
>>
>> On Fri, May 18, 2012 at 12:38 PM, Rich Megginson<rmegg...@redhat.com>
>>  wrote:
>>>
>>> On 05/18/2012 10:31 AM, Dan Scott wrote:
>>>>
>>>> On Fri, May 18, 2012 at 12:21 PM, Rich Megginson<rmegg...@redhat.com>
>>>>  wrote:
>>>>>
>>>>> On 05/18/2012 10:06 AM, Dan Scott wrote:
>>>>>>
>>>>>> On Fri, May 18, 2012 at 10:29 AM, Rich Megginson<rmegg...@redhat.com>
>>>>>>  wrote:
>>>>>>>
>>>>>>> On 05/18/2012 08:13 AM, Dan Scott wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden<rcrit...@redhat.com>
>>>>>>>>  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
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to