Import object class definitions to Active Directory (AD LDS) - active-directory

Question

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: ( 1.3.6.1.4.1.99.2
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: 1.3.6.1.4.1.99.2
ldapDisplayName: myNewClass
adminDisplayName: myNewClass
objectClassCategory: 0
systemOnly: FALSE
# subclassOf: top
subclassOf: 2.5.6.0
# rdnAttId: myAttribute1
rdnAttId: 1.3.6.1.4.1.99.1
# mustContain: myAttribute2
mustContain: 1.3.6.1.4.1.99.2
# mustContain: myAttribute3
mustContain: 1.3.6.1.4.1.99.3
# mayContain: someOtherAttribute
mayContain: 1.3.6.1.4.1.99.4
# possSuperiors: organizationalUnit
possSuperiors: 2.5.6.5
# 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?

Answer 1

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: 1.3.6.1.4.1.10558.2.2.1
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
In Active-Directory 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 CN.
Edited :
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
-
Edited :
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.