<div dir="ltr">Thanks for the update,<div><br></div><div>Not sure if I mentioned but it also happens to user accounts that are also protected, not just with groups that have sAMAccountName.</div><div><br></div><div>For now, I am going to just un-protect the OUs that have "user" accounts in them so that they are created in midpoint. I myself am not too worried about the groups with sAMAccountName. I checked all our groups and I would not imagine a username being provisioned that would match one of them.</div><div><br></div><div>JASON</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 29, 2015 at 12:52 PM, Pavol Mederly <span dir="ltr"><<a href="mailto:mederly@evolveum.com" target="_blank">mederly@evolveum.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Hello,<br>
      <br>
      as (another) temporary measure I've implemented a check that
      reports ObjectAlreadyExistException in case there are two
      successive attempts to execute the same operation on a resource
      resulting in AlreadyExistsException. (This means that the iterator
      was not applied.)<br>
      <br>
      So, the operation should now fail more cleanly - with a partial
      error of ObjectAlreadyExistException instead of fatal error of
      IllegalStateException - and much, much faster, not iterating 20,
      30, 200, 1000 times, only 2 times.<br>
      <br>
      However, this still does not address the original issue, which is
      a bit harder to solve.<span class="HOEnZb"><font color="#888888"><br>
      <br>
      Pavol<br>
      <br>
    </font></span></div><div><div class="h5">
    <blockquote type="cite">
      
      <div>Anton, Jason,<br>
        <br>
        I'm going to look at this problem.<br>
        <br>
        In the meanwhile: yes, I recently lowered the "safety limit" of
        maximum model "clicks" from 1000 to 200 and made it configurable
        in the system configuration object, like this:<br>
        <br>
        <tt><internals></tt><tt><br>
        </tt><tt>     
          <enableExperimentalCode>true</enableExperimentalCode></tt><tt><br>
        </tt><tt>      <maxModelClicks>20</maxModelClicks></tt><tt><br>
        </tt><tt></internals></tt><tt><br>
        </tt><br>
        This was some days ago in 3.2-SNAPSHOT version.<br>
        <br>
        Actually, the limit was meant to be (practically) never used.
        Unfortunately, it seems that it is applied quite often, on
        "object already exists" occasions, when there are some
        configuration problems. I'm going to have a look at this as
        well.<br>
        <br>
        Best regards,<br>
        Pavol<br>
        <br>
      </div>
      <blockquote type="cite">
        <div dir="ltr">Yeah I tested on 3.2devel, I just tested again
          with not so good news,
          <div><br>
          </div>
          <div>I removed the protection from the Builtin object,
            modified the "Users" group so that a shadow is created in
            midPoint, verified shadow exists before proceeding,</div>
          <div><br>
          </div>
          <div>I added back my user from previous,</div>
          <div><br>
          </div>
          <div>Unfortunately this did not solve the problem, I still get
            object already exist with no attempt to add an iteration
            token</div>
          <div><br>
          </div>
          <div>
            <div><br>
            </div>
            <div>JASON</div>
          </div>
        </div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Wed, Jul 22, 2015 at 9:04 AM, <span dir="ltr"><<a href="mailto:midpoint@mybtinternet.com" target="_blank">midpoint@mybtinternet.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Yes, looks like the same issue; mine stops at
                1000 (3.1.1) - I guess you're running a different
                version or may have changed the limit. <br>
                <br>
                In my case, I'm managing just part of the AD; e.g. to
                avoid breaking real accounts for parallel development.
                If this was not the case, <br>
                the account import would have brought in the users
                account from AD and iteration may have worked. That
                container however is <br>
                excluded, hence midPoint thinks it should be valid ... <br>
                <br>
                Regards, <br>
                  Anton<br>
                <br>
              </span>
              <blockquote style="margin-right:0px;margin-left:15px"><span>----Original message----<br>
                  From : <a href="mailto:jeverling@bshp.edu" target="_blank">jeverling@bshp.edu</a><br>
                  Date : 22/07/2015 - 14:36 (BST)<br>
                  To : <a href="mailto:midpoint@mybtinternet.com" target="_blank">midpoint@mybtinternet.com</a>, <a href="mailto:midpoint@lists.evolveum.com" target="_blank">midpoint@lists.evolveum.com</a><br>
                  Subject : Re: [midPoint] Protected / excluded accounts<br>
                  <br>
                </span>
                <div>
                  <div>
                    <div dir="ltr">I was curious to try this myself
                      being on AD and I have excluded/protected entire
                      OUs,
                      <div><br>
                      </div>
                      <div>I added a new person to my CSV resource with
                        first name Us and lastname Ers and yes, you are
                        correct, provisioning fails. I would have
                        figured that it should iterate to Users1 as that
                        is what it does for the other accounts.</div>
                      <div><br>
                      </div>
                      <div>I don't think mine attempted 1000 because in
                        the logs it doesn't seem to and it only took a
                        minute or so to error out,</div>
                      <div><br>
                      </div>
                      <div>
                        <div>2015-07-22 08:30:10,273 []
                          [midPointScheduler_Worker-6] ERROR
                          (com.evolveum.midpoint.provisioning.impl.ProvisioningServiceImpl):
                          Couldn't add object. Object already exist:
                          Object already exists on the resource:
                          org.identityconnectors.framework.common.exceptions.AlreadyExistsException(The

                          object already exists.</div>
                        <div>: when creating <a>LDAP://dc1.test.local/cn=Us</a>
                          Ers,OU=DPN,OU=SHP
                          Students,DC=TEST,DC=LOCAL)->org.identityconnectors.framework.impl.api.remote.RemoteWrappedException(The

                          object already exists.</div>
                        <div>: when creating <a>LDAP://dc1.test.local/cn=Us</a>
                          Ers,OU=DPN,OU=SHP Students,DC=TEST,DC=LOCAL)</div>
                        <div>com.evolveum.midpoint.util.exception.ObjectAlreadyExistsException:

                          Object already exists on the resource:
                          org.identityconnectors.framework.common.exceptions.AlreadyExistsException(The

                          object already exists.</div>
                        <div>: when creating <a>LDAP://dc1.test.local/cn=Us</a>
                          Ers,OU=DPN,OU=SHP
                          Students,DC=TEST,DC=LOCAL)->org.identityconnectors.framework.impl.api.remote.RemoteWrappedException(The

                          object already exists.</div>
                        <div>: when creating <a>LDAP://dc1.test.local/cn=Us</a>
                          Ers,OU=DPN,OU=SHP Students,DC=TEST,DC=LOCAL)</div>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div>
                        <div>2015-07-22 08:30:15,532 []
                          [midPointScheduler_Worker-6] ERROR
                          (com.evolveum.midpoint.model.impl.sync.LiveSyncTaskHandler):
                          Live Sync: Internal Error:</div>
                        <div>com.evolveum.midpoint.util.exception.SystemException:

                          Synchronization error:
                          java.lang.IllegalStateException: Model
                          operation took too many clicks (limit is 200).
                          Is there a cycle?</div>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div>JASON</div>
                    </div>
                    <div class="gmail_extra"><br>
                      <div class="gmail_quote">On Wed, Jul 22, 2015 at
                        5:56 AM, <span dir="ltr"><<a href="mailto:midpoint@mybtinternet.com" target="_blank">midpoint@mybtinternet.com</a>></span>
                        wrote:<br>
                        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Guys,<br>
                          <br>
                            I'm looking for a way to exclude certain
                          account names for use on any resource; this
                          could include:<br>
                          <span>    </span>- operating system accounts<br>
                          <span>    </span>- service accounts<br>
                          <span>    </span>- sensitive accounts<br>
                          <span>    </span>- account names generated
                          that may be offensive words etc<br>
                          <br>
                            I have noted the protected account feature,
                          however this seems to require definition on
                          every resource<br>
                            which can be tedious and prone to error on
                          large numbers of resources. Also, as this maps
                          to the<br>
                            designated repository name attribute, it is
                          not very flexible; e.g. if you take AD
                          built-in group Users.<br>
                            While this is a group, it still has a
                          sAMAccountName of Users. Setting a protection
                          of "Users" does not<br>
                            exclude an attempt to provision an account
                          with sAMAccountName of users.<br>
                          <br>
                            What happens in the above example, midPoint
                          attempts to add the account to AD, this fails
                          with "Already<br>
                            exists". This does not seem to trigger the
                          need for iteration. This is attempted a 1000
                          times until some<br>
                            limit in midPoint then aborts the
                          transaction. Needless to say, performance
                          deteriorates rapidly during<br>
                            this cycle ... I would like to understand
                          where this limit of a 1000 is set and ideally
                          reduce this significantly.<br>
                          <br>
                            Another side-effect of the AD problem
                          described above; we also have the AD "Recycle
                          Bin" feature<br>
                            enabled. Every failed attempt at
                          provisioning the "users" account, also leaves
                          a deleted object entry;<br>
                            e.g. with a 1000 attempted adds, this
                          results in a 1000 deleted object entries.<br>
                          <br>
                            I'm hoping there is a way of setting a
                          global exclusion list or policy that would
                          reject certain values<br>
                            by attribute name; e.g. filter, but not
                          based on an individual resource.<br>
                          <br>
                          Regards,<br>
                            Anton<br>
                          <br>
                          <br>
                          <br>
