Administración de Windows

Ampliación del esquema de Active Directory

Vikas Malhotra

Resumen:

• Descripción del esquema de Active Directory predeterminado
• Adición de objetos classSchema o attributeSchema
• Obtención y uso de identificadores de objetos
• Ampliación del esquema con archivos .ldif

Descargar el código de este artículo: Schema2008_05.exe (151KB)

Desde la aparición de Active Directory con el lanzamiento de Windows 2000, Microsoft ha proporcionado a los consumidores la definición del esquema de base para la implementación de Active Directory.

La presencia de Active Directory® también supuso un giro en la forma de escribir e implementar muchas aplicaciones en Windows®. Antes, las aplicaciones como Microsoft® Exchange 5.5 se creaban para que contuvieran sus propias estructuras de directorio. Con la aparición de Active Directory, muchas aplicaciones (tanto de Microsoft como de otras empresas) comenzaron a aprovechar la estructura subyacente que ofrecía, en lugar de crear sus propios esquemas desde cero.

Estas aplicaciones comenzaban con la arquitectura básica que proporcionaba Active Directory y la ampliaban según sus necesidades. Microsoft Exchange 2000, por ejemplo, usaba Active Directory para las implementaciones de mensajería, definiendo de este modo el futuro de la arquitectura de mensajería de Microsoft.

Hoy en día, muchas de las aplicaciones escritas para funcionar en un entorno de Active Directory dependen de su esquema subyacente para funcionar. Del mismo modo, muchas de ellas definen sus propios cambios en el esquema según sus necesidades. Esto, por supuesto, requiere un esquema que se pueda ampliar, como explicaré más adelante. Además, ya que hay tantas aplicaciones que dependen de las definiciones de base de Active Directory, la estabilidad continuada del esquema principal es esencial. Ya que muchas aplicaciones necesitan trabajar juntas en el mismo Active Directory, los cambios que se realicen para cualquier aplicación no deben afectar a las otras.

¿Qué es un esquema?

Para muchos, el esquema de Active Directory es una caja negra, por lo que la idea de modificar el esquema por cuenta propia puede resultar intimidante. Aunque la ampliación del esquema de Active Directory no es algo que necesite realizar todos los días, algunas aplicaciones o necesidades empresariales pueden requerir que lo haga. Por lo tanto, es muy importante entender qué es un esquema y qué contiene, ya que Active Directory es un activo esencial para muchas organizaciones y un funcionamiento incorrecto de éste a causa de una actualización incorrecta puede tener un impacto muy importante.

A modo de estrategia, hay muchas organizaciones que piensan en el uso de Active Directory Lightweight Directory Service (ADLDS) en Windows Server® 2008 (Active Directory Application Mode, ADAM, en Windows Server 2003) como una alternativa para probar o implementar directamente las definiciones de esquema personalizadas en lugar de ampliar el esquema de Active Directory.

Un esquema es la estructura subyacente que proporciona el formato para un servicio de directorio. El esquema de Active Directory define las clases y atributos de objeto que se usan en los Servicios de dominio de Active Directory (ADDS, Active Directory Domain Services). El esquema principal proporciona definiciones para muchas clases conocidas (como user, computer y organizationalUnit) y atributos (como telephoneNumber y objectSID). Los objetos presentes en la definición de esquema principal se conocen como objetos de Categoría 1 y los objetos que se agregan se denominan objetos de Categoría 2.

Se puede encontrar un esquema de Active Directory en el contenedor definido en la ruta de acceso cn=Schema,cn=Configuration,dc=X, donde "X" es el espacio de nombres del bosque de Active Directory. Tenga en cuenta que un bosque de Active Directory sólo contiene un esquema, los cambios que se realicen en la definición del esquema de un bosque afectarán a todos los dominios del mismo. En la Figura 1 se muestra el número de clases y atributos que se agregan al esquema de Active Directory en diferentes versiones de Windows Server.

Figure 1 Número de clases y de atributos

La actualización del esquema para las diferentes versiones de Windows Server se lleva a cabo a través de una utilidad llamada Adprep. Con las actualizaciones de Windows Server 2003 R2, la versión del esquema se actualiza a la 31, y cambia a la 44 con Windows Server 2008.

