[midPoint] Protected / excluded accounts
Pavol Mederly
mederly at evolveum.com
Wed Jul 29 19:52:00 CEST 2015
Hello,
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.)
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.
However, this still does not address the original issue, which is a bit
harder to solve.
Pavol
> Anton, Jason,
>
> I'm going to look at this problem.
>
> 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:
>
> <internals>
> <enableExperimentalCode>true</enableExperimentalCode>
> <maxModelClicks>20</maxModelClicks>
> </internals>
>
> This was some days ago in 3.2-SNAPSHOT version.
>
> 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.
>
> Best regards,
> Pavol
>
>> Yeah I tested on 3.2devel, I just tested again with not so good news,
>>
>> 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,
>>
>> I added back my user from previous,
>>
>> Unfortunately this did not solve the problem, I still get object
>> already exist with no attempt to add an iteration token
>>
>>
>> JASON
>>
>> On Wed, Jul 22, 2015 at 9:04 AM, <midpoint at mybtinternet.com
>> <mailto:midpoint at mybtinternet.com>> wrote:
>>
>> 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.
>>
>> 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,
>> the account import would have brought in the users account from
>> AD and iteration may have worked. That container however is
>> excluded, hence midPoint thinks it should be valid ...
>>
>> Regards,
>> Anton
>>
>> ----Original message----
>> From : jeverling at bshp.edu <mailto:jeverling at bshp.edu>
>> Date : 22/07/2015 - 14:36 (BST)
>> To : midpoint at mybtinternet.com
>> <mailto:midpoint at mybtinternet.com>,
>> midpoint at lists.evolveum.com <mailto:midpoint at lists.evolveum.com>
>> Subject : Re: [midPoint] Protected / excluded accounts
>>
>> I was curious to try this myself being on AD and I have
>> excluded/protected entire OUs,
>>
>> 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.
>>
>> 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,
>>
>> 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.
>> : when creating LDAP://dc1.test.local/cn=Us Ers,OU=DPN,OU=SHP
>> Students,DC=TEST,DC=LOCAL)->org.identityconnectors.framework.impl.api.remote.RemoteWrappedException(The
>> object already exists.
>> : when creating LDAP://dc1.test.local/cn=Us Ers,OU=DPN,OU=SHP
>> Students,DC=TEST,DC=LOCAL)
>> com.evolveum.midpoint.util.exception.ObjectAlreadyExistsException:
>> Object already exists on the resource:
>> org.identityconnectors.framework.common.exceptions.AlreadyExistsException(The
>> object already exists.
>> : when creating LDAP://dc1.test.local/cn=Us Ers,OU=DPN,OU=SHP
>> Students,DC=TEST,DC=LOCAL)->org.identityconnectors.framework.impl.api.remote.RemoteWrappedException(The
>> object already exists.
>> : when creating LDAP://dc1.test.local/cn=Us Ers,OU=DPN,OU=SHP
>> Students,DC=TEST,DC=LOCAL)
>>
>>
>> 2015-07-22 08:30:15,532 [] [midPointScheduler_Worker-6] ERROR
>> (com.evolveum.midpoint.model.impl.sync.LiveSyncTaskHandler):
>> Live Sync: Internal Error:
>> com.evolveum.midpoint.util.exception.SystemException:
>> Synchronization error: java.lang.IllegalStateException: Model
>> operation took too many clicks (limit is 200). Is there a cycle?
>>
>>
>> JASON
>>
>> On Wed, Jul 22, 2015 at 5:56 AM, <midpoint at mybtinternet.com
>> <mailto:midpoint at mybtinternet.com>> wrote:
>>
>> Hi Guys,
>>
>> I'm looking for a way to exclude certain account names
>> for use on any resource; this could include:
>> - operating system accounts
>> - service accounts
>> - sensitive accounts
>> - account names generated that may be offensive words etc
>>
>> I have noted the protected account feature, however
>> this seems to require definition on every resource
>> which can be tedious and prone to error on large
>> numbers of resources. Also, as this maps to the
>> designated repository name attribute, it is not very
>> flexible; e.g. if you take AD built-in group Users.
>> While this is a group, it still has a sAMAccountName of
>> Users. Setting a protection of "Users" does not
>> exclude an attempt to provision an account with
>> sAMAccountName of users.
>>
>> What happens in the above example, midPoint attempts to
>> add the account to AD, this fails with "Already
>> exists". This does not seem to trigger the need for
>> iteration. This is attempted a 1000 times until some
>> limit in midPoint then aborts the transaction. Needless
>> to say, performance deteriorates rapidly during
>> this cycle ... I would like to understand where this
>> limit of a 1000 is set and ideally reduce this significantly.
>>
>> Another side-effect of the AD problem described above;
>> we also have the AD "Recycle Bin" feature
>> enabled. Every failed attempt at provisioning the
>> "users" account, also leaves a deleted object entry;
>> e.g. with a 1000 attempted adds, this results in a 1000
>> deleted object entries.
>>
>> I'm hoping there is a way of setting a global exclusion
>> list or policy that would reject certain values
>> by attribute name; e.g. filter, but not based on an
>> individual resource.
>>
>> Regards,
>> Anton
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>>
>> --
>> JASON
>>
>>
>>
>> CONFIDENTIALITY NOTICE:
>> 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.
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>>
>> --
>> JASON
>>
>>
>>
>> CONFIDENTIALITY NOTICE:
>> 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.
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150729/a3f22ea5/attachment.htm>
More information about the midPoint
mailing list