[midPoint] OpenLDAP resource unavailable even though Test Connection comes back green

[Florin. Stingaciu]

Hey Radovan,

Thanks for you reply. Upon further debugging, it turns out there was a
problem with my server as you had suggested. There must've been some
character encoding issue when I added the Groups OU (I'm assuming it
must've been a trailing space character) and thus Midpoint couldn't write
to that location as it did not exist.

Also thanks for the write up on debugging the LDAP connector! That will
definitely come in handy at some point.

Thanks,
-F

On Tue, May 24, 2016 at 3:34 AM, Radovan Semancik <
radovan.semancik at evolveum.com> wrote:

> Hi,
>
> I have seen similar issue with TLS-enabled OpenLDAP. It looks like the
> default setting for TLS ciphers in OpenLDAP and some Java versions do not
> match. The problem is made worse by the notoriously bad error reporting and
> diagnostics in JCE. And honestly Apache Directory API is also not entirely
> perfect in this aspect. And that was also the reason for false "green"
> light the last time when I have experienced a similar behavior. Yet,
> according to your description this does not seem to be a TLS problem.
>
> Anyway, there is nice way how to troubleshoot the LDAP connector by
> enabling the logging. I have just realized that it is not documented
> anywhere, so I have documented it just now:
> https://wiki.evolveum.com/display/midPoint/LDAP+Connector+Troubleshooting
>
> Therefore please enable the connector logging. It will give you more
> details. However I'm a bit afraid that the "operationsError:  (1)" suggests
> an error on the server side. You may need to enable logging on the OpenLDAP
> server to see what is the root cause. The OpenLDAP is indeed a great
> directory server. But it is not easy to manage it or to diagnose the
> issues. Sometimes you just have to guess. But let's see the LDAP request
> and response. Maybe it will contain some hint.
>
> --
> Radovan Semancik
> Software Architectevolveum.com
>
>
>
> On 05/24/2016 01:46 AM, Florin. Stingaciu wrote:
>
> Hello,
>
> I'm running into this strange issue where I defined a resource, an
> OpenLDAP backend. I made sure to import the appropriate certificate within
> the keystore. After importing the resource, I test the connection and
> everything is green and good to go, however, if I try to assign an account
> to a user on this resource I get the following error:
>
> Could not create object=cn=testGroup,ou=Groups,dc=mgmt,dc=example,dc=net
>> on the resource, because resource: OpenLDAP Accounts Schema
>> (OID:fd6c4614-3f1d-42c6-aec5-3d367ce04f40) is unreachable at the moment.
>> Shadow is stored in the repository and the resource object will be created
>> when the resource goes online
>
>
> The above error is taken from the GUI. In the logs, I have the following:
>
>  ICF Exception
>> org.identityconnectors.framework.common.exceptions.ConnectorIOException in
>> connector:5b12de31-8e0c-48ab-8e5b-199467c16eab(ICF
>> com.evolveum.polygon.connector.ldap.LdapConnector v1.4.3.0-SNAPSHOT):
>> resource:fd6c4614-3f1d-42c6-aec5-3d367ce04f40(OpenLDAP Accounts Schema):
>> Error adding LDAP entry cn=testGroup,ou=Groups,dc=mgmt,dc=example,dc=net:
>> operationsError:  (1)
>
>
> I've done this numerous times and never had this issue. I've tried
> debuging it for the last two hours but I'm coming up empty handed. Here's
> my connector config:
>
>  <icfc:configurationProperties xmlns:gen36="
>> http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/bundle/com.evolveum.polygon.connector-ldap/com.evolveum.polygon.connector.ldap.LdapConnector
>> ">
>>          <gen36:host>example.symcpe.net</gen36:host>
>>          <gen36:port>389</gen36:port>
>>          <gen36:connectionSecurity>starttls</gen36:connectionSecurity>
>>          <gen36:bindDn>cn=admin</gen36:bindDn>
>>          <gen36:bindPassword>
>>             <t:encryptedData>
>>                <t:encryptionMethod>
>>                   <t:algorithm>
>> <http://www.w3.org/2001/04/xmlenc#aes128-cbc>
>> http://www.w3.org/2001/04/xmlenc#aes128-cbc</t:algorithm>
>>                </t:encryptionMethod>
>>                <t:keyInfo>
>>                   <t:keyName>hJhPsasaSRiv/SoyMVjnDmRq3PKNuwQ=</t:keyName>
>>                </t:keyInfo>
>>                <t:cipherData>
>>
>>  <t:cipherValue>ukt6JOfbox28PwIWwN4xnzg8/q8ZUHPlQyRm1IevYom6eaqUkzpxSiPKLxF6p4yO+v19fgegOwfqDxaXumzIQ==</t:cipherValue>
>>                </t:cipherData>
>>             </t:encryptedData>
>>          </gen36:bindPassword>
>>          <gen36:baseContext>dc=mgmt,dc=example,dc=net</gen36:baseContext>
>>          <gen36:passwordHashAlgorithm>SSHA</gen36:passwordHashAlgorithm>
>>          <gen36:pagingStrategy>auto</gen36:pagingStrategy>
>>          <gen36:vlvSortAttribute>uid</gen36:vlvSortAttribute>
>>          <gen36:vlvSortOrderingRule>2.5.13.3</gen36:vlvSortOrderingRule>
>>          <gen36:uidAttribute>dn</gen36:uidAttribute>
>>
>>  <gen36:operationalAttributes>memberOf</gen36:operationalAttributes>
>>       </icfc:configurationProperties>
>>    </connectorConfiguration>
>
>
> Any help in debugging this issue would be greatly appreciated.  Oh also,
> yes I do have write access to this ldap server :)
>
> Thanks,
> -F
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160525/42fec2e1/attachment.htm>