Esto se puede comprobar a través del valor del atributo objectVersion de cn=Schema,cn=Configuration,dc=X en Active Directory mediante el uso de una herramienta como ADSIEdit. Observe que algunas aplicaciones como Exchange Server, System Management Server (SMS) u otras que dependan de Active Directory pueden modificar el esquema en función de las necesidades de las aplicaciones.

Ladrillos y mortero

Active Directory consta de dos tipos de objetos: classSchema (abreviado clase) y attributeSchema (abreviado atributo). La ampliación del esquema de Active Directory suele plantearse cuando una organización desea almacenar datos en ciertos atributos que no están disponibles en el esquema existente. Para crear un atributo en un esquema de Active Directory, especifique, en primer lugar, un objeto attributeSchema en el contenedor de esquema y defina, a continuación, las propiedades necesarias para el nuevo objeto.

Podrá encontrar una lista de propiedades para los objetos attributeSchema e información relacionada en go.microsoft.com/fwlink/?LinkId=110445. Como puede ver, hay muchas propiedades que se pueden definir para los objetos attributeSchema. Muchas de estas propiedades son necesarias.

Aparte de los atributos habituales, también existen atributos especiales llamados atributos vinculados dentro de un esquema que se implementan en parejas proporcionando un vínculo hacia adelante y un vínculo hacia atrás. A modo de ejemplo, piense en la pertenencia a un grupo Active Directory. El atributo de miembro de cualquier grupo (por ejemplo, un grupo llamado ContosoEmployees con un miembro que se llame Arturo López) es el vínculo hacia adelante y el atributo correspondiente memberOf del objeto de miembro es el vínculo hacia atrás (de manera que, por ejemplo, al realizar una consulta al atributo memberOf de Arturo López, se calcula el nombre distintivo, o DN, de ContosoEmployees).

El vínculo hacia adelante se comporta como cualquier otro atributo. Los valores pueden tener un solo valor o diversos valores (al igual que ocurre con el atributo member, que puede contener varios objetos como miembros de un grupo) y se almacenan juntos con el objeto principal en el directorio.

Los vínculos hacia atrás, por otro lado, los mantiene el sistema para asegurar la integridad referencial. Al realizar una consulta para saber el valor de un vínculo hacia atrás, se calcularán los resultados a partir de todos los valores de los vínculos hacia adelante que coincidan. Los vínculos hacia atrás siempre tienen diversos valores

Las clases de objeto en ADDS las define un objeto classSchema del contenedor de esquema. Puede encontrar una lista con los atributos esenciales para definición correcta del objeto classSchema en go.microsoft.com/fwlink/?LinkId=110445.

Hay tres tipos de clases que se pueden especificar: estructurales, abstractas y auxiliares. A estas clases las define el valor de atributo objectClassCategory. Una cuarta categoría, conocida como 88, incluye las clases definidas antes de los estándares X.500 de 1993. Este tipo de clase lo especifica un valor de 0 en el atributo objectClassCategory. Este tipo de clase ya no debe definirse.

Obtención y uso de identificadores

Las identidades de todos los objetos classSchema y attributeSchema del directorio se definen mediante un identificador de objetos (OID) obligatorio, que se define con el atributo governsID para los objetos classSchema y attributeID para los objetos attributeSchema. Se trata de valores numéricos exclusivos que proporcionan algunas autoridades emisoras para identificar los objetos. La numeración se rige por la definición del protocolo LDAP (RFC 2251). Algunos de los OID del esquema de Active Directory los emite la Organización internacional de normalización (ISO, International Organization for Standardization) y otros los emite Microsoft. Un OID debe ser exclusivo para un objeto del directorio.

El OID es una cadena de números, por ejemplo, 1.2.840.113556.1.y.z, como aparece en la Figura 2. Por lo tanto, un OID para un objeto classSchema de user, por ejemplo, sería 1.2.840.113556.1.5.9.

Figure 2 Identificador para el objeto user

Cuando una organización tiene intención de ampliar el esquema, se asegura de que el OID sea exclusivo, obteniendo su número de OID raíz, que se ramifica para ofrecer identificadores únicos a los nuevos atributos y clases de objeto que crea la organización. EL OID raíz se puede obtener directamente de una autoridad de registro nacional (NRA) ISO, que en Estados Unidos es el American National Standards Institute (ANSI).

