Vediamo come fare

Prerequisiti

DCDIAG (Domain Controller Diagnostics Tool), NETDOM (Windows Domain Manager),PORTQRY (Port Query), NTDSUTIL e ADSIEdit (ADSI Edit), NETDIAG ( Network Connectivity Tester)

possibile scaricarli al seguente link Windows Server 2003 Service Pack 1 32-bit Support Tools

Diagnostica funzionalità rete

Un dominio Windows 2003 è sempre identificato da due nomi:

• Nome DNS. E' il nome completo DNS o FQDN (Fully Qualified Domain Name) ed è limitato a 255 caratteri, 63 per ogni etichetta (label) e rappresenta il nome nativo del dominio.
• Nome NetBIOS. E' utilizzato per compatibilità con i  sistemi pre-Windows 2000 ed è limitato a 15 caratteri. Coincide per default con i primi 15 caratteri della prima label del FQDN DNS del dominio.

• Test del servizio DNS: NETDIAG /test:dns
• Test dell'elenco dei controller di dominio: NETDIAG /test:dclist
• Test del rilevamento dei controller di dominio: NETDIAG /test:dsgetdc
• Test di LDAP NETDIAG /test:ldap
• Test dell'appartenenza al dominio: NETDIAG /test:member

Per verificare  la registrazione di NetBIOS, del servizio DNS e dei servizi utilizzare il seguente comando:

NETDIAG /debug

L' utility NETDIAG registra l'output sul file NetDiag.log che viene creato nella directory di esecuzione consentendo di esaminare il risultato del test diagnostico in modo più agevole, personalmente consiglio di operare in una directory test.

Condivisioni Netlogon e Sysvol

Nei Domain Controller di Windows NT gli script di logon venivano memorizzati nella condivisione amministrativa NETLOGON (che corrisponde alla directory %SystemRoot%\System32\Repl\Import\Scripts), mentre nei DC Windows 2000/2003 risiedono in SYSVOL (che corrisponde alla directory %SystemRoot%\Sysvol). Dcpromo modifica il valore di registro che definisce il path della condivisione NETLOGON facendola puntare a %SystemRoot%\Sysvol\Sysvol\NomeDominio\Scripts per consentire l'operatività ai client Windows 9x e Windows NT.

Ogni modifica alla directory %systemroot%\SYSVOL su un qualunque DC viene replicata agli altri DC utilizzando il servizio Replica file (FRS).

La struttura della condivisione SYSVOL è la seguente:

• Sysvol\Sysvol\NomeDominio\Policies che contiene i Group Policy Template
• Sysvol\Sysvol\NomeDominio\Scripts che contiene gli scripts

Verifica delle condivisioni Netlogon e Sysvol

Per verificare se il Domain Controller condivide Netlogon e Sysvol e che i privilegi di logon necessari alla replica siano impostati è possibile utilizzare l'utility DCDIAG:

 

DCDIAG /test:frssysvol

 

DCDIAG /test:netlogons

Global Catalog

In ogni domino è necessario avere un Global Catalog (GC)  server e per impostazione predefinita al primo DC del dominio è assegnato automaticamente tale ruolo. Il GC contiene una replica completa di tutti gli oggetti di directory nel dominio host e una parziale di tutti gli oggetti di directory in tutti i domini della struttura. Il compito principale del GC consiste nel fornire autenticazione per gli accessi. Inoltre, poiché contiene informazioni su tutti gli oggetti in tutti i domini dell'insieme di strutture, consente la ricerca di oggetti a livello generale indipendentemente dal dominio di appartenenza di ciascun utente e/o computer fornendo informazioni sulle ubicazioni in cui è possibile trovare l'oggetto evitando query inutili nei domini. E' possibile configurare un DC come GC e aggiungere GC ad un dominio per accelerare i tempi di risposta per le richieste di accesso e di ricerca.

Verificare se il DC è stato eletto come Global Catalog

