Importar definiciones de clases de objetos a Active Directory(AD LDS)

active-directory ldif

Question

Estoy atrapado migrando las definiciones de clase de objeto de OpenDS a Active Directory. Ya he migrado con éxito algunas definiciones (y puedo leer / escribir en AD con mi aplicación Java), pero ahora estoy atascado.

En mi descripción de esquema OpenDS tengo algo como esto:

objectClasses: ( 1.3.6.1.4.1.99.2
  NAME ''myNewClass''
  SUP top STRUCTURAL
  MUST ( myAttribute1 $ myAttribute2 $ myAttribute3 )
  MAY someOtherAttribute
  )

Traducí esto a la sintaxis del esquema AD de esta manera:

# 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

Pero cuando intento escribir un objeto de clase myNewClass obtengo esta excepción:

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 ];

Supongo que el problema es rdnAttId, que parece ser esencial en AD (y no en OpenDS). Solo puedo establecerlo en un solo valor (por lo que he elegido myAttribute1), pero ¿no debería ser más parecido a myAttribute1 AND myAttribute2 AND myAttribute3?

Que hacer?

Answer 1

Ok aquí hay un ejemplo de LDIF con una creación de clase. Deberías haber seguido mi consejo. Primero, lo crea con la consola de gestión de Microsoft, luego lo exporta usando LDIFDE.EXE, limpia su LDIFDE y luego puede importarlo en otro 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

En Active-Directory rDNAttID es el nombre del atributo que se usa para crear el nombre rDNAttID relativo. En el punto de vista teórico, puede elegir el que desee. Desde el punto de vista práctico, nunca uso nada más que CN .

Editado:

Una vez que haya creado sus atributos, tenga cuidado de volver a cargar su esquema para tenerlos disponibles para crear la clase. Aquí está el conmutador:

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

Editado:

Como su DN es cn=myNewClass,cn=Schema,cn=Configuration,dc=X , DEBE agregar CN a los atributos dn: cn:myNewClass (aunque debe agregarse automáticamente).

Editado: según la documentación de Microsoft :

En lo que respecta a RDN, la correspondencia entre el modelo de Active Directory y el modelo de datos LDAP es la siguiente. Un objeto con sus atributos y valores corresponde a una entrada LDAP con sus atributos y valores. Este modelo y LDAP acuerdan la definición del atributo objectClass. La definición de RDN en este modelo es un subconjunto de la definición de LDAP; todos los RDN en este modelo son RDN LDAP válidos, pero no al revés. Por ejemplo, el siguiente RDN multivalor es un RDN LDAP válido, pero no es válido en este modelo: "cn = Peter Houston + employeeID = ABC123". Dada la definición de RDN, la definición de DN en este modelo es la misma que la definición de LDAP. En el modelo de datos LDAP, la relación padre-hijo se representa en los DN del hijo y del padre, mientras que en el modelo de datos de Active Directory, la relación padre-hijo se representa en el atributo padre y se deriva el DN. Active Directory no expone el atributo principal del modelo a través de LDAP.