Administração do Windows

Extensão do esquema do Active Directory

Vikas Malhotra

Visão geral:

• Noções básicas sobre o esquema padrão do Active Directory
• Adição de objetos classSchema ou attributeSchema
• Obtenção e uso de identificadores de objetos
• Extensão do esquema usando arquivos .ldif

Faça download do código deste artigo: Schema2008_05.exe (151KB)

Desde a introdução do Active Directory, com o lançamento do Windows 2000, a Microsoft tem fornecido aos clientes a definição básica do esquema para implementar o Active Directory.

A presença do Active Directory® representou também uma mudança na forma como muitos aplicativos eram escritos e implementados no Windows®. Antes, aplicativos como o Microsoft® Exchange 5.5 eram criados de forma a conter uma estrutura própria de diretórios. Com a disponibilidade do Active Directory, muitos aplicativos (da Microsoft e de outras empresas) começaram a aproveitar a estrutura subjacente fornecida por ele, em vez de criar um esquema próprio a partir do zero.

Esses aplicativos partiram da arquitetura básica fornecida pelo Active Directory, estendendo-a conforme a necessidade. O Microsoft Exchange 2000, por exemplo, utilizou o Active Directory para implementações de mensagens, definindo assim o futuro da arquitetura de mensagens da Microsoft.

Atualmente, muitos aplicativos escritos para funcionar em um ambiente do Active Directory contam com seu esquema subjacente para funcionar. Há também muitos que definem suas próprias alterações no esquema, conforme a necessidade. Logicamente, isso requer um esquema passível de extensão, o que será abordado neste artigo. Além disso, como muitos aplicativos dependem das definições básicas do Active Directory, a estabilidade constante do esquema central é fundamental. Muitos aplicativos precisam operar juntos no mesmo Active Directory, então as alterações feitas para qualquer um deles não devem exercer impacto sobre os demais.

O que é um esquema?

Para muitos profissionais, o esquema do Active Directory é uma "caixa preta", e a idéia de modificá-lo por conta própria pode ser intimidadora. É claro que estender seu esquema do Active Directory não é algo que você precisará fazer todos os dias, mas pode ser um requisito para certos aplicativos ou necessidades de negócios. Portanto, é muito importante entender o que é um esquema e o que ele contém. Afinal, o Active Directory é um ativo vital para muitas organizações, e o seu mau funcionamento devido a uma atualização incorreta pode ter um impacto considerável.

Muitas organizações avaliam, como estratégia, o uso do ADLDS (Active Directory Lightweight Directory Service) no Windows Server® 2008, ou do ADAM (Active Directory Application Mode) no Windows Server 2003, como alternativa ao teste e à implementação direta de definições personalizadas de esquema, em vez da extensão do esquema do Active Directory.

Um esquema é a estrutura subjacente que fornece o formato de um serviço de diretório. O esquema do Active Directory define as classes de objetos e os atributos usados pelos ADDS (Serviços de Domínio Active Directory). O esquema central contém definições para muitas classes (como user, computer e organizationalUnit) e atributos (como telephoneNumber e objectSID) conhecidos. Os objetos presentes na definição do esquema central são conhecidos como objetos de Categoria 1; já os adicionados são chamados de objetos de Categoria 2.

É possível encontrar um esquema do Active Directory no contêiner definido no caminho cn=Schema, cn=Configuration,dc=X, onde X é o namespace da floresta do Active Directory. Observe que uma floresta do Active Directory contém um único esquema; fazer alterações na definição do esquema em uma floresta afeta todos os domínios nessa floresta. A Figura 1 mostra o número de classes e atributos adicionados ao esquema do Active Directory em diferentes versões do Windows Server.

Figure 1 Número de classes e atributos

A atualização do esquema em diferentes versões do Windows Server é feita com o uso de um utilitário chamado Adprep. Com as atualizações do Windows Server 2003 R2, a versão do esquema é atualizada para 31. Com o Windows Server 2008, ela é alterada para 44.

