[midPoint] New ldap connector and auxiliary objectClasses
midpoint at mybtinternet.com
midpoint at mybtinternet.com
Thu Nov 5 13:40:34 CET 2015
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> 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
_______________________________________________
midPoint mailing list
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
--
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20151105/4876be1a/attachment.htm>
More information about the midPoint
mailing list