Per verificare se un DC è stato eletto come Global Catalog e se, una volta inserito il flag Global Catalog, sia i grado di accettare richieste sulla porta TCP 3268 è possibile utilizzare l'utility PORTQRY e controllare il valore di isGlobalCatalogReady sia TRUE.

portqry -n <IP o Nome DC> -e 3268 -p tcp

Replica di Active Directory e Ruoli FSMO

Il database di Active Directory non ha una struttura monolitica ma è organizzato in partizioni che identificano strutture gerarchiche  di oggetti, ciascuna delle quali costituisce un'unità di replicazione indipendente. Le partizioni possono essere generali e applicativo.

Le partizioni generali possono essere di tre specie:

• Schema Partition. Contiene la definizioni degli oggetti (attributi e classi) utilizzabili in Active Directory (user, group, computer, organizational unit, etc...) e delle regole di utilizzo. Esiste una sola Schema Partition per ogni ciascuna foresta.
• Configuration Partition. Contiene informazioni generali sulla struttura e la composizione di una foresta (site, subnet, partizioni che compongono la foresta, dc, etc...). Esiste una sola Configuration Partition per ogni ciascuna foresta.
• Domain Partition. Contiene informazioni sugli oggetti creati in ogni dominio (user, group, computer, organizational unit, etc...). Esiste una sola Domain Partition per ogni dominio appartenente alla stessa foresta.

Le informazioni della Schema Partition e della Configuration Partition sono comuni a tutti i domini della foresta e quindi verranno replicate a tutti i DC della foresta, mentre le informazioni della Domain Partition sono private del dominio e quindi verranno replicate solo ai DC dello stesso dominio.

Le partizioni applicative possono essere di due specie:

• ADP builtin. Sono quelle dedicate al DNS (DomainDnsZones e ForestDnsZones) create automaticamente all'atto della creazione del dominio, nel caso si scelga di installare e configurare il servizioDNS dal wizard Dcpromo.
• ADP custom o personalizzate. Possono essere create manualmente per ospitare informazioni riguardanti applicazioni integrate in Active Directory (AD-aware)

Il processo di replica di Active Directory mantiene allineate le Directory Partition dei DC tramite una tipologia multimaster incrementale che consente di effettuare modifiche su qualsiasi DC e far sì che questo fornisca agli altri DC soltanto le differenze rispetto all'ultima sincronizzazione avvenuta. Per minimizzare i conflitti dovuti a modifiche dello stesso oggetto su DC diversi Active Directory implementa la replica a livello di singolo attributo, I DC, infatti, a seguito di una modifica aggiornano lo stamp associato all'attributo che è compostato da un Version Number (incrementato ad ogni modifica), un Timestamp (data e ora della modifica) e da un Server GUID (contenente il GUID del DC su cui è avvenuta la modifica). Nella comparazione degli stamp si considera il Version Number maggiore, nel caso ugualianza si considera il Timestamp maggiore e  se anche il Timestamp è uguale si valuta il Server GUID.

Allo scopo di evitare conflitti di replica non risolvibilit tramite la comparazione degli stamp, Active Directory introduce l'amministrazione centralizzata di alcune operazioni, in altre parole alcune attività possono essere eseguite esclusivamente a seguito dell'autorizzazione data dal DC in possesso del ruolo associato alla specifica tipologia di operazione. Tali ruoli sono definiti flexible o Floating Single Master Operations (FSMO) in quanto è possibile spostare un ruolo assegnandolo ad un altro DC.

I ruoli FSMO sono cinque:

