On 07/31/2013 01:36 PM, James Hogarth wrote: > Hi, > > We're looking to add monitoring to our IPA replicas and want to provide a > user with the minimum possible permissions to do so. > > Allowing the user to have the Replication Administrators role works but for > monitoring the ability to add/modify/remove is overkill by a long shot.
Agreed. > > There's no existing permission for Read Replication Agreements - only add, > remove and modify. > > I've tried to use ipa perimssion-add with --filter to allow access to > objectClass=nsds5replicationagreement but checking the status via: > > ldapsearch -Y GSSAPI -h c6test2.c6ipa.local -b cn=config > '(objectclass=nsds5replicationagreement)' > > Does not show anything unless the account being tested with gets > replication administrator privileges... > > I've tried using subtree as well but the ipa command errors that the base > of cn=config is not $SUFFIX ... and out of scope. Yes, this won't work with FreeIPA permission-* commands by design as they operate purely on the FreeIPA suffix. > > What am I missing to set this up - or is this not possible with the > role/privilege/permission mechanism within IPA? I can see how the > replication administration permissions are added in replica-acis.ldif but > I'm concerned that if I manually add an ACI via pure LDIF commands it will > cause issues with future IPA upgrades due to schema differences - so was > hoping to remain within the IPA command side of things... > > 1) Is this even possible with the ipa command? No - as above. > 2) If I use ldapmodify to add a new permission by hand via ldif for "Read > Replication Agreements" will this likely break on IPA upgrades in future? There may be upgrade issue e.g. if you name the new permission "Read Replication Agreements" as this will be the name that FreeIPA project will use in a future to name this permission - as it makes sense that there is a permission like that. I see 2 solutions for your issue: 1) Handle the ACIs and permission yourselves, I tested that an ACI like that works: # ldapmodify -h localhost -D "cn=Directory Manager" -x -w kokos123 dn: cn="$SUFFIX",cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectClass=nsMappingTree))")(version 3.0; acl "permission:Read Replication Agreements"; allow (read, search, compare) groupdn = "ldap:///$PERMISSION_OR_GROUP_DN";) It should be pretty safe to add ACI like this one, especially because cn=config tree is not replicated and your changes are only local. 2) Work with freeipa-devel list to add this permission to FreeIPA out of the box - this is of course the preferred option by us :-) The patch for this would do basically this: - remove the following aci: (targetattr != aci)(version 3.0; aci "replica admins read access"; allow (read, search, compare) groupdn = "ldap:///cn=Modify Replication Agreements,cn=permissions,cn=pbac,$SUFFIX";) ... from installer and from LDAP as it is too general - add new permission ACI like this: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectClass=nsMappingTree))")(version 3.0; acl "permission:Read Replication Agreements"; allow (read, search, compare) groupdn = "ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX";) - make sure that "Replication Administrators" privilege has it assigned. I created an upstream ticket to track this effort: https://fedorahosted.org/freeipa/ticket/3829 Martin _______________________________________________ Freeipa-users mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-users