Isso pode ser confirmado verificando o valor do atributo objectVersion de cn=Schema,cn=Configuration,dc=X no seu Active Directory, usando uma ferramenta como o ADSIEdit. Observe que alguns aplicativos, como o Exchange Server, o SMS (System Management Server) e outros que dependem do Active Directory, podem modificar o esquema de acordo com suas necessidades.

Elementos básicos

O Active Directory consiste em dois tipos de objetos: classSchema (classe, em resumo) e attributeSchema (atributo, em resumo). Em geral, avalia-se a possibilidade de estender o esquema do Active Directory quando uma organização deseja armazenar dados em certos atributos indisponíveis no esquema existente. Você pode criar um atributo em um esquema do Active Directory especificando, primeiro, um objeto attributeSchema no contêiner do esquema e, depois, definindo as propriedades necessárias para o novo objeto.

Você encontra uma lista de propriedades para objetos attributeSchema, juntamente com informações sobre elas, em go.microsoft.com/fwlink/?LinkId=110445. Como você pode ver, há muitas propriedades que podem ser definidas para objetos attributeSchema; algumas delas são obrigatórias.

Além dos atributos normais, um esquema contém atributos especiais chamados Vinculados, que são implementados aos pares, com o fornecimento de um vínculo progressivo e de um vínculo regressivo. Como exemplo, pense na associação a um grupo no Active Directory. O atributo member de qualquer grupo (por exemplo, um grupo chamado ContosoEmployees, com um membro chamado José Silva) é o vínculo progressivo, e o atributo correspondente memberOf do objeto member é o vínculo regressivo. Quando, por exemplo, o atributo memberOf de José Silva for consultado, o DN (nome diferenciado) do grupo ContosoEmployees será calculado.

O vínculo progressivo se comporta de forma bastante semelhante a qualquer outro atributo. Pode ter um só ou vários valores (assim como o atributo member, que pode conter vários objetos como membros de um grupo). Esses valores são armazenados juntamente com o objeto pai no diretório.

Os vínculos regressivos, por outro lado, são mantidos pelo sistema para garantir a integridade referencial. Quando você consulta o valor de um atributo de vínculo regressivo, os resultados são calculados a partir dos valores de todos os vínculos progressivos correspondentes. Os vínculos regressivos sempre têm vários valores.

Cada classe de objeto nos ADDS é definida por um objeto classSchema no contêiner do esquema. Você encontra uma lista de atributos essenciais para a definição bem-sucedida do objeto classSchema em go.microsoft.com/fwlink/?LinkId=110445.

É possível especificar três tipos de classes: estrutural, abstrata e auxiliar. Esses tipos são definidos pelo valor do atributo objectClassCategory (uma quarta categoria, conhecida como 88, inclui classes definidas antes dos padrões X.500 1993. Esse tipo de classe é especificado pelo valor 0 no atributo objectClassCategory. Não se deve mais definir esse tipo de classe).

Obtenção e uso de identificadores

As identidades de cada objeto classSchema e attributeSchema no diretório são definidas com o uso de um OID (identificador de objeto) obrigatório, definido em relação a governsID para objetos classSchema e em relação a attributeID para objetos attributeSchema. Os OIDs são valores numéricos exclusivos fornecidos por certas autoridades emissoras para identificar os objetos. A numeração é regida pela definição do protocolo LDAP (RFC 2251). Alguns OIDs no esquema do Active Directory são emitidos pela ISO (International Organization for Standardization) e alguns, pela Microsoft. Um OID deve ser exclusivo de um objeto no diretório.

O OID é uma cadeia de números, por exemplo, 1.2.840.113556.1.y.z, conforme descrito na Figura 2. Assim, o OID de um objeto classSchema de usuário, por exemplo, é 1.2.840.113556.1.5.9.

Figure 2 Identificador para o objeto user