• Schema Master. Lo Schema Master è l'unico DC della foresta che possiede una copia i scrittura della Schema Partition (ciò significa che la modifica dello schema può essere seguita da un qualunque DC, ma prevede la connessione diretta con lo Schema Master).
• Domain Naming Master. Il Domain Naming Master è unico nella foresta e viene contattato quando è necessario creare un dominio per verificare che non sia già stato definito e ottenere un identificatore GUID univoco. Il Domain Naming Master è responsabile anche dell'autorizzazione alla cancellazione di un dominio, della validazione durante le operazioni di modifica dei nomi di dominio tramite il tool RENDOM.EXE e della creazione e cancellazione di una Application Directory Partition.
• Relative Identifier Master. Il Relative Identifier Master è unico nel dominio ed è responsabile della distribuzione dei pool contenenti le sequenze univoche dei Relative ID (RID) ai DC del dominio. I RID sono utilizzati dai DC durante la creazione degli oggetti Security Principal (User, Group o Computer) per attribuirgli identificativi Security ID (SID) univoci.
  Il Relative Identifier Master si occupa anche di autorizzare lo spostamento di un oggetto in un altro dominio, tramite ad esempio l'Active Directory Migration Tool, per evitare che lo stesso oggetto possa essere spostato in due domini diversi.
  I DC del dominio ricevono un pool di 500 RID dal Relative Identifier Master e quando la quantità disponibile raggiunge circa le 100 unità il DC contatterà il Relative Identifier Master per ottenere un nuovo pool.
  Un SID è composto da 4 elementi S-1-5-Y1-Y2-Y3-Y4:

·         S-1 che indica la revisione del SID (al momento è in uso la 1)

·         5 che definisce l'autorità di emissione del SID (5 indica Windows NT, 2000 o 2003 Server, per i well know SID si utiliza 0 o 1)

·         Y1-Y2-Y3 è la porzione del domain SID (uguale per tutti i Security Principal del dominio)

·         Y4 rappresenta il relative ID del dominio.

• PDC emulator. il PDC emulator è unico nel domino e viene utilizzato come fonte di replica (master-slave) degli update della Domain Partition verso i BDC NT nel caso in cui il livello funzionale del dominio sia Windows server 2003 Interim o Windows 2000 Mixed Mode. il PDC emulator viene inoltre contattato da client precedenti Windows 2000 su cui non è installato l'Active Directory client durante la fase di cambio password degli account e per offrire piena compatibilità verso essi.
  Il PDC emulator assolve anche la funzionalità di Domain Master Browser e indipendetemente dal livelo funzionale del dominio ha i seguenti compiti:

·         Diminuire il tempo di convergenza nei cambi password.

·         Essere la fonte di sincronizzazione del Windows Time Service (in una foresta i DC di un dominio usano il PDC emulator del proprio dominio come time source e a loro volta i PDC emulator dei vari domini della foresta usano come time source il PDC emulator del Forest Root Domain il quale può essere sincronizzato su un time server esterno tramite il comando net time \\servername /setsntp:TimeServer).

·         Essere utilizzato di default dallo snap-in di creazione o modifica di un Group Policy Object.

·         Autorizzare il raise del livello funzionale del dominio.

• Infrastructure Master. l'Infrastructure Master è l'unico DC nel domino che ha il compito di mantenere aggiornata la relazione GUID-SID-DN degli utenti/gruppi definiti nei domini esterni a quello di appertenenze dell'Infrastructure Master, ma utilizzati anche nei gruppi del suo dominio (phantom record). In caso di modifica del Distinguished Name (DN) (per es. spostamento nel domino) o del SID (per es. spostamento in altri domini) di tali utenti/gruppi la visualizzazione dei membri dei gruppi che li contengono non deve produrre incoerenze. Per ottenere tale risultati l'Infrastructure Master verifica e aggiorna  periodicamente  eventuali differenze tra il proprio database locale di phantom record e le informazioni nei Global Catalog server.

Verifica funzionalità Active Directory

Tramite Dcdiag è possibile verificare la registrazione DNS di un controller di dominio, controllare che i descrittori di protezione (SID) nelle intestazioni del contesto dei nomi dispongano delle autorizzazioni appropriate per la replica, analizzare lo stato dei controller di dominio in un insieme di strutture o in un'organizzazione e così via.

DCDIAG /v /f:<NomeFileLog>