_______________________________________________<br>
                          midPoint mailing list<br>
                          <a href="mailto:midPoint@lists.evolveum.com" target="_blank">midPoint@lists.evolveum.com</a><br>
                          <a href="http://lists.evolveum.com/mailman/listinfo/midpoint" rel="noreferrer" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
                          <br>
                        </blockquote>
                      </div>
                      <br>
                      <br clear="all">
                      <div><br>
                      </div>
                      -- <br>
                      <div>
                        <div dir="ltr">JASON</div>
                      </div>
                    </div>
                    <br>
                  </div>
                </div>
                <font size="2"><br>
                  <br>
                  <span>CONFIDENTIALITY NOTICE:<br>
                    This e-mail together with any attachments is
                    proprietary and confidential; intended for only the
                    recipient(s) named above and may contain information
                    that is privileged. You should not retain, copy or
                    use this e-mail or any attachments for any purpose,
                    or disclose all or any part of the contents to any
                    person. Any views or opinions expressed in this
                    e-mail are those of the author and do not represent
                    those of the Baptist School of Health Professions.
                    If you have received this e-mail in error, or are
                    not the named recipient(s), you are hereby notified
                    that any review, dissemination, distribution or
                    copying of this communication is prohibited by the
                    sender and to do so might constitute a violation of
                    the Electronic Communications Privacy Act, 18 U.S.C.
                    section 2510-2521. Please immediately notify the
                    sender and delete this e-mail and any attachments
                    from your computer. </span></font><br>
                <br>
              </blockquote>
              <br>
              <br>
              _______________________________________________<br>
              midPoint mailing list<br>
              <a href="mailto:midPoint@lists.evolveum.com" target="_blank">midPoint@lists.evolveum.com</a><br>
              <a href="http://lists.evolveum.com/mailman/listinfo/midpoint" rel="noreferrer" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
              <br>
            </blockquote>
          </div>
          <br>
          <br clear="all">
          <div><br>
          </div>
          -- <br>
          <div>
            <div dir="ltr">JASON</div>
          </div>
        </div>
        <br>
        <font size="2"><br>
          <br>
          CONFIDENTIALITY NOTICE:<br>
          This e-mail together with any attachments is proprietary and
          confidential; intended for only the recipient(s) named above
          and may contain information that is privileged. You should not
          retain, copy or use this e-mail or any attachments for any
          purpose, or disclose all or any part of the contents to any
          person. Any views or opinions expressed in this e-mail are
          those of the author and do not represent those of the Baptist
          School of Health Professions. If you have received this e-mail
          in error, or are not the named recipient(s), you are hereby
          notified that any review, dissemination, distribution or
          copying of this communication is prohibited by the sender and
          to do so might constitute a violation of the Electronic
          Communications Privacy Act, 18 U.S.C. section 2510-2521.
          Please immediately notify the sender and delete this e-mail
          and any attachments from your computer. </font><br>
        <br>
        <fieldset></fieldset>
        <br>
        <pre>_______________________________________________
