Estensione dello schema di Active Directory. Schema master - Schema master di Active Directory

È difficile sottovalutare l'importanza dello "schema di Active Directory" per le reti costruite sulla base di un ambiente di dominio Active Directory. Questa è la base della tecnologia "AD" ed è molto importante comprendere correttamente i principi del suo funzionamento. La maggior parte degli amministratori di sistema non presta sufficiente attenzione allo schema a causa del fatto che raramente è necessario gestirlo. In questo articolo ti dirò cos'è una versione dello schema, perché è necessario conoscerla e, soprattutto, come visualizzare la versione corrente. Prima di tutto, qualche parola sullo schema stesso, ogni oggetto creato in Active Directory, sia esso un utente o un computer, ha determinati parametri chiamati attributi. L'esempio più semplice è l'attributo "Cognome" dell'oggetto utente. Lo schema definisce quali oggetti possiamo creare in Active Directory e quali attributi avranno.

Active Directory consente l'utilizzo all'interno di un'organizzazione di più controller di dominio basati su diverse versioni di Windows. Vale a dire, basato su Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Poiché queste versioni sono state rilasciate in anni diversi e ogni nuova versione ha più funzionalità della precedente, ogni sistema operativo ha la propria comprensione di lo schema. Pertanto, quando si aggiunge un nuovo controller basato su Windows Server 2008 a un'organizzazione in cui i controller esistenti sono basati su Windows Server 2003, è necessario eseguire " Adprep". In questo modo, hai aggiornato l'organigramma al livello con cui funziona Windows Server 2008.

Il processo di aggiornamento dello schema è stato eseguito prima dell'installazione del primo controller di Windows Server 2008 e la procedura effettiva per l'installazione di un nuovo controller stesso potrebbe non essere stata eseguita. Se stai appena iniziando a lavorare con un'organizzazione Active Directory e non sai quali attività sono state svolte prima della tua adesione, dovrai sapere a quale livello funziona lo Schema dell'organizzazione attuale per comprendere la completezza della struttura.

Possibili versioni dello schema:

13 - Windows 2000 Server
30 - Windows Server 2003 RTM, Windows 2003 con Service Pack 1, Windows 2003 con Service Pack 2
31 - Windows Server 2003 R2
44 - Windows Server 2008 RTM

Anche se tutti i controller dell'organizzazione eseguono Windows Server 2003 R2 e la versione dello schema mostra "44", non sorprenderti, ciò indica che lo schema è già stato aggiornato al livello RTM di Windows Server 2008, ma il controller stesso per qualche motivo non è stato installato.

Esistono diversi modi per visualizzare la versione dello schema. Il più semplice è il metodo che utilizza l'utilità DSQuery. Per fare ciò, dalla riga di comando, immettere il comando con i seguenti parametri:

“dsquery * cn=schema,cn=configurazione,dc=nomedominio,dc=local -scope base -attr objectVersion”

Naturalmente, nel dc= nome del dominio, dc= Locale" devi sostituire il tuo nome di dominio. (Esempio: dc= microsoft, dc= com )

Il risultato dell'immissione del comando è di ricevere l'attributo " ObjectVersion”, che sarà il numero di versione dello schema:

Riso. uno Ottenere la versione dello schema tramite l'utilità DSQuery.

Il secondo metodo è più lungo e prevede l'utilizzo di " ADSIModifica. msc» . Per visualizzare la versione dello schema, sarà necessario connettersi alla partizione dello schema di Active Directory.

"CN=Schema,CN=Configurazione,DC=dominio,DC=locale"

E trova il valore dell'attributo " ObjectVersion".

Fig.2 Ottenere la versione dello schema tramite lo snap-in ADSIModifica. msc».

Conoscendo la versione dello schema, puoi sempre dire con certezza se lo schema deve essere aggiornato e, in caso affermativo, a quale livello.

Va notato che gli aggiornamenti dello schema possono essere eseguiti da un software strettamente integrato con Active Directory. L'esempio più eclatante è Microsoft Exchange Server. E spesso in un'organizzazione che prevede di implementare Exchange Server, è necessario scoprire se lo schema è stato preparato? E se lo fosse, allora quale versione di Exchange Server. Esistono attualmente tre versioni di Exchange che funzionano con Active Directory, ma sono disponibili sei opzioni per modificare lo schema.

Capire se c'è stato un cambiamento
Lo schema di Exchange Active Directory non viene applicato dal server tramite l'attributo " gamma Superiore, che accetta quanto segue valori:

4397 - Exchange Server 2000 RTM
4406 - Exchange Server 2000 con Service Pack 3
6870 - Exchange Server 2003 RTM
6936 - Exchange Server 2003 con Service Pack 3
10628 - Exchange Server 2007
11116 - Exchange 2007 con Service Pack 1

