[midPoint] Standing up midPoint with existing accounts

[Pavol Mederly]

...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
>

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