Quando uma organização pretende estender o esquema, ela garante que o OID seja exclusivo obtendo seu próprio número raiz de OID, que é então ramificado para fornecer IDs exclusivos para as novas classes e os novos atributos de objetos criados pela organização. A raiz de OID pode ser obtida diretamente com uma NRA (autoridade nacional de registro) ISO, que nos Estados Unidos é o ANSI (American National Standards Institute).

Você pode acessar o procedimento e a tabela de taxas para obter um OID raiz em ansi.org. Para outras regiões, entre em contato com a organização membro da ISO correspondente. A ISO oferece uma lista em iso.org/iso/about/iso_members.htm.

As organizações costumavam obter OIDs da Microsoft enviando um email para schemreg@microsoft.com. Contudo, isso agora resulta em uma resposta automática com a informação de que o solicitante deve baixar e executar o VBScript em go.microsoft.com/fwlink/?LinkId=110453.

No caso dos OIDs emitidos pela Microsoft, o número é atribuído segundo o espaçamento numérico de OIDs da Microsoft: 1.2.840.113556.1.8000.x, onde x é um número exclusivo atribuído à organização. A organização pode dividir ainda mais esses OIDs para especificar os objetos. Assim, uma organização pode usar 1.2.840.113556.1.8000.x.1.y para novos objetos classSchema e 1.2.840.113556.1.8000.x.2.z para objetos attributeSchema (onde x representa o número exclusivo da organização; y e z são, respectivamente, os números atribuídos para objetos classSchema e attributeSchema específicos). Também é recomendável que um prefixo específico da organização seja usado nos nomes desses objetos para distingui-los.

Definição de atributos vinculados

É importante que o valor attributeSyntax de um vínculo progressivo seja 2.5.5.1, 2.5.5.7 ou 2.5.5.14. Esses valores correspondem a sintaxes que contêm um nome diferenciado, como a sintaxe Object (DS-DN).

O valor attributeSyntax de um vínculo regressivo deve ser 2.5.5.1, que é a sintaxe Object (DS-DN). Por convenção, atributos de vínculos progressivos são adicionados ao valor mayContain da classe abstrata top. Isso permite que o atributo de vínculo regressivo seja lido em objetos de qualquer classe, pois os atributos de vínculos regressivos não são realmente armazenados no objeto; na verdade, são calculados com base nos valores do vínculo progressivo.

O Windows Server 2003 introduziu um recurso que as organizações poderiam utilizar para vincular dois objetos em um esquema: a geração automática de linkIDs. Com esse recurso, o sistema gera automaticamente um linkID para um novo atributo vinculado quando o atributo linkID do atributo é definido como 1.2.840.113556.1.2.50. Um vínculo regressivo correspondente é criado pela definição do linkID para o attributeId ou o ldapDisplayName do vínculo progressivo. O cache do esquema deve ser recarregado após a criação do vínculo progressivo e antes da criação do vínculo regressivo. Caso contrário, o attributeId ou o ldapDisplayName do vínculo progressivo não será encontrado quando o vínculo regressivo for criado. O cache do esquema é recarregado por demanda, alguns minutos depois que a alteração do esquema for feita ou quando o controlador do domínio for reinicializado.

Se o seu Active Directory está no nível do Windows 2000, você precisará solicitar linkIDs da Microsoft enviando um email para schemreg@microsoft.com. Na resposta automática, você verá esta linha: "E-mails sent to schemreg@microsoft.com will be processed only if they are related to linkID registrations for legacy environments." (Os emails enviados para schemreg@microsoft.com somente serão processados se estiverem relacionados aos registros de linkID para ambientes legados.) Para isso, forneça no email as seguintes informações: nome da empresa, nome de contato, endereço de email, número de telefone, prefixo registrado (se for aplicável), OID registrado (se for aplicável).

Pronto para estender o esquema