Verifica funzionalità replica con altri Domain Controller

Per verificare verificare la funzionalità replica con altri Domain Controller è possibile utilizzare l'utility DCDIAG:

DCDIAG /test:replications

Verifica detenzione ruoli FSMO

Per verificare quale server detiene i ruoli FSMO è possibile utilizzare l'utility NETDOM:

netdom /query fsmo

Verifica della disponibilità dei ruoli master operazioni

Per verificare la disponibilità dei ruoli master operazioni è possibile utilizzare l'utility DCDIAG, controllandone la localizzazione tramite il test knowsofroleholders e la disponibilità e il corretto funzionamento tramite il test fsmocheck:

DCDIAG /s:<ServerName> /test:KNOWSOFROLEHOLDERS /verbose

 

DCDIAG /s:<ServerName> /test:FSMOCHECK

Servizio DNS

Uno degli aspetti più importanti dell'implementazione di Active Directory è la sua filosofia "IP-centrica", nel senso che questa tecnologia si basa su alcuni standard del TCP/IP e in modo particolare sul servizio DNS che svolge le seguenti funzioni:

• Servizio di risoluzione dei nomi dei computer e/o domini in in indirizzi IP e viceversa.
• Servizio di registrazione dinamica (Dynamic DNS o DDNS) dei nomi dei computer (resource record di tipo address o RR di tipo A), degli indirizzi IP (RR di tipo pointer o RR di tipo PTR) e degli RR di tipo service location o RR di tipo SRV. Gli RR di tipo A e PTR vengono registrati da tutti i computer mentre gli RR SRV sono registrati solo dai DC.
• Definizione degli standard da adottare per la definizione dei nomi dei domini AD. DNS e AD condividono gli stessi namespace, ovvero la stessa gerarchia di domini, pertanto ad ogni dominio AD deve obbligatoriamente corrispondere un dominio DNS
• Servizio per la localizzazione (service location) dei DC Windows 2000/2003 che offrono servizi strategici ai client AD (LDAP Server, Kerberos Server, Global Catalog Server, etc...)