Come puoi vedere, gli aggiornamenti dello schema si verificano anche quando si installa SP3 per Exchange Server 2000/2003 e SP1 per Exchange 2007.

Visualizza il valore dell'attributo " gamma Superiore" È possibile utilizzare l'utilità DSQuery:

"dsquery * CN=ms-Exch-Schema-Version-Pt, cn=schema, cn=configuration, dc=domainname, dc=local -scope base -attr rangeUpper"

Riso. 3 Ottenere attributo " gamma Superiore" tramite l'utilità DSQuery.

Se, dopo aver inserito questo comando, viene restituita una risposta che indica l'assenza dell'attributo " gamma Superiore" si può concludere che lo schema non è stato modificato.

Il processo di aggiornamento dello schema è un passaggio molto importante per ogni organizzazione di Active Directory, quindi è necessario evitare azioni non necessarie e non necessarie. Comprendere l'essenza degli attributi " ObjectVersion" e« gamma Superiore" offre un vantaggio a uno specialista quando lavora con Active Directory in un'organizzazione sconosciuta ed è anche uno strumento ausiliario per risolvere i problemi.

Dal rilascio di Active Directory con Windows 2000, Microsoft ha fornito agli utenti una definizione di schema di base per l'implementazione di Active Directory.

Il rilascio di Active Directory® ha anche segnato un cambiamento nel numero di applicazioni scritte e implementate su Windows®. In precedenza, applicazioni come Microsoft® Exchange 5.5 venivano create con una propria struttura di directory. Dall'avvento di Active Directory, molte applicazioni (Microsoft e non Microsoft) hanno sfruttato la struttura sottostante fornita invece di creare il proprio schema da zero.

Inizialmente, l'architettura di base fornita da Active Directory è stata utilizzata e quindi estesa secondo necessità. In Microsoft Exchange 2000, ad esempio, Active Directory è stato utilizzato per implementare i sistemi di messaggistica, definendo così il futuro dell'architettura di messaggistica Microsoft.

Oggi, molte applicazioni create per funzionare in un ambiente Active Directory si basano sul suo schema di base e molte applicazioni definiscono anche le proprie modifiche allo schema secondo necessità. Ciò, ovviamente, richiede un circuito espandibile, di cui parleremo in questo articolo. Inoltre, poiché molte applicazioni dipendono dalle definizioni sottostanti in Active Directory, la stabilità continua dello schema sottostante è fondamentale. Poiché molte applicazioni devono funzionare insieme nella stessa Active Directory, le modifiche a un'applicazione non devono influire su altre applicazioni.

Che cos'è uno schema?

Per molti, lo schema di Active Directory è una sorta di scatola nera e l'idea di modificare lo schema da soli può intimidire. Ovviamente, estendere lo schema di Active Directory non è qualcosa che devi fare ogni giorno, ma per alcune applicazioni o aziende, è esattamente ciò di cui hai bisogno. Pertanto, è molto importante comprendere l'essenza dello schema e la sua composizione, poiché Active Directory è una risorsa importante per molte organizzazioni, il cui fallimento, a causa di un aggiornamento errato, può avere gravi conseguenze.

Come strategia, molte organizzazioni utilizzano Active Directory Lightweight Directory Services (ADLDS) in Windows Server® 2008 (o Active Directory Application Mode (ADAM) in Windows Server 2003) come alternativa per testare o implementare direttamente definizioni di schemi personalizzati invece di estendere l'Active Directory degli schemi.

Uno schema è una struttura di base che fornisce un formato per un servizio di directory. Lo schema di Active Directory definisce gli attributi e le classi di oggetti utilizzati in Active Directory Domain Services (ADDS). Lo schema principale contiene definizioni per molte classi note (come user, computer e unità organizzativa) e attributi (come telephoneNumber e objectSID). Gli oggetti nella definizione dello schema principale sono chiamati oggetti di categoria 1 e gli oggetti aggiunti sono chiamati oggetti di categoria 2.

Lo schema di Active Directory risiede in un contenitore definito da cn=Schema, cn=Configuration,dc=X, dove X è lo spazio dei nomi della foresta di Active Directory. Tieni presente che una foresta di Active Directory contiene solo uno schema; le modifiche alla definizione dello schema in una foresta influiscono su tutti i domini in quella foresta. Sul Riso. uno mostra il numero di classi e attributi aggiunti allo schema di Active Directory in diverse versioni di Windows Server.

Numero di classi e attributi

L'aggiornamento dello schema per diverse versioni di Windows Server viene eseguito utilizzando l'utilità Adprep. Quando si esegue l'aggiornamento a Windows Server 2003 R2, la versione dello schema viene aggiornata a 31 e quando si esegue l'aggiornamento a Windows Server 2008, viene aggiornata a 44.

