On 01/23/2017 08:43 AM, Harald Dunkel wrote:
Hi Thierry,

On 01/20/17 14:17, thierry bordaz wrote:
I agree that it is looking like the conflict entry is the most up-to-date one.
To try to repair, it would help if you can search groups

cn=System: Read DNS Configuration,cn=permissions,cn=pbac,dc=example,dc=de
cn=System: Write DNS Configuration,cn=permissions,cn=pbac,dc=example,dc=de
cn=System: Add DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de
cn=System: Manage DNSSEC keys,cn=permissions,cn=pbac,dc=example,dc=de
cn=System: Manage DNSSEC metadata,cn=permissions,cn=pbac,dc=example,dc=de
cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de
cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de
cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de
cn=System: Read DNS Servers 
Configuration,cn=permissions,cn=pbac,dc=example,dc=de
cn=System: Read DNS Servers 
Configuration+nsuniqueid=109be363-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de

Hopefully the two last are identical, but the others may refer to  '
cn=System: Read DNS Servers 
Configuration+nsuniqueid=109be363-ccd911e6-a5b3d0c8-d8da17db' instead of the 
non conflict one.

They are not the same (see attachments):

--- /tmp/system_read_dns        2017-01-23 08:26:21.580128044 +0100
+++ /tmp/system_read_dns.nsuniqueid     2017-01-23 08:26:42.603217657 +0100
@@ -1,13 +1,13 @@
  # extended LDIF
  #
  # LDAPv3
-# base <cn=System: Read DNS Servers 
Configuration,cn=permissions,cn=pbac,dc=example,dc=de> with scope baseObject
+# base <cn=System: Read DNS Servers 
Configuration+nsuniqueid=109be363-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de>
 with scope baseObject
  # filter: (objectclass=*)
  # requesting: ALL
  #

-# System: Read DNS Servers Configuration, permissions, pbac, example.de
-dn: cn=System: Read DNS Servers 
Configuration,cn=permissions,cn=pbac,dc=example,dc=de
+# System: Read DNS Servers Configuration + 
109be363-ccd911e6-a5b3d0c8-d8da17db, permissions, pbac, example.de
+dn: cn=System: Read DNS Servers 
Configuration+nsuniqueid=109be363-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de
  ipaPermTargetFilter: (objectclass=idnsServerConfigObject)
  ipaPermRight: read
  ipaPermRight: compare
@@ -21,8 +21,7 @@
  objectClass: top
  objectClass: groupofnames
  objectClass: ipapermissionv2
-member: cn=DNS Administrators,cn=privileges,cn=pbac,dc=example,dc=de
-member: cn=DNS Servers,cn=privileges,cn=pbac,dc=example,dc=de
+member: cn=DNS 
Servers+nsuniqueid=109be317-ccd911e6-a5b3d0c8-d8da17db,cn=privileges,cn=pbac,dc=example,dc=de
  ipaPermDefaultAttr: idnsforwardpolicy
  ipaPermDefaultAttr: objectclass
  ipaPermDefaultAttr: idnsforwarders

We may try to fix groups (with conflict members).

thanks

Question: Would you agree its best to avoid swapping "valid" and
"nsuniqueid" records?
We need to get a clear status before trying to swap them.
For example in your attachment the valid entry is member of 'DNS Admin' while the conflict one is not. So possibly the valid entry is the one to keep.

Conflicts entry
dn: cn=DNS Servers,cn=privileges,cn=pbac,dc=example,dc=de

belong to all these groups
memberOf: cn=System: Read DNS Configuration,cn=permissions,cn=pbac,dc=example,dc=de memberOf: cn=System: Write DNS Configuration,cn=permissions,cn=pbac,dc=example,dc=de memberOf: cn=System: Add DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de memberOf: cn=System: Manage DNSSEC keys,cn=permissions,cn=pbac,dc=example,dc=de memberOf: cn=System: Manage DNSSEC metadata,cn=permissions,cn=pbac,dc=example,dc=de memberOf: cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de memberOf: cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de memberOf: cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de memberOf: cn=System: Read DNS Servers Configuration+nsuniqueid=109be363-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de

My initial thought was to check how it was member (which attribute it is using and if it is nested/direct membership). So then we may try to repair the "valid" entry, making it similarly member of those groups.

But this is looking to be complex job and no guaranty it will repair everything broken.

Do you have a way to restore from a state where there was no conflict ?

regards
theirry


Regards
Harri


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to