[midPoint] New ldap connector and auxiliary objectClasses

[Jason Everling]

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>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 listmidPoint at lists.evolveum.comhttp://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/20151026/d1c75099/attachment.htm>