Il numero di versione può essere ottenuto controllando il valore dell'attributo objectVersion in cn=Schema,cn=Configuration,dc=X in Active Directory utilizzando uno strumento come ADSIEdit. Si noti che alcune applicazioni, come Exchange Server, System Management Server (SMS) e altre applicazioni che dipendono da Active Directory, possono modificare lo schema per soddisfare i requisiti dell'applicazione.

Componenti di base

Active Directory è costituito da due tipi di oggetti: classSchema (brevemente - classe) e attributeSchema (brevemente - attributo). In genere, l'estensione dello schema di Active Directory viene presa in considerazione quando un'organizzazione deve archiviare i dati in determinati attributi che non sono disponibili nello schema esistente. Un attributo in uno schema Directory viene creato specificando un oggetto attributeSchema nel contenitore dello schema e quindi definendo le proprietà richieste del nuovo oggetto.

Per un elenco delle proprietà dell'oggetto attributeSchema e informazioni su di esse, vedere go.microsoft.com/fwlink/?LinkId=110445 . Come puoi vedere, è possibile definire un gran numero di proprietà per gli oggetti attributeSchema, alcune delle quali sono obbligatorie.

Oltre agli attributi regolari, lo schema contiene anche attributi speciali chiamati linkati e implementati in coppia specificando i link avanti e indietro. Ad esempio, considera l'appartenenza a un gruppo in Active Directory. L'attributo di appartenenza di qualsiasi gruppo (ad esempio, il gruppo ContosoEmployees con il membro John Doe) è un riferimento diretto e l'attributo memberOf corrispondente dell'oggetto membro è un riferimento a ritroso (in modo che quando si esegue una query sull'attributo memberOf di un membro di John Doe , viene calcolato il nome distinto (DN) del gruppo ContosoEmployees).

Il collegamento diretto funziona come qualsiasi altro attributo. I valori possono essere singoli o multivalore (così come l'attributo di appartenenza, che può contenere più oggetti come membri di un gruppo) e sono memorizzati nella directory insieme all'oggetto padre.

I backlink, d'altra parte, sono mantenuti dal sistema per garantire l'integrità dei dati. Quando si esegue una query sul valore dell'attributo backlink, il risultato viene calcolato in base a tutti i valori del collegamento diretto corrispondenti. I backlink sono sempre multivalore.

Tutte le classi di oggetti in ADDS sono definite dall'oggetto classSchema nel contenitore dello schema. Per un elenco degli attributi più importanti per definire correttamente un oggetto classSchema, vedere go.microsoft.com/fwlink/?LinkId=110445 .

Esistono tre tipi di classi che possono essere definite: strutturali, astratte e di supporto. Il tipo di classe è determinato dal valore dell'attributo objectClassCategory. (La quarta categoria, nota come 88, include classi definite prima degli standard X.500 del 1993. Questo tipo di classe è indicato dal valore 0 nell'attributo objectClassCategory. Questo tipo non deve più essere definito.)

Ottenere e utilizzare gli identificatori

Le identità di tutti gli oggetti classSchema e attributeSchema in una directory sono determinate da identificatori di oggetto obbligatori (OID), governasID per gli oggetti classSchema e attributeID per gli oggetti attributeSchema. Questi sono valori numerici univoci forniti da alcuni centri per identificare gli oggetti. La numerazione è conforme alla definizione del protocollo LDAP (RFC 2251). Alcuni identificatori di oggetto nello schema di Active Directory vengono emessi dall'Organizzazione internazionale per la standardizzazione (ISO) e da Microsoft. L'ID oggetto nella directory deve essere univoco.

L'ID oggetto è una stringa di numeri, come 1.2.840.113556.1.y.z, come mostrato in Riso. 2. Quindi l'ID oggetto utente classSchema è 1.2.840.113556.1.5.9.

ID oggetto utente

Quando un'organizzazione desidera estendere lo schema, garantisce l'unicità dell'identificatore di entità ottenendo il proprio numero OID radice, che viene utilizzato per creare identificatori univoci per i nuovi attributi dell'organizzazione e le classi di entità. La radice dell'identificatore dell'oggetto può essere ottenuta direttamente dall'autorità nazionale di registrazione ISO (negli Stati Uniti, l'American National Standards Institute (ANSI)).

La procedura ei costi di servizio per ottenere l'identificatore radice dell'oggetto sono disponibili su ansi.org. In altre regioni, contattare l'organizzazione membro ISO appropriata elencata su iso.org/iso/about/iso_members.htm .

In precedenza, le organizzazioni ricevevano un ID oggetto da Microsoft inviando un messaggio di posta elettronica a [email protetta]. Tuttavia, questo ora si traduce in una risposta automatica che ti chiede di scaricare ed eseguire VBScript da go.microsoft.com/fwlink/?LinkId=110453 .

