Can't Authenticate to Server

So this is a weird issue. We spun up 4 new edirectory servers and for some reason we can not authenticate to just one of them through designer. All over servers are fine. We found that there was an errant host in the host file and removed it. However we still can not get designer to contact and authenticate this server. It pulls the cert and then it says it can't authenticate. We've tried removing the certs and having Designer re-create them, doesn't work. Tried using ndsconfig upgrade to rebuild the kmo objects, didn't work. Something with the certs or with the server doesn't want to communicate. We are trying to deploy driverset changes to all new servers but can't deploy to this one server. We also cleared the network address attribute in the server object tree, Any clues to why designer doesn't like this server. Other than the errant ip address we're not sure why it's no longer communicating.

Tags:

  • This sounds very slightly similar to something else I saw in another
    forum. Have you compared the LDAP Group objects, particularly the class
    and attribute mappings, and then the extensionInfo (as I recall) attribute
    values? On servers with the same software and software version I would
    expect these to all be fairly uniform, but they could easily be different,
    and maybe that impacts what IDM Designer can do.

    --
    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.
  • Hi,

    wich version of Designer are you using? I found an issue with Designer 4.7.2 when the LDAP Servers were configured to use a "real" not self-signed certificate.

    In this case either re-configure the LDAP-Server to use one of the automatically created self-signbed certificates or add the following parameter to designer.ini

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

    This is a bug in the current Designer version.

    Kind regards,

    Thorsten
  • tschloesser wrote:

    > -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true
    >
    > This is a bug in the current Designer version.


    I thought this was due to increased security in JNDI since java 8u191 (both
    Oracle and OpenJDK). Also affects e.g. Apache Studio. A simple way to test for
    this particular issue is to temporarily replace the jre with an earlier version.

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

    (If you find this post helpful, please click on the star below.)
  • In my case replacing the jvm did not work!
    I filed in a SR and got the feedback that this issue is locked internally as an bug - as a work-around the parameter was provided!

    Kind regards,

    Thorsten
  • On 2019-03-19 13:44, tschloesser wrote:
    >
    > In my case replacing the jvm did not work!


    Did you use a version prior to 8u181?

    > I filed in a SR and got the feedback that this issue is locked
    > internally as an bug - as a work-around the parameter was provided!


    This happens if the hostname you specified in Designer does not match up
    with the subjectAltName in the LDAPS server certificate (or CN if there
    an no sANs).

    This check is mandatory: https://tools.ietf.org/html/rfc4513#section-3.1.3

    No performing this check was fixed with 8u181 in Java.

    https://www.oracle.com/technetwork/java/javase/8u181-relnotes-4479407.html#JDK-8200666

    Changes
    core-libs/javax.naming
    ➜ Improve LDAP support

    Endpoint identification has been enabled on LDAPS connections.

    To improve the robustness of LDAPS (secure LDAP over TLS) connections,
    endpoint identification algorithms have been enabled by default.

    Note that there may be situations where some applications that were
    previously able to successfully connect to an LDAPS server may no longer
    be able to do so. Such applications may, if they deem appropriate,
    disable endpoint identification using a new system property:
    com.sun.jndi.ldap.object.disableEndpointIdentification.



    --
    Norbert
  • Hi Norbert,

    thanks for this information -I was not aware of this!

    klasen;2497061 wrote:
    On 2019-03-19 13:44, tschloesser wrote:
    This happens if the hostname you specified in Designer does not match up
    with the subjectAltName in the LDAPS server certificate (or CN if there
    an no sANs).


    But I just checked the configuration, and the cn in the certificate is matching the DNS name configured in Designer!
    I am pretty sure, a authentication was not possible without providing the additional parameter in designer.ini.

    In our case the certificate was signed by a local CA, which received its own certificate by an intermediate CA (DFN). Maybe there is an issue with "unknown" and therefore not trusted CAs?

    We double checked - even in a remote session by M.F. support - that all needed CA certificates were in the keystore, but it did not help!

    Kind regards,

    Thorsten
  • On 2019-03-20 07:54, tschloesser wrote:
    > But I just checked the configuration, and the cn in the certificate is
    > matching the DNS name configured in Designer!


    Does the server certificate also have subjectAltName extensions?

    --
    Norbert
  • tschloesser wrote:

    > But I just checked the configuration, and the cn in the certificate is
    > matching the DNS name configured in Designer!


    Have a look at Subject Alterative Names (SAN) of the cert. If any SAN exists,
    the CN should not be considered by the client according to RFC, but only the
    SANs. So the DNS name must also be set as a SAN, which some older CAs did not
    do if it's the CN already.

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

    (If you find this post helpful, please click on the star below.)
  • No, the certificate only offers a subject name: C=DE.S=Hessen.L=Darmstadt.O=Technische Universitaet Darmstadt.OU=Hochschulrechenzentrum.CN=idm-ds07.hrz.tu-darmstadt.de
    According to iManager it has an alternative Subject name as well:
    Type 9
    OID {2 5 29 17}
    Critical no
    DNS Name idm-ds07.hrz.tu-darmstadt.de