Digamos que você decidiu estender seu esquema do Active Directory. Talvez essa análise tenha envolvido a eliminação do uso de um diretório alternativo implementado usando o ADLDS (ou o ADAM no Windows Server 2003), depois de verificar que isso não atenderia aos requisitos. Na etapa seguinte, você identificou os novos objetos attributeSchema que deseja adicionar ao esquema e, ao fazer isso, definiu todos os valores necessários (como cn, ldapDisplayName, e assim por diante) que especificam esses novos objetos. Ao definir os valores de atributos para o objeto, você obteve também o OID da Microsoft ou de outra fonte. Essencialmente, você documentou os itens acima como requisitos de negócios e especificações técnicas. Além disso, implementou um ambiente de laboratório imitando seu Active Directory e está pronto para a realização de testes.

Muitas organizações chegam a estabelecer comitês para aprovar ou negar essas alterações e para definir o processo de implementação delas. Essas verificações e avaliações são fundamentais, uma vez que o Active Directory é usado como uma fonte de informações autorizadas em muitas organizações. Por isso, nunca é demais reforçar a importância de mantê-lo em funcionamento após a realização das alterações.

Quando a organização decidir seguir adiante, você deverá definir planos de teste e implementação para o projeto. Você pode estender o esquema adicionando os novos objetos com o snap-in do esquema do Active Directory, que faz parte do MMC (Console de Gerenciamento Microsoft), ou então usando métodos programáticos ou semiprogramáticos para estender o esquema, como LDIFDE para importar arquivos no formato .ldif; CSVDE para importar arquivos no formato .csv; ou com scripts das ADSI (Active Directory Service Interfaces).

Seja qual for o método utilizado, essa função deve ser executada em um servidor conectado ou detentor da função de FSMO (Flexible Single Master Operations) do mestre de esquema na floresta do Active Directory. Além disso, a conta usada na atualização do esquema precisa ter privilégios de administração suficientes para executar a atualização. Portanto, torne-a membro do grupo de administradores de esquema. Por fim, você deve habilitar as atualizações do esquema para a floresta (são desabilitadas por padrão).

A menos que a alteração seja muito simples, deve ser feita de modo automatizado, a fim de promover a padronização entre as fases de implementação de teste e de produção e reduzir os tipos de erros que provavelmente resultariam da execução manual dessas etapas. Suponhamos que você decida implementar sua alteração usando LDIFDE. Para aplicar atualizações ao estender o esquema, você deve adicionar os novos atributos e classes, adicionar os novos atributos às classes e então disparar uma recarga do cache. Vamos analisar alguns cenários.

Adição de atributos

Suponha, para fins de argumentação, que uma organização chamada Contoso quer adicionar um atributo a seu Active Directory para identificar o tamanho do calçado de cada funcionário. A floresta do Active Directory tem dois domínios: contoso.com e employees.contoso.com. O requisito é que todos os objetos criados usando a definição da classe user contenham também esse novo atributo.

É importante lembrar-se de que a alteração do esquema afetará os dois domínios, pois estão na mesma floresta. Vamos supor que você tenha recebido o OID de 1.2.840.113556.8000.9999 da Microsoft e que tenha feito uma subdivisão em 1.2.840.113556.8000.9999.1 para objetos classSchema e 1.2.840.113556.8000.9999.2 para objetos attributeSchema da Contoso. Agora, você definirá todos os valores de atributos para esse novo objeto, conforme mostrado na Figura 3.

Figure 3 Definindo o atributo contosoEmpShoe

Além disso, embora o atributo contosoEmpShoe precise estar disponível para todos os objetos criados como objetos da classe user, não é recomendável que você modifique a definição padrão da classe user. Em vez disso, você deve definir uma classe auxiliar chamada contosoUser, que tem o valor de mayContain especificado como contosoEmpShoe, conforme mostrado na Figura 4. Então, você deve adicionar os atributos definidos para a classe auxiliar contosoUser à classe user.

Figure 4 Definindo a classe contosoUser

Agora que você realizou a análise e definiu os valores, é hora de criar o arquivo .ldif, que terá uma aparência semelhante à do código na Figura 5. Você pode copiar o conteúdo da Figura 5 no Bloco de Notas e salvar o arquivo como contosoUser.ldif (também há uma cópia disponível no download de código da technetmagazine.com).