Agli identificatori di oggetto emessi da Microsoft vengono assegnati numeri nello spazio numerico dell'identificatore di oggetto Microsoft: 1.2.840.113556.1.8000.x, dove x è un numero univoco assegnato all'organizzazione. Un'organizzazione può separare questi identificatori per identificare le entità. Ad esempio, puoi usare 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 è un numero di organizzazione univoco e yez sono numeri assegnati rispettivamente agli oggetti classSchema e attributeSchema definiti). Si consiglia inoltre di utilizzare un prefisso dell'organizzazione univoco per distinguere tra questi nomi di oggetti.

Definizione di attributi correlati

Il valore della sintassi dell'attributo backlink deve essere 2.5.5.1, che è la sintassi dell'oggetto (DS-DN). In genere, gli attributi di backlink vengono aggiunti al valore mayContain della classe con la maggiore astrazione. Ciò consente di leggere l'attributo backlink da oggetti di qualsiasi classe, poiché tali attributi non sono memorizzati nell'oggetto, ma sono calcolati in base ai valori del collegamento diretto.

Windows Server 2003 ha introdotto una funzionalità che le organizzazioni possono utilizzare per collegare due oggetti in uno schema: la generazione automatica di linkID. Questa funzione genera automaticamente un linkID per un nuovo attributo collegato se il linkID dell'attributo è impostato su 1.2.840.113556.1.2.50. Il collegamento a ritroso corrispondente viene creato impostando il linkID su attributeId o ldapDisplayName del collegamento in avanti. La cache dello schema deve essere ricaricata dopo aver creato un collegamento diretto e prima di creare un collegamento indietro. In caso contrario, durante la creazione del collegamento a ritroso non verrà trovato alcun attributo attributeId o ldapDisplayName. La cache dello schema viene ricaricata su richiesta alcuni minuti dopo una modifica dello schema o al riavvio di un controller di dominio.

Se Active Directory è in esecuzione a livello di Windows 2000, è necessario richiedere i linkID a Microsoft inviando un'e-mail a [email protetta]. La risposta automatica conterrà la seguente riga: "E-mail inviate a [email protetta] verranno elaborati solo se relativi a registrazioni linkID per ambienti legacy." (E-mail inviate a [email protetta], verranno elaborati solo se fanno riferimento alla registrazione di linkID per ambienti legacy.). A tal fine, nel messaggio di posta elettronica devono essere incluse le seguenti informazioni: ragione sociale, nome del referente, indirizzo e-mail, numero di telefono, prefisso registrato (se necessario), ID oggetto registrato (se necessario).

Puoi iniziare a espandere lo schema

Supponiamo che tu decida di estendere lo schema di Active Directory. La soluzione potrebbe consistere nell'interruzione dell'utilizzo della directory alternativa implementata con ADLDS (o ADAM in Windows Server 2003) dopo aver verificato che non soddisferà i requisiti. Il passaggio successivo consiste nel definire i nuovi oggetti attributeSchema da aggiungere allo schema; questo definisce eventuali valori necessari (come cn, ldapDisplayName, ecc.) che indicano questi nuovi oggetti. Quando si definiscono i valori di attributo per un oggetto, l'ID oggetto viene ottenuto anche da Microsoft o da un'altra fonte. Le attività di cui sopra sono documentate come requisiti aziendali e specifiche tecniche. Inoltre, viene implementato un ambiente di laboratorio sperimentale che simula il lavoro di Active Directory ed è pronto per il test.

Molte organizzazioni creano comitati ad hoc per approvare o rifiutare tali modifiche e stabilire un processo per implementarle. Questo sistema di controlli e contrappesi è fondamentale perché Active Directory viene utilizzato come fonte di informazioni affidabile in molte organizzazioni e l'importanza di mantenerlo attivo e funzionante dopo le modifiche non può essere sottovalutato.

Una volta che un'organizzazione decide di procedere con un progetto, è necessario definire i piani per il test e l'attuazione del progetto. È possibile estendere lo schema aggiungendo nuovi oggetti utilizzando lo snap-in Active Directory Schema di Microsoft Management Console (MMC) o utilizzando metodi programmatici o semi-software (ad esempio, utilizzando LDIFDE per importare file LDIF; utilizzando CSVDE per importare file CSV; oppure utilizzando gli script per le interfacce ADSI).

Indipendentemente dal metodo scelto, questa funzione deve essere eseguita su un server che dispone o è connesso al ruolo di master dello schema FSMO (Flexible Single Master Operations) nella foresta di Active Directory. Inoltre, l'account utilizzato per aggiornare lo schema necessita di diritti amministrativi sufficienti per eseguire l'aggiornamento, quindi deve essere incluso nel gruppo degli amministratori dello schema. Infine, gli aggiornamenti dello schema devono essere abilitati per la foresta (disabilitato per impostazione predefinita).

