<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Good question. Are you sure that the roles are assigned to the
      user correctly?</p>
    <p>Because today when I tested this, users <i>with</i> roles
      assigned got their auxiliary object classes right. Only users
      without roles were left without the OCs.</p>
    <pre class="moz-signature" cols="72">Pavol Mederly
Software developer
evolveum.com
</pre>
    <div class="moz-cite-prefix">On 28.08.2018 17:57, Andrew Morgan
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:alpine.DEB.2.11.1808280856020.839@shell.onid.oregonstate.edu">Why
      is:
      <br>
      <br>
      <auxiliaryObjectClassMappings>
      <br>
          <tolerant>true</tolerant>
      <br>
      </auxiliaryObjectClassMappings>
      <br>
      <br>
      necessary?
      <br>
      <br>
      I have the roles assigned that will induce the objectclasses and
      attributes that are present on the existing accounts, but the
      synchronization during linking seems to be ignoring the
      inducements that come from the roles.  Bug?
      <br>
      <br>
      Thanks,
      <br>
      <br>
      Andy Morgan
      <br>
      Systems Administrator, Identity & Access Management
      <br>
      Information Services | Oregon State University
      <br>
      541-737-8877 | is.oregonstate.edu
      <br>
      <br>
      On Tue, 28 Aug 2018, Pavol Mederly wrote:
      <br>
      <br>
      <blockquote type="cite">Andy,
        <br>
        <br>
        returning to your situation: I have replicated it in my TIER
        setup and got the same behavior as you did.
        <br>
        <br>
        I suggest the following:
        <br>
        <br>
         1.  If you just want to create shadows without linking them to
        their respective owners (users), then dryRun import task is the
        way to go. It will evaluate situation of each shadow (unmatched,
        unlinked, linked) and update its status. However, it will not
        apply the synchronization reaction(s), so e.g. even if you
        define "link" action for unlinked shadows, the dry import will
        not execute it. The shadow will not be linked with their
        potential owner.
        <br>
         2.  If you want to create shadows and to link them (and not
        lose auxiliary object class information), then use Brad
        suggestion. It works in my case (with roles inducing auxiliary
        OCs) and I think it will also in yours.
        <br>
        <br>
        I have tried e.g. setting
        <synchronize>false</synchronize> on the unlinked
        reaction, i.e.
        <br>
        <br>
                       <reaction>
        <br>
                           <situation>unlinked</situation>
        <br>
                           <synchronize>false</synchronize>
        <br>
                           <action>
        <br>
                              