Figure 5 Arquivo .ldif para estender seu 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

Depois de gerar o arquivo .ldif, você vai querer testar minuciosamente a implementação em um ambiente de laboratório, verificar a replicação completa do seu domínio e da sua floresta e habilitar a atualização do esquema na floresta. Neste ponto, você deve fazer logon com uma conta que tenha privilégios de administração de esquema. Talvez você queira desabilitar a replicação de saída no mestre de esquema (onde a alteração será executada) e depois executar o seguinte comando para importar o arquivo .ldif:

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

Quando a alteração ocorrer, habilite a replicação de saída no mestre de esquema e verifique se ocorreu a replicação de todos os controladores de domínio.

Respire fundo — você terminou! Você definiu um novo atributo no esquema que será associado aos objetos criados usando a classe user (ou seja, as contas de usuários).

Para verificar a alteração, abra Usuários e Computadores do Active Directory, conecte-se ao domínio employees.contoso.com, navegue até a UO (unidade organizacional) Users e crie uma nova conta de usuário chamada ContosoTestUser. Agora, abra o console adsiedit.msc e conecte-se à partição de domínio dc=employees,dc=contoso,dc=com, expanda a UO Users, clique com o botão direito do mouse em ContosoTestUser e abra a página de propriedades. Procure o atributo contosoEmpShoe. Você pode editar esse atributo para inserir um valor. Pode também usar o utilitário Ldp.exe para verificar e modificar os atributos.

Vejamos agora um exemplo que define e vincula dois atributos, e vamos imaginar um cenário onde a Contoso considere de grande importância o tamanho do calçado dos funcionários e queira que o desempenho anual das pessoas que medem esse tamanho na empresa seja controlado de alguma forma. Embora pareça engraçado, vamos supor ainda que a Contoso, além de manter o controle de quem foi responsável por medir o tamanho do calçado dos funcionários, queira controlar de quem foi o tamanho medido e quantas medições foram feitas — tudo isso com a consulta a um só atributo (talvez você ache que é mais adequado armazenar esses dados em tabelas de banco de dados, mas a idéia aqui é simplesmente explicar o funcionamento dos vínculos progressivos e regressivos).

É claro que, em primeiro lugar, você faria o mesmo tipo de análise mencionado no exemplo anterior. No entanto, aqui é preciso ir mais adiante e gerar os arquivos .ldif linkids1.ldif e linkids2.ldif, conforme mostrado na Figura 6. Então, é preciso executar este comando para importar os arquivos .ldif:

Figure 6 Arquivos .ldif de vínculos progressivos e regressivos

 
#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

Agora, quando um objeto de usuário for criado, ele terá também ContosoShoeSizeTaker e ContosoShoeSizesTakenByMe como atributos. Ao criar o objeto de usuário para, digamos, José, o atributo ContosoShoeSizeTaker será preenchido com o DN do funcionário que mediu o tamanho do calçado, chamado Francisco. Agora, quando você analisar as propriedades de objeto de usuário de Francisco e consultar o atributo ContosoShoeSizesTakenByMe, o resultado irá conter o DN de José e dos outros funcionários que tiveram o calçado medido por Francisco. Para concluir o cenário, a gerência pode recompensar Francisco com base na quantidade de DNs existentes no atributo ContosoShoeSizesTakenByMe da sua conta de usuário.

Verificações e avaliações do sistema

Uma atualização crítica como a modificação de esquema não pode ser realizada sem verificações em relação a requisitos de arquitetura. Essas verificações de consistência e segurança são usadas pelo Active Directory para verificar se as alterações não causam inconsistências ou outros problemas, sempre que uma adição ou modificação é feita no esquema do Active Directory.

Primeiro, o valor de governsID para cada classe deve ser exclusivo no esquema. Quando você definir um objeto schemaClass, todos os atributos definidos nas listas systemMayContain, mayContain, systemMustContain e mustContain já devem existir. Ao mesmo tempo, todas as classes definidas nas listas subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors e possSuperiors também já devem existir.

