[midPoint] Standing up midPoint with existing accounts

Brad Fardig brad.fardig at cogitogroup.net
Tue Aug 28 01:06:12 CEST 2018


There is the:

 

<auxiliaryObjectClassMappings>

    <tolerant>true</tolerant>

</auxiliaryObjectClassMappings>

 

shown in Read-Only Auxiliary Object Classes section:  https://wiki.evolveum.com/display/midPoint/Auxiliary+Object+Classes

 

it will allow you to add auxiliary object classes without removing the ones that are already there

 

I’m not sure if it works with inducements however but might be worth a try

 

 

 

 

From: midPoint <midpoint-bounces at lists.evolveum.com> On Behalf Of Jason Everling
Sent: Tuesday, 28 August 2018 8:41 AM
To: midPoint General Discussion <midpoint at lists.evolveum.com>
Subject: Re: [midPoint] Standing up midPoint with existing accounts

 

Yours should look like this, 

 

<objectType>

        <kind>account</kind>

        <default>true</default>

        <objectClass>ri:inetOrgPerson</objectClass>

        <auxiliaryObjectClass>ri:osuPerson</auxiliaryObjectClass>

        <auxiliaryObjectClass>ri:eduPerson</auxiliaryObjectClass>

        <auxiliaryObjectClass>ri:lpSghePerson</auxiliaryObjectClass>

        <auxiliaryObjectClass>ri:posixAccount</auxiliaryObjectClass>

        <auxiliaryObjectClass>ri:shadowAccount</auxiliaryObjectClass>

<auxiliaryObjectClass>ri:googlePerson</auxiliaryObjectClass>

 

 

 

 

 

On Mon, Aug 27, 2018 at 5:38 PM Jason Everling <jeverling at bshp.edu <mailto:jeverling at bshp.edu> > wrote:

If users within the same resource need to have different objectclasses then create different intents with their own object sync with the correct correlation to distinguish them. Pretty sure its the only way users in the same resource can have different objectclasses. Anyone else know differently? 

 

 

 

 

On Mon, Aug 27, 2018 at 5:33 PM Jason Everling <jeverling at bshp.edu <mailto:jeverling at bshp.edu> > wrote:

Try removing the objectClasses from your Roles (leave the account construction ) and define all of them (each and every objectclass you use) in the resource config itself. 

 

 

 

On Mon, Aug 27, 2018 at 4:15 PM Andrew Morgan <morgan at oregonstate.edu <mailto:morgan at oregonstate.edu> > wrote:

My configuration is pretty simple.  In the resource, I have:

<objectType>
        <kind>account</kind>
        <default>true</default>
        <objectClass>ri:inetOrgPerson</objectClass>
        <auxiliaryObjectClass>ri:osuPerson</auxiliaryObjectClass>
        <auxiliaryObjectClass>ri:eduPerson</auxiliaryObjectClass>
        <auxiliaryObjectClass>ri:lpSghePerson</auxiliaryObjectClass>

In the Unix role:

<inducement id="1">
        <construction>
                <!-- This is the ONIDLDAPDEV resource -->
                <resourceRef oid="ef2bc95b-76e0-48e2-86d6-3d4f02d3e1aa" relation="org:default" type="c:ResourceType"/>
                <kind>account</kind>
                <auxiliaryObjectClass>ri:posixAccount</auxiliaryObjectClass>
                <auxiliaryObjectClass>ri:shadowAccount</auxiliaryObjectClass>

In the Google role:

<inducement id="1">
        <construction>
                <!-- This is the ONIDLDAPDEV resource -->
                <resourceRef oid="ef2bc95b-76e0-48e2-86d6-3d4f02d3e1aa" relation="org:default" type="c:ResourceType"/>
                <kind>account</kind>
                <auxiliaryObjectClass>ri:googlePerson</auxiliaryObjectClass>


