[Freeipa-users] Providing minimal permissions to read replication status

[Martin Kosek]

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