Além disso, a objectClassCategory de todas as classes nas listas systemAuxiliaryClass e auxiliaryClass deve ser a classe 88 ou auxiliar. Da mesma forma, a objectClassCategory de todas as classes nas listas systemPossSuperiors e possSuperior deve ser especificada como a classe 88 ou estrutural.

Ao definir várias classes, as classes abstratas podem herdar somente de outras classes abstratas; as classes auxiliares não podem herdar de classes estruturais; e as classes estruturais não podem herdar de classes auxiliares. Além disso, o atributo especificado no atributo rDNAttID deve ter a cadeia de caracteres Unicode como sua sintaxe e ter um único valor.

Essas são algumas das regras relacionadas aos objetos classSchema. E quanto às regras para os objetos attributeSchema? Assim como o valor governsID para as classes, o valor de attributeID deve ser exclusivo. Também o valor de mAPIID, se houver, deve ser exclusivo. Ainda, se rangeLower e rangeUpper estiverem presentes, rangeLower deve ser menor do que rangeUpper. Os valores de attributeSyntax e oMSyntax devem ser correspondentes. Se o atributo tiver sintaxe de objeto (oMSyntax =127), deverá ter a oMObjectClass correta. O linkID, se houver, deve ser exclusivo. Um vínculo regressivo também precisa ter um vínculo progressivo correspondente.

E se você errar?

Quando o esquema tiver sido estendido com os novos objetos (classes e atributos), eles não poderão ser excluídos. No entanto, é possível desativar uma classe ou um atributo, configurando o atributo isDefunct como TRUE no objeto do esquema. Você não pode desativar objetos de esquema que fazem parte do esquema padrão fornecido com o Active Directory (objetos da Categoria 1). Pode apenas desativar objetos que foram adicionados ao esquema padrão, ou seja, somente objetos da Categoria 2 podem ser desabilitados, e somente quando o Active Directory tiver verificado que a classe não é utilizada nas listas subClassOf, auxiliaryClass ou possSuperiors de qualquer uma das classes não-extintas existentes.

Diante de qualquer tentativa de tornar um atributo extinto, o Active Directory verifica se o atributo não é usado no mustContain ou no mayContain de qualquer classe não-extinta existente. Os objetos desabilitados podem ser reativados com a configuração do atributo isDefunct como FALSE. Se o seu Active Directory estiver no nível do Windows Server 2003, você poderá reutilizar os valores de ldapDisplayName, schemaIdGuid, OID e mapiID do objeto desabilitado.

Conclusão

Adicionar ou modificar definições de classes ou atributos no esquema envolve a adição ou a modificação do objeto classSchema ou attributeSchema correspondente. Esse processo é semelhante à adição ou à modificação de qualquer objeto no Active Directory, exceto pelo fato de que verificações adicionais são realizadas para garantir que as alterações não causem inconsistências ou problemas futuros no esquema.

Embora modificar o esquema do Active Directory seja simples, é importante entender a formação do esquema e como ele funciona para implementar essas alterações. Qualquer alteração no esquema de produção do Active Directory requer muito planejamento e deve ser feita com cautela. É fundamental que você defina os requisitos de negócios e as especificações técnicas para os novos objetos e realize muitos testes em laboratório. Como as alterações podem ter efeitos profundos, é recomendável somente estender o esquema do Active Directory quando for absolutamente necessário.

Vikas Malhotra atua nos Serviços de Consultoria Microsoft, em Nova York. Há 12 anos no setor, ele já trabalhou com muitas organizações de TI, atendendo a necessidades de arquitetura de infra-estrutura em diretórios, mensagens, segurança e redes de dados. É bacharel em engenharia eletrônica e de telecomunicações e possui mestrado em gerenciamento tecnológico de telecomunicações. Entre em contato com ele pelo email vikasmal@microsoft.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..