I am stuck migrating object class definitions from OpenDS to Active Directory. I have already successfully migrated some definitions (and can read/write to AD with my Java application) - but now I'm stuck.
In my OpenDS schema description I have something like this:
objectClasses: ( 220.127.116.11.18.104.22.168 NAME 'myNewClass' SUP top STRUCTURAL MUST ( myAttribute1 $ myAttribute2 $ myAttribute3 ) MAY someOtherAttribute )
I translated this to the AD schema syntax like this:
# Class: myNewClass dn: cn=myNewClass,cn=Schema,cn=Configuration,dc=X changetype: add objectClass: classSchema governsID: 22.214.171.124.126.96.36.199 ldapDisplayName: myNewClass adminDisplayName: myNewClass objectClassCategory: 0 systemOnly: FALSE # subclassOf: top subclassOf: 188.8.131.52 # rdnAttId: myAttribute1 rdnAttId: 184.108.40.206.220.127.116.11 # mustContain: myAttribute2 mustContain: 18.104.22.168.22.214.171.124 # mustContain: myAttribute3 mustContain: 126.96.36.199.188.8.131.52 # mayContain: someOtherAttribute mayContain: 184.108.40.206.220.127.116.11 # possSuperiors: organizationalUnit possSuperiors: 18.104.22.168 # defaultObjectCategory: myNewClass defaultObjectCategory: cn=myNewClass,cn=Schema,cn=Configuration,dc=X
But when I try to write an object of class myNewClass I get this exception:
javax.naming.InvalidNameException: "myAttribute1=Read+myAttribute2=Allow+myAttribute3=cn\=someResource": [LDAP: error code 34 - 0000208F: LdapErr: DSID-0C090715, comment: Error processing name, data 0, v1db1 ];
I assume the problem is rdnAttId, which seems to be essential in AD (and not in OpenDS). I can only set it to a single value (so I have chosen myAttribute1), but shouldn't it be more like myAttribute1 AND myAttribute2 AND myAttribute3?
What do do?
Ok here is an example of a LDIF with a class creation. You should have followed my advice. First you create it with Microsoft Mananagement Console, then you export it using LDIFDE.EXE, you clean your LDIFDE and then you are able to import it in an other AD.
dn: CN=SlxOeuvre,CN=Schema,CN=Configuration,DC=XXXX changetype: add objectClass: top objectClass: classSchema cn: SlxOeuvre distinguishedName: CN=SlxOeuvre,CN=Schema,CN=Configuration,DC=XXXX instanceType: 4 possSuperiors: organizationalUnit subClassOf: top governsID: 22.214.171.124.4.1.105126.96.36.199 mustContain: SlxTitre mayContain: SlxChapitres mayContain: SlxEditeur mayContain: SlxGenre mayContain: SlxLangue mayContain: SlxPages rDNAttID: cn showInAdvancedViewOnly: TRUE adminDisplayName: SlxOeuvre objectClassCategory: 1 lDAPDisplayName: SlxOeuvre name: SlxOeuvre systemOnly: FALSE
rDNAttID is the name of the attribute that is use to create the Relative Distinguished Name. On the theorical point of view you can choose the one you want. On the practical point of view I never user anything else than
Once created your attributes, be carreful to reload you Schema in order to have them available to create the class. Here is the commutator :
dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 -<hr>
As your DN is
cn=myNewClass,cn=Schema,cn=Configuration,dc=X you MUST add CN to tne attributes dn:
cn:myNewClass (thow it should be added automaticaly).
Edited : According to Microsoft documentation :
As far as RDN is concerned the correspondence between Active-Directory model and the LDAP data model is as follows. An object with its attributes and values corresponds to an LDAP entry with its attributes and values. This model and LDAP agree on the definition of the objectClass attribute. The definition of RDN in this model is a subset of LDAP's definition; all RDNs in this model are valid LDAP RDNs, but not vice versa. For example, the following multivalued RDN is a valid LDAP RDN, but it is not valid in this model: "cn=Peter Houston+employeeID=ABC123". Given the RDN definition, the definition of DN in this model is the same as LDAP's definition. In the LDAP data model, the child-parent relationship is represented in the DNs of the child and parent, whereas in the Active Directory data model, the child-parent relationship is represented in the parent attribute and the DN is derived. Active Directory does not expose the model's parent attribute through LDAP.