[midPoint] Standing up midPoint with existing accounts
Jason Everling
jeverling at bshp.edu
Tue Aug 28 01:24:18 CEST 2018
if all of them are kind -> account then you could still just run 1 import
task, using different ones you would then have to create multiple tasks.
On Mon, Aug 27, 2018 at 6:18 PM Jason Everling <jeverling at bshp.edu> wrote:
> Ah I see, didn't know that was added. Have been running since 3.1 so ours
> has been through a lot of upgrades over time and most of our configs are
> still as is except for changes that needed to happen. It looks like it
> should working as expected then, maybe you hit a bug.
> http://jira.evolveum.com . You can always try what Brad mentioned.
>
> We are using intents in our resources to assign different objectClasses
> that really need the separation. When running import with different intents
> you would just create an import task for each intent, the same for live
> sync tasks.
>
>
> JASON
>
>
> On Mon, Aug 27, 2018 at 6:16 PM Brad Fardig <brad.fardig at cogitogroup.net>
> wrote:
>
>> 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>
>> 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
>>
>>
>>
>> *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. *
>> _______________________________________________
>> 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/e5faf331/attachment.htm>
More information about the midPoint
mailing list