[midPoint] effectiveStatus in shadows causing some issues

[Ivan Noris]

Hi Jason,

just to add... : upgrading from 3.2 would require to run all the db
migration scripts (3.2->3.3->3.3.1->3.4->3.4.1->3.5) and whatever is
required by Release notes for specific versions. Sometimes
logic/configuration of your resources, roles etc. needs to be updated;
connector references will certainly require change.

I have recently (9-10/2016) upgraded from 3.3 to 3.4.x; still using .NET
connector server and AD/Exchange with that customer.

Installing second midPoint (e.g. 3.5 independent from your 3.2
installation) could work, but you would need to resynchronize your data
to have it in (new) midPoint...

Best regards,

Ivan


On 02/13/2017 05:32 PM, Jason Everling wrote:
> 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
> <mailto: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 developer
>     evolveum.com <http://evolveum.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 list
>>>     midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>>     http://lists.evolveum.com/mailman/listinfo/midpoint
>>>     <http://lists.evolveum.com/mailman/listinfo/midpoint>
>>     -- 
>>     Ivan Noris
>>     Senior Identity Engineer
>>     evolveum.com <http://evolveum.com>
>>
>>     _______________________________________________
>>     midPoint mailing list
>>     midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>     http://lists.evolveum.com/mailman/listinfo/midpoint
>>     <http://lists.evolveum.com/mailman/listinfo/midpoint>
>     _______________________________________________ midPoint mailing
>     list midPoint at lists.evolveum.com
>     <mailto:midPoint at lists.evolveum.com>
>     http://lists.evolveum.com/mailman/listinfo/midpoint
>     <http://lists.evolveum.com/mailman/listinfo/midpoint> 
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
-- 
Ivan Noris
Senior Identity Engineer
evolveum.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20170214/650219cf/attachment.htm>