[Freeipa-users] Duplicate objects after 4.1 ipa-server upgrade

[Andrew Krause]

I upgraded 4 at the same time actually.  It makes sense why the objects were created and I do understand how replication conflicts are handled.  I just wanted to be absolutely certain that it was ok to delete these objects since it seems pointless to ever keep them around.  Has there been any talk of a mechanism to just handle this on a regular basis (not that this situation should happen regularly)?


> On Nov 3, 2015, at 1:42 AM, Martin Kosek <mkosek at redhat.com> wrote:
> 
> On 11/03/2015 12:05 AM, Andrew Krause wrote:
>> After upgrading to 4.1 I have duplicated permission objects in my directory with names including nsuniqueid.  Is it safe to delete all of these objects?  Somehow this is only causing an issue for a specific user hitting a specific HBAC policy. 
>> 
>> (Mon Nov  2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_eval_user_element] (0x0080): Parse error on [cn=Read PassSync Managers Configuration+nsuniqueid=4ae3220f-4d2b11e5-a06ffcc2-215714a9 …………..
>> (Mon Nov  2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_ctx_to_rules] (0x0020): Could not construct eval request
>> (Mon Nov  2 14:29:23 2015) [sssd[be[blue-shift.com]]] [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules
>> 
>> 
>> This is causing authentication to fail for the user in question, and I would like to get rid of these useless objects if they are no longer necessary.  
> 
> It looks like you had some replication problem in your network, or maybe
> upgraded 2 FreeIPA instances at the same time, so they both generated
> conflicting permissions?
> 
> In any case, it should be case to delete the permissions with nsuniqueid,
> FreeIPA should generate the managed permissions from scratch anyway, if they
> are missing and upgrade is run again.
> 
> More info on replication conflicts here:
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#Solving_Common_Replication_Conflicts-Solving_Naming_Conflicts
> 
> Martin