active-directory ldif opends

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



active-directory ldif (1)

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?


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.