<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
do you have the DS access logs from your servers from the time
around the conflicting entry was created ?<br>
<br>
Thanks,<br>
Ludwig<br>
<br>
<div class="moz-cite-prefix">On 03/17/2015 11:14 AM, Andreas
Skarmutsos Lindh wrote:<br>
</div>
<blockquote
cite="mid:CABpWgAmcJhZ999G4PqvDi5rqhG7Bta49JfZ2GpKo6bBugeC_2A@mail.gmail.com"
type="cite">
<div dir="ltr">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.
<div>I guess a script for tackling this issue in a slightly more
automated way could probably be of value to other people.</div>
<div><br>
</div>
<div>Thanks a lot for the help & support guys</div>
<div><br>
</div>
<div><br>
</div>
<div>- Andreas</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Mar 16, 2015 at 11:24 PM, Dan
Lavu <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:dan@redhat.com" target="_blank">dan@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div
style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000">I
was helping a friend out with his environment that was
experiencing the same issue. CC'ing him as well. <br>
<br>
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, <a moz-do-not-send="true"
href="https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html"
target="_blank">https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html</a>
and with a simple script we were able to clean up the
conflicts. <br>
<br>
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. <br>
<br>
Dan<br>
<br>
<br>
<hr>
<div
style="color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From:
</b>"Jakub Hrozek" <<a moz-do-not-send="true"
href="mailto:jhrozek@redhat.com" target="_blank">jhrozek@redhat.com</a>><br>
<b>To: </b>"Andreas Skarmutsos Lindh" <<a
moz-do-not-send="true"
href="mailto:andreas@superblock.se" target="_blank">andreas@superblock.se</a>><br>
<b>Cc: </b><a moz-do-not-send="true"
href="mailto:freeipa-users@redhat.com"
target="_blank">freeipa-users@redhat.com</a>, "Dan
Lavu" <<a moz-do-not-send="true"
href="mailto:dlavu@redhat.com" target="_blank">dlavu@redhat.com</a>><br>
<b>Sent: </b>Monday, March 16, 2015 5:37:16 PM<br>
<b>Subject: </b>Re: [Freeipa-users] 4.1.0: Logon
issue after upgrading IPA
<div>
<div class="h5"><br>
<br>
<br>
> On 16 Mar 2015, at 22:03, Andreas Skarmutsos
Lindh <<a moz-do-not-send="true"
href="mailto:andreas@superblock.se"
target="_blank">andreas@superblock.se</a>>
wrote:<br>
> <br>
> Hi everyone,<br>
> <br>
> After upgrading (using rpm, yum upgrade) I
can no longer login to my machines using ssh.
Before the upgrade everything was working fine.<br>
> <br>
> Some loose facts:<br>
> - 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<br>
> - I have a basic setup of IPA with minimum
rules (deleted HBAC rules to single that out),
using SSSD+PAM.<br>
> - 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.<br>
> - I'm able to obtain a kerberos ticket via
kinit<br>
> - Running the following package version:
ipa-server-4.1.0-18.el7.x86_64<br>
> <br>
> SSH returns (adding -vvv hardly tells me
anything useful):<br>
> Connection closed by UNKNOWN<br>
> <br>
> I think that I have boiled down the issue to
the following..<br>
> 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:<br>
> (Mon Mar 16 14:12:17 2015) [sssd[be[<a
moz-do-not-send="true" href="http://domain.com"
target="_blank">domain.com</a>]]]
[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]<br>
> (Mon Mar 16 14:12:17 2015) [sssd[be[<a
moz-do-not-send="true" href="http://domain.com"
target="_blank">domain.com</a>]]]
[hbac_ctx_to_rules] (0x0020): Could not construct
eval request<br>
> (Mon Mar 16 14:12:17 2015) [sssd[be[<a
moz-do-not-send="true" href="http://domain.com"
target="_blank">domain.com</a>]]]
[ipa_hbac_evaluate_rules] (0x0020): Could not
construct HBAC rules<br>
> (Mon Mar 16 14:12:17 2015) [sssd[be[<a
moz-do-not-send="true" href="http://domain.com"
target="_blank">domain.com</a>]]]
[be_pam_handler_callback] (0x0100): Backend
returned: (3, 4, <NULL>) [Internal Error
(System error)]<br>
> (Mon Mar 16 14:12:17 2015) [sssd[be[<a
moz-do-not-send="true" href="http://domain.com"
target="_blank">domain.com</a>]]]
[be_pam_handler_callback] (0x0100): Sending result
[4][<a moz-do-not-send="true"
href="http://domain.com" target="_blank">domain.com</a>]<br>
> (Mon Mar 16 14:12:17 2015) [sssd[be[<a
moz-do-not-send="true" href="http://domain.com"
target="_blank">domain.com</a>]]]
[be_pam_handler_callback] (0x0100): Sent result
[4][<a moz-do-not-send="true"
href="http://domain.com" target="_blank">domain.com</a>]<br>
> (Mon Mar 16 14:12:17 2015) [sssd[be[<a
moz-do-not-send="true" href="http://domain.com"
target="_blank">domain.com</a>]]]
[sdap_process_result] (0x2000): Trace:
sh[0x7f5711099220], connected[1], ops[(nil)],
ldap[0x7f571108d0e0]<br>
> (Mon Mar 16 14:12:17 2015) [sssd[be[<a
moz-do-not-send="true" href="http://domain.com"
target="_blank">domain.com</a>]]]
[sdap_process_result] (0x2000): Trace: ldap_result
found nothing!<br>
> <br>
<br>
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:<br>
cn=Modify PassSync Managers
Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com]<br>
note the nsUniqueID. As I learned today, entries
with nsUniqueID in the RDN are relicts of broken
replication.<br>
<br>
Dan Lavu (CC) has helped another setup with the
same symtoms recently, maybe he can help here as
well?<br>
<br>
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.<br>
<br>
> I'm happy to attach more logs if needed.<br>
> I would very much like to avoid rolling back
to an older IPA version by reinstalling everything
from scratch.<br>
> Any and all help would be very much
appreciated.<br>
> <br>
> Thanks in advance,<br>
> Andreas<br>
> -- <br>
> Manage your subscription for the
Freeipa-users mailing list:<br>
> <a moz-do-not-send="true"
href="https://www.redhat.com/mailman/listinfo/freeipa-users"
target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
> Go to <a moz-do-not-send="true"
href="http://freeipa.org" target="_blank">http://freeipa.org</a>
for more info on the project<br>
<br>
</div>
</div>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>