[midPoint] Existing Active Directory Users

Thu Oct 16 15:48:09 CEST 2014

Thanks for the explanation,

AD only needs to be authoritative during the initial deployment since we
have thousands of accounts in AD, after that, all accounts will be
modified/added using midpoint.

I think using the method I outlined last to build the DN is more or less
what I am moving towards. I have looked through AD attributes and the
attribute, "ou" in AD is not used and would make sense to populate that
attribute with the actual OU. I can simply use a powershell script to add
the correct value to this attribute based on the users current ou and then
build the DN in midpoint off this value.

Using the "ou" attribute in AD might also be the best way since later on I
can use the attribute in roles and orgs, I have been looking to the orgsync
story test on github for inspiration.

JASON

On Thu, Oct 16, 2014 at 3:14 AM, Ivan Noris <Ivan.Noris at evolveum.com> wrote:

> Hi Jason,
>
> setting modify=false will dissallow midPoint to change this attribute, but
> be adwised that if you disable modification of icfs:name attribute, you
> will be unable to rename/move the AD accounts.
>
> I believe that the moving of your users (described in your earlier emails)
> could be caused by the resource configuration being two-direction.
>
> If you are using AD for Active Sync, you are making it authoritative
> source. If account is synchronized to midPoint and midPoint is modifying it
> back, it will evaluate icfs:name outbound expression and behave accordingly.
>
> So, midPoint was trying to update icfs:name (DN) because of the
> configuration in midPoint.
>
> You can also have the icfs:name mapping configured as "weak" so it will
> never recompute values if the target (AD) value already exists.
>
> This will effectively disable automatic renaming/moving as well.
>
> Disabling modification of the attribute does also prevent you from
> modifying that attribute in GUI. Setting weak strength in outbound for
> icfs:name will only limit propagation of changes from midPoint to AD.
> The example of weak mapping:
>
> <attribute>
>   <ref>icfs:name</ref>
>   <outbound>
>     <strength>weak</strength>
>     <source>
>       ....
>
> Do you need your Active Directory to be authoritative for changes, or only
> for first importing of user data?
> Is there any attribute in AD that you could use to store in midPoint
> user's attribute when importing and then in provisioning you could deduce
> the correct DN from it? In your case the extended attribute
> eduPersonAffiliation could hold the value.
>
> Regards,
> ivan
>
> ------------------------------
>
> *From: *"Jason Everling" <jeverling at bshp.edu>
> *To: *"midPoint General Discussion" <midpoint at lists.evolveum.com>
> *Sent: *Wednesday, October 15, 2014 4:41:06 PM
> *Subject: *Re: [midPoint] Existing Active Directory Users
>
>
> Just a follow up on this, I was comparing the AD Sync Resource XML with
> the OpenDJ sample and I noticed within that field on how the DN should look
> like I added the below to the <limitations> section
>
> <modify>false</modify>
>
> After adding that, existing accounts in AD are not moved into the OU
> defined in the <code> section. The user is imported into Midpoint and the
> account stays in the original OU.
>
> Am I correct on why the account stays in the correct OU after adding
> <modify>false</modify> ?
>
> Additionally, I did some further testing with this:
>
> <expression>
> <script>
> <code>
> 'cn='+givenName+' '+familyName+iterationToken+',ou=The
> '+eduPersonAffiliation+',dc=test,dc=local'
> </code>
> </script>
> </expression>
>
> This actually works! New accounts are added to the OU in AD based on the
> attribute 'eduPersonAffiliation' so if the value is Student then the new
> account is built/placed in OU=The Student,DC=TEST,DC=LOCAL
>
> JASON
>
> On Fri, Oct 10, 2014 at 5:50 PM, Pavol Mederly <mederly at evolveum.com>
> wrote:
>
>> Jason,
>>
>> look at the following:
>>
>> 'cn='+givenName+' '+familyName+iterationToken+',cn=Users,dc=test,dc=local'
>>
>> It is in schemaHandling -> objectType (account) -> attribute (icfs:name)
>> -> outbound -> expression. It tells midPoint how the Distinguished Name for
>> user accounts should look like - and it points to the Users container. (I'm
>> not 100% sure why midPoint moved the user during initial import, but
>> definitely this is the place where you tell midPoint where should your
>> accounts go.)
>>
>> Anyway, for start, I would recommend you to deal with a much simpler
>> scenario: try not to work with pre-existing accounts, but instead try to
>> provision new accounts into an "empty" resource.
>>
>> It could be OpenDJ (it is preferred because of the connector maturity),
>> or, if you wish, AD. But if AD, it would be better to create an empty OU
>> and then do all the experiments within it. (In that case don't forget to
>> set icfcad:Container to that OU, in order for midPoint to "see" only
>> objects in it.) Play with creating user accounts, using various kinds of
>> attribute mappings, etc, and you'll gradually see how things work. Then you
>> can add live sync and reconciliation.
>>
>> Definitely, start with users and accounts (skipping roles, orgs,
>> entitlements, groups, etc. for the time being).
>>
>> Read our wiki; there are nice explanations for basic mechanisms there.
>>
>> Hope this helps,
>> Pavol
>>
>>
>>
>> On 11. 10. 2014 0:30, Jason Everling wrote:
>>
>> Thanks Again, Midpoient looks like it will do what we need it too, just a
>> ton of configuration but first I need to get the basics understood,
>>
>> I attached the xml
>>
>> JASON
>>
>> On Fri, Oct 10, 2014 at 5:03 PM, Pavol Mederly <mederly at evolveum.com>
>> wrote:
>>
>>> Hm, that's interesting.
>>>
>>> Please, could you post here your resource configuration (i.e. AD
>>> Resource object, i.e. the "ad advanced sync" sample with your local
>>> changes)?
>>>
>>> It's too late today, so perhaps I'll be able to have a look at it
>>> tomorrow evening/Monday morning but nevertheless please send it here.
>>>
>>> Best regards,
>>> Pavol
>>>
>>>
>>>
>>> On 10. 10. 2014 23:58, Jason Everling wrote:
>>>
>>> Yes that is correct,
>>>
>>> I have a development environment setup, I got the AD Resource/Connector
>>> setup. I haven't done any type of modification outside of adding the sample
>>> ad advanced sync xml.
>>>
>>> Before running import within Midpoint under Resource, Accounts for AD
>>> the accounts resided in the container "OU=Students,DC=TEST,DC=LOCAL" .
>>> After I import them in Midpoint the accounts get moved into
>>> "CN=Users,DC=TEST,DC=LOCAL"
>>>
>>> I had thought it would have left them in the current OU but they get
>>> moved, I haven't setup any roles yet besides the default that are there but
>>> I haven't assigned them yet. I am just getting it setup so I can better
>>> understand how the system works.
>>>
>>> Thanks,
>>> JASON
>>>
>>> On Fri, Oct 10, 2014 at 4:51 PM, Pavol Mederly <mederly at evolveum.com>
>>> wrote:
>>>
>>>> Hello Jason,
>>>>
>>>> I'm not sure I understand your problem.
>>>>
>>>> Is it so that your users are *moved* from AD container into another AD
>>>> container during "import into midPoint" operation?
>>>> I've never seen such behavior.
>>>>
>>>> BTW, of course, midPoint can put accounts into any container you define
>>>> - based on organization or role assignment or any other condition.
>>>>
>>>> Perhaps send here more information about your situation. E.g. what was
>>>> the situation in your AD before the operation, what exactly the operation
>>>> was, and what was the situation after that.
>>>>
>>>> Best regards,
>>>> Pavol
>>>>
>>>>
>>>> On 10. 10. 2014 23:40, Jason Everling wrote:
>>>>
>>>> Is there a way I can keep the existing Active Directory users in their
>>>> current container in AD during Import/Provisioning.
>>>>
>>>> Can someone point me in the right direction so that I could do this,
>>>> maybe provision new users to specific container based on membership, role
>>>> or group?
>>>>
>>>> Currently when a user is imported they are put in the container that is
>>>> specified in the resource xml which is fine for development but once we get
>>>> into production accounts would need to be provisioned into the appropriate
>>>> containers.
>>>>
>>>> Thanks Again,
>>>>
>>>> JASON
>>>>
>>>>
>>>>
>>>> CONFIDENTIALITY NOTICE:
>>>> This e-mail together with any attachments is proprietary and
>>>> confidential; intended for only the recipient(s) named above and may
>>>> contain information that is privileged. You should not retain, copy or use
>>>> this e-mail or any attachments for any purpose, or disclose all or any part
>>>> of the contents to any person. Any views or opinions expressed in this
>>>> e-mail are those of the author and do not represent those of the Baptist
>>>> School of Health Professions. If you have received this e-mail in error, or
>>>> are not the named recipient(s), you are hereby notified that any review,
>>>> dissemination, distribution or copying of this communication is prohibited
>>>> by the sender and to do so might constitute a violation of the Electronic
>>>> Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately
>>>> notify the sender and delete this e-mail and any attachments from your
>>>> computer.
>>>>
>>>>
>>>> _______________________________________________
>>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> midPoint mailing list
>>>> midPoint at lists.evolveum.com
>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>
>>>>
>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE:
>>> This e-mail together with any attachments is proprietary and
>>> confidential; intended for only the recipient(s) named above and may
>>> contain information that is privileged. You should not retain, copy or use
>>> this e-mail or any attachments for any purpose, or disclose all or any part
>>> of the contents to any person. Any views or opinions expressed in this
>>> e-mail are those of the author and do not represent those of the Baptist
>>> School of Health Professions. If you have received this e-mail in error, or
>>> are not the named recipient(s), you are hereby notified that any review,
>>> dissemination, distribution or copying of this communication is prohibited
>>> by the sender and to do so might constitute a violation of the Electronic
>>> Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately
>>> notify the sender and delete this e-mail and any attachments from your
>>> computer.
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>
>>
>>
>> CONFIDENTIALITY NOTICE:
>> This e-mail together with any attachments is proprietary and
>> confidential; intended for only the recipient(s) named above and may
>> contain information that is privileged. You should not retain, copy or use
>> this e-mail or any attachments for any purpose, or disclose all or any part
>> of the contents to any person. Any views or opinions expressed in this
>> e-mail are those of the author and do not represent those of the Baptist
>> School of Health Professions. If you have received this e-mail in error, or
>> are not the named recipient(s), you are hereby notified that any review,
>> dissemination, distribution or copying of this communication is prohibited
>> by the sender and to do so might constitute a violation of the Electronic
>> Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately
>> notify the sender and delete this e-mail and any attachments from your
>> computer.
>>
>>
>> _______________________________________________
>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>
>
>
> CONFIDENTIALITY NOTICE:
> This e-mail together with any attachments is proprietary and confidential;
> intended for only the recipient(s) named above and may contain information
> that is privileged. You should not retain, copy or use this e-mail or any
> attachments for any purpose, or disclose all or any part of the contents to
> any person. Any views or opinions expressed in this e-mail are those of the
> author and do not represent those of the Baptist School of Health
> Professions. If you have received this e-mail in error, or are not the
> named recipient(s), you are hereby notified that any review, dissemination,
> distribution or copying of this communication is prohibited by the sender
> and to do so might constitute a violation of the Electronic Communications
> Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the
> sender and delete this e-mail and any attachments from your computer.
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
>
> --
>   Ing. Ivan Noris
>   Senior Identity Management Engineer
>   evolveum.com
>   ___________________________________________
>            "Idem per idem - semper idem Vix."
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>

-- 

CONFIDENTIALITY NOTICE:
This e-mail together with any attachments is proprietary and confidential; 
intended for only the recipient(s) named above and may contain information 
that is privileged. You should not retain, copy or use this e-mail or any 
attachments for any purpose, or disclose all or any part of the contents to 
any person. Any views or opinions expressed in this e-mail are those of the 
author and do not represent those of the Baptist School of Health 
Professions. If you have received this e-mail in error, or are not the 
named recipient(s), you are hereby notified that any review, dissemination, 
distribution or copying of this communication is prohibited by the sender 
and to do so might constitute a violation of the Electronic Communications 
Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the 
sender and delete this e-mail and any attachments from your computer. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20141016/c0110eb5/attachment.htm>