[midPoint] Reconcile Task disabled users in GUI
Ivan Noris
ivan.noris at evolveum.com
Fri Oct 2 15:52:05 CEST 2015
BTW I'm not sure if effectiveStatus is even used now for shadows.
In User it seems to work OK.
Regards,
I.
On 10/02/2015 03:22 PM, Jason Everling wrote:
> Yes I saw that yesterday as I was searching, I have been able to
> manually change effectiveStatus to enabled using the debug pages for
> each shadow that got disabled last week.
>
> I still do not know why those 30 or so users had that value of
> disabled when there are other same type of users that has enabled instead.
>
> Thanks Again!
>
> JASON
>
> On Fri, Oct 2, 2015 at 2:17 AM, Ivan Noris <ivan.noris at evolveum.com
> <mailto:ivan.noris at evolveum.com>> wrote:
>
> 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 <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/5641d7d5/attachment.htm>
More information about the midPoint
mailing list