[midPoint] Standing up midPoint with existing accounts

Tue Aug 28 18:16:42 CEST 2018

Good question. Are you sure that the roles are assigned to the user 
correctly?

Because today when I tested this, users /with/ roles assigned got their 
auxiliary object classes right. Only users without roles were left 
without the OCs.

Pavol Mederly
Software developer
evolveum.com

On 28.08.2018 17:57, Andrew Morgan wrote:
> Why is:
>
> <auxiliaryObjectClassMappings>
>     <tolerant>true</tolerant>
> </auxiliaryObjectClassMappings>
>
> necessary?
>
> I have the roles assigned that will induce the objectclasses and 
> attributes that are present on the existing accounts, but the 
> synchronization during linking seems to be ignoring the inducements 
> that come from the roles.  Bug?
>
> Thanks,
>
> Andy Morgan
> Systems Administrator, Identity & Access Management
> Information Services | Oregon State University
> 541-737-8877 | is.oregonstate.edu
>
> On Tue, 28 Aug 2018, Pavol Mederly wrote:
>
>> 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<mailto:midPoint at lists.evolveum.com>
>> 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
>>
>>
>>
> _______________________________________________
> 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/ef298c3f/attachment.htm>