[midPoint] Protected / excluded accounts

Wed Jul 29 20:15:11 CEST 2015

Thanks for the update,

Not sure if I mentioned but it also happens to user accounts that are also
protected, not just with groups that have sAMAccountName.

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.

JASON

On Wed, Jul 29, 2015 at 12:52 PM, Pavol Mederly <mederly at evolveum.com>
wrote:

>  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> 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
>> Date : 22/07/2015 - 14:36 (BST)
>> To : midpoint at mybtinternet.com, 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> 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
>>> 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
>>
>>
>
>
>  --
>  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 listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> midPoint mailing list
> 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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150729/dea9d3f5/attachment.htm>