Unable to connect to Vault, Designer 4.7.2

I am running into an issue with Designer 4.7.2 where there are some Vaults I am not able to connect. I tried using Secure and Non-Secure. I am certain the connection information is accurate as I verified connectivity via Apache Directory Studio, and loading DXCMD on the console and used an LDAP DN to connect. Both worked fine. As far as I can tell, the certificate used by Designer is good, and matches the one imported into Apache. There is nothing showing in the Error Log. I have tried both IP address and the DNS Name used in the Cert, no joy. When I try to import a new Identity Vault, I get an Error popup that says "Connection to the Identity Vault failed. Make sure that the credential information is valid". It is valid. When I try importing that vaults eDir2eDir driver, starting from the other vault (which has no connections issues), I get a similar message. The problem is, there are no details that I can find to explain the error.

Does anybody know where connection issues can be seen in Designer?

I have a project that has multiple trees, and right now all are at IDM 4.6.2, eDir 8.8.8.11, but they will be upgraded real soon. Of all the trees in the project, only two exhibit this behavior.

One of the ideas I was given was to try and replace the JDK used by Designer with an older version. I did replace the JDK used by Apache with the one used by Designer (pointed Apache directly at the Designer files) and Apache still connects.

As an FYI, in case anybody is looking, the certificate store for Designer can be found under the Designer\configuration folder called LDAPServerCerts (thank you Geoff Carman). It is a Java Keystore with password changeit.

