[midPoint] Reconcile Task disabled users in GUI
Jason Everling
jeverling at bshp.edu
Fri Oct 2 16:36:21 CEST 2015
Disregard that last email, was not caused by the shadow effectiveStatus
On Fri, Oct 2, 2015 at 9:02 AM, Jason Everling <jeverling at bshp.edu> wrote:
> Yeah I read that on the jira issue BUT it seems that since the
> effectiveStatus for the shadow was changed even though the user object was
> enabled for both effectiveStatus and administrativeStatus, it still fired
> the below notification.
>
> <expressionFilter>
> <script>
> <code>
> event.isRelatedToItem(new
> com.evolveum.midpoint.prism.path.ItemPath("activation",
> "administrativeStatus")) &&
> basic.getExtensionPropertyValue(requestee, '
> http://www.bshp.edu/xml/ns/public/bshp', 'eduPersonAffiliation') ==
> 'student'
> </code>
> </script>
> </expressionFilter>
>
>
> On Fri, Oct 2, 2015 at 8:52 AM, Ivan Noris <ivan.noris at evolveum.com>
> wrote:
>
>> 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>
>> 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>
>>> 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>
>>>> 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>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 listmidPoint at lists.evolveum.comhttp://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."
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>> --
>>>> Ing. Ivan Noris
>>>> Senior Identity Management Engineer & IDM Architect
>>>> evolveum.com evolveum.com/blog/
>>>> ___________________________________________________
>>>> "Semper Id(e)M Vix."
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>> --
>>> Ing. Ivan Noris
>>> Senior Identity Management Engineer & IDM Architect
>>> evolveum.com evolveum.com/blog/
>>> ___________________________________________________
>>> "Semper Id(e)M Vix."
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>> --
>> Ing. Ivan Noris
>> Senior Identity Management Engineer & IDM Architect
>> evolveum.com evolveum.com/blog/
>> ___________________________________________________
>> "Semper Id(e)M Vix."
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>
>
> --
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20151002/ea2a8f99/attachment.htm>
More information about the midPoint
mailing list