<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 09/09/2015 03:39 AM, Martin Basti
      wrote:<br>
    </div>
    <blockquote cite="mid:55EFFE67.4060406@redhat.com" type="cite">
      <br>
      <br>
      On 09/09/2015 10:50 AM, Andreas Calminder wrote:
      <br>
      <blockquote type="cite">Forgot to write that deleting users in
        active directory not migrated with the migrate-ds command works
        fine, it's only migrated users present in the ad that breaks the
        winsync agreement on deletion.
        <br>
        <br>
        On 09/09/2015 10:35 AM, Andreas Calminder wrote:
        <br>
        <blockquote type="cite">Hi,
          <br>
          I've asked in #freeipa on freenode but to no avail, figured
          I'll ask here as well, since I think I've actually hit a bug
          or (quite) possibly I've done something moronic
          configuration/migration -wise.
          <br>
          <br>
          I've got an existing FreeIPA 3.0.0 environment running with a
          fully functioning winsync agreement and passsync service with
          the windows environments active directory, I'm trying to
          migrate the 3.0.0 environments users into a freshly installed
          4.1 (rhel7) environment, after migration I setup a winsync
          agreement and make it bi-directional  (one-way sync from
          windows) everything seems to be working alright until I delete
          a migrated user from the Active Directory, after the winsync
          picks up on the change it'll break and suggests a
          re-initialize. After the re-initialization the agreement seems
          to be fine, however the deleted user are still present in the
          ipa 4.1 environment and cannot be deleted. The webgui and ipa
          cli says: ipauser1: user not found. ipa user-find ipauser1
          finds the user and it's visible in the ui.
          <br>
          <br>
          Anyone had the same problem or anything similar or any
          pointers on where to start looking?
          <br>
          <br>
          Regards,
          <br>
          Andreas
          <br>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
      Hello, this might be a replication conflict.
      <br>
      <br>
      Can you list that user via ldapsearch to check if this is
      replication conflict?
      <br>
      <br>
<a class="moz-txt-link-freetext" href="https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html">https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html</a>
      <br>
      <br>
    </blockquote>
    <font size="+1">Use the latest docs, just in case they are more
      accurate:
<a class="moz-txt-link-freetext" href="https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html">https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html</a></font><br>
  </body>
</html>