[midPoint] New ldap connector and auxiliary objectClasses
midpoint at mybtinternet.com
midpoint at mybtinternet.com
Thu Nov 5 14:00:27 CET 2015
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.
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>
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.
_______________________________________________
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/5f84b9f0/attachment.htm>
More information about the midPoint
mailing list