[midPoint] New ldap connector and auxiliary objectClasses
Ivan Noris
ivan.noris at evolveum.com
Thu Nov 5 14:52:25 CET 2015
Hi,
On 11/05/2015 02:00 PM, midpoint at mybtinternet.com wrote:
> Hi Ivan,
>
> Yes, that was also my interpretation of what happens ... the point
> of deleting the older was from reference
> of procedure in the Wiki .. don't recall the exact page. What I was
> attempting to pre-empt was creating a
> new resource and this subsequently using the older connector.
>
> So, what is supposed to happen when a new resource is created and
> more than one connector exists?
> I seem to recall that failed, but can't recall authoritatively.
>
if more than one connector of the same connectorType exist, they must
have different version. It's no problem to have more than 1 version of
the connector, for example for migration purposes.
The only drawback is that if you import resource XML and the
connectorRef is a filter, it may find more than connector and fails. Two
options:
- use filter for connectorRef with connectorType and connectorVersion
(nicer)
- don't use connectorRef, but reference the connector by oid (oid is
different in each environment)
Eventually with newer midpoint you'll have also newer connector bundled
and you can get rid of your added connector and use the bundled and
remove the restriction for connectorVersion in the filter.
Regards,
Ivan
> Regards,
> Anton
>
> ----Original message----
> From : ivan.noris at evolveum.com
> Date : 05/11/2015 - 12:48 (GMT)
> To : midpoint at lists.evolveum.com
> Subject : Re: [midPoint] New ldap connector and auxiliary
> objectClasses
>
> Hi Anton,
>
> did not quite understand the last thing about deleting connectors.
>
> Did you try to delete/remove connector which is bundled with
> midpoint? By deleting Connector object in repository?
>
> If this is so, the connector is still bundled, it's somewhere in
> WEB-INF/lib and corresponding Connector object will be created in
> repository when midpoint is starting.
>
> Regards,
> Ivan
>
> On 11/05/2015 01:40 PM, midpoint at mybtinternet.com wrote:
>> Hi,
>>
>> I have not tried talking to AD, not in the new env, but have
>> used the snapshot connector on OpenDJ ...
>> Also had to switch to
>> connector-ldap-1.4.2.0-20151029.212327-51.jar as the other
>> (older) was
>> replaced.
>>
>> Can confirm this works nicely with my use of auxiliary
>> objectClasses. Also, I like the feel of the new
>> connector; much cleaner ... great job!
>>
>> One thing I did notice; I delete the older connector using REST
>> on build phase. The new resource
>> is created using the new connector also during build. As I also
>> update system configuration, a
>> restart of midPoint is required. Post restart, the older
>> connector is back in the list of connectors.
>>
>> Regards,
>> Anton
>>
>>
>> ----Original message----
>> From : jeverling at bshp.edu
>> Date : 26/10/2015 - 19:38 (GMT)
>> To : midpoint at lists.evolveum.com
>> Subject : Re: [midPoint] New ldap connector and auxiliary
>> objectClasses
>>
>> That is good news! I don't think, out of all the other
>> systems I looked at a while back, had this type of feature or
>> on any of their road maps, they all required a connector
>> server. We do not use the scripting or exchange features, we
>> use Office 365/Google Apps which currently has their own sync
>> running.
>>
>> I will also test it out in my dev environment and report
>> anything,
>>
>> JASON
>>
>> On Sat, Oct 24, 2015 at 2:55 PM, Ivan Noris
>> <ivan.noris at evolveum.com <mailto:ivan.noris at evolveum.com>> wrote:
>>
>> Hi Jason,
>>
>> yes, with some restrictions - no home directory creation,
>> no scripting on server side, no Exchange support.
>>
>> My coleagues are already testing/deploying the connector
>> and (will) have more real-life experiences soon. I expect
>> I will probably also deploy it the following weeks.
>>
>> Regards,
>> Ivan
>>
>>
>> On 10/23/2015 09:59 PM, Jason Everling wrote:
>>> A built-in AD connector? Wow, that is great! Does that
>>> mean we would not have to rely on a connector server
>>> anymore?
>>>
>>> JASON
>>>
>>> On Fri, Oct 23, 2015 at 9:25 AM, Radovan Semancik
>>> <radovan.semancik at evolveum.com> wrote:
>>>
>>> Hi,
>>>
>>> On 10/23/2015 03:20 PM, midpoint at mybtinternet.com wrote:
>>>
>>> I agree with your principals around
>>> retrieving and interpreting the schema. However,
>>> attribute names are not supposed to be case
>>> sensitive. I have worked with many
>>> servers, and have only encountered one that
>>> was. I believe this was configurable
>>> in that particular server.
>>>
>>>
>>> Yes, that's right. They are not supposed to be case
>>> sensitive. But I think it is good practice for
>>> operations to use the same capitalization as is
>>> specified in the schema. I have seen some problems
>>> with this in the past. I'm not sure how much this
>>> applies to current LDAP servers, but it is perhaps
>>> better to stay on the safe side. And the same
>>> applies to object classes. Actually, I have seen a
>>> problem with objectclass name capitalization just a
>>> couple of days ago ...
>>>
>>> As for the server that provided no syntax
>>> definitions; wow!! I have not encountered
>>> that before ... do you mean when querying the
>>> server or no syntax period?
>>>
>>>
>>> Actually, the attributeTypes definition provided
>>> syntax OID (otherwise it would be a complete
>>> disaster). But there was no ldapSyntaxes definition.
>>> None at all. Fortunately, the Apache Directory API
>>> still works with this. Just instead of
>>> attributeType.getSyntax().getOid() I had to use
>>> attibuteType.getSyntaxOid() - which seems to be the
>>> same but it is not. The former takes OID from
>>> ldapSyntaxes definition, the latter takes it from
>>> attributeTypes definition. So obviously, the former
>>> fails if there are no ldapSyntaxes definition.
>>> Simple fix, but unless you encounter a server like
>>> that it is hard to believe that this can actually
>>> happen ...
>>>
>>> So, the bottom line is that the more LDAP servers
>>> are tested with the new LDAP connector the more
>>> robust it will become. For now we have tested it
>>> with OpenLDAP, OpenDJ, OpenDS, 389ds, eDirectory and
>>> Active Directory. I'd appreciate reports of
>>> connector success/failure with any other directory
>>> server.
>>>
>>>
>>> --
>>> Radovan Semancik
>>> Software Architect
>>> evolveum.com <http://evolveum.com>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> <mailto:midPoint at lists.evolveum.com>
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>>
>>>
>>> --
>>> 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 list
>>> midPoint at lists.evolveum.com
>>> <mailto:midPoint at lists.evolveum.com>
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>> -- Ing. Ivan Noris Senior Identity Management Engineer &
>> IDM Architect evolveum.com <http://evolveum.com>
>> evolveum.com/blog/ <http://evolveum.com/blog/>
>> ___________________________________________________
>> "Semper Id(e)M Vix."
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>>
>> --
>> 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 list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
> --
> Ing. Ivan Noris
> Senior Identity Management Engineer & IDM Architect
> evolveum.com evolveum.com/blog/
> ___________________________________________________
> "Semper Id(e)M Vix."
>
>
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
--
Ing. Ivan Noris
Senior Identity Management Engineer & IDM Architect
evolveum.com evolveum.com/blog/
___________________________________________________
"Semper Id(e)M Vix."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20151105/170bce08/attachment.htm>
More information about the midPoint
mailing list