Per un client Windows 2000/XP/2003 membro di un dominio AD Windows 2000/2003 l'assenza o l'incorretta impostazione del server DNS comporta un declassamento del dominio AD da Windows 2000/2003 a semplice dominio Windows NT (eseguendo l'utility gpresult.exe per la determinazione del "Resultant Set Of Policy" il dominio di appartenenza appare infatti come "Domain Type: WindowsNT 4"). Su questi client  configurati in modo errato il dominio AD Windows 2000/2003 verrà visto come un dominio Windows NT con un determinato nome NETBIOS che offre servizi di autenticazione NTLM e tutti i servizi nativi AD (autenticazione Kerberos, GPO, ricerche LDAP e/o ADSI, etc...) non saranno disponibili. Ovviamente queste considerazioni sono valide anchenel caso in cui il client sia configurato correttamente ma il servizio DNS non sia disponibile.

Verifica funzionalità DNS del Domain Controller

Per verificare verificare la funzionalità del DNS del Domain Controller è possibile utilizzare l'utility DCDIAG (il test diagnostico del DNS è stato introdotto con la versione di DCDIAG rilasciata con Windows Server 2003 SP1):

DCDIAG /test:DNS

Struttura fisica di Active Directory

Active Directory è basata su un database di tipo ISAM (Index as Sequential Access Method) gestito da un DBMS ESE (Extensible Storage Engine) noto anche col nome di Jet Blue (vi sono infatti due implementazioni separate delle Jet Api, chiamate Jet Blue e Jet Red e spesso il termina "Jet" viene utilizzato per riferirsi a Jet Red che è il DBMS utilizzato da Microsoft Access).

ESE è un componente introdotto con Windows 2000 che implementa un user-mode storage engine che gestisce i dati mediante un file binario. I dati saranno resi disponibili all'applicazione tramite Api mediante l'utilizzo di una DLL. Questo DBMS viene utilizzato da svariate applicazioni, come ad esempio Exchange e ADAM, in quanto offre buone performance ed un elevata scalabilità.

Il database di Active Directory è contenuto di default nella directory %SystemRoot%\NTDS e il cuore del DIB (Directory Infomation Base) è rappresentato dal file NTDS.DIT che viene creato dal comando dcpromo all'atto della promozione del server a DC utilizzando il modello %SystemRoot%\System32\ntds.dit.
Per la gestione dei log il DBMS ESE utilizza i file edb.log, edb*.log, res1.log e res2.log, mentre per la gestione del checkpoint utilizza il file edb.chk (per default la dimensione dei file di log è di 10 MB mentre quella del file di checkpoint è variabile).

Per conoscere la posizione del database NTDS.DIT e dei file log è possibile utilizzare l'utility NTDSUTIL:

1.     Aprire il prompt dei comandi.

2.     Digitare SET SAFEBOOT_OPTION=DSREPAIR e premere invio.

3.     Digitare ntdsutil e premere invio.

4.     Digitare files e premere invio.

5.     Digitare info e premere invio per visualizzare le informazioni sul file di database e sui file di log.

6.     Digitare quit e premere invio.

7.     Digitare quit e premere invio per chiudere la sessione NTDSUTIL.

 

Quando viene eseguita un'operazione sul DC che avvia una scrittura sul database (creazione/cancellazione di un oggetto, modifica di un attributo di un oggetto o replica di oggetti e attributi da altri DC partner di replica) viene generata una transazione che contiene i dati e i meta-dati (numero di versione USN, il timestamp, il GUID del server su cui è stata generata la modifica). Una transazione è un'unità atomica di operazioni da eseguire su un database, ovvero devono essere portate a termine con successo tutte in caso contrario verrà ripristinata la situazione precedente all'esecuzione della transazione.

Le transazioni vengono immediatamente registrate in modo sequenziale nel file di log corrente (EDB.LOG) e quindi viene eseguita la modifica  nella copia del database in memoria, ciò garantisce che le modifiche vengano eseguite anche nel caso di uno shutdown o di un crash immediatamente successivo.

Il DBMS ESE si occupa di di aggiornare il file NTDS.DIT con le transazioni contenute nei file log e aggiornando il contenuto del file di checkpoint (EDB.CHK) in modo che contenga la posizione sino a cui le operazioni di scrittura nel database sono state eseguite con successo (stato di committed della transazione).

Quando il file di log corrente (EDB.LOG) raggiunge la dimensione massima di default di 10.204 KB viene rinominato come EDBHHHHH.LOG (dove H è una cifra esadecimale) e viene creato un nuovo file EDB.LOG. Per una miglior ottimizzazione dello spazio su disco i file di log vengono gestiti tramite la modalità circular logging, che consiste nel sovrascrivere i log più vecchi in modo circolare cancellano i file non più necessari una volta eseguite le scritture sul database e aggiornato il file di checkpoint.

Per garantire la disponibiltà di spazio anche in situazioni di emergenza oper le normali operazioni di deframmentazione online, vi sono due file di riserva (RES1.LOG e RES2.LOG) della dimensione standard dei file log che vengono utilizzati nel caso in cui il sistema esaurisca lo spazio disponibile sul volume  contenente il database.

I file EDBTMP.LOG e TEMP.EDB sono due file temporanei utilizzati da attività quali deframmentazione online, recovery, situazioni di emegenza derivati da sovraccarico, ecc.

Nel caso di chiusura anomala del sistema il DBMS ESE rileva l'esistenza di una situazione anomala controllando il log degli eventi e se l'ultimo record non corrisponde ad uno shutdown "normale", ESE riapplica il log segnalati nel file di checkpoint (EDB.CHK) notificandolo nell'Event Viewer tramite gli eventi NTDS ISAM 300, 301, 302. Nel caso di assenza del file di checkpoint (EDB.CHK) vengono riaplicate tutte le transazione contenute file di log.

Verifica dell'integrità del database di Active Directory

Per verificare l'integrità del database di Active Directory è possibile utilizzare l'utility NTDSUTIL:

1.     Riavviare il sistema.

2.     Durante la fase di avvio premere F8.

3.     Selezionare l'opzione Modalità ripristino servizi directory (solo controller domini Windows).

4.     Selezionare il sistema operativo da avviare.

5.     Autenticarsi tramite l'account Administrator con la password di "amministratore modalità ripristino servizi" specificata durante l'esecuzione di dcpromo.

6.     Confermare il messaggio che indica che Windows è in esecuzione in modalità provvisoria.

7.     Aprire il prompt dei comandi.

8.     Digitare ntdsutil e premere invio.

9.     Digitare files e premere invio.

10.  Digitare integrity e premere invio per avviare il controllo di integrità

11.  Digitare quit e premere invio.

12.  Digitare sematic database analysis e premere invio.

13.  Digitare go e premere invio per avviare il controllo semantico del database.

14.  Digitare quit e premere invio.

15.  Digitare quit e premere invio per chiudere la sessione NTDSUTIL.

Per trasferire (transfer) i 5 ruoli FSMO da un DC ad un'altro quando entrambi i Server sono operativi e regolarmente funzionanti, effettuare i seguenti passaggi:

 

1.     Su qualsiasi DC, cliccare su Start -> Esegui, digitare ntdsutil e premere INVIO

2.     Al prompt di ntdsutil inserire il comando roles e premere INVIO

3.     Al prompt fsmo maintenance inserire il comando connections e premere INVIO

4.     Al prompt server connections inserire il comando connect to server nomeserver dovenomeserver è il nome del Server sul quale si vogliono trasferire i ruoli FSMO

5.     Inserire il comando quit e premere INVIO per tornare al contesto fsmo maintenance

6.     Inserire il comando transfer domain naming master e premere INVIO (al messaggio di conferma cliccare su Sì)

7.     Inserire il comando transfer infrastructure master e premere INVIO (al messaggio di conferma cliccare su Sì)

8.     Inserire il comando transfer PDC e premere INVIO (al messaggio di conferma cliccare su Sì)

9.     Inserire il comando transfer RID master e premere INVIO (al messaggio di conferma cliccare su Sì)

10.   Inserire il comando transfer schema master e premere INVIO (al messaggio di conferma cliccare su Sì)

11.   Inserire il comando quit seguito da INVIO fino alla chiusura di Ntdsutil.

 

Per trasferire forzosamente (seize) i 5 ruoli FSMO da un DC ad un'altro quando il server che detiene i ruoli FSMO è guasto o non in linea, effettuare i seguenti passaggi:

Su qualsiasi DC, cliccare su Start -> Esegui, digitare ntdsutil e premere INVIO

1.     Al prompt di ntdsutil inserire il comando roles e premere INVIO

2.     Al prompt fsmo maintenance inserire il comando connections e premere INVIO

3.     Al prompt server connections inserire il comando connect to server nomeserver dove nomeserver è il nome del Server sul quale si vogliono trasferire i ruoli FSMO

4.     Inserire il comando quit e premere INVIO per tornare al contesto fsmo maintenance

5.     Inserire il comando seize domain naming master e premere INVIO (al messaggio di conferma cliccare su Sì)

6.     Inserire il comando seize infrastructure master e premere INVIO (al messaggio di conferma cliccare su Sì)

7.     Inserire il comando seize PDC e premere INVIO (al messaggio di conferma cliccare su Sì)

8.     Inserire il comando seize RID master e premere INVIO (al messaggio di conferma cliccare su Sì)

9.     Inserire il comando seize schema master e premere INVIO (al messaggio di conferma cliccare su Sì)

10.  Inserire il comando quit seguito da INVIO fino alla chiusura di Ntdsutil