A meno che la modifica non sia semplice, dovrebbe essere eseguita automaticamente per garantire la standardizzazione tra le fasi di test e implementazione e per prevenire errori che potrebbero verificarsi durante l'esecuzione di azioni manuali. Supponiamo che tu decida di implementare una modifica utilizzando lo strumento LDIFDE. Per installare gli aggiornamenti durante l'estensione dello schema, è necessario aggiungere nuovi attributi e classi, aggiungere nuovi attributi alle classi e quindi attivare un ricaricamento della cache. Di seguito sono riportati alcuni esempi.

Aggiunta di attributi

Per i nostri scopi, si supponga che un'organizzazione denominata Contoso debba aggiungere un attributo ad Active Directory che specifichi la misura delle scarpe per tutti i dipendenti. Esistono due domini in una foresta di Active Directory: contoso.com e dipendenti.contoso.com. È necessario che tutti gli oggetti creati con la definizione della classe utente contengano anche questo nuovo attributo.

È importante ricordare che la modifica dello schema interessa entrambi i domini perché si trovano nella stessa foresta. Si supponga di ricevere un ID oggetto di 1.2.840.113556.8000.9999 da Microsoft, che si divide in 1.2.840.113556.8000.9999.1 per l'oggetto classSchema e 1.2.840.113556.8000.9999.2 per Contoso attributeSchema. Ora dobbiamo definire tutti i valori degli attributi per questo nuovo oggetto, come mostrato in Riso. 3.

Definizione dell'attributo contosoEmpShoe

Inoltre, sebbene l'attributo contosoEmpShoe debba essere disponibile su tutti gli oggetti creati come oggetti della classe utente, non è consigliabile modificare la definizione della classe utente predefinita. Definire invece una classe helper contosoUser con l'attributo mayContain impostato su contosoEmpShoe, come illustrato in Riso. 4. Successivamente, è necessario aggiungere gli attributi definiti per la classe helper contosoUser alla classe utente.

definizione della classe contosoUser

Ora che l'analisi è stata eseguita e i valori sono stati determinati, dobbiamo creare un file LDIF che assomigli al codice in Riso. 5. Puoi copiare il codice su Riso. 5 blocco note e salvare il file come contosoUser.ldif (incluso nei download su technetmagazine.com).

File LDIF di estensione dello schema

#Definizione attributo per 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 - # Classi dn: CN=contosoUser,CN=Schema,CN=Configuration,DC =X changetype: ntdsschemaadd objectClass: top objectClass: classSchema cn: contosoUser governa ID: 1.2.840.113556.1.8000.9999.1.1 mayContain: contosoEmpShoe rDNAttID: cn adminDisplayName: contosoUser adminDescription: contosoUser objectClass sistema: contosoUser governa nome: contosoUser objectClass sistema: contosoUserALSE name : contosoUser objectClass sistema: contosoUserALSE name : changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - dn: CN=User,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemamodify a dd: ausiliareClasse ausiliareClass: contosoUser - dn: changetype: modifica add: schemaUpdateNow schemaUpdateNow: 1

Dopo aver creato il file LDIF, è necessario testare attentamente l'implementazione in un ambiente di laboratorio pilota, convalidare la replica end-to-end del dominio e della foresta e consentire gli aggiornamenti dello schema nella foresta. Ora devi accedere con un account che disponga dei diritti di amministratore dello schema. Potrebbe essere necessario disabilitare la replica in uscita sul master schema (dove verranno apportate le modifiche) ed eseguire il comando seguente per importare il file LDIF:

Ldifde -i -f \contosoUser.ldif -b -k -j. –c "CN=schema,CN=Configurazione,DC=X" #schemaNamingContext

Dopo aver apportato le modifiche, consentire la replica in uscita sul master schema e verificare che sia stata eseguita la replica per tutti i controller di dominio.

Fai un respiro profondo: hai finito! È stato definito un nuovo attributo nello schema che verrà associato agli oggetti creati con la classe utente (ovvero gli account utente).

Per verificare le modifiche, aprire Utenti e computer di Active Directory, connettersi al dominio dipendenti.contoso.com, selezionare l'unità organizzativa degli utenti e creare un nuovo account utente denominato ContosoTestUser. Ora apri la console adsiedit.msc e connettiti alla partizione di dominio dc=employees,dc=contoso,dc=com, espandi l'UO Utenti, fai clic con il pulsante destro del mouse su ContosoTestUser, quindi apri la pagina Proprietà. Cerca l'attributo contosoEmpShoe. È possibile modificare questo attributo per inserire un valore. È inoltre possibile utilizzare l'utilità Ldp.exe per verificare e modificare gli attributi.

Ora, diamo un'occhiata a un esempio di definizione e relazione di due attributi e immaginiamo che Contoso sia molto interessato alle dimensioni delle scarpe dei dipendenti e debba tenere traccia delle prestazioni annuali delle persone che misurano le dimensioni delle scarpe dei dipendenti dell'azienda. Anche se questo può sembrare ridicolo, supponiamo anche che Contoso voglia tenere traccia non solo dei soggetti responsabili della misurazione delle scarpe dei dipendenti, ma anche dei dipendenti di cui è stata misurata la taglia e il loro numero, il tutto interrogando un unico attributo. (Anche se potresti pensare che le tabelle del database siano più adatte per archiviare questo tipo di dati, in questo caso stiamo semplicemente perseguendo lo scopo di spiegare come funzionano i collegamenti avanti e indietro.)