Puede conseguir el programa de procedimientos y de honorarios para obtener un OID raíz en ansi.org. En el caso de otras regiones, póngase en contacto con la organización miembro de ISO correspondiente. Puede encontrar una lista en iso.org/iso/about/iso_members.htm.

Antes, las organizaciones podían obtener un OID de Microsoft enviando un mensaje de correo electrónico a schemreg@microsoft.com. No obstante, ahora se produce una respuesta automática que pide al solicitante que descargue y ejecute el VBScript de go.microsoft.com/fwlink/?LinkId=110453.

Ya que Microsoft emite los OID, el número se asigna en el espacio de número de OID de Microsoft: 1.2.840.113556.1.8000.x, donde "x" es un número exclusivo asignado a la organización. La organización puede seguir dividiendo estos OID para especificar los objetos. Por lo tanto, una organización puede usar 1.2.840.113556.1.8000.x.1.y para los nuevos objetos de classSchema y 1.2.840.113556.1.8000.x.2.z para los objetos de attributeSchema (donde x representa el número único de la organización e "y" y "z", son los números asignados respectivamente para los objetos específicos de classSchema y attributeSchema). Además, se recomienda el uso de un prefijo específico de la organización en los nombres de los objetos para distinguirlos.

Definición de los atributos vinculados

Es importante que el valor attributeSyntax de un vínculo hacia adelante sea 2.5.5.1, 2.5.5.7 o 2.5.5.14. Estos valores corresponden a las sintaxis que contiene un nombre distintivo, como la sintaxis de objeto (DS-DN).

El valor attributeSyntax de un vínculo hacia atrás debe ser 2.5.5.1, que es la sintaxis de objeto (DS-DN). Por convención, los atributos hacia atrás se agregan al valor mayContain de la clase abstracta principal. Esto permite que el vínculo hacia atrás lea de objetos de cualquier clase, ya que los atributos de vínculos hacia atrás no se almacenan realmente con el objeto, sino que se calculan en función de los valores de los vínculos hacia adelante.

Windows Server 2003 presentó una característica que las organizaciones podían usar para vincular dos objetos en un esquema: generación automática de atributos linkID Gracias a esta característica, el sistema genera de forma automática un atributo linkID para un atributo vinculado nuevo cuando el linkID del atributo se establece en 1.2.840.113556.1.2.50. Se crea un vínculo correspondiente al establecer el linkID en el attributeId o ldapDisplayName del vínculo hacia adelante. Hay que volver a cargar la memoria caché del esquema tras la creación del vínculo hacia adelante y antes de crear el vínculo hacia atrás. De lo contrario, no se encontrarán los atributos attributeId o ldapDisplayName cuando se cree el vínculo hacia atrás. La memoria caché del esquema se vuelve a cargar a petición unos minutos después de realizar un cambio o al reiniciar el controlador del dominio.

Si Active Directory se encuentra en el nivel de Windows 2000, necesitará solicitar atributos linkID de Microsoft mediante el envío de un mensaje de correo electrónico a schemreg@microsoft.com. En la respuesta automática se le informará de que los mensajes de correo electrónico enviados a schemreg@microsoft.com sólo se procesarán si están relacionados con los registros de linkID para entornos heredados. Por este motivo, proporcione la siguiente información en el mensaje de correo electrónico: nombre de la empresa, nombre de contacto, dirección de correo electrónico, prefijo registrado (si corresponde), OID registrado (si corresponde).

Preparado para ampliar el esquema

Supongamos que se ha decidido a ampliar el esquema de Active Directory. Este análisis puede haber implicado la reducción en el uso de un directorio alternativo implementado mediante ADLDS (o ADAM en Windows Server 2003) tras asegurarse de que no cumple los requisitos. El siguiente paso, es identificar los nuevos objetos attributeSchema que desea agregar al esquema y, al hacerlo, ha definido todos los valores necesarios (como ocurre con, ldapDisplayName y demás) que especifican estos nuevos objetos. En la definición de los valores de atributo para el objeto, ha obtenido también el OID de Microsoft o de otra fuente. Principalmente, ha documentado lo anterior como requisitos empresariales y especificaciones técnicas. Además, ha implementado un entorno de laboratorio que imita a Active Directory y que está preparado para realizar pruebas.

Muchas organizaciones forman comités para aprobar o denegar dichos cambios y establecen el proceso para implementarlos. Sobra decir que la necesidad de tales comprobaciones y balances es crítica, ya que muchas organizaciones usan Active Directory como una fuente de información de peso, por lo que conservarlo en perfecto estado y en funcionamiento tras los cambios es esencial.

