<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
<br>
<div class="moz-cite-prefix">On 11/05/2015 02:00 PM,
<a class="moz-txt-link-abbreviated" href="mailto:midpoint@mybtinternet.com">midpoint@mybtinternet.com</a> wrote:<br>
</div>
<blockquote
cite="mid:26141301.27906.1446728427555.JavaMail.defaultUser@defaultHost"
type="cite">Hi Ivan,<br>
<br>
Yes, that was also my interpretation of what happens ... the
point of deleting the older was from reference<br>
of procedure in the Wiki .. don't recall the exact page. What I
was attempting to pre-empt was creating a<br>
new resource and this subsequently using the older connector.<br>
<br>
So, what is supposed to happen when a new resource is created
and more than one connector exists?<br>
I seem to recall that failed, but can't recall authoritatively.<br>
<br>
</blockquote>
<br>
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.<br>
<br>
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:<br>
- use filter for connectorRef with connectorType and
connectorVersion (nicer)<br>
- don't use connectorRef, but reference the connector by oid (oid is
different in each environment)<br>
<br>
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.<br>
<br>
Regards,<br>
Ivan<br>
<br>
<blockquote
cite="mid:26141301.27906.1446728427555.JavaMail.defaultUser@defaultHost"
type="cite">Regards,<br>
Anton<br>
<br>
<blockquote style="margin-right: 0px; margin-left:15px;">----Original
message----<br>
From : <a class="moz-txt-link-abbreviated" href="mailto:ivan.noris@evolveum.com">ivan.noris@evolveum.com</a><br>
Date : 05/11/2015 - 12:48 (GMT)<br>
To : <a class="moz-txt-link-abbreviated" href="mailto:midpoint@lists.evolveum.com">midpoint@lists.evolveum.com</a><br>
Subject : Re: [midPoint] New ldap connector and auxiliary
objectClasses<br>
<br>
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
Hi Anton,<br>
<br>
did not quite understand the last thing about deleting
connectors.<br>
<br>
Did you try to delete/remove connector which is bundled with
midpoint? By deleting Connector object in repository?<br>
<br>
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.<br>
<br>
Regards,<br>
Ivan<br>
<br>
<div class="moz-cite-prefix">On 11/05/2015 01:40 PM, <a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:midpoint@mybtinternet.com"><a class="moz-txt-link-abbreviated" href="mailto:midpoint@mybtinternet.com">midpoint@mybtinternet.com</a></a>
wrote:<br>
</div>
<blockquote
cite="mid:33476908.26175.1446727234203.JavaMail.defaultUser@defaultHost"
type="cite">Hi,<br>
<br>
I have not tried talking to AD, not in the new env, but have
used the snapshot connector on OpenDJ ...<br>
Also had to switch to
connector-ldap-1.4.2.0-20151029.212327-51.jar as the other
(older) was<br>
replaced.<br>
<br>
Can confirm this works nicely with my use of auxiliary
objectClasses. Also, I like the feel of the new<br>
connector; much cleaner ... great job!<br>
<br>
One thing I did notice; I delete the older connector using
REST on build phase. The new resource<br>
is created using the new connector also during build. As I
also update system configuration, a<br>
restart of midPoint is required. Post restart, the older
connector is back in the list of connectors.<br>
<br>
Regards,<br>
Anton<br>
<br>
<br>
<blockquote style="margin-right: 0px; margin-left:15px;">----Original
message----<br>
From : <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:jeverling@bshp.edu">jeverling@bshp.edu</a><br>
Date : 26/10/2015 - 19:38 (GMT)<br>
To : <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:midpoint@lists.evolveum.com">midpoint@lists.evolveum.com</a><br>
Subject : Re: [midPoint] New ldap connector and auxiliary
objectClasses<br>
<br>
<div dir="ltr">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.
<div><br>
</div>
<div>I will also test it out in my dev environment and
report anything,</div>
<div><br>
</div>
<div>JASON</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Oct 24, 2015 at 2:55 PM,
Ivan Noris <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ivan.noris@evolveum.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ivan.noris@evolveum.com">ivan.noris@evolveum.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Hi Jason,<br>
<br>
yes, with some restrictions - no home directory
creation, no scripting on server side, no Exchange
support.<br>
<br>
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.<br>
<br>
Regards,<br>
Ivan
<div>
<div class="h5"><br>
<br>
<div>On 10/23/2015 09:59 PM, Jason Everling
wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<div dir="ltr">A built-in AD connector? Wow,
that is great! Does that mean we would not
have to rely on a connector server anymore?
<div><br>
</div>
<div>JASON</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Oct 23,
2015 at 9:25 AM, Radovan Semancik <span
dir="ltr"><<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:radovan.semancik@evolveum.com">radovan.semancik@evolveum.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">Hi,<span><br>
<br>
On 10/23/2015 03:20 PM, <a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:midpoint@mybtinternet.com"><a class="moz-txt-link-abbreviated" href="mailto:midpoint@mybtinternet.com">midpoint@mybtinternet.com</a></a>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> I agree
with your principals around
retrieving and interpreting the
schema. However,<br>
attribute names are not supposed
to be case sensitive. I have worked
with many<br>
servers, and have only
encountered one that was. I believe
this was configurable<br>
in that particular server.<br>
</blockquote>
<br>
</span> 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 ...<span><br>
<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> As for
the server that provided no syntax
definitions; wow!! I have not
encountered<br>
that before ... do you mean when
querying the server or no syntax
period?<br>
</blockquote>
<br>
</span> 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 ...<br>
<br>
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.
<div>
<div><br>
<br>
-- <br>
Radovan Semancik<br>
Software Architect<br>
<a moz-do-not-send="true"
href="http://evolveum.com"
rel="noreferrer" target="_blank">evolveum.com</a><br>
<br>
_______________________________________________<br>
midPoint mailing list<br>
<a moz-do-not-send="true"
href="mailto:midPoint@lists.evolveum.com"
target="_blank">midPoint@lists.evolveum.com</a><br>
<a moz-do-not-send="true"
href="http://lists.evolveum.com/mailman/listinfo/midpoint"
rel="noreferrer" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>
<div dir="ltr">JASON</div>
</div>
</div>
<br>
</div>
</div>
<font size="2"><br>
<br>
CONFIDENTIALITY NOTICE:<br>
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. </font><br>
<span class=""> <br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
midPoint mailing list
<a moz-do-not-send="true" href="mailto:midPoint@lists.evolveum.com" target="_blank">midPoint@lists.evolveum.com</a>
<a moz-do-not-send="true" href="http://lists.evolveum.com/mailman/listinfo/midpoint" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
</span></blockquote>
<span class="HOEnZb"><font color="#888888"> <br>
</font></span>
<pre cols="72"><span class="HOEnZb"><font color="#888888">--
Ing. Ivan Noris
Senior Identity Management Engineer & IDM Architect
</font></span><span class=""><a moz-do-not-send="true" href="http://evolveum.com" target="_blank">evolveum.com</a> <a moz-do-not-send="true" href="http://evolveum.com/blog/" target="_blank">evolveum.com/blog/</a>
___________________________________________________
"Semper Id(e)M Vix."
</span></pre>
</div>
<br>
_______________________________________________<br>
midPoint mailing list<br>
<a moz-do-not-send="true"
href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a><br>
<a moz-do-not-send="true"
href="http://lists.evolveum.com/mailman/listinfo/midpoint"
rel="noreferrer" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div dir="ltr">JASON</div>
</div>
</div>
<br>
<font size="2"><br>
<br>
CONFIDENTIALITY NOTICE:<br>
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. </font><br>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
midPoint mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Ing. Ivan Noris
Senior Identity Management Engineer & IDM Architect
evolveum.com evolveum.com/blog/
___________________________________________________
"Semper Id(e)M Vix."
</pre>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
midPoint mailing list
<a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<a class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Ing. Ivan Noris
Senior Identity Management Engineer & IDM Architect
evolveum.com evolveum.com/blog/
___________________________________________________
"Semper Id(e)M Vix."
</pre>
</body>
</html>