Ovviamente, prima eseguirai un'analisi simile a quella che ho menzionato nell'esempio precedente. Tuttavia, per ora, andiamo avanti e creiamo file LDIF (linkids1.ldif e linkids2.ldif) come mostrato in Riso. 6. Quindi eseguire il comando seguente per importare i file LDIF:

File LDIF di collegamento avanti e indietro

#linkids1.ldif #Definizione attributo per collegamento diretto Attributo 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 #ReloadUpdate: schemaNow addtypelinkifddn:.type schema definizione per l'attributo collegamento a ritroso dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attributeSchema cn: ContosoShoeShoeSizesTakenByMe attributeID: 1.2.840.113556.1.8000.9999.2 .3 LinkID: 1.13556. .8000.9999.2.2 attributeSintassi: 2.5.5.1 isSingleValued: FALSE adminDisplayName: ContosoShoeSizesTakenByMe adminDescript ion: ContosoShoeSizesTakenByMe oMSyntax: 64 searchFlags: 1 lDAPDisplayName: ContosoShoeSizesTakenByMe systemOnly: FALSE dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - #Add ContosoShoeSizeTaker e ContosoShoeSizesTakenByMe Attributo come contosoUserContain in #contoso: MayserCN=Schema=SDC=SchemaConfigurazione =X changetype: ntdsschemamodify add: mayContain mayContain: ContosoShoeSizeTaker mayContain: ContosoShoeSizesTakenByMe dn: changetype: modifica aggiungi: schemaUpdateNow schemaUpdateNow: 1 - #Add Backward Link Attribute as MayContain in Top dn: CN=Top,CN=Schema,CN =Configuration,DC =X tipo di modifica: ntdsschemamodify aggiungi: mayContain mayContain: ContosoShoeSizesTakenByMe dn: changetype: modifica aggiungi: schemaUpdateNow schemaUpdateNow: 1 ldifde –i –f \linkedids.ldif –b -k –j. –c "CN=schema,CN=Configurazione,DC=X" #schemaNamingContext

Ora, quando viene creato un oggetto utente, avrà anche gli attributi ContosoShoeSizeTaker e ContosoShoeSizesTakenByMe. Quando viene creato un oggetto utente, ad esempio per John, l'attributo ContosoShoeSizeTaker viene popolato con il nome distinto della persona che ha misurato la taglia della scarpa, Frank. Se ora accediamo alle proprietà dell'oggetto utente di Frank e interroghiamo l'attributo ContosoShoeSizesTakenByMe, il risultato conterrà il nome distinto di Frank e le altre persone la cui taglia di scarpa Frank ha misurato. Per completare il nostro caso, la direzione può premiare Frank in base al numero di nomi distinti esistenti nell'attributo ContosoShoeSizesTakenByMe del suo account utente.

Sistema di controlli e contrappesi

Non è possibile eseguire un aggiornamento critico, come una modifica dello schema, senza verificare la conformità dell'architettura. Questi controlli di sicurezza e coerenza vengono utilizzati da Active Directory per verificare che le modifiche non causino incoerenze o altri problemi quando lo schema di Active Directory viene esteso o modificato.

Innanzitutto, il valore governasID per ogni classe deve essere univoco nello schema. Quando si definisce un oggetto schemaClass, tutti gli attributi definiti negli elenchi systemMayContain, mayContain, systemMustContain e mustContain devono esistere già. Allo stesso tempo, tutte le classi definite negli elenchi subClassOf, systemAuxiliaryClass, ausiliariClass, systemPossSuperiors e possSuperiors devono esistere già.

Inoltre, l'attributo objectClassCategory di tutte le classi negli elenchi systemAuxiliaryClass e ausiliariClass deve essere di classe 88 o una classe ausiliaria. Allo stesso modo, l'attributo objectClassCategory di tutte le classi negli elenchi systemPossSuperiors e possSuperiors deve essere definito come classe 88 o una classe strutturale.

Quando si definiscono classi diverse, le classi astratte possono essere derivate solo da altre classi astratte, le classi ausiliarie non possono essere derivate da classi strutturali e le classi strutturali non possono essere derivate da classi ausiliarie. Inoltre, l'attributo specificato in rDNAttID deve essere non ambiguo e deve essere nella sintassi della stringa unicode.

