I was helping a friend out with his environment that was experiencing the same 
issue. CC'ing him as well. 

Between his ipa servers, the conflicted values were the same just time stamp 
that created the conflict? (I'm still not sure what caused the conflict in the 
first place). So what we did to fix the issue was to modify the entries and 
remove the conflict. You can follow this guide, 
 and with a simple script we were able to clean up the conflicts. 

Then SSSD started working again as soon as these conflicts were cleaned up, 
just make sure the values are the same between both servers otherwise you may 
be updating the environment with old data. Let me know if you have specific 


----- Original Message -----

From: "Jakub Hrozek" <jhro...@redhat.com> 
To: "Andreas Skarmutsos Lindh" <andr...@superblock.se> 
Cc: freeipa-users@redhat.com, "Dan Lavu" <dl...@redhat.com> 
Sent: Monday, March 16, 2015 5:37:16 PM 
Subject: Re: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA 

> On 16 Mar 2015, at 22:03, Andreas Skarmutsos Lindh <andr...@superblock.se> 
> wrote: 
> Hi everyone, 
> After upgrading (using rpm, yum upgrade) I can no longer login to my machines 
> using ssh. Before the upgrade everything was working fine. 
> Some loose facts: 
> - I'm installing IPA packages from the RHEL repositories onto RHEL systems, 
> so I'm not sure if this is the right mailing list to ask for assistance 
> - I have a basic setup of IPA with minimum rules (deleted HBAC rules to 
> single that out), using SSSD+PAM. 
> - Both other machines that are upgraded to a more recent version of sssd and 
> it's fellow packages and servers which was not yum upgraded are affected by 
> the issue, thus, everything seems to point at IPA. 
> - I'm able to obtain a kerberos ticket via kinit 
> - Running the following package version: ipa-server-4.1.0-18.el7.x86_64 
> SSH returns (adding -vvv hardly tells me anything useful): 
> Connection closed by UNKNOWN 
> I think that I have boiled down the issue to the following.. 
> Both clients with upgraded sssd (1.12.2-58) and non upgraded clients 
> (1.11.2-65) give me the following output in sssd_<domain>.log: 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_eval_user_element] 
> (0x0080): Parse error on [cn=Modify PassSync Managers 
> Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com]
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_ctx_to_rules] 
> (0x0020): Could not construct eval request 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [ipa_hbac_evaluate_rules] 
> (0x0020): Could not construct HBAC rules 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] 
> (0x0100): Backend returned: (3, 4, <NULL>) [Internal Error (System error)] 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] 
> (0x0100): Sending result [4][domain.com] 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] 
> (0x0100): Sent result [4][domain.com] 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] 
> (0x2000): Trace: sh[0x7f5711099220], connected[1], ops[(nil)], 
> ldap[0x7f571108d0e0] 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] 
> (0x2000): Trace: ldap_result found nothing! 

This is a combination of a broken replication on the server side and too strict 
SSSD processing which can't handle unexpected entries. The broken replication 
has yielded entries like: 
cn=Modify PassSync Managers 
note the nsUniqueID. As I learned today, entries with nsUniqueID in the RDN are 
relicts of broken replication. 

Dan Lavu (CC) has helped another setup with the same symtoms recently, maybe he 
can help here as well? 

The SSSD should just skip malformed entries if no DENY rules are used. That is 
tracked by SSSD ticket #2603. I have local patches for that one and I'll send 
them out to the list tomorrow. 

> I'm happy to attach more logs if needed. 
> I would very much like to avoid rolling back to an older IPA version by 
> reinstalling everything from scratch. 
> Any and all help would be very much appreciated. 
> Thanks in advance, 
> Andreas 
> -- 
> 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 

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to