Una vez que la organización se decide a actuar, debe definir los planes de prueba y de implementación para el proyecto. Puede ampliar el esquema agregando nuevos objetos con el complemento del esquema de Active Directory que se encuentra en Microsoft Management Console (MMC) o mediante métodos de programación o de semiprogramación para ampliar el esquema (usando, por ejemplo, LDIFDE para importar archivos con el formato .ldif; CSVDE para importar archivos con el formato .csv; o mediante el scripting con interfaces ADSI).

Independientemente del método que use, debe realizar esta función en un servidor que esté conectado o que disponga de la función Flexible Single Master Operations (FSMO) del maestro de esquema del bosque de Active Directory. Además, la cuenta que use para actualizar el esquema necesita disponer de los privilegios de administración suficientes para realizar la actualización, así que puede hacerla un miembro del grupo Administradores de esquemas. Finalmente, debe habilitar las actualizaciones del esquema para el bosque (deshabilitadas de forma predeterminada).

A menos que el cambio sea muy sencillo, debería realizarse de forma automática para fomentar la estandarización entre las fases de prueba y de implementación de producción y para reducir los tipos de error que se pueden producir al realizar los pasos de forma manual. Imagine que decide implementar el cambio mediante LDIFDE. Para aplicar actualizaciones a la hora de ampliar el esquema, debería agregar los nuevos atributos y clases, agregar los nuevos atributos a las clases y activar una carga de la memoria caché. Examinemos un par de situaciones.

Adición de atributos

Imagine que una organización llamada Contoso desea agregar un atributo a Active Directory que identifique la talla de zapato de los empleados. El bosque de Active Directory tiene dos dominios: contoso.com y employees.contoso.com. El requisito es que todos los objetos creados con la definición de clase user deberían contener este nuevo atributo.

Es importante que recuerde que el cambio en el esquema afectará a ambos dominios, ya que se encuentran en el mismo bosque. Supongamos que ha recibido el OID de 1.2.840.113556.8000.9999 de Microsoft y que lo ha subdividido en 1.2.840.113556.8000.9999.1 para los objetos de classSchema y en 1.2.840.113556.8000.9999.2 para los objetos de attributeSchema para Contoso. Ahora va a definir todos los valores de atributo para este nuevo objeto, como se muestra en la Figura 3.

Figure 3 Definición del atributo contosoEmpShoe

Además, aunque el atributo contosoEmpShoe necesita estar disponible para todos los objetos creados como objetos de clase user, no se recomienda modificar la definición predeterminada de la clase user. En lugar de eso, debería definir una clase auxiliar llamada contosoUser que tenga el valor de mayContain especificado como contosoEmpShoe, como se muestra en la Figura 4. A continuación, puede agregar los atributos definidos para la clase auxiliar contosoUser a la clase user.

Figure 4 Definición de la clase contosoUser

Una vez que ha realizado el análisis y definido los valores, es el momento de crear el archivo .ldif, que tiene el aspecto del código de la Figura 5. Puede copiar los contenidos de la Figura 5 en el Bloc de notas y guardar el archivo como contosoUser.ldif (o puede encontrar una copia en la descarga de código de technetmagazine.com).

Figure 5 Archivo .ldif para ampliar el esquema

#Attribute definition for contosoEmpShoe

dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: contosoEmpShoe
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: contosoEmpShoe
adminDescription: contosoEmpShoe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: contosoEmpShoe
systemOnly: FALSE

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

# Classes

dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: classSchema
cn: contosoUser
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: contosoEmpShoe
rDNAttID: cn
adminDisplayName: contosoUser
adminDescription: contosoUser
objectClassCategory: 3
lDAPDisplayName: contosoUser
name: contosoUser
systemOnly: FALSE

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

dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: auxiliaryClass
auxiliaryClass: contosoUser
-

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

Tras generar el archivo .ldif, deberá probar la implementación a conciencia en un entorno de laboratorio, comprobar la réplica de un extremo a otro del dominio y del bosque y activar la actualización del esquema en el bosque. Llegado a este punto, debería iniciar sesión con una cuenta que disponga de privilegios de administración de esquemas. Tal vez desee deshabilitar la réplica de salida en el maestro de esquema (donde se realizará el cambio) y ejecutar el siguiente comando para importar el archivo .ldif:

