[midPoint] Standing up midPoint with existing accounts

Jason Everling jeverling at bshp.edu
Tue Aug 28 00:40:35 CEST 2018


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> 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> 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>
>> 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
>>>
>>> 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>> 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>
>>> >
>>> > 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>
>>> >>           OLD: <username>@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>
>>> >>
>>> >> 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>
>>> >>> 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>    Sr. IT Architect
>>> >>>
>>> >>> calendar: http://go.wisc.edu/i6zxx0
>>> >>>
>>> >>> ________________________________
>>> >>> From: midPoint <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>>
>>> >>> Sent: Friday, August 24, 2018 7:42:26 PM
>>> >>> To: 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>
>>> >>> _______________________________________________
>>> >>> 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<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/20180827/d7e6b788/attachment.htm>


More information about the midPoint mailing list