[midPoint] New ldap connector and auxiliary objectClasses
Ivan Noris
ivan.noris at evolveum.com
Thu Nov 5 13:48:34 CET 2015
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
>> <mailto:radovan.semancik at evolveum.com>> wrote:
>>
>> Hi,
>>
>> On 10/23/2015 03:20 PM, midpoint at mybtinternet.com
>> <mailto: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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20151105/6816fafd/attachment.htm>
More information about the midPoint
mailing list