[midPoint] effectiveStatus in shadows causing some issues

[Pavol Mederly]

I think that almost certainly (or, let's say, with 99% probability) the 
midPoint version is not a problem with regards to the connector.

.Net connector is deprecated, yes, but only because it was so awkward to 
maintain. As far as I know, there's nothing in midPoint 3.5.x that would 
prohibit using that connector with newest midPoint. (You'd need to test 
it for yourself, of course.) It's just not officially supported, and in 
general, not much recommended. But running on MP 3.2 is not recommended 
either :) At least in my opinion.

--

But, of course, migration to AD-LDAP would be very useful as well. I 
wanted just to point out that you'd probably need not wait with midPoint 
upgrade because of the connector issue.

Pavol Mederly
Software developer
evolveum.com

On 13.02.2017 17:32, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20170213/a7855cfc/attachment.htm>