Directory Studio
  1. Directory Studio
  2. DIRSTUDIO-487

Empty namingcontexts causes javax.naming.InvalidNameException: Bad DN

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.4.0
    • Fix Version/s: 1.5.0
    • Component/s: studio-ldapbrowser
    • Labels:
      None
    • Environment:
      Domino 7, Exchange 5.5

      Description

      When attempting to connect to domino server with an empty namingcontexts, using option to get base DNs from Root DSE (or leaving as empty), an error is generated and DIT does not display.

      Problem Occurred popup when fetching Base DNs:

      Error while fetching base DNs

      • Can't set Base DN entry
      • Bad DN :
        javax.naming.InvalidNameException: Bad DN :

      Modification Logs when connecting:

      #!RESULT ERROR
      #!CONNECTION ldap://10.x.x.x:389
      #!DATE 2009-04-24T12:04:10.247
      #!ERROR [LDAP: error code 89 - No given DN]
      dn:
      changetype: modify
      add: namingcontexts
      namingcontexts: o=mydomain
      -

      And Domino Root DSE:

      objectClass: top
      namingcontexts:
      subschemasubentry: cn=schema
      supportedextension: 1.3.6.1.4.1.1466.20037
      supportedextension: LanguageCodes
      supportedldapversion: 2
      supportedldapversion: 3
      supportedschemamechanisms: EXTERNAL
      vendorname: IBM Lotus Software
      vendorversion: Release 7.0.2

        Activity

        Hide
        Stefan Seelmann added a comment -

        Hi James,

        thanks for your report.

        I checked the code. Your reported error "Can't set Base DN entry" is only thrown in one case: if the namingContext is not empty, but the DN can't be parsed, I just added the code snippet below. I was able to reproduce your error by setting namingContext to the space or newline character. Could you please check if the namingcontexts of the domino server is really empty or if there is some whitespace? Nevertheless it makes sense to trim() the value in the code...

        --------------------------------------------------------------------------------------------------
        if ( !"".equals( namingContext ) ) //$NON-NLS-1$
        {
        try

        { LdapDN dn = new LdapDN( namingContext ); ... }

        catch ( InvalidNameException e )

        { monitor.reportError( BrowserCoreMessages.model__error_setting_base_dn, e ); }

        }
        --------------------------------------------------------------------------------------------------

        Show
        Stefan Seelmann added a comment - Hi James, thanks for your report. I checked the code. Your reported error "Can't set Base DN entry" is only thrown in one case: if the namingContext is not empty, but the DN can't be parsed, I just added the code snippet below. I was able to reproduce your error by setting namingContext to the space or newline character. Could you please check if the namingcontexts of the domino server is really empty or if there is some whitespace? Nevertheless it makes sense to trim() the value in the code... -------------------------------------------------------------------------------------------------- if ( !"".equals( namingContext ) ) //$NON-NLS-1$ { try { LdapDN dn = new LdapDN( namingContext ); ... } catch ( InvalidNameException e ) { monitor.reportError( BrowserCoreMessages.model__error_setting_base_dn, e ); } } --------------------------------------------------------------------------------------------------
        Hide
        James Brown added a comment -

        Stefan-

        Thanks for investigating.

        Using a different version of ldapsych, it does appear that this is using a single null-byte value for namingcontexts.

        dn:
        objectclass: top
        subschemasubentry: cn=schema
        namingcontexts:: AA==
        supportedextension: 1.3.6.1.4.1.1466.20037
        supportedextension: LanguageCodes
        supportedsaslmechanisms: EXTERNAL
        supportedldapversion: 3
        supportedldapversion: 2
        vendorname: IBM Lotus Software
        vendorversion: Release 7.0.2

        Show
        James Brown added a comment - Stefan- Thanks for investigating. Using a different version of ldapsych, it does appear that this is using a single null-byte value for namingcontexts. dn: objectclass: top subschemasubentry: cn=schema namingcontexts:: AA== supportedextension: 1.3.6.1.4.1.1466.20037 supportedextension: LanguageCodes supportedsaslmechanisms: EXTERNAL supportedldapversion: 3 supportedldapversion: 2 vendorname: IBM Lotus Software vendorversion: Release 7.0.2
        Hide
        James Brown added a comment -

        sorry, should read ...using a different version of ldapsearch....

        Show
        James Brown added a comment - sorry, should read ...using a different version of ldapsearch....
        Hide
        Stefan Seelmann added a comment -

        Thanks James for the update.

        What a mess. Where does this null-byte come from? Is it default for a Domino server or was this added by configuration?

        Anyway, the question is, if and how Studio should handle this situation. According to RFC 4514 and 2253 this is not valid. I don't know if this null-byte has a special meaning.
        We could just left-trim the namingcontexts value, then is becomes the empty string. In that case a one-level search using the RootDSE as search base would be performed.

        James, could you please try to do such a one-level, just to see if some results are returned?

        Show
        Stefan Seelmann added a comment - Thanks James for the update. What a mess. Where does this null-byte come from? Is it default for a Domino server or was this added by configuration? Anyway, the question is, if and how Studio should handle this situation. According to RFC 4514 and 2253 this is not valid. I don't know if this null-byte has a special meaning. We could just left-trim the namingcontexts value, then is becomes the empty string. In that case a one-level search using the RootDSE as search base would be performed. James, could you please try to do such a one-level, just to see if some results are returned?
        Hide
        James Brown added a comment -

        Stefan-

        I am not an expert on domino, but as I now understand it this single null-byte value for namingcontexts is a bug that is supposed to be remedied at some point. This appears to be aan issue with at least Lotus Domino R5.x, R6.x and R7.0.x.

        performaing a one level search works, no issue.

        ldapsearch -h <host> -x -b "" -s one "objectclass=*"

        1. extended LDIF
          #
        2. LDAPv3
        3. base <> with scope one
        4. filter: objectclass=*
        5. requesting: ALL
          #
        1. Administration Requests
          dn: CN=Administration Requests
          cn: Administration Requests
          mail: Administration_Requests%domain@domain.com
          maildomain: domain
          objectclass: dominoServerMailInDatabase
          objectclass: top
        1. BE
          dn: C=BE
          c: BE
          objectclass: country
          objectclass: top

        ...
        ...

        1. search result
          search: 2
          result: 0 Success
        1. numResponses: 19
        2. numEntries: 18
        Show
        James Brown added a comment - Stefan- I am not an expert on domino, but as I now understand it this single null-byte value for namingcontexts is a bug that is supposed to be remedied at some point. This appears to be aan issue with at least Lotus Domino R5.x, R6.x and R7.0.x. performaing a one level search works, no issue. ldapsearch -h <host> -x -b "" -s one "objectclass=*" extended LDIF # LDAPv3 base <> with scope one filter: objectclass=* requesting: ALL # Administration Requests dn: CN=Administration Requests cn: Administration Requests mail: Administration_Requests%domain@domain.com maildomain: domain objectclass: dominoServerMailInDatabase objectclass: top BE dn: C=BE c: BE objectclass: country objectclass: top ... ... search result search: 2 result: 0 Success numResponses: 19 numEntries: 18
        Hide
        Stefan Seelmann added a comment -

        I also found some refernces, looks like this bug exists very long:
        http://www.openldap.org/lists/openldap-software/200202/msg00541.html
        http://www.web2ldap.de/compability.html

        I think the simplest solution is to check if the namingcontexts string ends with an \NUL and if so just remove it.

        Show
        Stefan Seelmann added a comment - I also found some refernces, looks like this bug exists very long: http://www.openldap.org/lists/openldap-software/200202/msg00541.html http://www.web2ldap.de/compability.html I think the simplest solution is to check if the namingcontexts string ends with an \NUL and if so just remove it.
        Hide
        Stefan Seelmann added a comment -
        Show
        Stefan Seelmann added a comment - Fixed in trunk: http://svn.apache.org/viewvc?rev=778898&view=rev
        Hide
        Pierre-Arnaud Marcelot added a comment -

        Apache Directory Studio version 1.5.0 has been released.

        Show
        Pierre-Arnaud Marcelot added a comment - Apache Directory Studio version 1.5.0 has been released.

          People

          • Assignee:
            Stefan Seelmann
            Reporter:
            James Brown
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development