[midPoint] Provisioning questions

[Ivan Noris]

Hi Lucie,

can you please check your setting in System config - Assignment Policy
Enforcement?
I've just test your issue:

1) when *Relative* (default) assignment policy is used: the behaviour is
as you have specified. Unassigning the role (or account) will disable it
because of your configuration. Disabling/enabling User in midPoint will
disable/enable the account (even if it is unassigned)

2) when *Full* assignment policy is used: unassigning the role (or
account) will disable it because of your configuration. Disabling User
in midPoint will disable the User+account (although it is disabled, so
no change will be provisioned). BUT, when you try to Enable User, the
User will be enabled, but the account will be DISABLED.

As I understand the behaviour is caused by

                                    import
com.evolveum.midpoint.xml.ns._public.common.common_2a.ActivationStatusType;
                                    if (legal) {
                                        input;
                                    } else {
ActivationStatusType.DISABLED;

the "legal" variable will be false after the account/role is unassigned
and the assignment enforcement policy is FULL.

Please refer to
https://wiki.evolveum.com/display/midPoint/Projection+Policy page for
the enforcement policy modes. In the short, unassigned accounts are
prohibited in FULL enforcement policy, they would be deleted, but in
your configuration you've replaced delete with disable.

Hope this helps.

Regards,
IVan

On 03/20/2014 03:06 PM, Lucie Rút Bittnerová wrote:
> Hello,
>
> I have some issues which I cannot solve.
>
> I have configured activation of resource exactly as it is written on
> wiki:
>
>            <activation>
>                 <existence>
>                     <outbound>
>                         <expression>
>                             <path>$focusExists</path>
>                         </expression>
>                     </outbound>
>                 </existence>
>                 <administrativeStatus>
>                     <outbound>
>                         <expression>
>                             <script>
>                                 <code>
>                                     import
> com.evolveum.midpoint.xml.ns._public.common.common_2a.ActivationStatusType;
>                                     if (legal) {
>                                         input;
>                                     } else {
> ActivationStatusType.DISABLED;
>                                     }
>                                 </code>
>                             </script>
>                         </expression>
>                     </outbound>
>                 </administrativeStatus>
>             </activation>
>
> But the behaviour is not such as it should be. When I unassign role
> which assigns this resource to the user, the account stays in the list
> of accounts and is disabled, that is ok. When I change some attribute
> of the user, it is synchronized to the account, which stays disabled,
> thats also ok. But when I change state of the user to disabled and
> then back to enabled, the account, which should stay disabled, changes
> its state to enabled, which I think is wrong. Can you please help me
> how to change the configuration that the account would be on
> unassignment not only disabled but also unlinked?
>
> I have also problem how to configure resource to achieve this
> behaviour: When resource is assigned to the user and the user account
> already exists on that resource I'd like to have linked this account
> to the user without any errors  but now I get only error message and
> no account is linked.
>
> Is it possible to configure Midpoint in the way that when user with
> some accounts is deleted the accounts are only disabled and unlinked
> and not deleted?
>
> Thank you for any help.
> Lucie
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-- 
  Ing. Ivan Noris
  Senior Identity Management Engineer
  evolveum.com
  ___________________________________________________
  "Semper cautus - semper paratus - semper idem Vix."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20140320/ae838960/attachment.htm>