Hi Markus, On 7/21/07, Markus Pohle <[EMAIL PROTECTED]> wrote:
Hi list, I used a ApacheDS in version 1.5.0 (officially released version downloaded from directory website) on my server and created my on partition with the following ldap structure: dn: dc=DOUGLASHOLDING objectClass: domain objectClass: extensibleObject objectClass: top dc: douglasholding dn: dc=VERWALTUNG,dc=DOUGLASHOLDING objectClass: domain objectClass: top 0.9.2342.19200300.100.1.25: verwaltung dc: VERWALTUNG dn: cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING objectClass: organizationalRole objectClass: top 2.5.4.3: users cn: users dn: dc=APPLICATIONS,dc=DOUGLASHOLDING objectClass: domain objectClass: top 0.9.2342.19200300.100.1.25: applications dc: APPLICATIONS dn: cn=cms,dc=APPLICATIONS,dc=DOUGLASHOLDING objectClass: organizationalRole objectClass: top 2.5.4.3: cms cn: cms Then I needed to switch to apacheds-1.5.1-snapshot release that Alex Karasulu due to apacheds-tools problems with version 1.5.0 build for me. And what I found out browsing the ldap schema using LDAP Studio on the apacheds-1.5.1-snapshot is the following: dn: dc=DOUGLASHOLDING objectClass: domain objectClass: extensibleObject objectClass: top dc: douglasholding dn: dc=VERWALTUNG,dc=DOUGLASHOLDING objectClass: domain objectClass: top dc: VERWALTUNG dn: cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING objectClass: organizationalRole objectClass: top cn: users dn: dc=APPLICATIONS,dc=DOUGLASHOLDING objectClass: domain objectClass: top dc: APPLICATIONS dn: cn=cms,dc=APPLICATIONS,dc=DOUGLASHOLDING objectClass: organizationalRole objectClass: top cn: cms And here comes the question: What are these additional objectclasses for that can be seen in the upper example of the ldap structure, e.g.: 0.9.2342.19200300.100.1.25: applications 2.5.4.3: cms
These are the normalized representations of attributes dc and cn respectively. These numbers are their OIDs. Looks to me like your LDIF export contained them and so ApacheDS preserved them as you loaded them into the server. ApacheDS is required to return entries as you entered them without modifying the entries attribute names. BTW in LDAP you can use OID, or an alias like cn, or even commonName. What ever you choose on the import or add operation should be returned back to you as it was imported/added. Now this leads us to the question of why the export from ApacheDS resulted in returning these canonical representations instead of the attribute aliases which you probably originally provided like cn and dc instead. I presume before the LDIF export you took, you initially added these entries to the first ADS instance using dc and cn correct? If this is happening the server may be reverting indexed attribute identifiers to their OID. If so this is a bug we need to fix. However there was a switch in the server that forces denormalization which I had thought was enabled by default. I recommend performing a little test to see what is going on. Just delete the structure you loaded and massage your export file to just use the alias names dc and cn instead of using their OIDs. Then load it into the server again and see if in studio the OID appears instead. Let us know if the server is changing these attribute identifiers back into their OID. Also take an export to LDIF again and see if that export has replaced cn and dc with their OID. HTH, Alex
