[midPoint] effectiveStatus in shadows causing some issues

[Jason Everling]

I know, I have seen all the latest features and additions!!! Going from 3.2
and having to run all the upgrades and scripts for each version since is
much work. Is what I thought about doing... just deploy an updated midpoint
war on the server as a different name and add in my updated
configs/resources/objects etc.. The thing that is really keeping me from
doing that now is the switch to AD-LDAP connector from the .NET connector,
I haven't had time to test an updated config using that connector.


JASON

On Mon, Feb 13, 2017 at 9:27 AM, Pavol Mederly <mederly at evolveum.com> wrote:

> Yes. And the shadow integrity checker tool looks for this information, and
> removes it if necessary.
>
> Jason, maybe you could start thinking about an upgrade ... You'll see -
> the 3.4/3.5 version is much, much nicer than 3.2. :-)
>
> Pavol Mederly
> Software developerevolveum.com
>
> On 13.02.2017 13:37, Ivan Noris wrote:
>
> Hi Jason,
>
> AFAIK somewhere between 3.2 and 3.4 there was a change and this is no
> longer stored in Shadows. Only metadata e.g. activation/enableTimestamp,
> but not the state. (Just looking to my shadows on midpoint 3.5.x)
>
> Regards,
>
> Ivan
>
> On 02/08/2017 06:52 PM, Jason Everling wrote:
>
> Not sure if this was fixed in later versions, we are on 3.2 still BUT i
> ran into some activation issues when testing my new authoritative resource,
> it kept enabling accounts even though their resource account was 'disabled'
> and inbound was strong, on every single reconcile.
>
> It took forever to figure it out, it was the same accounts every single
> time, I finally found through a ton of logging, the shadow account for the
> AD resource had wrong activation information, below.
>
>    <activation>
>       <administrativeStatus>disabled</administrativeStatus>
>       <effectiveStatus>enabled</effectiveStatus>
>       <lockoutStatus>normal</lockoutStatus>
>    </activation>
> </shadow>
>
> It was that effectiveStatus that kept enabling their midpoint account even
> though on AD it is still disabled.
>
> I went through each shadow, one by one, and changed effectiveStatus to
> disabled and ran a full recon and it no longer enables the accounts.
>
> In any case, I did this one by one, it took quite a while to do it. I was
> hoping I could scan through the database for any I might have missed and
> just compare 'administrativeStatus' to 'effectiveStatus' for the shadows
> BUT it seems in the shadow table those columns do not exist.
>
> Where are these values stored for a shadow object? Out of all my
> resources, the AD resource is the only one that actually has those values,
> all other resource shadows contain no activation even though they have
> inbound/outbound mappings.
>
> Thanks!
> JASON
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
> --
> Ivan Noris
> Senior Identity Engineerevolveum.com
>
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20170213/efb913bf/attachment.htm>