Amministrazione di Windows

Estensione dello schema di Active Directory

Vikas Malhotra

Panoramica:

• Informazioni sullo schema predefinito di Active Directory
• Aggiunta di oggetti classSchema o attributeSchema
• Acquisizione e utilizzo di identificativi di oggetti
• Estensione del proprio schema tramite file .ldif

Scarica il codice per questo articolo: Schema2008_05.exe (151KB)

Dall'introduzione di Active Directory con la versione di Windows 2000, Microsoft ha fornito ai clienti la definizione di schema di base per l'implementazione di Active Directory.

La presenza di Active Directory® ha inoltre rappresentato una svolta nella modalità di scrittura e implementazione di molte applicazioni in Windows®. Prima di allora, le applicazioni come Microsoft® Exchange 5.5 venivano create con una struttura di directory integrata. Con l'introduzione di Active Directory, molte applicazioni (sia di Microsoft che di altre aziende) hanno iniziato ad utilizzare la struttura sottostante fornita, anziché creare il proprio schema da zero.

Tali applicazioni hanno iniziato con l'architettura di base fornita da Active Directory e l'hanno estesa in base alle necessità. Microsoft Exchange 2000, ad esempio, utilizzava Active Directory per le implementazioni di messaggistica, definendo in questo modo il futuro dell'architettura di messaggistica di Microsoft.

Attualmente, il funzionamento di molte applicazioni scritte per operare in un ambiente Active Directory si basa sul suo schema sottostante e molte definiscono anche le proprie modifiche allo schema, in base alle necessità. Questo scenario richiede, ovviamente, uno schema che supporti l'estensione, come illustrerò in questo articolo. Inoltre, poiché molte applicazioni dipendono dalle definizioni di base presenti in Active Directory, la stabilità continua dello schema centrale è essenziale. Poiché molte applicazioni devono essere utilizzate l'una accanto all'altro nella stessa Active Directory, le modifiche apportate ad un'applicazione non devono avere alcun impatto sulle altre.

Definizione di uno schema

Per molti, lo schema di Active Directory è una scatola nera e l'idea di modificare tale schema per conto proprio può apparire assurda. Ovviamente, l'estensione del proprio schema di Active Directory non è un'operazione da eseguire tutti i giorni, ma alcune applicazioni o esigenze aziendali potrebbero richiederla. Quindi, è molto importante capire in cosa consiste lo schema e qual è il suo contenuto, poiché Active Directory è una risorsa essenziale in molte organizzazioni e il suo malfunzionamento a causa di un aggiornamento non corretto può avere un impatto estremamente significativo.

Come strategia, molte organizzazioni considerano l'utilizzo di Active Directory Lightweight Directory Service (ADLDS) in Windows Server® 2008 (o di Active Directory Application Mode, ADAM, in Windows Server 2003) come un'alternativa per verificare o implementare direttamente le definizioni di schema personalizzate anziché estendere lo schema di Active Directory.

Uno schema è la struttura sottostante che fornisce il formato per un servizio di directory. Lo schema di Active Directory definisce le classi di oggetto e gli attributi utilizzati in Active Directory Domain Services (ADDS). Lo schema centrale fornisce definizioni per molte classi note (tra cui user, computer e organizationalUnit) e attributi (tra cui telephoneNumber e objectSID). Gli oggetti presenti nella definizione di schema centrale sono noti come oggetti di Categoria 1, mentre gli oggetti aggiunti sono denominati oggetti di Categoria 2.

Uno schema di Active Directory può essere trovato nel contenitore definito nel percorso cn=Schema,cn=Configuration,dc=X in cui X è lo spazio nomi della foresta di Active Directory. Tenere presente che una foresta di Active Directory contiene soltanto un singolo schema, quindi l'esecuzione di modifiche alla definizione di schema in una foresta influisce su tutti i domini presenti in tale foresta. La figura 1 mostra il numero di classi e attributi aggiunti nello schema di Active Directory in differenti versioni di Windows Server.

Figure 1 Numero di classi e attributi

L'aggiornamento dello schema per tali versioni viene eseguito tramite un'utilità denominata Adprep. Con gli aggiornamenti per Windows Server 2003 R2, la versione di schema viene aggiornata a 31 e cambia in 44 con Windows Server 2008.

