[midPoint] Reconcile Task disabled users in GUI
Ivan Noris
ivan.noris at evolveum.com
Fri Oct 2 09:17:59 CEST 2015
Hi Jason,
possibly related to https://jira.evolveum.com/browse/MID-2585
I.
On 10/01/2015 05:46 PM, Jason Everling wrote:
> Oh I meant also in my resources, not the task directly,
>
> Why does this have effectiveStatus disabled for the persons shadow?
> that timestamp is when the notification fired
>
> <activation>
> <administrativeStatus>enabled</administrativeStatus>
> <effectiveStatus>disabled</effectiveStatus>
> <enableTimestamp>2015-09-29T12:30:23.392-05:00</enableTimestamp>
> <lockoutStatus>normal</lockoutStatus>
> </activation>
>
> On Thu, Oct 1, 2015 at 9:48 AM, Ivan Noris <ivan.noris at evolveum.com
> <mailto:ivan.noris at evolveum.com>> wrote:
>
> Hi Jason,
>
> the configuration for administrativeStatus that I posted was not
> in the task, but in resource schema handling. I have multiple
> (all) resources with that configuration.
>
> I also remember that I also get "false" positives of changing
> administrativeStatus to ENABLED even if the account is already
> enabled; but I assumed that in my case it may be caused by the
> fact that I'm using strong mappings...
>
> ... which is not your case...
>
> I'm not sure if this is error or just false positive; I hope
> someone else may be able to answer this.
>
> Best regards,
> Ivan
>
>
> On 10/01/2015 03:55 PM, Jason Everling wrote:
>> No I don't have anything like that in my recon task, no
>> activation at all in it. This happened again a few days ago when
>> a value in my CSV resource was modified for a user, their last
>> name which is "weak" so it did not update in midpoint, and when I
>> ran the audit report I saw that it replaced ENABLED with ENABLED
>> making it look like they were "disabled" but they were not, it
>> just replaced enabled with enabled.
>>
>> I went further into my CSV resource and found the below,
>>
>> <activation>
>> <administrativeStatus>
>> <inbound>
>> <expression>
>> <value>enabled</value>
>> </expression>
>> </inbound>
>> </administrativeStatus>
>> </activation>
>>
>> So I changed it and added the highlighted,
>>
>> <activation>
>> <administrativeStatus>
>> <inbound>
>> <strength>weak</strength>
>> <expression>
>> <value>enabled</value>
>> </expression>
>> </inbound>
>> </administrativeStatus>
>> </activation>
>>
>> This might have been causing the false positives as when an
>> attribute was changed, even if the attribute was "weak" it would
>> still replace "enabled" with "enabled" in the user object causing
>> a notification to fire.
>>
>> So far after the change, a few days now, I have not had the issue
>> again,
>>
>> Maybe this is not the cause? But I will keep an eye on it, I have
>> notifications going to my email so I will be able to see if it
>> happens again before I let the notifications go out to the users.
>>
>> JASON
>>
>> On Thu, Oct 1, 2015 at 5:31 AM, Ivan Noris
>> <ivan.noris at evolveum.com <mailto:ivan.noris at evolveum.com>> wrote:
>>
>> Hi Jason,
>>
>> I have encountered similar behaviour - reconciliation or
>> recompute task (or reconcile checkbox) disabled accounts that
>> were not provided by roles.
>>
>> This happened after migration from 3.0.x -> 3.3-snapshot and
>> with the following configuration in resource (see bold text):
>>
>> <activation>
>> <existence>
>> <outbound>
>> <strength>weak</strength>
>> <expression>
>> <path>$focusExists</path>
>> </expression>
>> </outbound>
>> </existence>
>> <administrativeStatus>
>> <outbound>
>> <strength>strong</strength>
>> <!-- XXX to allow to disable when removing roles by
>> recomputing users; but
>> enforcement MUST be set to FULL for this to work -->
>> <expression>
>> <script>
>> <code>
>> import
>> com.evolveum.midpoint.xml.ns._public.common.common_3.ActivationStatusType;
>> * if (legal &&
>> assigned) { // previously only "legal" was used**
>> * input;
>> } else {
>>
>> ActivationStatusType.DISABLED;
>> }
>> </code>
>> </script>
>> </expression>
>> </outbound>
>> </administrativeStatus>
>> </activation>
>>
>> Are you using this config too?
>>
>> Regard,
>> I.
>>
>>
>> On 09/25/2015 05:58 PM, Jason Everling wrote:
>>> I found out why!
>>>
>>> So if these users did not have any role assigned then their
>>> GUI accounts were being disabled.
>>>
>>> Strange though, this did not happen in 3.1.1, so maybe there
>>> was a bug in 3.1.1 related to that?
>>>
>>> JASON
>>>
>>> On Fri, Sep 25, 2015 at 10:08 AM, Jason Everling
>>> <jeverling at bshp.edu <mailto:jeverling at bshp.edu>> wrote:
>>>
>>> I have a recon task that runs every night and after I
>>> updated us to 3.2 the task last night disabled about 30
>>> accounts, only their GUI account and not all their other
>>> resource accounts.
>>>
>>> It should have never disabled their accounts, I cannot
>>> figure out why that happened and even within the
>>> resource there is nothing stated to inactivate or
>>> anything, this same task/resource has been running every
>>> night for about 3 weeks now and this is the first time
>>> this happened,
>>>
>>> Thanks!
>>>
>>> --
>>> JASON
>>>
>>>
>>>
>>>
>>> --
>>> 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
>>
>> --
>> Ing. Ivan Noris
>> Senior Identity Management Engineer & IDM Architect
>> evolveum.com <http://evolveum.com> evolveum.com/blog/ <http://evolveum.com/blog/>
>> ___________________________________________________
>> "Semper Id(e)M Vix."
>>
>>
>> _______________________________________________
>> 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
>
> --
> Ing. Ivan Noris
> Senior Identity Management Engineer & IDM Architect
> evolveum.com <http://evolveum.com> evolveum.com/blog/ <http://evolveum.com/blog/>
> ___________________________________________________
> "Semper Id(e)M Vix."
>
>
> _______________________________________________
> 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
--
Ing. Ivan Noris
Senior Identity Management Engineer & IDM Architect
evolveum.com evolveum.com/blog/
___________________________________________________
"Semper Id(e)M Vix."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20151002/f21e493b/attachment.htm>
More information about the midPoint
mailing list