<handlerUri><a class="moz-txt-link-freetext" href="http://midpoint.evolveum.com/xml/ns/public/model/action-3#link">http://midpoint.evolveum.com/xml/ns/public/model/action-3#link</a></handlerUri><br>
                           </action>
        <br>
                       </reaction>
        <br>
        <br>
        but it does not work: synchronize=false causes the link action
        to be skipped as well.
        <br>
        <br>
        Maybe we could implement a reaction like "link but do not
        synchronize" but I am not sure how complex would that be.
        <br>
        <br>
        Thinking about assignment policy enforcement, it should not make
        a difference here. It deals with the mere existence of
        projections (accounts), not with their synchronization.
        <br>
        <br>
        Best regards,
        <br>
        <br>
        Pavol Mederly
        <br>
        Software developer
        <br>
        evolveum.com
        <br>
        <br>
        <br>
        On 28.08.2018 8:44, Pavol Mederly wrote:
        <br>
        <br>
        ...though, I think you need those accounts to be linked to the
        users. Dry run will probably not do that.
        <br>
        <br>
        Pavol Mederly
        <br>
        Software developer
        <br>
        evolveum.com
        <br>
        <br>
        <br>
        On 28.08.2018 8:33, Pavol Mederly wrote:
        <br>
        <br>
        Andy,
        <br>
        <br>
        just a quick shot as I have to go away just now:
        <br>
        <br>
        SECOND METHOD TRIED:
        <br>
        <br>
        Instead of importing accounts, I tried assigning the roles to
        the midPoint users to induce the correct resources,
        objectclasses, and roles.  That actually worked great, but I
        don't know how to get 80,000 shadows into midPoint's repository
        without importing.  I can get 20 shadows created at a time by
        browsing the Accounts in the LDAP resource, but I don't know how
        to get all of them.  If midPoint doesn't have a shadow when I
        assign the roles, it tries (and fails) to create a new account. 
        Then, it makes a bunch of modifications to the existing account
        because it thinks it has changes to process.  No good.
        <br>
        A quick method of account creation is to run import from that
        resource with dryRun option set. It should do nothing except for
        creating the shadows. :)
        <br>
        <br>
        Pavol Mederly
        <br>
        Software developer
        <br>
        evolveum.com
        <br>
        <br>
        <br>
        On 25.08.2018 2:42, Andrew Morgan wrote:
        <br>
        I'm looking for advice on standing up midPoint with resources
        that already have accounts present.  I have 1 resource with
        inbound mappings (a database table) and 2 resources with
        outbound mappings (AD and LDAP). There are approximately 80,000
        accounts in AD and LDAP.
        <br>
        <br>
        <br>
        FIRST METHOD TRIED:
        <br>
        <br>
        I attempted to import accounts from LDAP in order to link to
        existing midPoint users and then assign the appropriate roles to
        match the existing state of the LDAP account.
        <br>
        <br>
        When I import an LDAP account, it is linked to the correct
        midPoint user. However, midPoint strips off the extra
        objectclasses and attributes that are defined in my roles (not
        in the LDAP resource).  I have tried setting the
        assignmentPolicyEnforcement to "positive" or "none", but it
        still happens.  No good.
        <br>
        <br>
        <br>
        SECOND METHOD TRIED:
        <br>
        <br>
        Instead of importing accounts, I tried assigning the roles to
        the midPoint users to induce the correct resources,
        objectclasses, and roles.  That actually worked great, but I
        don't know how to get 80,000 shadows into midPoint's repository
        without importing.  I can get 20 shadows created at a time by
        browsing the Accounts in the LDAP resource, but I don't know how
        to get all of them.  If midPoint doesn't have a shadow when I
        assign the roles, it tries (and fails) to create a new account. 
        Then, it makes a bunch of modifications to the existing account
        because it thinks it has changes to process.  No good.
        <br>
        <br>
        <br>
        NEXT???:
        <br>
        <br>
        Maybe I can define the LDAP resource with no outbound mappings,
        import all the accounts in order to link them to users, assign
        the correct roles, and then update the LDAP resource to have the
        outbound mappings...
        <br>
        <br>
        <br>
        Is there a wiki page that covers this?  I'm running out of
        ideas...  Help!
        <br>
        <br>
        Thanks,
        <br>
        <br>
        Andy Morgan
        <br>
        Systems Administrator, Identity & Access Management
        <br>
        Information Services | Oregon State University
        <br>
        541-737-8877 | is.oregonstate.edu
        <br>
        _______________________________________________
        <br>
        midPoint mailing list
        <br>
<a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a><a class="moz-txt-link-rfc2396E" href="mailto:midPoint@lists.evolveum.com"><mailto:midPoint@lists.evolveum.com></a>
        <br>
        <a class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
        <br>
        <br>
        <br>
        <br>
        <br>
        <br>
        _______________________________________________
        <br>
        midPoint mailing list
        <br>
<a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a><a class="moz-txt-link-rfc2396E" href="mailto:midPoint@lists.evolveum.com"><mailto:midPoint@lists.evolveum.com></a>
        <br>
        <a class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
        <br>
        <br>
        <br>
        <br>
      </blockquote>
      _______________________________________________
      <br>
      midPoint mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
      <br>
      <a class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
      <br>
    </blockquote>
    <br>
  </body>
</html>