Tale situazione può essere verificata controllando il valore dell'attributo objectVersion di cn=Schema,cn=Configuration,dc=X nella propria Active Directory tramite uno strumento come ADSIEdit. Tenere presente che alcune applicazioni tra cui Exchange Server, System Management Server (SMS) o altre che dipendono da Active Directory potrebbero modificare lo schema in base alle esigenze dell'applicazione.

Componenti essenziali

Active Directory è composta da due tipi di oggetti: classSchema (classe per short) e attributeSchema (attributo per short). Generalmente, l'estensione dello schema di Active Directory viene presa in considerazione quando un'organizzazione intende memorizzare i dati in attributi non disponibili nello schema esistente. Per creare un attributo in uno schema di Active Directory, specificare prima un oggetto attributeSchema nel contenitore schema e poi definire le proprietà necessarie per il nuovo oggetto.

Per un elenco di proprietà per gli oggetti di attributeSchema con relative informazioni, consultare il collegamento go.microsoft.com/fwlink/?LinkId=110445. Come appare evidente, è possibile definire molte proprietà per gli oggetti attributeSchema e alcune di queste sono obbligatorie.

Oltre agli attributi regolari, esistono anche attributi speciali denominati "attributi collegati all'interno di uno schema", implementati in coppie fornendo un collegamento in avanti e un collegamento a ritroso. Come esempio, si consideri l'appartenenza ai gruppi in Active Directory. L'attributo member di qualunque gruppo (ad esempio, un gruppo denominato ContosoEmployees con un membro denominato John Doe) è il collegamento in avanti, mentre il corrispondente attributo memberOf dell'oggetto member è il collegamento a ritroso (quindi, ad esempio, quando l'attributo memberOf di John Doe viene sottoposto a query, viene calcolato il nome distinto o DN del gruppo ContosoEmployees).

Il collegamento in avanti si comporta in modo molto simile a qualunque altro attributo. I valori possono essere a valore singolo o multiplo (come avviene con l'attributo member,, che può contenere più oggetti come membri di un gruppo) e vengono memorizzati insieme all'oggetto parent nella directory.

I collegamenti a ritroso, invece, sono gestiti dal sistema per garantire integrità referenziale. Quando si esegue una query del valore di un attributo di collegamento a ritroso, i risultati verranno calcolati da tutti i valori del collegamento a ritroso corrispondente. I collegamenti a ritroso sono sempre a più valori.

Ogni classe di oggetti in ADDS è definita da un oggetto classSchema nel contenitore di schema. Per un elenco di attributi critici per la corretta definizione dell'oggetto classSchema, consultare il collegamento go.microsoft.com/fwlink/?LinkId=110445.

È possibile specificare tre tipi di classi: Structural, Abstract e Auxiliary. Tali tipi sono definiti dal valore dell'attributo objectClassCategory. (Una quarta categoria, conosciuta come 88, contiene delle classi definite prima degli standard X. 500 1993. Questo tipo di classe è specificato dal valore 0 nell'attributo objectClassCategory e non dovrebbe più essere definito).

Acquisizione e utilizzo di identificativi

Le identità di ogni oggetto classSchema e attributeSchema nella directory vengono definite utilizzando un identificativo di oggetto obbligatorio (OID), definito rispetto a governsID per oggetti classSchema e rispetto ad attributeID per oggetti attributeSchema. Questi sono dei valori numerici univoci forniti da alcune autorità emittenti per identificare gli oggetti. La numerazione è regolata dalla definizione del protocollo LDAP (RFC 2251). Alcuni degli OID nello schema di Active Directory vengono emessi dalla International Organization for Standardization (ISO) e altri da Microsoft. Un OID deve essere univoco per un oggetto all'interno della directory.

L'OID è una stringa di numeri, ad esempio 1.2.840.113556.1.y.z, come descritto nella Figura 2. Quindi, ad esempio, un OID per un oggetto utente classSchema è 1.2.840.113556.1.5.9.

Figure 2 Identificativo per l'oggetto utente

Quando un'organizzazione intende estendere lo schema, verifica l'univocità dell'OID acquisendo il relativo numero root di OID, da cui vengono poi ottenuti ID univoci per le nuove classi di oggetto e gli attributi creati dall'organizzazione. La root di OID può essere ottenuta direttamente da una National Registration Authority (NRA) ISO, che negli Stati Uniti è American National Standards Institute (ANSI).

