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.
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