Even when I have assigned the Unix and Google roles to the user, importing 
an account from ONIDLDAPDEV is stripping those objectclasses and 
attributes off the ONIDLDAPDEV account.  :(

I can protect my resource by disabling the create, update, and delete 
capabilities, but it throws large Java errors in the audit log still... 
:(

Andy Morgan
Systems Administrator, Identity & Access Management
Information Services | Oregon State University
541-737-8877 | is.oregonstate.edu <http://is.oregonstate.edu> 

On Mon, 27 Aug 2018, Jason Everling wrote:

> at the resource level config do you have each objectclass defined for each intent that these accounts fall under?
>
>      <objectType>
>         <displayName>Person Registry Account</displayName>
>         <default>true</default>
>         <objectClass>ri:inetOrgPerson</objectClass>
>         <auxiliaryObjectClass>ri:yourClass1</auxiliaryObjectClass>
>         <auxiliaryObjectClass>ri:yourClass2</auxiliaryObjectClass>
>         <auxiliaryObjectClass>ri:yourClass3</auxiliaryObjectClass>
>
>      <objectType>
>         <kind>entitlement</kind>
>         <intent>registryGroup</intent>
>         <displayName>Person Registry Group</displayName>
>         <default>true</default>
>         <objectClass>ri:groupOfNames</objectClass>
>         <auxiliaryObjectClass>ri:customGrpClass1</auxiliaryObjectClass>
>         <auxiliaryObjectClass>ri:customGrpClass2</auxiliaryObjectClass>
>
>
>
>
>
> On Mon, Aug 27, 2018 at 3:24 PM Andrew Morgan <morgan at oregonstate.edu <mailto:morgan at oregonstate.edu> <mailto:morgan at oregonstate.edu <mailto:morgan at oregonstate.edu> >> wrote:
> I conducted a further test, and I'm confused by what I'm seeing.
>
> I set the global Projection Policy to "none".  I assigned my 3 roles (Base
> ONID, Unix, and Google) to a user.  No changes were made to any accounts.
> The assignments were present on the user, but no projections were added.
> This is what I expected to see.  Great!
>
> Then, I imported the account from the ONIDLDAPDEV resource so that I could
> establish the link between the user and the account.  The import removed
> the role-assigned (from the Unix and Google roles) objectclasses and
> attributes!  Out of curiosity, I ran a reconciliation on that user - no
> changes.  Why did the import make any changes to the account??
>
> Andy Morgan
> Systems Administrator, Identity & Access Management
> Information Services | Oregon State University
> 541-737-8877 | is.oregonstate.edu <http://is.oregonstate.edu> <http://is.oregonstate.edu>
>
> On Mon, 27 Aug 2018, Morgan, Andrew Jason wrote:
>
>> Yes, you are reading between the lines correctly.
>>
>>
>> I have 3 resources:
>>
>> 1. GYBONID
>>
>> This is a DatabaseTable resource with only inbound mappings.  The table
>> is from our Banner system, a system of record that is our single (for now)
>> source of identities.  I imported these accounts to create approximately
>> 113,000 users in midPoint.  I have a LiveSync task that processes updates.
>>
>> 2. ONIDLDAPDEV
>>
>> This is an LDAP resource with only outbound mappings.It has approximately
>> 80,000 accounts all in the same OU.  There are 2 different types of
>> accounts: Regular and Retiree.  All accounts have the inetOrgPerson
>> objectclass plus eduPerson, osuPerson, and lpSghePerson auxiliary
>> objectclasses.  Regular accounts also have posixAccount, shadowAccount,
>> and googlePerson auxiliary objectclasses (Retirees don't get Unix or
>> Google).
>>
>> 3. ADDEV
>>
>> This is an LDAP resource with only outbound mappings. It has the same
>> number of accounts as ONIDLDAPDEV because our existing provisioning
>> scripts create both LDAP and AD accounts at the same time.  AD accounts
>> all have the same objectclasses.  For simplicity, let's ignore this
>> resource for now.
>>
>>
>>
>> I have 3 roles:
>>
>> 1. Base ONID
>>
>> This role induces the ONIDLDAPDEV and ADDEV resources.
>>
>> 2. Unix
>>
>> This role induces the posixAccount and shadowAccount objectclasses on the
>> ONIDLDAPDEV resource and has outbound mappings for their attributes.
>>
>> 3. Google
>>
>> This role induces the googlePerson objectclass on the ONIDLDAPDEV
>> resource and has outbound mappings for its attributes.
>>
>>
>>
>> When I import an account from ONIDLDAPDEV, the existing user has no roles
>> assigned.  Midpoint links the account to the user, but it also modifies
>> the ONIDLDAPDEV account.  Let me summarize what the audit log shows:
>>
>> Deltas:
>>   LensObjectDeltaOperation
>>     Delta:
>>       ObjectDelta<UserType>(UserType:73121f33-ee86-4d09-9769-72acecedea6e,MODIFY):
>>         metadata/modifyChannel
>>           REPLACE: http://midpoint.evolveum.com/xml/ns/public/provisioning/channels-3#import
>>
>>   LensObjectDeltaOperation
>>     Delta:
>>       ObjectDelta<UserType>(UserType:73121f33-ee86-4d09-9769-72acecedea6e,MODIFY):
>>         linkRef
>>           ADD: oid=5ad37e7e-c783-462e-9c1f-8b9eab5816b8(ShadowType)('osuuid=88313159795,ou=people,o=midpointdev')
>>
>>     Object name:
>>       PolyString(88313159795,88313159795)
>>     Resource: ONID LDAP DEV (ef2bc95b-76e0-48e2-86d6-3d4f02d3e1aa)
>>
>>   LensObjectDeltaOperation
>>     Delta:
>>       ObjectDelta<ShadowType>(ShadowType:5ad37e7e-c783-462e-9c1f-8b9eab5816b8,MODIFY):
>>         auxiliaryObjectClass
>>           DELETE: {...resource/instance-3}posixAccount, {...resource/instance-3}shadowAccount, {...resource/instance-3}googlePerson
>>           OLD: {...resource/instance-3}posixAccount, {...resource/instance-3}shadowAccount, {...resource/instance-3}osuPerson, {...resource/instance-3}lpSghePerson, {...resource/instance-3}googlePerson, {...resource/instance-3}eduPerson
>>         attributes/googlePrincipalName
>>           DELETE: <username>@oregonstate.edu <http://oregonstate.edu> <http://oregonstate.edu>
>>           OLD: <username>@oregonstate.edu <http://oregonstate.edu> <http://oregonstate.edu>
>>         attributes/googleMailEnabled
>>           DELETE: 1
>>           OLD: 1
>>         attributes/gecos
>>           DELETE: <redacted>,,,
>>           OLD: <redacted>,,,
>>         attributes/gidNumber
>>           DELETE: 300
>>           OLD: 300
>>         attributes/loginShell
>>           DELETE: /bin/bash
>>           OLD: /bin/bash
>>         attributes/homeDirectory
>>           DELETE: /users/u2/a/<username>
>>           OLD: /users/u2/a/<username>
>>         attributes/uidNumber
>>           DELETE: 7225
>>           OLD: 7225
>>
>>
>> It does this even when I have:
>>
>> <globalAccountSynchronizationSettings>
>>   <assignmentPolicyEnforcement>none</assignmentPolicyEnforcement>
>> </globalAccountSynchronizationSettings>
>>
>>
>> You can see my resource and role definitions here:
>>
>>   http://people.oregonstate.edu/~morgan/midpoint/
>>
>>
>> How can I import these accounts without midPoint trying to modify them?
>>
>> Thanks,
>>
>> Andy Morgan
>> Systems Administrator, Identity & Access Management
>> Information Services | Oregon State University
>> 541-737-8877 | is.oregonstate.edu <http://is.oregonstate.edu> <http://is.oregonstate.edu>
>>
>> On Sun, 26 Aug 2018, Keith Hazelton wrote:
>>
>>> Not sure I have a full picture of the setup, but I'd suggest looking at this: https://wiki.evolveum.com/display/midPoint/Mapping+Evaluation+Examples
>>>
>>>
>>> The notion of strong and weak attribute mapping seems promising here.
>>>
>>>
>>> Please correct my picture of how things are set up there. Reading between the lines, I get the sense that before you do anything with the LDAP or AD resources you somehow already have 80,000 user objects in midPoint. Is that correct? If so, how were they created?
>>>
>>> Mapping Evaluation Examples - midPoint - Evolveum Confluence<https://wiki.evolveum.com/display/midPoint/Mapping+Evaluation+Examples>
>>> wiki.evolveum.com <http://wiki.evolveum.com> <http://wiki.evolveum.com>
>>> Resource and Role Attribute Mappings. Resource attribute can be set by several means: manually specified in midPoint user interface, produced by a mapping in a role or in resource schema handling.
>>>
>>>
>>>
>>> __________
>>>
>>> email & jabber: keith.hazelton at wisc.edu <mailto:keith.hazelton at wisc.edu> <mailto:keith.hazelton at wisc.edu <mailto:keith.hazelton at wisc.edu> >    Sr. IT Architect
>>>
>>> calendar: http://go.wisc.edu/i6zxx0
>>>
>>> ________________________________
>>> From: midPoint <midpoint-bounces at lists.evolveum.com <mailto:midpoint-bounces at lists.evolveum.com> <mailto:midpoint-bounces at lists.evolveum.com <mailto:midpoint-bounces at lists.evolveum.com> >> on behalf of Andrew Morgan <morgan at oregonstate.edu <mailto:morgan at oregonstate.edu> <mailto:morgan at oregonstate.edu <mailto:morgan at oregonstate.edu> >>
>>> Sent: Friday, August 24, 2018 7:42:26 PM
>>> To: midpoint at lists.evolveum.com <mailto:midpoint at lists.evolveum.com> <mailto:midpoint at lists.evolveum.com <mailto:midpoint at lists.evolveum.com> >
>>> Subject: [midPoint] Standing up midPoint with existing accounts
>>>
>>> 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 <http://is.oregonstate.edu> <http://is.oregonstate.edu>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com> <mailto: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> <mailto: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> <mailto: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



This email, and any attachment, is confidential and also privileged. If you have received it in error, please notify me immediately and delete it from your system along with any attachments. You should not copy or use it for any purpose, nor disclose its contents to any other person. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180827/5be63e10/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4836 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180827/5be63e10/attachment.bin>


More information about the midPoint mailing list