È possibile consultare la procedura e la pianificazione dei costi per ottenere un OID root sul sito ansi.org. Per altre aree, contattare la corrispondente organizzazione membro di ISO; ISO offre un elenco all'indirizzo iso.org/iso/about/iso_members.htm.

In passato, le organizzazioni richiedevano un OID a Microsoft inviando un messaggio e-mail a schemreg@microsoft.com. Tuttavia, attualmente il risultato è una risposta automatica in cui si invita il richiedente a scaricare ed eseguire VBScript dal sito go.microsoft.com/fwlink/?LinkId=110453.

Per gli OID emessi da Microsoft, il numero viene assegnato nello spazio di numeri OID di Microsoft: 1.2.840.113556.1.8000.x, dove x è un numero univoco assegnato all'organizzazione. L'organizzazione può dividere ulteriormente tali OID per specificare gli oggetti, utilizzando ad esempio 1.2.840.113556.1.8000.x.1.y per nuovi oggetti classSchema e 1.2.840.113556.1.8000.x.2.z per oggetti attributeSchema (dove x rappresenta il numero univoco dell'organizzazione e y e z, rispettivamente, sono i numeri assegnati a specifici oggetti classSchema ed attributeSchema). È inoltre consigliato utilizzare un prefisso specifico dell'organizzazione nei nomi di tali oggetti per distinguerli.

Definizione di attributi collegati

È importante che il valore attributeSyntax di un collegamento in avanti sia 2.5.5.1, 2.5.5.7 o 2.5.5.14. Questi valori corrispondono alle sintassi che contiene un nome distinto, ad esempio alla sintassi DS-DN dell'oggetto.

Il valore attributeSyntax di un collegamento a ritroso deve essere 2.5.5.1, ovvero la sintassi DS-DN dell'oggetto. Per convenzione, gli attributi di collegamento a ritroso vengono aggiunti al valore mayContain della classe astratta principale. In questo modo, l'attributo di collegamento a ritroso può essere letto dagli oggetti di qualunque classe poiché gli attributi di collegamento a ritroso non vengono in realtà memorizzati con l'oggetto, ma vengono calcolati in base ai valori di collegamento in avanti.

Windows Server 2003 ha introdotto una funzione che le organizzazioni possono utilizzare per collegare due oggetti in uno schema: la generazione automatica di linkID. Con tale funzione, il sistema genera automaticamente un linkID per un nuovo attributo collegato quando l'attributo linkID dell'attributo è impostato su 1.2.840.113556.1.2.50. Un collegamento a ritroso corrispondente viene creato impostando il linkID sull'attributeId o sull'ldapDisplayName del collegamento in avanti. La cache dello schema deve essere ricaricata dopo la creazione del collegamento in avanti e prima di creare il collegamento a ritroso. Altrimenti, l'attributeId del collegamento in avanti o l'ldapDisplayName non verranno trovati al momento della creazione del collegamento a ritroso. La cache dello schema viene ricaricata su richiesta, pochi minuti dopo l'esecuzione di una modifica dello schema o quando il controller di dominio viene riavviato.

Se Active Directory si trova al livello Windows 2000, è necessario richiedere i linkID a Microsoft inviando un messaggio e-mail all'indirizzo schemreg@microsoft.com. All'interno della risposta automatica, verrà visualizzato un messaggio simile al seguente: "I messaggi e-mail inviati a schemreg@microsoft.com verranno elaborati soltanto se sono correlati a registrazioni linkID per ambienti legacy". Per questo, fornire le informazioni seguenti nel messaggio e-mail: nome azienda, nome contatto, indirizzo e-mail, numero di telefono, prefisso registrato (se applicabile), OID registrato (se applicabile).

Estensione dello schema

Supponiamo di voler estendere lo schema di Active Directory. Questa analisi potrebbe essere condotta scartando l'uso di una directory alternativa implementata tramite ADLDS (o ADAM in Windows Server 2003) dopo avere verificato che non avrebbe soddisfatto i requisiti. Come mossa successiva, si identificano i nuovi oggetti attributeSchema da aggiungere allo schema e, in tal modo, si definiscono tutti i valori richiesti (tra cui cn, ldapDisplayName e altri) che specificano tali oggetti. Nella definizione dei valori di attributo per l'oggetto, si ottiene inoltre l'OID da Microsoft o da un'altra fonte. Le suddette operazioni vengono considerate essenzialmente come requisiti aziendali e specifiche tecniche. Inoltre, si implementa un ambiente di laboratorio che emuli Active Directory e che sia pronto per la verifica.

In realtà, molte organizzazioni formano una commissione per approvare o rifiutare tali modifiche e per impostare il relativo processo di implementazione. La necessità di tali verifiche e bilanci è fondamentale poiché Active Directory viene utilizzata come fonte di informazioni autorevole in molte organizzazioni e l'importanza di restare aggiornati e operativi dopo le modifiche non viene mai sottolineata abbastanza.

Non appena l'organizzazione decide di procedere, è necessario definire i piani di implementazione e di test per questo progetto. È possibile estendere lo schema aggiungendo i nuovi oggetti tramite lo snap-in dello schema di Active Directory all'interno di Microsoft Management Console (MMC) o utilizzando metodi programmatici o semi-programmatici per estendere lo schema (ad esempio, utilizzando script LDIFDE per importare file in formato .ldif; CSVDE per importare file in formato .csv o Active Directory Service Interfaces (ADSI).

Indipendentemente dal metodo utilizzato, questa funzione deve essere eseguita su un server connesso o che disponga del ruolo Flexible Single Master Operations (FSMO) di Master Schema nella foresta di Active Directory. Inoltre, l'account utilizzato per l'aggiornamento dello schema necessita di adeguati privilegi di gestione per eseguire l'aggiornamento, quindi occorre renderlo un membro del gruppo Amministratori di schemi. Infine, è necessario abilitare degli aggiornamenti di schema per la foresta (disabilitati per impostazione predefinita).

A meno che la modifica non sia estremamente semplice, dovrebbe essere eseguita in modo automatico per favorire la standardizzazione tra le fasi di implementazione test e produzione e per ridurre i tipi di errori probabili dovuti all'esecuzione manuale della procedura. Supponiamo di voler implementare la nostra modifica utilizzando LDIFDE. Per applicare gli aggiornamenti durante l'estensione dello schema, è necessario aggiungere i nuovi attributi e classi, aggiungere i nuovi attributi alle classi e quindi attivare un ricaricamento della cache. Esaminiamo un paio di scenari.

Aggiunta di attributi

Si supponga che un'organizzazione denominata Contoso desideri aggiungere nella propria Active Directory un attributo che identifichi il numero di scarpa di ogni dipendente. La foresta di Active Directory ha due domini: contoso.com ed employees.contoso.com. Il requisito è che tutti gli oggetti creati utilizzando la definizione della classe utente devono contenere anche questo nuovo attributo.

È importante tenere a mente che la modifica dello schema interesserà entrambi i domini poiché si trovano nella stessa foresta. Supponiamo di avere ricevuto l'OID 1.2.840.113556.8000.9999 da Microsoft e di avere diviso ulteriormente tale OID in 1.2.840.113556.8000.9999.1 per oggetti classSchema ed in 1.2.840.113556.8000.9999.2 per oggetti attributeSchema per Contoso. A questo punto, si definiranno tutti i valori di attributo per questo nuovo oggetto, come illustrato nella Figura 3.

Figure 3 Definizione dell'attributo contosoEmpShoe

Inoltre, sebbene l'attributo contosoEmpShoe debba essere disponibile per tutti gli oggetti creati come oggetti della classe utente, non è consigliabile modificare la definizione predefinita di tale classe. È preferibile definire una classe ausiliaria denominata contosoUser con il valore mayContain specificato come contosoEmpShoe, come illustrato nella Figura 4. In seguito, aggiungere gli attributi definiti per la classe ausiliaria contosoUser alla classe utente.

Figure 4 Definizione della classe contosoUser

Dopo avere eseguito l'analisi e definito i valori, è possibile creare il file .ldif, simile al codice riportato nella Figura 5. È possibile copiare il contenuto della Figura 5 nel Blocco note e salvare il file come contosoUser.ldif (una copia è disponibile anche nel download del codice riportato in technetmagazine com).

Figure 5 file .ldif per l'estensione dello schema

#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

Dopo avere generato il file .ldif, è possibile verificare l'implementazione in un ambiente di laboratorio, verificare la replica end-to-end del proprio dominio e foresta e attivare l'aggiornamento dello schema al suo interno. A questo punto, è necessario accedere con un account che disponga dei privilegi di amministratore dello schema. È possibile disattivare la replica in uscita sul master schema (dove la modifica verrà eseguita) e quindi eseguire il comando seguente per importare il file .ldif:

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

Una volta apportata la modifica, attivare la replica in uscita sul master schema e verificare che la replica sia avvenuta per tutti i controller di dominio.

E ora potete tirare un sospiro di sollievo...avete finito! È stato definito un nuovo attributo nello schema che verrà associato agli oggetti creati tramite la classe utente (ovvero, gli account utente).

Per verificare la modifica, aprire Utenti e computer di Active Directory, connettersi al dominio employees.contoso.com, ricercare l'unità organizzativa (OU) Utenti e creare un nuovo account utente denominato ContosoTestUser. Aprire poi la console adsiedit.msc e connettersi alla partizione di dominio dc=employees,dc=contoso,dc=com, espandere l'OU Utenti, fare clic con il pulsante destro del mouse su ContosoTestUser e aprire la pagina Proprietà. Ricercare l'attributo contosoEmpShoe. È possibile modificare tale attributo per inserire un valore e utilizzare l'utilità Ldp.exe per verificare e modificare gli attributi.

Diamo ora un'occhiata ad un esempio che definisce e collega due attributi e immaginiamo uno scenario in cui Contoso considera di elevata importanza il numero di scarpa dei dipendenti e desidera registrare le prestazioni annuali delle persone che si occupano di acquisire tali numeri di scarpa nell'azienda. Sebbene tale scenario possa apparire buffo, supponiamo anche che Contoso intenda tenere traccia non solo delle persone responsabili della misurazione del numero di scarpa dei dipendenti ma anche dei dipendenti di cui viene misurato il numero di scarpa, registrandone anche il numero, il tutto tramite query su un unico attributo. Si potrebbe pensare che sia meglio memorizzare tali dati nelle tabelle del database, ma l'idea in questo caso serve semplicemente a spiegare l'attività dei collegamenti in avanti e a ritroso.

Ovviamente, la prima analisi da eseguire è quella descritta nell'esempio da me riportato all'inizio di questo articolo. Nell'esempio attuale, tuttavia, ci dedicheremo a generare i file .ldif linkids1.ldif e linkids2, come illustrato nella Figura 6. Per importare tali file, immettere il seguente comando:

Figure 6 File .ldif dei collegamenti in avanti e a ritroso

 
#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

Non appena viene creato, l'oggetto utente presenterà come attributi anche ContosoShoeSizeTaker e ContosoShoeSizesTakenByMe. Durante la creazione dell'oggetto utente per, ad esempio, John, l'attributo ContosoShoeSizeTaker viene compilato con il DN della persona che ha misurato il numero di scarpa, ad esempio Frank. A questo punto, quando si accede alle proprietà dell'oggetto utente Frank e si esegue una query dell'attributo ContosoShoeSizesTakenByMe, il risultato conterrà il DN di John DN e gli altri DN misurati da Frank. Per completare il nostro scenario, la gestione potrebbe fornire a Frank delle provvigioni in base al numero di DN presenti nell'attributo ContosoShoeSizesTakenByMe del suo account utente.

Controlli e bilanci del sistema

Un aggiornamento essenziale come la modifica di uno schema non può essere eseguito senza controlli rispetto ai requisiti dell'architettura. Active Directory esegue tali controlli di sicurezza e uniformità per verificare che le modifiche non causino incongruenze o altri problemi ogni qualvolta viene eseguita un'aggiunta o una modifica allo schema di Active Directory.

In primo luogo, il valore di governsID per ogni classe deve essere univoco all'interno dello schema. Quando si definisce un oggetto schemaClass, tutti gli attributi definiti negli elenchi systemMayContain, mayContain, systemMustContain e mustContain devono esistere già. Allo stesso tempo, devono esistere già anche tutte le classi definite negli elenchi subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors e possSuperiors.

Inoltre, la objectClassCategory di tutte le classi negli elenchi systemAuxiliaryClass e auxiliaryClass deve essere la classe 88 o la classe Auxiliary. In modo analogo, la objectClassCategory di tutte le classi negli elenchi systemPossSuperiors e possSuperiors deve essere la classe 88 o la classe Structural.

Durante la definizione di varie classi, le classi Abstract possono ereditare soltanto da altre classi Abstract, le classi Auxiliary non possono ereditare dalle classi Structural e le classi Structural non possono ereditare dalle classi Auxiliary. Inoltre, l'attributo specificato nell'attributo rDNAttID deve presentare la stringa Unicode come sintassi ed essere a valore singolo.

Queste sono alcune delle regole correlate agli oggetti classSchema. Quali sono quelle relative agli oggetti attributeSchema? Come avviene con il valore governsID per le classi, il valore di attributeID deve essere univoco, così come deve esserlo il valore di mAPIID, se presente. E se sono presenti rangeLower e rangeUpper, rangeLower deve essere inferiore a rangeUpper. I valori di attributeSyntax e oMSyntax devono corrispondere. Se l'attributo ha come sintassi un oggetto (oMSyntax=127), deve presentare la oMObjectClass corretta. Il valore linkID, se presente, deve essere univoco. In più, un collegamento a ritroso deve disporre di un corrispondente collegamento in avanti.

Come comportarsi in caso di errore?

Una volta esteso lo schema con i nuovi oggetti (classi e attributi), tali oggetti non possono essere eliminati. Tuttavia, è possibile disattivare una classe o un attributo impostando l'attributo su TRUE sull'oggetto schema. Non è possibile disattivare oggetti di schema che fanno parte dello schema predefinito fornito con Active Directory (oggetti della Categoria 1). È possibile disattivare soltanto gli oggetti aggiunti allo schema predefinito, ovvero soltanto gli oggetti di Categoria 2 ed esclusivamente dopo che Active Directory ha verificato che la classe non è utilizzata nell'elenco subClassOf, auxiliaryClass o possSuperiors di alcuna classe attiva esistente.

Con qualunque tentativo di disattivare un attributo, Active Directory controlla che l'attributo non sia utilizzato nell'elenco mustContain o mayContain di alcuna classe attiva esistente. Gli oggetti disattivati possono essere riattivati impostando l'attributo isDefunct su FALSE. Se Active Directory si trova a livello di Windows Server 2003, è possibile riutilizzare i valori ldapDisplayName, schemaIdGuid, OID e mapiID dell'oggetto disattivato.

Conclusioni

L'aggiunta o la modifica di definizioni di attributi o classi nello schema implica l'aggiunta o la modifica del corrispondente oggetto classSchema o attributeSchema. Questo processo è simile all'aggiunta o alla modifica di qualunque oggetto in Active Directory, con l'eccezione che i controlli aggiuntivi vengono eseguiti per garantire che le modifiche non causino incongruenze o problemi successivi nello schema.

Sebbene la modifica dello schema di Active Directory sia semplice, è importante capire la formazione dello schema e il relativo funzionamento per implementare tali modifiche. Qualunque modifica allo schema di Active Directory di produzione richiede una notevole pianificazione e deve essere eseguita con estrema attenzione. È essenziale definire i requisiti aziendali e le specifiche tecniche per i nuovi oggetti ed eseguire una gran quantità di test di laboratorio. Poiché le modifiche possono avere effetti profondi, è consigliabile estendere lo schema di Active Directory soltanto quando è assolutamente necessario.

Vikas Malhotra lavora per i servizi di consulenza Microsoft a New York. Durante i suoi 12 anni nel mondo degli affari, ha lavorato con diverse organizzazioni IT in aziende di medie e grandi dimensioni concentrandosi sulle esigenze dell'architettura della loro infrastruttura, ovvero directory, messaggistica, protezione e rete di dati. Ha un diploma di laurea in Ingegneria Elettronica e delle Telecomunicazioni e una laurea specialistica in Gestione delle telecomunicazioni tecniche. È possibile contattarlo all'indirizzo vikasmal@microsoft.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.