ldifde –i –f <Path>\contosoUser.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext

Una vez que se hayan efectuado los cambios, habilite la réplica en el maestro de esquemas y compruebe que la réplica se ha producido en todos los controladores de dominio.

Respire hondo... Ya ha acabado. Ha definido un atributo nuevo en el esquema que se asociará con los objetos creados mediante la clase user (es decir, cuentas de usuario).

Para comprobar el cambio, abra Usuarios y equipos de Active Directory, conecte con el dominio employees.contoso.com, busque la unidad organizativa (OU) Users y cree una nueva cuenta de usuario llamada ContosoTestUser. Abra la consola adsiedit.msc y conéctese a la partición de dominio dc=employees,dc=contoso,dc=com, expanda la OU Users, haga clic con el botón secundario en ContosoTestUser y abra la página Propiedades. Busque el atributo contosoEmpShoe. Puede editar este atributo para escribir un valor. También puede usar la utilidad Ldp.exe para comprobar y modificar los atributos.

Echemos un vistazo a un ejemplo que defina y vincule dos atributos e imaginemos una situación en la que Contoso le dé una gran importancia a las tallas de zapatos de los empleados y desea registrar de alguna forma el rendimiento anual de las personas en relación con las tallas de zapatos. Aunque pueda sonar extraño, imaginemos que Contoso desea realizar un seguimiento no sólo de los responsables de medir las tallas de zapatos de los empleados, sino también de a quiénes corresponden las tallas y del número de medidas realizadas, todo mediante la consulta de un atributo. Tal vez crea que estos datos se almacenarían mejor en tablas de bases de datos, pero mi intención es explicar el funcionamiento de los vínculos hacia adelante y hacia atrás.

Por supuesto, antes de nada, debería realizar el mismo tipo de análisis que traté en el ejemplo anterior. No obstante, avancemos para generar los archivos .ldif linkids1.ldif y linkids2.ldif, como aparecen en la Figura 6. A continuación, ejecute este comando para importar los archivos .ldif:

Figure 6 Archivos .ldif de vínculos hacia adelante y hacia atrás

 
#linkids1.ldif
#Attribute definition for Forward Link Attribute

dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizeTaker
attributeID: 1.2.840.113556.1.8000.9999.2.2
LinkID: 1.2.840.113556.1.2.50
attributeSyntax: 2.5.5.1
isSingleValued: TRUE
adminDisplayName: ContosoShoeSizeTaker
adminDescription: ContosoShoeSizeTaker
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizeTaker
systemOnly: FALSE

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

#Reload schema

#linkids2.ldif

#Attribute definition for Backward Link Attribute

dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizesTakenByMe
attributeID: 1.2.840.113556.1.8000.9999.2.3
LinkID: 1.2.840.113556.8000.9999.2.2
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: ContosoShoeSizesTakenByMe
adminDescription: ContosoShoeSizesTakenByMe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizesTakenByMe
systemOnly: FALSE

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

#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in 
#contosoUser class

dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizeTaker
mayContain: ContosoShoeSizesTakenByMe

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

#Add Backward Link Attribute as MayContain in Top

dn: CN=Top,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

ldifde –i –f <Path>\linkedids<>.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext

Al crear un objeto user, también se crearán ContosoShoeSizeTaker y ContosoShoeSizesTakenByMe como sus atributos. Al crear el objeto user para, por ejemplo, Arturo, se rellena el atributo ContosoShoeSizeTaker con el DN de la persona que midió la talla de zapato, una persona llamada Tomás. Al mirar las propiedades de objeto user de Tomás y realizar una consulta del atributo ContosoShoeSizesTakenByMe, el resultado contendrá el DN de Arturo y todos los que Frank haya tomado. Para completar este escenario, la dirección puede recompensar a Tomás en función del número de DN que haya en el atributo ContosoShoeSizesTakenByMe de su cuenta de usuario.

Comprobaciones de sistema y balances

Una actualización crítica como la modificación del esquema no se puede realizar sin comprobar los requisitos arquitectónicos. Active Directory usa estas comprobaciones de coherencia y de seguridad para asegurarse de que los cambios no causan incoherencias u otros problemas cuando se realiza una adición o modificación en el esquema de Active Directory.

