[midPoint] Standing up midPoint with existing accounts

[Pavol Mederly]

Andy,

returning to your situation: I have replicated it in my TIER setup and 
got the same behavior as you did.

I suggest the following:

 1. If you just want to create shadows without linking them to their
    respective owners (users), then dryRun import task is the way to go.
    It will evaluate situation of each shadow (unmatched, unlinked,
    linked) and update its status. However, it will not apply the
    synchronization reaction(s), so e.g. even if you define "link"
    action for unlinked shadows, the dry import will not execute it. The
    shadow will not be linked with their potential owner.
 2. If you want to create shadows and to link them (and not lose
    auxiliary object class information), then use Brad suggestion. It
    works in my case (with roles inducing auxiliary OCs) and I think it
    will also in yours.

I have tried e.g. setting <synchronize>false</synchronize> on the 
unlinked reaction, i.e.

                 <reaction>
                     <situation>unlinked</situation>
                     <synchronize>false</synchronize>
                     <action>
<handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/action-3#link</handlerUri>
                     </action>
                 </reaction>

but it does not work: synchronize=false causes the link action to be 
skipped as well.

Maybe we could implement a reaction like "link but do not synchronize" 
but I am not sure how complex would that be.

Thinking about assignment policy enforcement, it should not make a 
difference here. It deals with the mere existence of projections 
(accounts), not with their synchronization.

Best regards,

Pavol Mederly
Software developer
evolveum.com

On 28.08.2018 8:44, Pavol Mederly wrote:
>
> ...though, I think you need those accounts to be linked to the users. 
> Dry run will probably not do that.
>
> Pavol Mederly
> Software developer
> evolveum.com
> On 28.08.2018 8:33, Pavol Mederly wrote:
>>
>> Andy,
>>
>> just a quick shot as I have to go away just now:
>>
>>> SECOND METHOD TRIED:
>>>
>>> Instead of importing accounts, I tried assigning the roles to the 
>>> midPoint users to induce the correct resources, objectclasses, and 
>>> roles.  That actually worked great, but I don't know how to get 
>>> 80,000 shadows into midPoint's repository without importing.  I can 
>>> get 20 shadows created at a time by browsing the Accounts in the 
>>> LDAP resource, but I don't know how to get all of them.  If midPoint 
>>> doesn't have a shadow when I assign the roles, it tries (and fails) 
>>> to create a new account.  Then, it makes a bunch of modifications to 
>>> the existing account because it thinks it has changes to process. No 
>>> good.
>> A quick method of account creation is to run import from that 
>> resource with *dryRun* option set. It should do nothing except for 
>> creating the shadows. :)
>> Pavol Mederly
>> Software developer
>> evolveum.com
>>   
>> On 25.08.2018 2:42, Andrew Morgan wrote:
>>> I'm looking for advice on standing up midPoint with resources that 
>>> already have accounts present.  I have 1 resource with inbound 
>>> mappings (a database table) and 2 resources with outbound mappings 
>>> (AD and LDAP). There are approximately 80,000 accounts in AD and LDAP.
>>>
>>>
>>> FIRST METHOD TRIED:
>>>
>>> I attempted to import accounts from LDAP in order to link to 
>>> existing midPoint users and then assign the appropriate roles to 
>>> match the existing state of the LDAP account.
>>>
>>> When I import an LDAP account, it is linked to the correct midPoint 
>>> user. However, midPoint strips off the extra objectclasses and 
>>> attributes that are defined in my roles (not in the LDAP resource).  
>>> I have tried setting the assignmentPolicyEnforcement to "positive" 
>>> or "none", but it still happens.  No good.
>>>
>>>
>>> SECOND METHOD TRIED:
>>>
>>> Instead of importing accounts, I tried assigning the roles to the 
>>> midPoint users to induce the correct resources, objectclasses, and 
>>> roles.  That actually worked great, but I don't know how to get 
>>> 80,000 shadows into midPoint's repository without importing.  I can 
>>> get 20 shadows created at a time by browsing the Accounts in the 
>>> LDAP resource, but I don't know how to get all of them.  If midPoint 
>>> doesn't have a shadow when I assign the roles, it tries (and fails) 
>>> to create a new account.  Then, it makes a bunch of modifications to 
>>> the existing account because it thinks it has changes to process. No 
>>> good.
>>>
>>>
>>> NEXT???:
>>>
>>> Maybe I can define the LDAP resource with no outbound mappings, 
>>> import all the accounts in order to link them to users, assign the 
>>> correct roles, and then update the LDAP resource to have the 
>>> outbound mappings...
>>>
>>>
>>> Is there a wiki page that covers this?  I'm running out of ideas...  
>>> Help!
>>>
>>> Thanks,
>>>
>>> Andy Morgan
>>> Systems Administrator, Identity & Access Management
>>> Information Services | Oregon State University
>>> 541-737-8877 | is.oregonstate.edu
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> 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/20180828/6329b5af/attachment.htm>