Tags:

  • My best guess is that there is something amiss on the LDAP side; what does
    ndstrace show when you connect? You may want to be sure you have all of
    the tracing/screen options enabled before running this test, or else the
    LDAP output is not complete:


    ndstrace
    set dstrace=nodebug
    dstrace time tags ldap dxml
    set dstrace=*m9999999
    dstrace file on
    set dstrace=*r

    #test here

    dstrace file off
    quit


    Post the (by default) /var/opt/novell/eDirectory/log/ndstrace.log file's
    contents. I'm hoping something about unrecognized extensions may be in
    there. If that's the case, the extensionInfo attribute may be deficient.

    You mentioned TLS-related stuff quite a bit; a LAN/wire trace from tcpdump
    could probably rule that in or out pretty quickly, as could the ndstrace
    output above.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • TEdmonds wrote:

    > One of the ideas I was given was to try and replace the JDK used by
    > Designer with an older version. I did replace the JDK used by Apache
    > with the one used by Designer (pointed Apache directly at the Designer
    > files) and Apache still connects.


    Try adding -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true to
    Designer.ini to restores the behaviour from before JRE 8u181.

    Apache Studio might not be a valid comparison, as it's only affected if you use
    the JNDI LDAP API (which is NOT the default and would have to be set manually).
    The default Apache LDAP API is not affected by this change in the JRE.

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • I traced out a number of attempts, both from Designer and from Apache. Apache has several different combinations of settings and I tried them all;

    Encryption Method Provider Status
    ldaps:// Apache API succeeded
    ldaps:// JNDI failed
    startTLS Apache API failed
    startTLS JNDI failed

    Attempt from Designer, failed
    2721650432 LDAP: [2019/05/08 11:09:23.539] TLS accept failure 5 on connection 0xfcfc380, setting err = -5875. Error stack:
    2721650432 LDAP: [2019/05/08 11:09:23.539] TLS handshake failed on connection 0xfcfc380, err = -5875
    2135897856 LDAP: [2019/05/08 11:09:23.842] BIO ctrl called with unknown cmd 7
    2117691136 LDAP: [2019/05/08 11:09:24.101] TLS accept failure 1 on connection 0xfcfc380, setting err = -5875. Error stack:
    error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown - SSL alert number 46
    2117691136 LDAP: [2019/05/08 11:09:24.101] TLS handshake failed on connection 0xfcfc380, err = -5875
    2117691136 LDAP: [2019/05/08 11:09:24.101] BIO ctrl called with unknown cmd 7

    Attempt from Apache, LDAPS:, Apache API, Succeeded
    2135897856 LDAP: [2019/05/08 11:09:36.25] BIO ctrl called with unknown cmd 7

    Again...
    2003465984 LDAP: [2019/05/08 11:10:23.944] BIO ctrl called with unknown cmd 7

    Attempt from Apache, StartTLS, Apache API, Failed
    1968543488 LDAP: [2019/05/08 11:11:08.770] TLS accept failure 1 on connection 0xfcfc380, setting err = -5875. Error stack:
    error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
    1968543488 LDAP: [2019/05/08 11:11:08.770] TLS handshake failed on connection 0xfcfc380, err = -5875

    Attempt from Apache, Start TLS, JNDI, Failed
    2123560704 LDAP: [2019/05/08 11:11:49.695] TLS accept failure 1 on connection 0xfcfc380, setting err = -5875. Error stack:
    error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
    2123560704 LDAP: [2019/05/08 11:11:49.695] TLS handshake failed on connection 0xfcfc380, err = -5875

    Attempt from Apache, LDAPS:, JNDI, Failed
    2117691136 LDAP: [2019/05/08 11:12:23.796] TLS accept failure 1 on connection 0xfcfc380, setting err = -5875. Error stack:
    error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown - SSL alert number 46
    2117691136 LDAP: [2019/05/08 11:12:23.796] TLS handshake failed on connection 0xfcfc380, err = -5875
    2117691136 LDAP: [2019/05/08 11:12:23.796] BIO ctrl called with unknown cmd 7

    Attempt from Apache, LDAPS:, Apache API, Succeeded
    2003465984 LDAP: [2019/05/08 11:12:55.477] BIO ctrl called with unknown cmd 7
  • lhaeger;2499420 wrote:
    TEdmonds wrote:

    > One of the ideas I was given was to try and replace the JDK used by
    > Designer with an older version. I did replace the JDK used by Apache
    > with the one used by Designer (pointed Apache directly at the Designer
    > files) and Apache still connects.


    Try adding -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true to
    Designer.ini to restores the behaviour from before JRE 8u181.

    Apache Studio might not be a valid comparison, as it's only affected if you use
    the JNDI LDAP API (which is NOT the default and would have to be set manually).
    The default Apache LDAP API is not affected by this change in the JRE.

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)


    Lothar Haeger, two points, for the WIN!!!.

    Obviously, something changed with the new JDK. What is it? And can we look forward to something similar with eDIr once we get to 9.1.3 and IDM 4.7.2?
  • tse7147 wrote:

    > Obviously, something changed with the new JDK. What is it?


    Basically a stricter cert validation in JNDI has been enabled as default in
    8u181, which lets LDAPS connections fail that use non-standard (but widely
    used) certificates now. See
    https://www.oracle.com/technetwork/java/javase/8u181-relnotes-4479407.html

    Make sure your SSL server cert has the the ip/hostname/dns name(s) you actually
    use to connect as Subject Alternative Names (SAN) and not only as Common Name
    (CN), as per RFC 2818. A matching CN used to be good enough but is not anymore
    with JNDI in 8u181 or later by default.

    Something similar happened when Chrome 58 dropped CN checking and required
    proper SANs in 2017, btw.

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • On 5/8/2019 2:24 PM, tse7147 wrote:
    >
    > lhaeger;2499420 Wrote:
    >> TEdmonds wrote:
    >>
    >>> One of the ideas I was given was to try and replace the JDK used by
    >>> Designer with an older version. I did replace the JDK used by Apache
    >>> with the one used by Designer (pointed Apache directly at the

    >> Designer
    >>> files) and Apache still connects.

    >>
    >> Try adding -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true
    >> to
    >> Designer.ini to restores the behaviour from before JRE 8u181.
    >>
    >> Apache Studio might not be a valid comparison, as it's only affected if
    >> you use
    >> the JNDI LDAP API (which is NOT the default and would have to be set
    >> manually).
    >> The default Apache LDAP API is not affected by this change in the JRE.
    >>
    >> --
    >> http://www.is4it.de/en/solution/identity-access-management/
    >>
    >> (If you find this post helpful, please click on the star below.)

    >
    > Lothar Haeger, two points, for the WIN!!!.
    >
    > Obviously, something changed with the new JDK. What is it? And can we
    > look forward to something similar with eDIr once we get to 9.1.3 and IDM
    > 4.7.2?


    To be fair, I pointed this out to you, you slacker. :) Believe someone
    who jumps off perfectly servicable mountains but not me. Hmm...

    What happened in post 1.8 181 JVMs is that the Subject Name in the Cert
    (Tree CA name) has to match the URL in the connect string. It is a
    security 'feature'.

    As for eDir? It should break every single cert in every single eDir
    tree until you tell the JVM to ignore it as Lothar suggested.

    Had you swapped JVMs as i suggested it would have worked, which would
    have shown it. But you won't listen to me... Hmmph. Maybe I will make a
    sock puppet account so I can pretend to be Austrain so you will listen?

  • Geoffrey Carman wrote:

    > To be fair, I pointed this out to you, you slacker. :)


    There you have me!

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • On 5/8/2019 3:51 PM, Lothar Haeger wrote:
    > Geoffrey Carman wrote:
    >
    >> To be fair, I pointed this out to you, you slacker. :)

    >
    > There you have me!


    Actually I meant I pointed it out to Tim, not you. I would never
    criticize you. (Oh wait, never mind).


  • TEdmonds;2499416 wrote:
    I am running into an issue with Designer 4.7.2 where there are some Vaults I am not able to connect. I tried using Secure and Non-Secure. I am certain the connection information is accurate as I verified connectivity via Apache Directory Studio, and loading DXCMD on the console and used an LDAP DN to connect. Both worked fine. As far as I can tell, the certificate used by Designer is good, and matches the one imported into Apache. There is nothing showing in the Error Log. I have tried both IP address and the DNS Name used in the Cert, no joy. When I try to import a new Identity Vault, I get an Error popup that says "Connection to the Identity Vault failed. Make sure that the credential information is valid". It is valid. When I try importing that vaults eDir2eDir driver, starting from the other vault (which has no connections issues), I get a similar message. The problem is, there are no details that I can find to explain the error.

    Does anybody know where connection issues can be seen in Designer?

    I have a project that has multiple trees, and right now all are at IDM 4.6.2, eDir 8.8.8.11, but they will be upgraded real soon. Of all the trees in the project, only two exhibit this behavior.

    One of the ideas I was given was to try and replace the JDK used by Designer with an older version. I did replace the JDK used by Apache with the one used by Designer (pointed Apache directly at the Designer files) and Apache still connects.

    As an FYI, in case anybody is looking, the certificate store for Designer can be found under the Designer\configuration folder called LDAPServerCerts (thank you Geoff Carman). It is a Java Keystore with password changeit.



    If this is problem related to JRE upgrade, yo can try adding below line into Designer.ini

    -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true

    Regards,
    Vrijendra
  • geoffc;2499446 wrote:
    On 5/8/2019 3:51 PM, Lothar Haeger wrote:
    > Geoffrey Carman wrote:
    >
    >> To be fair, I pointed this out to you, you slacker. :)

    >
    > There you have me!


    Actually I meant I pointed it out to Tim, not you. I would never
    criticize you. (Oh wait, never mind).


    Hmmm... I seem to recall something about how I should never trust an Austrian...

    If it should break every single cert in every tree, why did it work on 8 out of 10?