Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.6.0
    • Fix Version/s: 0.8.0
    • Component/s: studio-ldapbrowser
    • Labels:
      None
    • Environment:
      eclipse 3.2 with

      Description

      The empty DN is a perfectly valid DN for a directory server. When getting the DN from the root DSE ldap studio displays an error if the root dn is empty. Also the empty dn can't be set manually.

        Activity

        Hide
        Emmanuel Lecharny added a comment -

        That's right : when you set the "search Base" to the empty string, the "Search" button is not active. It should be, if the scope is Object and if the filter is (ObjectClass=*).

        How do you get the other error?

        Last point : you must select an entry to be able to do a search. It would be better if we can launch a search from the menu even if no partition is selected.

        Show
        Emmanuel Lecharny added a comment - That's right : when you set the "search Base" to the empty string, the "Search" button is not active. It should be, if the scope is Object and if the filter is (ObjectClass=*). How do you get the other error? Last point : you must select an entry to be able to do a search. It would be better if we can launch a search from the menu even if no partition is selected.
        Hide
        Leif Johansson added a comment -

        This is not in the context of making a search but when creating a directory server configuration - my directory server is based on the empty DN!

        Show
        Leif Johansson added a comment - This is not in the context of making a search but when creating a directory server configuration - my directory server is based on the empty DN!
        Hide
        Emmanuel Lecharny added a comment -

        Creating a directory server using an empty DN as a root is not allowed, simply because it's already existing : it's the RootDSE, which is not really a DIT.

        Show
        Emmanuel Lecharny added a comment - Creating a directory server using an empty DN as a root is not allowed, simply because it's already existing : it's the RootDSE, which is not really a DIT.
        Hide
        Stefan Seelmann added a comment -

        Leif, which directory server are you using?

        Show
        Stefan Seelmann added a comment - Leif, which directory server are you using?
        Hide
        Emmanuel Lecharny added a comment -

        More infos :

        From RFC 2251, chapter 3.2 :
        "The largest collection of entries, starting at an entry that is
        mastered by a particular server, and including all its subordinates
        and their subordinates, down to the entries which are mastered by
        different servers, is termed a naming context. *The root of the DIT
        is a DSA-specific Entry (DSE) and not part of any naming context:
        each server has different attribute values in the root DSE*. "

        From RFC 4512, chapter 5.1 :
        "An LDAP server SHALL provide information about itself and other
        information that is specific to each server. This is represented as
        a group of attributes located in *the root DSE, which is named with
        the DN with zero RDNs (whose [RFC 4514] representation is as the
        zero-length string).*"

        Show
        Emmanuel Lecharny added a comment - More infos : From RFC 2251, chapter 3.2 : "The largest collection of entries, starting at an entry that is mastered by a particular server, and including all its subordinates and their subordinates, down to the entries which are mastered by different servers, is termed a naming context. *The root of the DIT is a DSA-specific Entry (DSE) and not part of any naming context: each server has different attribute values in the root DSE*. " From RFC 4512, chapter 5.1 : "An LDAP server SHALL provide information about itself and other information that is specific to each server. This is represented as a group of attributes located in *the root DSE, which is named with the DN with zero RDNs (whose [RFC 4514] representation is as the zero-length string).*"
        Hide
        Stefan Seelmann added a comment -

        Some more information from RFC 4512:
        5.1.2. 'namingContexts'
        The 'namingContexts' attribute lists the context prefixes of the
        naming contexts the server masters or shadows (in part or in whole).
        If the server is a first-level DSA [X.501], it should list (in
        addition) an empty string (indicating the root of the DIT). If the
        server does not master or shadow any information (e.g., it is an LDAP
        gateway to a public X.500 directory) this attribute will be absent.
        If the server believes it masters or shadows the entire directory,
        the attribute will have a single value, and that value will be the
        empty string (indicating the root of the DIT).

        I checked it with Novell's eDirectory, it returns an empty DN in the namingContexts attribute of the rootDSE. LS doesn't handle that case atm. Additionally LS should accept the empty DN as connection's base DN and as search base.

        Show
        Stefan Seelmann added a comment - Some more information from RFC 4512: 5.1.2. 'namingContexts' The 'namingContexts' attribute lists the context prefixes of the naming contexts the server masters or shadows (in part or in whole). If the server is a first-level DSA [X.501] , it should list (in addition) an empty string (indicating the root of the DIT). If the server does not master or shadow any information (e.g., it is an LDAP gateway to a public X.500 directory) this attribute will be absent. If the server believes it masters or shadows the entire directory, the attribute will have a single value, and that value will be the empty string (indicating the root of the DIT). I checked it with Novell's eDirectory, it returns an empty DN in the namingContexts attribute of the rootDSE. LS doesn't handle that case atm. Additionally LS should accept the empty DN as connection's base DN and as search base.
        Hide
        Leif Johansson added a comment -

        I am using OpenLDAP and Stefans comment above clearly shows that there is a difference between the name of the RootDSE (which is a subentry) and the root naming context. In other words just because the root DSE and the root naming context have the same string representation doesn't mean they are the same

        Show
        Leif Johansson added a comment - I am using OpenLDAP and Stefans comment above clearly shows that there is a difference between the name of the RootDSE (which is a subentry) and the root naming context. In other words just because the root DSE and the root naming context have the same string representation doesn't mean they are the same
        Hide
        Emmanuel Lecharny added a comment -

        They are the same, definitively. You cant' have a DN pointing on two different DIT, that's simply impossible in LDAP.

        Show
        Emmanuel Lecharny added a comment - They are the same, definitively. You cant' have a DN pointing on two different DIT, that's simply impossible in LDAP.
        Hide
        Leif Johansson added a comment -

        Yes you can - thats what you have subentries for. Granted they were never defined for LDAP but in the case of the root dse and naming contexts (which both are subentries in X.500) they sort-of exist.

        This is getting away from the basic point: empty DNs are valid and don't just implicitly refer to the root dse. All directory servers I've come across support them as do most if not all directory clients (including all administrative clients) with the exception of ldap studio.

        Show
        Leif Johansson added a comment - Yes you can - thats what you have subentries for. Granted they were never defined for LDAP but in the case of the root dse and naming contexts (which both are subentries in X.500) they sort-of exist. This is getting away from the basic point: empty DNs are valid and don't just implicitly refer to the root dse. All directory servers I've come across support them as do most if not all directory clients (including all administrative clients) with the exception of ldap studio.
        Hide
        Emmanuel Lecharny added a comment -

        http://tools.ietf.org/html/rfc3672 :
        "From [X.501]:

        A subentry is a special kind of entry immediately subordinate to
        an administrative point. It contains attributes that pertain to
        a subtree (or subtree refinement) associated with its
        administrative point. The subentries and their administrative
        point are part of the same naming context.

        A single subentry may serve all or several aspects of
        administrative authority. Alternatively, a specific aspect of
        administrative authority may be handled through one or more of
        its own subentries."

        Here is a description about subentries in ADS : http://directory.apache.org/apacheds/1.0/the-administrative-model.html

        Basically, no way to get a DN pointing to 2 entries. At least in ADS, and I don't see how it can be possible in any other ldap server (or I would be surprised).

        Again, the fact that other ldap server define a DIT with an empty DN is breaking LDAP specs. I think they allow this as a workaround to a problem with Exchange servs which kind of allow this. But you will have to find me the place in the RFC where this is explicitely allowed, when I exposed the place where it is said that it's the rootDSE DN ...

        Of course, I can be plain wrong, and in this case, we will have to reconsider a lot of things in ADS, but that's another story

        Show
        Emmanuel Lecharny added a comment - http://tools.ietf.org/html/rfc3672 : "From [X.501] : A subentry is a special kind of entry immediately subordinate to an administrative point. It contains attributes that pertain to a subtree (or subtree refinement) associated with its administrative point. The subentries and their administrative point are part of the same naming context. A single subentry may serve all or several aspects of administrative authority. Alternatively, a specific aspect of administrative authority may be handled through one or more of its own subentries." Here is a description about subentries in ADS : http://directory.apache.org/apacheds/1.0/the-administrative-model.html Basically, no way to get a DN pointing to 2 entries. At least in ADS, and I don't see how it can be possible in any other ldap server (or I would be surprised). Again, the fact that other ldap server define a DIT with an empty DN is breaking LDAP specs. I think they allow this as a workaround to a problem with Exchange servs which kind of allow this. But you will have to find me the place in the RFC where this is explicitely allowed, when I exposed the place where it is said that it's the rootDSE DN ... Of course, I can be plain wrong, and in this case, we will have to reconsider a lot of things in ADS, but that's another story
        Hide
        Emmanuel Lecharny added a comment -

        I just wanted to add somethiong moe interesting, and related to the issue :

        1) This is not because ADS does not accept empty DN except for rootDSE that LdapStudio should not provide such a DN : there are other Ldap server out there
        2) A search operation with an empty DN should always be accepted, an sent to the server
        3) A modify operation applied on a empty DN should be sent to the server, this is the server responsaibilty to accept it or not
        4) A delete operation should be sent to the server, with the same behavior
        5) a create operation should be sent to the server, with the same behavior.

        In other words, from the LdapStudio point of view, empty DN musr be seen as legitimate.

        Any discussion about the legitimity of an empty DN would deserve another thread on dev@directory.apache.org.

        (and I must admit that I started the discussion, so my bad

        Show
        Emmanuel Lecharny added a comment - I just wanted to add somethiong moe interesting, and related to the issue : 1) This is not because ADS does not accept empty DN except for rootDSE that LdapStudio should not provide such a DN : there are other Ldap server out there 2) A search operation with an empty DN should always be accepted, an sent to the server 3) A modify operation applied on a empty DN should be sent to the server, this is the server responsaibilty to accept it or not 4) A delete operation should be sent to the server, with the same behavior 5) a create operation should be sent to the server, with the same behavior. In other words, from the LdapStudio point of view, empty DN musr be seen as legitimate. Any discussion about the legitimity of an empty DN would deserve another thread on dev@directory.apache.org. (and I must admit that I started the discussion, so my bad
        Hide
        Leif Johansson added a comment -

        You are missing the point. Its not a question of having an entry with two DNs. I am claiming that you have confused two uses of a DN: a naming context and an entry dn.

        The bottom line is that you must be able to support the empty naming context or you won't be able to host dc=org and dc=com in the same naming context. The fact that both eDirectory and OpenLDAP support this should make you think twice before making claims that this feature somehow breaks the spec

        Show
        Leif Johansson added a comment - You are missing the point. Its not a question of having an entry with two DNs. I am claiming that you have confused two uses of a DN: a naming context and an entry dn. The bottom line is that you must be able to support the empty naming context or you won't be able to host dc=org and dc=com in the same naming context. The fact that both eDirectory and OpenLDAP support this should make you think twice before making claims that this feature somehow breaks the spec
        Hide
        Leif Johansson added a comment -

        Note that I replied to the last but one post I agree with the last post you made.

        Show
        Leif Johansson added a comment - Note that I replied to the last but one post I agree with the last post you made.
        Hide
        Stefan Seelmann added a comment -

        Most items are fixed. The empty DN in namingContext is now handled and could be used as search base. The browser view has been restructured, the RootDSE is now always visible and the root of the DIT.

        Some issues aren't fixed:

        • The LDIF editor isn't able to handle the empty DN. This will be resolved with DIRSTUDIO-43.
        • It isn't possible to create an entry with the empty DN using the New Entry wizard. And it isn't possible to rename or move the entry with the empty DN using the rename or move dialogs. I think such operations are not necessary, otherwise we have to redesign some GUI widgets.
        Show
        Stefan Seelmann added a comment - Most items are fixed. The empty DN in namingContext is now handled and could be used as search base. The browser view has been restructured, the RootDSE is now always visible and the root of the DIT. Some issues aren't fixed: The LDIF editor isn't able to handle the empty DN. This will be resolved with DIRSTUDIO-43 . It isn't possible to create an entry with the empty DN using the New Entry wizard. And it isn't possible to rename or move the entry with the empty DN using the rename or move dialogs. I think such operations are not necessary, otherwise we have to redesign some GUI widgets.

          People

          • Assignee:
            Stefan Seelmann
            Reporter:
            Leif Johansson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development