En primer lugar, el valor de governsID para cada clase debe ser único en el esquema. Al definir un objeto schemaClass, todos los atributos que se definen en las listas systemMayContain, mayContain, systemMustContain y mustContain deben existir con anterioridad. Al mismo tiempo, todas las clases que se definen en las listas subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors y possSuperiors también deben existir con anterioridad.

Además, el atributo objectClassCategory de todas las clases de las listas systemAuxiliaryClass y auxiliaryClass deben pertenecer a la clase 88 o a la clase auxiliar. De forma similar, los atributos objectClassCategory de todas las clases de las listas systemPossSuperiors y possSuperiors se deben especificar como de clase 88 o clase estructural.

Al definir distintas clases, las clases abstractas sólo pueden heredar de otras clases abstractas, las clases auxiliares no pueden heredar de clases estructurales y las clases estructurales no pueden heredar de clases auxiliares. Asimismo, el atributo especificado en rDNAttID debe tener una cadena Unicode como sintaxis y presentar un solo valor.

Estas son algunas de las reglas relacionadas con los objetos classSchema. ¿Qué ocurre con los objetos attributeSchema? Como ocurre con el valor governsID para las clases, el valor de attributeID debe ser exclusivo. Además, el valor de mAPIID, si existe, debe ser único. Si existen los valores rangeLower y rangeUpper, rangeLower debe ser menor que rangeUpper. Los valores de attributeSyntax y oMSyntax deben coincidir. Si el atributo tiene sintaxis de objeto (oMSyntax =127), debe tener el atributo oMObjectClass. El atributo linkID, si existe, debe ser exclusivo. Además, un vínculo hacia atrás debe contar con el correspondiente vínculo hacia adelante.

¿Qué ocurre si se equivoca?

Una vez que se ha ampliado el esquema con nuevos objetos (clases y atributos), éstos no se pueden eliminar. No obstante, se puede desactivar una clase o atributo al establecer el atributo isDefunct en TRUE en el objeto de esquema. No se pueden desactivar objetos de esquema que formen parte del esquema predeterminado que incluye Active Directory (objetos de Categoría 1). Sólo puede desactivar objetos que se hayan agregado al esquema predeterminado, es decir, sólo los objetos de Categoría 2 y siempre y cuando Active Directory haya comprobado que ninguna lista subClassOf, auxiliaryClass o possSuperiors usa ninguna de las clases no inactivas existentes.

Siempre que se produzca cualquier intento de inactivar un atributo, Active Directory comprueba que el atributo no lo usen los atributos mustContain ni mayContain de las clases no inactivas. Los objetos inactivos se pueden volver a activar mediante el establecimiento del atributo isDefunct en FALSE. Si Active Directory está a nivel de Windows Server 2003, puede volver a usar los valores ldapDisplayName, schemaIdGuid, OID o mapiID del objeto inactivo.

Conclusión

La adición o modificación de definiciones de clases o atributos en el esquema implica agregar o modificar el objeto classSchema o el objeto attributeSchema correspondiente. Este proceso es similar a la adición o modificación de cualquier objeto en Active Directory, salvo que las comprobaciones adicionales se realizan para asegurar que los cambios no produzcan incoherencias o problemas en el esquema en el futuro.

Aunque la modificación del esquema de Active Directory es una tarea muy sencilla, es importante comprender cómo se forma el esquema y cómo implementa estos cambios. Los cambios en la producción del esquema de Active Directory necesita mucho planeamiento y hay que hacerlos con cuidado. Es esencial definir los requisitos empresariales y las especificaciones técnicas para los nuevos objetos, así como realizar muchas pruebas de laboratorio. Ya que los cambios pueden tener efectos profundos, se recomienda ampliar el esquema de Active Directory sólo cuando sea estrictamente necesario.

Vikas Malhotra trabaja en Servicios de consultoría de Microsoft (Microsoft Consulting Services, MCS) en Nueva York. En los 12 años que lleva en la industria, ha trabajado con muchas organizaciones de TI de tamaño grande y mediano para ayudarles a optimizar su arquitectura de infraestructura, como directorios, mensajería, seguridad y redes de datos. Es licenciado en ingeniería electrónica y telecomunicaciones y ha realizado un máster en ciencias de la administración de las telecomunicaciones. Póngase en contacto con él en vikasmal@microsoft.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.