midPoint mailing list
<a href="mailto:midPoint@lists.evolveum.com" target="_blank">midPoint@lists.evolveum.com</a>
<a href="http://lists.evolveum.com/mailman/listinfo/midpoint" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
midPoint mailing list
<a href="mailto:midPoint@lists.evolveum.com" target="_blank">midPoint@lists.evolveum.com</a>
<a href="http://lists.evolveum.com/mailman/listinfo/midpoint" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
midPoint mailing list<br>
<a href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a><br>
<a href="http://lists.evolveum.com/mailman/listinfo/midpoint" rel="noreferrer" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">JASON</div></div>
</div>

<br>
<font size="2"><br><br>CONFIDENTIALITY NOTICE:<br>This e-mail together with any attachments is proprietary and confidential; intended for only the recipient(s) named above and may contain information that is privileged. You should not retain, copy or use this e-mail or any attachments for any purpose, or disclose all or any part of the contents to any person. Any views or opinions expressed in this e-mail are those of the author and do not represent those of the Baptist School of Health Professions. If you have received this e-mail in error, or are not the named recipient(s), you are hereby notified that any review, dissemination, distribution or copying of this communication is prohibited by the sender and to do so might constitute a violation of the Electronic Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the sender and delete this e-mail and any attachments from your computer. </font><br>