[midPoint] Possible to sync lockoutStatus from AD?
Jason Everling
jeverling at bshp.edu
Thu Jan 21 16:41:51 CET 2016
No, the password is only generated on new account creation, the password is
then only sync'd when I manually enter a new password. I'll keep messing
with it and see what I can come up with.
Thanks!
JASON
JASON
On Thu, Jan 21, 2016 at 9:34 AM, Ivan Noris <ivan.noris at evolveum.com> wrote:
> 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>
> 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>
>> 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 evolveum.com/blog/
>>> ___________________________________________________
>>> "Semper Id(e)M Vix."
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> 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 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
>>
>>
>
>
>
> 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
>
>
--
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/20160121/8ab97369/attachment.htm>
More information about the midPoint
mailing list