Queste sono alcune delle regole relative agli oggetti classSchema. Che dire delle regole per gli oggetti attributeSchema? Come il valore governasID per le classi, il valore attributeID deve essere univoco. Inoltre, anche il valore mAPIID (se presente) deve essere univoco. Inoltre, se sono presenti rangeLower e rangeUpper, rangeLower deve essere minore di rangeUpper. I valori di attributeSyntax e oMSyntax devono corrispondere. Se la sintassi dell'attributo è oggetto (oMSyntax =127), deve avere un oMObjectClass valido. L'eventuale linkID deve essere univoco. Inoltre, un collegamento a ritroso deve avere un collegamento in avanti corrispondente.

E se si verifica un errore?

Una volta che lo schema è stato esteso e vi sono stati aggiunti nuovi oggetti (classi e attributi), non possono essere rimossi. Tuttavia, le classi e gli attributi possono essere disabilitati impostando l'attributo isDefunct dell'oggetto schema su TRUE. Non è possibile disattivare gli oggetti dello schema che fanno parte dello schema predefinito fornito con Active Directory (oggetti della categoria 1). Puoi disattivare solo gli oggetti aggiunti allo schema predefinito, ad es. oggetti di categoria 2 e solo dopo aver verificato che la classe non sia utilizzata negli elenchi subClassOf, ausiliariClass o possSuperiors di qualsiasi classe di recitazione esistente.

Quando si tenta di disabilitare qualsiasi attributo, Active Directory verifica se è utilizzato negli elenchi mustContain e mayContain di qualsiasi classe effettiva esistente. Gli oggetti disabilitati possono essere riabilitati impostando l'attributo isDefunct su FALSE. Se Active Directory è in esecuzione a livello di Windows Server 2003, è possibile riutilizzare i valori ldapDisplayName, schemaIdGuid, OID e mapiID degli oggetti disabilitati.

Conclusione.

Quando si aggiungono o si modificano le definizioni di classi o attributi nello schema, si aggiunge o si modifica anche l'oggetto classSchema o attributeSchema corrispondente. Questo processo è simile all'aggiunta o alla modifica di qualsiasi oggetto in Active Directory, ad eccezione del fatto che vengono effettuati controlli aggiuntivi per garantire che le modifiche non causino incoerenze e non possano causare problemi nello schema in futuro.

Sebbene la modifica dello schema di Active Directory non sia un processo difficile, è importante comprendere la struttura dello schema e il processo per l'implementazione di queste modifiche. Tutte le modifiche allo schema di Active Directory devono essere pianificate ed eseguite con grande attenzione. È importante definire i requisiti aziendali e le specifiche tecniche per le nuove strutture ed eseguire test approfonditi. Poiché le modifiche possono avere un effetto significativo, si consiglia di estendere lo schema di Active Directory solo quando assolutamente necessario.

Un servizio di directory viene utilizzato per identificare utenti e risorse sulla rete. Rispetto alle versioni precedenti di Windows, Microsoft Windows 2003 migliora notevolmente le funzionalità di Active Directory. Active Directory è un unico strumento di gestione della rete che semplifica l'aggiunta, la rimozione e lo spostamento di utenti e risorse.

Introduzione ad Active Directory

Gli strumenti di Active Directory ti consentono di progettare la struttura della directory proprio nel modo in cui la tua organizzazione ne ha bisogno. In questa lezione imparerai l'uso degli oggetti di Active Directory e lo scopo dei suoi componenti.

Dopo aver studiato il materiale di questa lezione, sarai in grado di:

spiegare lo scopo dell'oggetto Active Directory e gli attributi dello schema;

definire e descrivere le funzioni dei componenti di Active Directory.

Oggetti AD

Come tutti i servizi che rendono le informazioni accessibili e utili, Active Directory memorizza le informazioni sulle risorse di rete. Queste risorse, come dati utente, descrizioni di stampanti, server, database, gruppi, computer e criteri di sicurezza, sono denominate oggetti.

Un oggetto è un unico insieme denominato di attributi che rappresenta una risorsa di rete. Gli attributi di un oggetto sono le sue caratteristiche nella directory. Ad esempio, gli attributi dell'account utente potrebbero includere il nome e il cognome, il reparto e l'indirizzo e-mail dell'utente (Figura 2-1)

In Active Directory, gli oggetti possono essere organizzati in classi, ovvero in gruppi logici. Un esempio di classe è una raccolta di oggetti che rappresentano account utente, gruppi, computer, domini o unità organizzative (UO).

Nota Gli oggetti che possono contenere altri oggetti sono chiamati contenitori. Ad esempio, un dominio è un oggetto contenitore che può contenere utenti, computer e altri oggetti.

Quali oggetti possono essere archiviati in Active Directory è determinato dal relativo schema.

schemaAttivoDirectory

Lo schema di Active Directory è un elenco di definizioni che definiscono i tipi di oggetti che possono essere archiviati in Active Directory e i tipi di informazioni su di essi. Queste definizioni stesse vengono anche archiviate come oggetti, quindi vengono gestite da Active Directory utilizzando le stesse operazioni utilizzate per altri oggetti in Active Directory.

