Re: [Freeipa-users] Providing minimal permissions to read replication status
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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Providing minimal permissions to read replication status
On 1 August 2013 09:36, Martin Kosek mko...@redhat.com wrote: 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 Reading the upstream documentation I'm wondering if it'd be sensible to include an additional ACI in replica-acis.ldif of: dn: $SUFFIX changetype: modify add: aci aci: (targetattr=dn nsDS5ReplConflict nsUniqureID)(targetfilter=(|(objectclass=nsTombstone)(nsDS5ReplConflict=*)))((version 3.0; aci conflict read access; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) From the upstream documentation here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Configuration_Command_and_File_Reference/index.html#Replication_Attributes_under_cnreplica_cnsuffixName_cnmapping_tree_cnconfig This would allow a user with Read Replication Agreements permission to be able to search for conflicts or tombstone records which would seem sane from a monitoring point of view... What do you think? Also just to confirm the only thing I need to do with ACIs like this is to update the ldif (delegation.ldif and replica-acis.ldif) with the new role/privilege/permission and acis in install/share for the new installs and add an appropriate entry (not quite ldif) in install/updates to update the default schema of those updating in future, given no new attributes - right? Cheers, James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Providing minimal permissions to read replication status
On 08/01/2013 03:56 PM, James Hogarth wrote: On 1 August 2013 09:36, Martin Kosek mko...@redhat.com wrote: 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 Reading the upstream documentation I'm wondering if it'd be sensible to include an additional ACI in replica-acis.ldif of: dn: $SUFFIX changetype: modify add: aci aci: (targetattr=dn nsDS5ReplConflict nsUniqureID)(targetfilter=(|(objectclass=nsTombstone)(nsDS5ReplConflict=*)))((version 3.0; aci conflict read access; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) From the upstream documentation here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Configuration_Command_and_File_Reference/index.html#Replication_Attributes_under_cnreplica_cnsuffixName_cnmapping_tree_cnconfig This would allow a user with Read Replication Agreements permission to be able to search for conflicts or tombstone records which would seem sane from a monitoring point of view... What do you think? I think it would make sense, but IMO it should have a separate permission named Read Replication Conflicts - this would also need the aci to be named permission:Read Replication Conflicts to let IPA couple it with the actual ACI. Also just to confirm the only thing I need to do with ACIs like this is to update the ldif (delegation.ldif and replica-acis.ldif) with the new role/privilege/permission and acis in install/share for the new installs and add an appropriate entry (not quite ldif) in install/updates to update the default schema of those updating in future, given no new attributes - right? That's right (you also need to remove the inappropriate ACI) You also need to make sure that the appropriate privilege has these new permissions as members - I tried to capture these steps in the upstream ticket. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Providing minimal permissions to read replication status
James Hogarth wrote: On 1 August 2013 09:36, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: 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 Reading the upstream documentation I'm wondering if it'd be sensible to include an additional ACI in replica-acis.ldif of: dn: $SUFFIX changetype: modify add: aci aci: (targetattr=dn nsDS5ReplConflict nsUniqureID)(targetfilter=(|(objectclass=nsTombstone)(nsDS5ReplConflict=*)))((version 3.0; aci conflict read access; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) From the upstream documentation here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Configuration_Command_and_File_Reference/index.html#Replication_Attributes_under_cnreplica_cnsuffixName_cnmapping_tree_cnconfig This would allow a user with Read Replication Agreements permission to be able to search for conflicts or tombstone records which would seem sane from a monitoring point of view... What do you think? I think this would be a separate issue. Being able to find the conflicting issues leads directly to the question what do I do with them? That is ticket https://fedorahosted.org/freeipa/ticket/1025 Also just to confirm the only thing I need to do with ACIs like this is to update the ldif (delegation.ldif and replica-acis.ldif) with the new role/privilege/permission and acis in install/share for the new installs and add an appropriate entry (not quite ldif) in install/updates to update the default schema of those updating in future, given no new attributes - right? You'll need to create a .update file in install/updates to modify an existing installation. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Providing minimal permissions to read replication status
On 1 August 2013 15:55, Rob Crittenden rcrit...@redhat.com wrote: James Hogarth wrote: On 1 August 2013 09:36, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: 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=** nsDSWindowsReplicationAgreemen**t)(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/3829https://fedorahosted.org/freeipa/ticket/3829 Reading the upstream documentation I'm wondering if it'd be sensible to include an additional ACI in replica-acis.ldif of: dn: $SUFFIX changetype: modify add: aci aci: (targetattr=dn nsDS5ReplConflict nsUniqureID)(targetfilter=(|(**objectclass=nsTombstone)(** nsDS5ReplConflict=*)))((**version 3.0; aci conflict read access; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=** pbac,$SUFFIX;) From the upstream documentation here: https://access.redhat.com/**site/documentation/en-US/Red_** Hat_Directory_Server/9.0/html-**single/Configuration_Command_** and_File_Reference/index.html#**Replication_Attributes_under_** cnreplica_cnsuffixName_**cnmapping_tree_cnconfighttps://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Configuration_Command_and_File_Reference/index.html#Replication_Attributes_under_cnreplica_cnsuffixName_cnmapping_tree_cnconfig This would allow a user with Read Replication Agreements permission to be able to search for conflicts or tombstone records which would seem sane from a monitoring point of view... What do you think? I think this would be a separate issue. Being able to find the conflicting issues leads directly to the question what do I do with them? That is ticket https://fedorahosted.org/**freeipa/ticket/1025https://fedorahosted.org/freeipa/ticket/1025 Thanks Rob - I think it worthwhile adding the permissions in place to at least find them as a 'quick win' as it were ... What to do after that is an interesting question and would probably take a fair chuck of work to make it nicely visible plus show ways to resolve it. Also just to confirm the only thing I need to do with ACIs like this is to update the ldif (delegation.ldif and replica-acis.ldif) with the new role/privilege/permission and acis in install/share for the new installs and add an appropriate entry (not quite ldif) in install/updates to update the default schema of those updating in future, given no new attributes - right? You'll need to create a .update file in install/updates to modify an existing installation. That's great - I had a look through the README in there and looking at other similar bits appears to be fairly simple. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Providing minimal permissions to read replication status
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. 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. 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? 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? Cheers, James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
