Hi,

do you have the DS access logs from your servers from the time around the conflicting entry was created ?

Thanks,
Ludwig

On 03/17/2015 11:14 AM, Andreas Skarmutsos Lindh wrote:
Quick update: I think that I have solved it, by just deleting the entries holding nsuniqueid additional string. I went forward using a gui application for browsing LDAP structures. I guess a script for tackling this issue in a slightly more automated way could probably be of value to other people.

Thanks a lot for the help & support guys


- Andreas

On Mon, Mar 16, 2015 at 11:24 PM, Dan Lavu <d...@redhat.com <mailto:d...@redhat.com>> wrote:

    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,
    
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
    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 questions.

    Dan


    ------------------------------------------------------------------------
    *From: *"Jakub Hrozek" <jhro...@redhat.com
    <mailto:jhro...@redhat.com>>
    *To: *"Andreas Skarmutsos Lindh" <andr...@superblock.se
    <mailto:andr...@superblock.se>>
    *Cc: *freeipa-users@redhat.com <mailto:freeipa-users@redhat.com>,
    "Dan Lavu" <dl...@redhat.com <mailto: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 <mailto: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
    <http://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
    <http://domain.com>]]] [hbac_ctx_to_rules] (0x0020): Could not
    construct eval request
    > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com
    <http://domain.com>]]] [ipa_hbac_evaluate_rules] (0x0020): Could
    not construct HBAC rules
    > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com
    <http://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
    <http://domain.com>]]] [be_pam_handler_callback] (0x0100): Sending
    result [4][domain.com <http://domain.com>]
    > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com
    <http://domain.com>]]] [be_pam_handler_callback] (0x0100): Sent
    result [4][domain.com <http://domain.com>]
    > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com
    <http://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
    <http://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
    
Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com]
    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:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to