Esistono due tipi di definizioni in uno schema: attributi e classi. Sono anche chiamati oggetti schema o metadati.

Gli attributi sono definiti separatamente dalle classi. Ogni attributo è definito una sola volta e può essere utilizzato in più classi. Ad esempio, l'attributo Description è utilizzato in molte classi, ma è definito solo una volta nello schema, il che ne garantisce l'integrità.

Le classi, dette anche classi di oggetti, descrivono quali oggetti di Active Directory è possibile creare. Ogni classe è una raccolta di attributi. Quando un oggetto viene creato, gli attributi memorizzano le informazioni che lo descrivono. Ad esempio, gli attributi della classe Utente includono Indirizzo di rete, Directory iniziale e così via.Ogni oggetto in Active Directory è un'istanza di una classe di oggetti.

Windows 2000 Server viene fornito con un insieme di classi e attributi di base. Definendo nuove classi e nuovi attributi per le classi esistenti, gli sviluppatori esperti e gli amministratori di rete possono estendere dinamicamente lo schema. Ad esempio, se è necessario archiviare informazioni sugli utenti che non sono definite nello schema, è possibile estendere lo schema per la classe Users. Tuttavia, tale estensione del regime è un'operazione abbastanza complessa con possibili gravi conseguenze. Poiché lo schema non può essere eliminato, ma solo disattivato e si replica automaticamente, è necessario prepararlo e pianificarne l'espansione.

Lo schema include una descrizione formale del contenuto e della struttura del database di Active Directory. In particolare, contiene tutte le proprietà degli oggetti e delle loro classi. Per ciascuna classe di oggetti vengono definite tutte le possibili proprietà, parametri aggiuntivi e quale classe di oggetti è e può essere un predecessore della classe corrente.

Installando Active Directory, viene creato uno schema predefinito sul primo controller di dominio che descrive gli oggetti più comunemente utilizzati e le proprietà degli oggetti. Inoltre, il diagramma fornisce una descrizione degli oggetti interni e delle proprietà di Active Directory.

Lo schema è estensibile, quindi l'amministratore di sistema può creare nuovi tipi di oggetti e le relative proprietà, aggiungere nuove proprietà per quegli oggetti già esistenti. Lo schema viene distribuito e archiviato con Active Directory nel catalogo globale. Viene aggiornato automaticamente, in modo che un'applicazione appositamente creata possa aggiungere in modo indipendente nuove proprietà e classi.
Estendere lo schema standard non è facile. La modifica non corretta dello schema può interrompere sia il server che l'intero servizio di directory. Per risolvere questo problema, è necessaria l'esperienza e le conoscenze necessarie. Quindi, prima di tutto, devi conoscere le regole di denominazione.

Regole di denominazione

Ogni oggetto di Active Directory ha un nome specifico. Vari schemi di denominazione vengono utilizzati per identificare gli oggetti in Active Directory, come segue:

Nomi composti (DN);
- nomi distinti relativi (RDN);
- identificatori univoci globali (GUID);
-Nomi utente primari (UPN).

Ogni oggetto di Active Directory ha nome composto. Il nome è un identificatore di oggetto e contiene dati sufficienti per individuare l'oggetto nella directory. Il nome distinto include il nome del dominio che contiene l'oggetto e il percorso completo ad esso. Ad esempio, il nome utente composito Andrew Kushnir nel dominio server.com potrebbe essere simile al seguente:
DC=COM/DC=SERVER/CN=Utenti/CK=Andrew Kushnir

Se il nome completo di un oggetto è sconosciuto o è stato modificato, è possibile trovare l'oggetto in base alle sue proprietà, una delle quali è il nome distinto relativo (parte del nome distinto). Nell'esempio precedente, l'alias relativo per l'oggetto Andrew Kushnir è CK=Andrew Kushnir e l'oggetto padre è CN=Usere.

Oltre al nome distinto, ogni oggetto di Active Directory ha un identificatore univoco globale (GUID), che è un numero a 128 bit. L'identificatore non cambia anche dopo che l'oggetto è stato spostato o rinominato. L'identificatore univoco globale è univoco in tutti i domini, anche quando un oggetto viene spostato da un dominio a un altro dominio.
È più facile ricordare il nome utente principale (UPN). Il nome principale è costituito dal nome abbreviato dell'utente più il nome DNS del dominio in cui risiede l'oggetto. Il formato per il nome utente principale è il seguente:

Nome utente, carattere suffisso dominio DNS

Ad esempio, il nome utente principale è Andrew Kushnir nel dominio del server. potrebbe assomigliare alla soia [email protetta] Il nome principale di un utente è indipendente dal suo nome distinto, quindi l'oggetto utente può essere spostato o rinominato senza dover modificare l'accesso al dominio dell'utente.