[midPoint] Possible to sync lockoutStatus from AD?
Ivan Noris
ivan.noris at evolveum.com
Thu Jan 21 16:34:07 CET 2016
This is interesting. One thing: isn't the password generated from
midpoint to AD each time? Could this not cause unlocking account
automatically?
No other thoughts yet..
On 01/21/2016 04:27 PM, Jason Everling wrote:
> The user remains NORMAL. But the user does not have NORMAL until they
> get locked in AD which for 15 seconds it turns to LOCKED and then 15
> seconds later, NORMAL again without me unlocking it. 15 seconds is the
> live sync task time.
>
> I just noticed, my "progress" for the live sync task has gone way up
> from 33 to 2440, and every 15 seconds it goes up another 10-12 in
> progress. I removed the mapping and the progress has not moved.
>
> As you stated, it should be under
> <activation>
> <lockoutStatus>
> ..
>
> So I think I will wait unless you figure it out another time!
>
> Thanks!
> JASON
>
> JASON
>
> On Thu, Jan 21, 2016 at 9:15 AM, Ivan Noris <ivan.noris at evolveum.com
> <mailto:ivan.noris at evolveum.com>> wrote:
>
> Hi Jason,
>
> maybe I somehow fouled with the values in the example... But don't
> see it yet.
> If the account is automatically and unintentionally unlocked, is
> the user in midPoint locked or unlocked?
>
> Anyway just for importing the data, you can leave outbound
> commented out, unless you need it to be synced bi-directional.
>
> IVan
>
>
> On 01/21/2016 03:25 PM, Jason Everling wrote:
>> I had figured as much BUT your code is very close!
>>
>> Using the code below it detects the lockout and set's it in
>> midpoint but it immediately unlocks the account! So in AD the
>> account becomes locked and then a few seconds later when live
>> sync occurs it becomes unlocked automatically.
>>
>> I am looking at the code now to see what could be causing that,
>> this is one of those "nice to have" features but something that
>> is urgent so if it get's pushed then I am not to worried, but we
>> are very close with the code!
>>
>> JASON
>>
>> <attribute>
>> <c:ref>icfs:lockOut</c:ref>
>> <outbound>
>> <source>
>> <c:path>$user/activation/lockoutStatus</c:path>
>> </source>
>> <expression>
>> <script>
>> <code>
>> import
>> com.evolveum.midpoint.xml.ns._public.common.common_3.LockoutStatusType;
>> if (lockoutStatus ==
>> LockoutStatusType.NORMAL) return false
>> else return true
>> </code>
>> </script>
>> </expression>
>> </outbound>
>> <inbound>
>> <expression>
>> <script>
>> <code>
>> import
>> com.evolveum.midpoint.xml.ns._public.common.common_3.LockoutStatusType;
>> if (input) return LockoutStatusType.LOCKED
>> else return LockoutStatusType.NORMAL
>> </code>
>> </script>
>> </expression>
>> <target>
>> <c:path>$user/activation/lockoutStatus</c:path>
>> </target>
>> </inbound>
>> </attribute>
>>
>> JASON
>>
>> On Thu, Jan 21, 2016 at 6:31 AM, Ivan Noris
>> <ivan.noris at evolveum.com <mailto:ivan.noris at evolveum.com>> wrote:
>>
>> Hi Jason,
>>
>> after discussion with developers it seems that there is
>> missing feature
>> for "normal" using of lockout in schema handling without
>> workarounds.
>> I'd assume something similar as administrativeStatus mapping
>> should be
>> used without need to manually hack schema for icfs:lockOut first.
>>
>> I've created https://jira.evolveum.com/browse/MID-2770
>>
>> The implementation time is roughly set for 3.4, subject to
>> change. As
>> always this can be prioritized by subscription.
>>
>> Please let us know if the workaround works anyway. Thank you!
>>
>> Best regards,
>> Ivan
>>
>> On 01/20/2016 04:25 PM, Jason Everling wrote:
>> >
>> > Expected boolean type, but got class
>> >
>> com.evolveum.midpoint.xml.ns._public.common.common_3.LockoutStatusType
>> > in outbound mapping for
>> {.../connector/icf-1/resource-schema-3}lockOut
>> > in resource:10000000-2000-3000-4000-10000000ad01(Active
>> Directory:
>> > Office 365, Google Apps, Moodle)
>> >
>>
>> --
>> 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
>>
>>
>>
>>
>>
>> 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
>
>
>
>
>
> 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/20160121/a29b44be/attachment.htm>
More information about the midPoint
mailing list