[midPoint] New ldap connector and auxiliary objectClasses

Ivan Noris ivan.noris at evolveum.com
Sat Oct 24 21:55:14 CEST 2015


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
> 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/20151024/e7d968cd/attachment.htm>


More information about the midPoint mailing list