Windows 2000 e Windows 2003 in Profondit�

1. Fondamenti di Windows 2000 e Windows 2003

In questa sezione verranno illustrate le principali caratteristiche di Windows 2000 e Windows 2003.

1.1 Caratterstiche dei sistemi operativi Windows 2000

Il sistema operativo Windows 2000 è l'evoluzione del vecchio sistema operativo Windows NT 4.0. Tant'è vero che il suo nome originario, cioè quello fornito dagli sviluppatori e non dall'ufficio marketing, era Windows NT 5.0. Il sistema operativo Windows 2000 è stato suddiviso, in base alle sue caratteristiche impostate all'atto dell'acquisto, nelle seguenti varianti:

A parte la variante Windows 2000 Professional, realizzata per gli utenti finali, tutte le altre sono orientate al lato server ed è di quest'ultime che illustreremo le principali caratteristiche:

Per avere informazioni sui file che vengono installati con i Support Tools basta consultare il documento Support Tools.

Licenze di Windows 2000

Windows 2000 mette a disposizione degli utenti due tipi di licenze:

Ogni client che accede ad un server Windows 2000 deve avere un tipo particolare di licenza chiamato Client Access License o più brevemente CAL. Nel caso delle Per Seat Licensing la licenza CAL deve essere in posseso o del client o del server che tenta di collegarsi, mentre nel caso delle Per Server Licensing è il server di rete che assegna o al client o al server che tenta di collegarsi una licenza CAL.

I profili in Windows 2000

A ciascun utente di un server o workstation su cui è installato Windows 2000, viene assegnato un profilo, ovvero la capacità di personalizzare l'ambiente in cui sta operando. L'utente è in grado di cambiare le seguenti impostazioni:

Tutte queste informazioni vengono archiviate all'interno del file NTUser.dat che di solito si trova all'interno della cartella Document and Settings\<AccountUtente>.

Il SAM di Windows 2000

Il SAM, ovvero il Security Accounts Mabager è il database locale di Windows 2000 in cui vengono conservati e gestiti gli account locali. Il SAM è conservato nel registry, ma viene implementato come semplice file all'interno della cartella %windir%\System32\Config. Facendo uso del comando del Resource kit di Windows 2000 Server, NTRights.exe, è possibile modificare le impostazioni locali della sicurezza (Local Security Policy). Queste impostazioni vengono disolito modificate facendo uso del omonimo tool grafico.

System State

Il System State di Windows 2000 è composto dai seguenti componenti:

Strumenti per la gestione di Windows 2000

Di seguito riportiamo alcuni degli strumenti più comuni nella gestione di Windows 2000.

Strumenti per la gestione della memoria

I Support Tools di Windows 2000 mettono a disposizione dell'Amministratore di Sistema i seguenti strumenti per la diagniosi dello stato della memoria:

Strumenti per la gestione dei Device Driver Software

I sistemi operativi della Microsodft, a partire da Windows 2000 in poi, sono in grado di distingure se un Device Driver Software è firmato digitalmente o meno. Per determinare come si deve comportare il sistema operativo difronte ad un Device Driver non firmata digitalmente si devono ad andare selezionare le seguenti opzioni:

Conviene, a volte, controllare se tutto il software che si è deciso d'installare è Firmato Digitalmente. Per portare a termine questa analisi si possono utilizzare due approcci:

  1. Lanciare il comando SigVerif.exe.
  2. Sfruttare i Tools del System Information:
    • Aprire la Computer Management console.
    • Cliccare sopra la sigla System Information
    • Dal menu Tools selezionare prima la voce Windows poi quella Driver Signing.

Entrambi i metodi lanciano la finestra di dialogo File Signature Verification. Cliccando sul pulsante Advanced si possono impostare i valori di logging dell'applicazione. Di default l'applicazione File Signature Verification crea un file di log chiamato SigVerif.txt.

1.2 Installazione di Windows 2000 e Windows 2003

Installazione automatica

I sistemi operativi Windows 2000 e superiori, mettono a disposizione dell'amministratore di sistema tutta una serie di strumenti per automatizzare la loro installazione su di un server. Esiste una versione opportunamente personalizzata di Windows XP, chiamata Windows PE che consente di realizzare installazioni particolarmente sofisticate dei sistemi operativi Windows 2000 e superiori. Per maggiori informazioni sulle capacità di Windows PE si possono consultare i documenti Windows PE User's Guide e Windows Deployment Sysprep and the Windows PE. Un documento che si rivela particolarmente utile ogni qual volta si decide d'installare in modo automatico i sistemi operativi Windows 2000 o superiori è il seguente Windows 2000 Unattended Setup. Per personalizzare il file Winnt.sif in base alla Lingua e alla codifica della Tastiera, si può consultare il documento LocaleID Input Locale and Language.

Di solito, quando si decide d'installare in modo automatico i sistemi operativi Windows 2000 o superiori, si procede nel seguente modo:

In questo modo la procedura di setup del sistema operativo pesca le informazioni necessarie per l'installazione dal file Winnt.sif che si trova all'interno del floppy disk.

Installazione di Driver Plung and Play

Quando s'installa un driver Plugn and Play (PNP) vengono fornite in automatico le seguenti informazioni:

Installazione di Windows 2003

Per avere maggiori informazioni su come viene realizzata un'installazione Unattened di Windows 2003 si può consultare i documenti How Unattended Installation Works e How Setup Works.

Se si sta eseguendo una migrazione a Windows 2003 partendo da Windows 2000 può tornare utile il seguente articolo Common mistake in configuring Windows 2003.

Per avere un'idea delle opzioni di boot che mette a disposizione Windows 2003 si può consultare il documento Boot INI Options Reference.

Le licenze di Windows 2003

Esistono diversi tipi di licenze di Windows 2003. La conoscenza di quale tipo di licenza di Windows 2003 si è in possesso è fondamentale per sapere come aggiornare le proprie copie di Windows 2003 alla versione R2. Le licenze disponibili di Windows 2003 sono:

Per maggiori informazioni su come risalire al tipo di licenza acquistata si può consultare la Knowledge Base KB889713

1.3 Domain Name System

Nel linguaggio dei DNS, il computer che chiede informazioni al server DNS viene chiamato DNS Resolver, mentre il server DNS prende il nome di Name Server.

I componenti su cui poggia una struttura basata su DNS sono:

I prerequisiti per installare un DNS Server sono:

Si osservi che sebbene non sia necessario, conviene configurare il file %SystemRoot%\system32\drivers\etc\Hosts con gli indirizzi IP di tutti i server presenti nella LAN. Questo poichè i client Windows 2000 caricano all'interno della loro DNS Cache, in modo permanente, tutte le informazioni contenute all'interno del file Hosts. Essendo la DNS Cache interrogata prima dei DNS Server, ne segue che le informazioni contenute nel file Hosts possono ridurre il traffico di rete e snellire la connessione ai server presenti all'interno della LAN. Per avere maggiori informazioni sul ruolo che svolgono i DNS Server nel processo di risoluzione dei nomi in una LAN, si può consultare il documento DNS in Name Resolution Designs. Per vedere il contenuto della DNS Cache si può utilizzare il comando ipconfig /displaydns Il valore della TTL che viene riportato esprime per quanti secondi il record corrispondente rimmarrà nella DNS Cache. Eseguendo in sequenza due o più comandi ipconfig /displaydns si può osservare che il valore del campo TTL diminuisce.

Esistono tre tipi di DNS Query che un DNS Resolver può fare ad un Name Server:

In tutte e tre i tipi di DNS Query citate, la risposta del Name Server può essere anche un eventuale messaggio d'errore qualora non sia in grado di dare una risposta adeguata.

Le DNS Query vengono gestite dal servizio DNS Client sia sui DNS Resolver sia sui Name Server. Il DNS Client non si preoccupa invece della registrazione dinamica dei DNS Records (questa operazione viene svolta dal servizio DHCP Client).

I server DNS di Windows 2000 non possono essere inseriti in Network Load Balancing. Conviene poi che un server DNS sia anche Domain Controller. Visto il sistema di replica dei DNS non ha senso inserirli all'interno di un cluster ad alta affidabilità (sebbene ciò sia tecnicamente fattibile).

Per poter amministrare un server DNS bisogna appartenere a gruppi diversi a seconda della tipologia d'installazione del server DNS:

Con Windows 2000 sono possibili i seguenti tipi di zone:

All'interno di un file di zona sono possibili i seguenti tipi di record:

Il servizio Net Logon si preoccupa di registrare i record SRV, ma non di registrare in modo dinamico i DNS records (questa operazione viene svolta dal servizio DHCP Client).

Per ciascuna zona, i server che gesticono il corrispondente file di zona assumono i seguenti nomi:

Per maggiori informazioni sui DNS Server realizzati col sistema operativo Windows 2000 si può consultare il documento Windows 2000 DNS.

Root Zone

La Root Zone è la zona da cui nascono tutte le zone. La Root Zone è rappresentata dal simbolo . e viene di solito omesso nei nomi FQDN, infatti di solito si preferisce scrivere miocomputer.miodominio.net piuttosto che miocomputer.miodominio.net.

Quando s'installa il servizio DNS su una macchina Windows 2000 o superiore, viene anche creato il file %SystemRoot%\System32\DNS\cache.dns contenente l'elenco completo dei DNS autoritativi sulla Root Zone. I server che ospitano una copia della Root Zone prendono il nome di Root Name Server. Per vedere un esempio di file cache.dns cliccare qui.

Bisogna creare una Root Zone ogni qual volta ci si trova in una delle seguenti situazioni:

Cache File

Il file cache.dns deve sempre esistere in qualunqe implementazione di DNS. Il file cache.dns contiene, di solito:

Per i DNS Server che non devono risolvere nomi di server Internet, il file cache.dns dovrebbere contenere solamente i nomi e gli indirizzi IP dei Name Server autoritativi dei vari Root Domain dell'Intranet aziendale.

Negative Caching

Un server DNS che non ospita nessuna zona si dice essere un Caching-Only Name Server. Prende il nome di Negative Caching la possibilità che ha un Caching-Only Name Server di conservare, per un tempo massimo di 15min, nomi FQDN di cui non riesce a risolvere l'indirizzo IP. In questo modo il Caching-Only Name Server, quando torna a ricevere query su quei particolari nomi FQDN, risponde direttamente in modo negativo al DNS Resolver, avanzando d'inoltrare la richiesta ai Name Server di riferimento. Per attivare il Negative Caching bisogna modificare la seguente chiave di registry: HKEY_Local_Machine\System\CurrentControlSet\Services\DNSCache\Parameters\NegativeCacheTime, impostando un valore compreso fra 1 (1sec) e 900 (900sec, cioè 15min). Il valore 0 significa che il Negative Caching non è abilitato.

Subnet Priotization

La Subnet Prioritization è una caratteristica dei DNS Server e dei DNS Client. Sui DNS Client basati su Windows 2000 il Subnet Prioritization è abilitato di default. Questa proprietà consente ad un DNS Client di ordinare gli Indirizzi IP che riceve in risposta delle DNS Query, in base alla loro sottorete di appartenenza, dando priorità agli Indirizzi IP che appartengono alla sua stessa sottorete. In questo modo il DNS Client tende ad usufruire dei servizi erogati dai server che appartengono alla sua stessa sottorete. Per disabilitare questa funzionalità bisogna modificare il Registry del DNS Client, introducendo la chiave PrioritizeRecordData (REG_WORD), con valore 0, all'interno della sottochiave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DnsCache\Parameters

La Subnet Prioritization può essere abilitata anche sui DNS Server selezionando la voce Enable Netmask Ordering che si trova all'interno della sezione Advanced, delle Properties del DNS Server. L'ordine con cui il DNS Server fornisce gli Indirizzi IP in risposta alle DNS Query che riceve dipende da come è stato configurato il DNS Server. Le impostazioni del DNS Server che condizionano l'ordine con cui gli Indirizzi IP vengono forniti ai DNS Client dipende da:

La Subnet Prioritization inibisce il funzionamento del Round Robin solamente se gli indirizzi IP da mettere in Round Robin non appartengono alla stessa sottorete, pertanto, in questi casi, se si desidera utilizzare il Round Robin bisogna disabilitare la Subnet Prioritization.

Per maggiori informazioni sulla Subnet Prioritization si può consultare il documento Windows 2000 DNS.

DNS Forwarding

Di solito il porcesso di risoluzione dei nomi avviene nel seguente modo:

  1. Un DNS Resolver interroga il suo primary Name Server inviandogli un nome FQDN di cui desidera avere l'indirizzo IP.
  2. Se il Name Server riesce a risolvre in autonomia la DNS Query restituisce l'informazione richiesta al DNS Resolver, atrimenti interroga il primo server della lista dei Root Hints. Ha così inizio una Iterative Query.
  3. A seguito della Iterative Query il Name Server o il DNS Resolver, a seconda della configurazione del Name Server, inizia una catena di DNS Query ai vari Name Server che compongono la struttura gerarchica del DNS Domain inserito nel FQDN richiesto dal DNS Resolver nella sua prima DNS Query.

Questo comporta che quando il Name Server non è autoritativo sulla zona a cui il nome FQDN richiesto dal DNS Resolver appartiene, viene generato, a seguito della Iterative Query, un cospiquo traffico di rete. Tipicamente questo traffico di rete viene prodotto quando un DNS Resolver chiede un indirizzo IP di un server pubblico, ovvero di un server presente in Internet. Se la banda con cui il Name Server o il DNS Resolver non è particolarmente veloce, si possono avere dei cali prestazionali abbastanza marcati. Per ovviare a questo, si può demandare ad un particolare Name Server la gestione delle Iterative Query. Questi particolari Name Server prendono il nome di DNS Forwarder. Per svolgere il ruolo di DNS Forwarder si prende di solito un Name Server pubblico. In questo modo il DNS Forwarder preoccupandosi di gestire l'Iterative Query consente di ridurre il consumo della banda, in quanto o il Name Server o il DNS Resolver si vedrà recapitare solamente la risposta della DNS Query originale. Quando in un Name Server si abilita l'utilizzo dei DNS Forwarder la risoluzione delle DNS Query avviene in maniera leggermente differente:

L'operazione di blindare un DNS Server tramite la selezione dell'opzione Do Not Use Recursion prende il nome di Slaving DNS. Quando i DNS Server sono anche Domain Controller e le zone vengono integrate in Active Directory conviene sempre trasformare il server in un Slaving DNS per motivi di sicurezza. Per garantire però la possibilità ai client di navigare in Internet è bene garantire che le seguenti condizioni siano soddisfatte:

Per maggiori informazioni sui DNS Forwarder si può leggere il documento Using Forwarders.

Boot File

Il Boot File è un file di configurazione caratteristico dell'implementazione BIND (Berkley Internet Name Daemon) del servizio DNS. Questo file contiene informazioni sugli host che necessitano di essere risolti al di fuori del dominio autoritativo. La sua implementazione in Windows 2000 ha come scopo quello di migliorare la compatibilità con le implementazioni BIND del servizio DNS. La struttura di un Boot File presenta le seguenti sezioni:

Active Directory Integrated Zones

Accanto alle zone Standard Primary Zone e Standard Secondary Zone, Windows 2000 mette a disposizione una terza possibile zona chiamata Active Directory Integrated Zone. Affinchè un server DNS possa ospitare una Active Directory Integrated Zone si devono verificare le seguenti due situazioni:

Una Active Directory Integrated Zone viene conservata e mantenuta all'interno di Active Directory. I vantaggi di utilizzare una Active Directory Integrated Zone consistono in:

Solamente le Standard Primary Zone possono venire convertite in Active Directory Integrated Zone.

L'opzione Secure Dynamic Update è valida solamente per le Active Directory Integrated Zone e non anche per le altre tipologie di zone. Quando s'imposta la Secure Dynamic Update solamente i client che appartengono al dominio possono registrarsi dinamicamente sul DNS e solamente i client che originariamente avevano registrato il loro record nel DNS possono aggiornarlo.

Le zone DNS Active Directory Integrated Zone si trovano all'interno della Organization Unit OU=MicrosoftDNS,OU=System,DC=<NomeDominio>,DC=<SuffissoPrimario> (ad esempio OU=MicrosoftDNS,OU=System,DC=homeworks,DC=local).

Come salvare le Active Directory Integrated Zone

Il salvagtaggio delle Active Directory Integrated Zone non � semplice come per le Primary Zone o le Secondary Zone. Per svolgere il salvataggio delle Active Directory Integrated Zone si deve utilizzare il comando dnscmd.exe, che si trova all'interno dei Support Tools di Windows 2000/2003/XP. I Support Tools si trovano all'interno del cdrom d'installazione di Windows 2000/2003/XP. Il file d'installazione dei Support Tools cambia a seconda del sistema operativo in cui si opera (nel caso di Windows 2003 R2, i Support Tools si trovano nel primo cdrom d'installazione):

In alternativa, i Support Tools si possono scaricare direttamente dal sito della Microsoft (www.microsoft.com)

Per eseguire il salvataggio di una Active Directory Integrated Zone basta eseguire il comando:

dnscmd <DomainController> /zoneexport <NomeZonaDNS> backup\<NomeZonaDNS>.dns.txt

Ad esempio:

dnscmd /zoneexport homeworks.it backup\homeworks.it.dns.txt

oppure:

dnscmd dc01.homeworks.it /zoneexport homeworks.it backup\homeworks.it.dns.txt

Il file backup\<NomeZonaDNS>.dns.txt viene creato all'interno della cartella %systemroot%\system32\dns del Domain Controller a cui il comando dnscmd.exe ha fatto riferimento. Il comando dnscmd.exe non � in grado di sovrascrivere un file esistente, pertanto, se si desidera inserire il salvataggio di una Active Directory Integrated Zone all'interno di uno script, ci si deve preoccupare di spostare o cancellare di volta in volta il file %systemroot%\system32\dns\backup\<NomeZonaDNS>.dns.txt

Per maggiori informazioni si pu� leggere il documento DNS Backups Without the Baggage dal quale risulta pure possibile scaricare uno script per l'esecuzione del backup o il restore di una zona DNS integrata in Active Directory.

Dynamic Update Protocol

Il Dynamic Update Protocol è conforme a quanto contenuto nelle RFC 3007 e RFC 2136. Solamente i client che hanno Windows 2000 o versioni successive di windows, possono sfruttare il Dynamic Update Protocol. L'aggiornamento dinamico dei record A viene eseguito dal DHCP Client, anche quando l'indirizzo IP è statico. Il Dynamic Update Protocol viene attivato solamente sulle Zone DNS e non sui Domini DNS; pertanto se una zona DNS ha più sottodomini DNS, il dynamic update protocol può venire definito solamente sulla zona che ospita i vari domini DNS, col risultato che tutti i domini DNS della zona accetterenno gli aggiornamenti dinamici dei propri record.

L'aggiornamento dinamico del record A avviene, di solito, nelle seguenti circostanze:

Per motivi di sircurezza, conviene installare i server DHCP su macchine che non svolgono anche il ruolo di Domain Controller, quando i server DNS sono in Active Directory Integrated Zone. Per maggiori informazioni sui problemi che si possono avere quando il servizio DHCP viene svolto da un Domain Controller che è anche Name Server, si può consultare la Knowledge Base KB255134.

Per consentire ad un server DHCP di aggiornare i record A anche di macchine che non sono Windows 2000 o superiori, qualora i server DNS siano in Active Directory Integrated Zone, bisogna inserire il server DHCP all'interno del gruppo DnsUpdateProxy. I membri di questo gruppo possono aggiornare e rinfrescare tutti i record DNS appartenenti ai vari server che sono censiti nel gruppo.

Quando un client Windows 2000 o superiore, configurato per ricevere un indirizzo IP in modo dinamico via DHCP, non riesce a registrare dinamicamente il proprio Record A all'interno dei System Log's del Event Viewer compare un messaggio con le seguenti caratteristiche:

Questo messaggio compare di solito quando il client non ha i permessi per registrare il proprio Record A. Per ovviare a questo bisogna verificare se i permessi di Dynamic Update del server DNS sono su Yes o su Only secure updates poichè in questo caso, solamente i client che appartengono alla foresta a cui appartiene il DNS possono registrare i propri Record A. Al contrario, quando un client riesce a registare il proprio Record A all'interno del Event Viewer (sia del client sia del Server) non compare nessuna segnalazione. Se il client riceve il proprio indirizzo IP in modo dinamico tramite un DHCP Server, la registrazione del PTR Record viene effettuata dal Servizio DHCP Server del DHCP Server.

I DHCP Client da Windows 2000 in poi, specificano, all'interno della richiesta di DHCPREQUEST il proprio FQDN (codice 81 Client FQDN Option), in questo modo risulta più appropriata la gestione della registrazione dei record A e PTR da parte del DHCP Server (per maggiori informazioni si consulti il documento KB191290). Per evitare problemi sulla proprietà dei record A e PTR conviene inserire il server DHCP all'interno del gruppo DnsUpdateProxy. Per essere sicuri che il DHCP Server elimini i record PTR corrispondenti a DHCP lease scadute, bisogna abilitare l'opzione Discard forward (name-to-address) lookups when lease expires all'interno delle opzioni del DHCP Server o dello Scope (per maggiori informazioni si consulti il documento KB306780).

Per avere maggiori informazioni su come impostare i vari parametri di un DHCP Client, si può consultare il documento Windows 2000 DNS. Quando un DNS Client registra il proprio Record A specifica anche il Time To Live (TTL) del record stesso (di default è di 20 minuti). Per cambiare il TTL del Record A bisogna aggiungere la seguente chiave nel registry del DNS Client:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DefaultRegistrationTTL

In questo modo si può modificare il valore di default del TTL che è specificato nel SOA Resource Record del Primary DNS Server a cui il DNS Client tenta di registrarsi.

Per sapere come integrare un DNS Server che supporta DNS Dynamic Update in un ambiente che non supporta il DNS Dynamic Update, si può consultare il documento KB255913 del TechNet.

Scavenge Records

Gli Scavenge Records sono quei record del DNS il cui TimeStamp, sommato all'intervallo di tempo di Refresh e di No-Refresh è inferirore alla data e ora correnti. Ciò si può verificare solamente per quei record del DNS che non vengono aggiornati o rinfrescati da molto tempo. Il termine molto tempo si riferisce all'intervallo di tempo che si ottiene sommando l'intervallo di tempo di Refresh con quello di No-Refresh, l'intervallo di tempo così ottenuto prende il nome di Scavenging Interval. Se viene abilitata la cancellazione degli Scavenge Records, allora periodicamente, il DNS provvede ad eliminare questi record. La presenza degli Scavenge Records può provocare delle incongruenze all'interno del database DNS, specie se questi records si riferiscono a computer che hanno IP dinamico, in quanto si possono presentare situazioni in cui l'indirizzo IP che avevano queste macchine, in seguito alla scadenza della lease del DHCP, viene assegnato ad altre macchine, col risultato che all'interno del DNS ci sono due computer con nomi diversi che portano allo stesso indirizzo IP.

Con i termini No-Refresh Interval e Refresh Interval intendiamo:

Da quanto detto ne segue che lo Scavenging Interval deve essere uguale allo Scope Lease Time, per cui se ad esempio lo Scope Lease Time è di 14gg allora il Refresh Interval dovrà essere di 8gg e quindi il No-Refresh Interval sarà di 6gg (8gg +6gg = 14gg).

Per abilitare lo scavenging dei record scaduti si deve:

Per sapere quando ha avuto luogo una procedura di Scavenging, bisogna consultare l'Event Viewer e controllare la presenza del evento 2501 (SymbolicName: DNS_EVENT_AGING_SCAVENGING_END).

Per maggiori informazioni sugli eventi del DNS di Windows 2000 si possono consultare i seguenti documenti:

Si ricordi che quando s'imposta lo scavengin dei record di una certa zona, si fa sì che i record di quella zona non siano più record standard, ovvero la presenza della data di creazione del record impedisce a questi record di essere condivisi con implementazioni del servizio DNS diverse da quelle Microsoft. Pertanto se una data zona primaria deve essere replicata su un server secondario BIND, non bisogna abilitare lo scavenging dei record scaduti.

Come impostare un client Windows 2000/XP per il dynamic update

Per configurare un client Windows 2000/XP per utilizzare il Dynamic Update del DNS basta procedere come indicato:

Quando si utilizza l'opzione Use this connection's DNS suffix in DNS registration il client registra oltre al record A anche il record PTR.

Record SRV registrati dai Domain Controller

Ogni Domain Controller registra all'interno dei server DNS dei Record SRV che servono ai vari client per identificare i vari servizi che mettono a disposizione i domain controller presenti nella rete. Come sappiamo, infatti, la struttura di active directory risulta alquanto articolata, col risultato che questa struttura, nella sua complessità, dovrà venire riprodotta fedelmente all'interno dei vari server DNS. La struttura di un record SRV è la seguente:

_service_.protocol.name ttl class SRV priority weight port target

Dove ciascun termine ha un significato ben preciso:

Un esempio di record SRV potrebbe essere:

_ldap_tcp.home.lan 600 IN SRV 0 100 389 master.home.lan

I Domain Controller, al loro avvio, inseriscono i seguenti record facendo uso del servizio di Net Logon:

Questi record vengono inseriti in modo dinamico sfruttando il Dynamic Update.

I record SRV standard, ovvero che valgono per tutti i domain controller, anche quelli che non sono windows 2000, che vengono inseriti di solito sono:

Si osservi che il nome SiteName è il Relative Distinguished Name del sito a cui il domain controller appartiene, esattamente così com'è inserito in Active Directory.

I record SRV che abbiamo elencato sono tutti i record SRV standard DNS che di solito si trovano in un file di zona. I domain controller Windows 2000 (e superiori) inseriscono, oltre ai record sopra citati, anche degli altri record SRV proprietari:

Per maggiori informazioni sui record SRV, si può consultare l'articolo RFC 2782.

Trasferimenti di Zona

Esistono due metodi possibili per trasferire le informazioni fra una zona primaria e una zona secondaria, a seconda della quantità di dati che vengono trasferiti.

I DNS server realizzati con Windows 2000 utilizzano il metodo dell'Incremental Zone Trasfer per trasferire i dati fra di loro. Ad ogni modo, però, sono in grado di ricorrere al meccanismo della Full Zone Trasfer se il Secondary Server non è in grado di utilizzare l'Incremental Zone Trasfer. Un trasferimento di zona ha luogo solamente se si verifica una delle due seguenti situazioni:

Le informazioni relative al trasferimento dei file di zona sono contenute all'interno del Record SOA.

Island DNS

Per maggiori informazioni sul problema degli Island DNS si può consultare la Knowledge Base: KB275278.

Prestazioni dei DNS

Quando si hanno molte Active Directory Integrated Zone, si possono porre seri problemi di performance del DNS, in particolare nella gestione delle eventuali repliche di zona. Per cercare di migliorare le prestazioni del DNS si può procedere nel seguente modo:

DNS Performance Counter

Quando s'installa il Domain Name System vengono aggiunti anche i seguenti Performance Counters:

Modifiche alle Zone Primarie

Se una Primary Zone non è integrata in Active Directory, allora è possibile modificare manualmente il file di zona corrispondente. Per rendere però operative queste modifiche, bisogna riavviare il DNS Service:

		net stop "Server DNS"
		net start "Server DNS"

Le Primary Zone che non sono integrate in Active Directory vengono inserite nella chiave di registry HKLM\System\CurrentControlSet\Services\DNS\Zone.

Comandi utili

Talvolta possono tornare utili i seguenti comandi da eseguire sui client:

1.4 Windows Internet Name Service

In una rete composta interamente da macchine dotate di sistema operativo Windows 2000 o superire non è necessario attivare un Windows Internet Name Service (WINS), sebbene sia consigliabile farlo. L'implementazione di WINS si rende assolutamente necessaria quando all'interno della rete sono presenti o sistemi operativi che si basano su NetBIOS o sistemi operativi antecedenti a Windows 2000 oppure applicazione che utilizzano solamente i Nomi NetBIOS, quest'ultima situazione �, oggigiorno, la pi� comune. Se si � deciso di mettere in piedi una rete con sistemi operativi Windows 2000 o superiori e si ha un unico Dominio di Active Directory ed un unico site, allora si pu� pensare di disabilitare il traffico NetBIOS dei client e dei server (prima di farlo, per�, conviene svolgere un'attenta fase di test). Per avere maggiori informazioni su come disabilitare il protocollo NetBIOS si pu� consultare la Knowledge Base KB299977 Per avere un'idea sulle conseguenze che si possono avere a causa della disabilitazione del protocollo NetBIOS, si pu� leggere il bellissimo articolo di Tim Rains Why you still run Windows Internet Naming Service (WINS). Se si desiderano invece maggiori informazioni sul servizio Windows Internet Name Service si possono consultare i documenti Windows Internet Name Service e Windows NT Browsing.

Si osservi che il sistema di stampa di Windows 2000/2003/XP, pu� prevedere l'utilizzo del protocollo NetBIOS, ad esempio quando la coda di stampa si basa sulla condivizione \\NomeServer\NomeStampante. In questi casi, la disabilitazione del protocollo NetBIOS non � possibile.

Il protocollo NetBIOS

Il protocollo NetBIOS utilizza le seguenti porte:

I nomi NetBIOS

I nomi NetBIOS presentano le seguenti caratteristiche:

Alcuni servizi di Windows 2000 si basano sui Nomi NetBIOS, come ad esempio:

Si osservi che a partire dal sistema operativo Windows 2000 il Computer Name (o NetBIOS Name della macchina) e lo Host Name devono coincidere, infatti, essendo il DNS il meccanismo preferito da Windows 2000 per risolvere i nomi, non vi può essere distinzione fra i NetBIOS Name e gli Host Name. Per maggiori informazioni si può consultare il documento KB227410.

Registrazione dei Nomi NetBIOS

La registrazioni dei nomi NetBIOS può avvenire in due modalità:

Il ciclo di vita di un Nome NetBIOS è il seguente:

Tipologia di nodi NetBIOS

A seconda di qual'è il meccanismo utilizzato per risolvere i nomi NetBIOS, vengono individuate quattro tipologie di Nodi NetBIOS (i Nodi NetBIOS possono venire identificati con i computer su cui è installato un sistema operativo che si basa su NetBIOS per le comunicazioni via rete):

Un client Windows 2000 si comporta di default come un B-Node, diventa un H-Node non appena gli viene configurato un WINS server a cui rivolgersi per risolvere i nomi NetBIOS. La chiave di registry che identifica il tipo di nodo NetBIOS è: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\NodeType (questa chiave non esiste di default, ma viene aggiunta quanto si modifica il comportamento del NetBT protocol driver di Windows 2000). I valori possibili per questa chiave di registro sono:

Per maggiori informazioni sulle chiavi di registry dei protocolli di rete consulatare la Knowledge Base KB120642.

Caratteristiche di WINS

Il servizio WINS offre i seguenti vantaggi:

All'interno di WINS vengono registrati tutti i servizi che si basano su NetBIOS, pertanto è normale vedere comparire più volte il medesimo nome NetBIOS.

Come regola generale si dovrebbe installare un server WINS ogni 10.000 WINS Client. Il database utilizzato da WINS è un relational database engine a cui si accede con un Indexed Sequential Access Method (ISAM).

La comunicazione fra il NetBIOS Name Server e il NetBIOS Name Client avviene utilizzando le porte TCP e UDP 137. Per impostare, via DHCP, i parametri relativi al WINS Server nei WINS Client si devono utilizzare le seguenti scope options:

Affinché un WINS Server possa erogare il suo servizio di risoluzione dei nomi, bisogna che questi venga configurato come WINS Client di se stesso all'interno delle impostazioni della scheda di rete.

Name Refresh Request

Un WINS Client esegue tre tentativi per registare il proprio nome all'interno del Primary WINS Server. Se dopo questi tre tentativi non è riuscito a registarsi, tenta di rieseguire la procedura di registrazione altre tre volte ma col Secondary WINS Server, se questi è configurato. Se anche questi tre tentativi non sono andati a buon fine oppure se nessun Secondary WINS Server risulta configurato, il WINS Client tenta di registare il suo NetBIOS name via Broadcast. La resgistrazione del nome NetBIOS all'interno di un server WINS è temporanea. L'intervallo di tempo entro il quale il nome NetBIOS di una macchina è attivo (viene tradotto in indirizzo IP dal server WINS) prende il nome di Renewal Interval. Un WINS client segue la procedura indicata di seguito per rinnovare la propria registrazione all'interno del server WINS.

Stato di un record WINS

A seconda di come sia andata la procedura di Refresh di un record all'interno di una database WINS, sono possibili i seguenti tre stati:

All'interno di un record sono contenute le seguenti informazioni:

Un record WINS può essere:

Manutenzione del database WINS

La manutenzione del databse di Server WINS è particolarmente importante per consentire:

Per ridurre la presenza di record imprecisi all'interno del database e per mantenere allineato il suo contenuto con quello degli altri database dei vari Server WINS presenti nella rete bisogna:

Eliminare i record non più validi

Per record non più valido intendiamo un record che non è stato più rinnovato all'interno di un certo intervallo di tempo. Questo intervallo di tempo è la somma di tre intervalli di tempo: Renewal Interval, Extinction Interval e Extinction Timeout. Dove:

I cicli che abbiamo indicato si riferiscono solamente ai record posseduti da un certo Server WINS. Per quanto riguarda i record Active che, seppur presenti nel database di un Server WINS, non sono di sua proprietà, fa fede un'altro intervallo di tempo, chiamato Verification Interval, trascorso il quale il Server WINS controlla che i record Active in questione siano ancora validi. Questo intervallo di tempo non può essere inferiore ai 24 giorni. Si tenga presente che questi record Active di cui il WINS server non risulta proprietario, vengono cancellati solamente se il server WINS, proprietario di questi record, conferma che i record in questione non sono più validi, in caso contrario, ossia che la riposta sia negativa o che non arrivi nessuna risposta (il server WINS risulta indisponibile), questi record non verranno cancellati, pertanto se un server WINS smette di funzionare, tutti i record di cui questi è proprietario non verranno mai cancellati, a meno che non sia un amministratore di sistema a farlo. In generale, un WINS server, cancella solamente i record di cui è proprietario, mai quelli di cui non è proprietario.

Per maggiori informazioni sulla gestione dei record dei database dei WINS Server si può consultare il documento WINS Database Files.

Per quanto riguarda invece i record Tombstone che vengono replicati da un Server WINS all'altro, trascorso l'Extinction Timeout, questi record, anche se non di proprietà del Server WINS, vengono eliminati.

Per mantenere coerenti i vari database dei diversi Server WINS che possono essere presenti all'interno di una LAN, bisogna mantenere in buono stato ciascun singolo database, in quanto i meccanismi di replica possono alterare in modo artificioso la coerenza di ogni singolo database coinvolto nel ciclo di replicazione.

Verificare il contenuto del database con quello degli altri database

Questo controllo permette di matenere allineati fra loro i diversi database dei vari Server WINS che sono presenti in una LAN. Questo controllo, per essere abilitato, ha bisogno che venga selezionata la voce Verify database consistency every all'interno della sezione Database Verification delle Properties di un Server WINS. Conviene, visto che questo processo di controllo è parecchio oneroso, sia in termini di cicli macchina sia in consumo di banda, eseguirlo durante i periodi di relativa tranquillità, come ad esempio la notte. Conviene schedulare questo controllo ogni 24 ore (ovvero una volta al giorno), avendo cura di specificare un Maximum number of records verified each period non troppo grande ne troppo piccolo in misura alle dimensioni del database del Server WINS. Se la linea che lega i vari Server WINS fra di loro è buona, conviene selezionare la voce Owner servers in luogo di quella Randomly selected patners. Nel controllo viene verificato che:

WINS Database Replication

Per motivi di ridondanza conviene installare in una rete almeno due Server WINS, configurandoli per aggiornarsi, l'uno con l'altro, i propri database di modo da rimanere, il quanto più possibile, allineati. Due Server WINS che replicano fra di loro il propri database vengono chiamati Partner. Per ridurre il traffico di rete, i due Partner non si scambiano l'intero database, ma solamente le variazioni che il database ha subito. I tempi e i modi con cui avvengono questi scambi dipendono dalla relazione di patnership che li lega. I metodi che hanno a disposizione due Server WINS per replicare fra di loro i propri database sono due:

Un Server WINS può essere contemporaneamente sia un Pull Partner sia un Push Partner, in questo caso si parla di Push/Pull Partner. Affinchè due Server WINS possano scambiarsi informazioni sui propri database bisogna che uno dei server sia configurato come Pull Partner e l'altro come Push Partner. Ne segue che i due server possono venire configurati entrambi come Push/Pull Partner l'uno dell'altro. Di default, due Server WINS quando diventano patner vengono configurati comePush/Pull Partner. Lo scambio d'informazioni sui database può avvenire solamente fra due Server WINS alla volta, per cui se più di due server WINS sono configurati come patner lo scambio d'informazioni sui database potrà avvenire a due a due.

I due WINS Partner, per individuarsi a vicenda all'interno della rete, utilizzano richieste multicast all'indirizzo 224.0.1.24. Se i due patner appartengono allo stesso segmento di rete, questo meccanismo d'individuazione, non è di solito causa di problemi; diversamente se i partner appartengono a segmenti di rete diversi, interconnessi tramite router, allora bisogna configurare i router per consentire il passaggio di richieste multicasting ad indirizzi noti, altrimenti i due server partner non riescono a percepire l'uno la presenza dell'altro.

Le Proprietà della cartella Replication Partners relativa alla Microsoft Management Console WINS, costituiscono le proprietà di default dei WINS Partners. Tra i vari parametri che si possono configurare vi sono le sezioni:

Se si desidera replicare i dati dei database anche su Server WINS che non sono fra loro Partner, bisogna togliere il segno di selezione dalla voce Replicate only with Partner, che si trova all'interno della sezione General.

I record che vengono replicati tra due WINS Partner sono i seguenti:

Tutti i record che invece si trovano nello stato Released non vegnon replicati fra i vari WINS Partner. Per ovviare ad eventuali problemi di inconsistenza fra i database dei due WINS Partner a partire da Windows 2000 viene adotatto lo schema riportato di seguito per la gestione dei record allo scaderedel Renewal Interval:

Durante le operazioni di replica dei record il Version ID del record non viene modificato. Mentre il Time Stamp del record replicato è dato dalla somma del Current Time relativo al momento in cui la replica ha avuto luogo (per il Pull Server), più la somma del Verification Interval. Si ricordi che tutte le repliche sono di tipo Pull. La replica Push non è altro che l'invito ad un Pull Partner ad eseguire la sua replica Pull. Lo Owner ID relativo ad WINS Server non viene mai replicato. Pertanto la Owner ID Table è puramente locale.

Scavenging di un database WINS

Periodicamente un server WINS esegue una pulizia dei propri record onde mantenere in ordine i dati che contiene. Questa pulizia avviene su tutti i record che sono presenti sul database WINS, siano essi di sua propietà o meno. L'intervallo con cui viene eseguito lo scavenging (pulizia) del database è pari alla una volta e mezzo il Renewal Interval, pertanto se il Renewal Interval è di sei giorni, lo Scavenging Interval sarà di nove giorni. Fa eccezione a questa regola il primo Scavenging Interval che è pari a metà del Renewal Interval. Lo Scavenging Interval ha inzio a partire dal momento in cui il Servizio WINS viene avviato. Conviene poi evitare di riavviare o fermare il Servizio WINS all'interno del primo Scavenging Interval. Durante il primo ciclo di scavenging vengono eseguite tutte le operazioni di pulizia tranne quella di cancellazione dei record Tombstone. I record Tombstone potranno venire cancellati dopo tre giorni dall'avvio del Servizio WINS. Le operazioni che vengono svolte durante l'esecuzione di un ciclo di scavenging sono:

Come ripristinare un database WINS

Prima di procedere con il ripristino di una database WINS, bisogna avere a disposizione un backup valido del database WINS. I passi da seguire per recuperare il database sono:

  1. Controllare qual'è il percorso in cui il database WINS viene salvato. Per ottenere questa informazione bisogna controllare il campo Default Backup Path che si trova all'interno della sezione General, nelle Properties del Server WINS.
  2. Fermare il servizio WINS.
  3. Copiare tutti i file che si trovano all'interno della cartella %windir%\system32\wins, o più in generale quella specificata all'interno della casella di testo Database Path, in una cartella temporanea.
  4. Eliminare tutti i file contenuti nella cartella %windir%\system32\wins, o più in generale quella specificata all'interno della casella di testo Database Path.
  5. Copiare i file relativi al backup del database all'interno della cartella specificata al primo punto (Default Backup Path). Si ricordi che il backup del database viene sempre inserito all'interno della cartella Wins_bak.
  6. Eseguire il Restore del database. Controllare il messagio a video per verificare che sia andato tutto bene. Il servizio WINS verrà avviato in automatico.

Impostazioni Avanzate

Tra le varie impostazioni avanzate di un Server WINS, le più importanti sono sicuramente le seguenti:

WINS e DNS

Risulta possibile e necessario, se in una rete sono presenti macchine con sistema operativo antecedente a Windows 2000, far convivere i Server DNS con i Server WINS. In queste circostanze conviene far diventare i Server DNS autoritativi di una certa zona, dei WINS Client dei Server WINS. In questo modo i NetBIOS Name dei Server DNS autoritativi vengono registrati all'interno dei Server WINS. Per ciascun client della rete l'unico sistema disponibile come name services è quello fornito dai Server DNS. In questo modo, anche i client con sistema operativo antecedente a Windows 2000, utilizzano solamente i server DNS per la conversione dei nomi di computer, siano essi FQDN o NetBIOS, in indirizzi IP. Nell'utilizzo simultaneo dei Server DNS e dei Server WINS bisogna tenere conto che:

Per consentire ad un Server DNS Non-Microsoft di essere autoritativo su di una zona in cui si desidera abilitare un Server DNS ad essere WINS Client di un Server WINS, conviene procedere nel seguente modo:

Per vedere se l'indirizzo IP viene rilascaito dal Server DNS o dal Server WINS si può osservare il Time to Live del record restituito da una query eseguita col comando nslookup (per vedere il Time to Live si deve abilitare l'opzione di debug: set debug). Se si osserva il Time to Live di due query consecutive e si nota che nella seconda query il Time to Live del record risulta diminuito, allora vuol dire che l'indirizzo IP viene fornito dal Server WINS. Si osservi infine che le rispote alle query fornite dal Server DNS sono autoritative anche nel caso che questi consulti il Server WINS per ottenere la risposta.

WINS Proxy

Quando all'interno di una rete o di un segmento di rete sono presenti della macchine che si basano su NetBIOS ma che non sono WINS Client, per ridure il traffico broadcast generato da queste macchine, conviene installare un WINS Proxy. Un sistema operativo che si basa su NetBIOS ma che non è un WINS Client si comporta nel seguente modo:

Compito del WINS Proxy è quello di ridurre il traffico boradcast che si genere col modo di operare indicato nei due punti precedenti. Un WINS Proxy si comporta nel seguente modo:

Per configurare una macchina con sistema operativo Windows 2000 per funzionare come WINS Proxy si deve modificare la chiave di registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\EnableProxy; (questa chiave non esiste di default) i valori ammessi sono due:

Per maggiori informazioni sulle chiavi di registry dei protocolli di rete consulatare la Knowledge Base KB120642.

Raccomandazioni sulla configurazione dei WINS

Quando si configura un WINS Server si dovrebbero osservare le seguenti regole:

Per maggiori informazioni su come eseguire il design di una struttura di WINS Server si può consultare il documento Windows Internet Name Service Design.

Comandi utili

Di seguito vengono indicati alcuni comandi utili per la gestione dei Server WINS:

1.5 Active Directory

Active Directory presenta le seguenti strutture logiche:

Le Forest sono insiemi di Domain Tree, i Domain Tree sono insiemi di Domain.

Caratteristiche:

Viene chiamato Forest Root Domain il primo dominio creato in una foresta. Vengono chiamati Top-Level Domain i primi Domain creati per ciascun Domain Tree. Dalla definizione appena data si evince che un Forest Root Domain è anche un Top-Level Domain ma che un Top-Level Domain non è detto che sia un Forest Root Domain.

Il Forest Root Domain si distingue dagli altri domini in quanto alcuni Operation Master Role devono appartenere a questo dominio, ovvero i ruoli di Schema Operations Master e di Domain Naming Master. Non solo, ma alcuni gruppi di amministrazione di Active Directory vengono creati solamente all'interno del Forest Root Domain, tra questi gruppi ci sono gli Enterprise Admins Group e gli Schema Admins Group. Più in generale, tutto il database di un dominio di Active Directory viene conservato all'interno del file %SystemRoot%\NTDS\NTDS.dit.

Per avere un'idea di come vengono individuati i Domain Controller da parte di un client, si può leggere la Knowledge Base: KB247811.

Scelta dei nomi dei Domini

Per la scelta dei nomi da assegnare ai domini di Active Directory si dovrebbero seguire i seguenti criteri di scelta:

Il primo criterio dovrebbe essere preferito al secondo, il quale è da considerarsi un ripiego qualora il primo criterio non fosse applicabile.

Migrazione da Windows 2000 a Winows 2003

Per avere un'idea di quelle che sono le operazioni da non fare quando si migra da Windows 2000 a Windows 2003 si può consultare il documento Common Mistake Upgrading Windows 2000 to Windows 2003.

Oggetti di Active Directory

Active Directory è composta dai seguenti oggetti:

Gli oggetti di Active Directory possono venire spostati da un dominio di Active Directory ad un'altro dominio di Active Directory oppure all'interno dello stesso dominio di Active Directory. Per spostare un oggetto all'interno del dominio a cui appartiene, si può utilizzare l'Active Directory Users and Computers console, mentre per spostare un oggetto da un dominio ad un'altro si deve utilizzare il comando MoveTree.exe dei Support Tools. Per maggiori informazioni sul comando MoveTree.exe si può consultare la Knowledge Base: KB238394. Quando si utilizza il comando MoveTree.exe i collegamenti con le vecchie Group Policy Object viene conservato, in questo modo però, l'oggetto spostato nel nuovo dominio preleverà le GPO dai suoi vecchi Domain Controller.

Quando un utente o un gruppo viene spostato in un nuovo dominio, gli viene assegnato un nuovo SID, mentre il suo vecchio SID viene aggiunto alla SIDHistory dell'utente. Compito della SIDHistory è quello di conservare le credenziali dell'utente. La SIDHistory è disponibile solamente se il dominio di Active Directory è in Native Mode.

Per quanto riguarda i Domain Controller, questi possono essere spostati da un Site ad un'altro, tutti tranne il First Domain Controller, ovvero il Domain Controller che ha creato il Default-Fist-Site-Name.

In generale, quando si sposta una oggetto di Active Directory all'interno di uno stesso dominio, valgono le seguenti regole:

Per rendere sicuro l'ambiente di un Domain Control si può consultare il documento Deploying Secure Domain Controllers.

Active Directory viene suddivisa in Partizioni:

Delega del Controllo degli Oggetti di Active Directory

Per meglio venire incontro alle esigenze delle grandi aziende, la Microsoft ha implementato in Active Directory la possibilità di delegare il controllo degli oggetti di Active Directory. Per delega del controllo degli oggetti di Active Directory s'intende:

Quando si delega il controllo di un'oggetto di Active Directory conviene tenere ben presente le seguenti regole generali:

La delega del controllo di alcuni oggetti di Active Directory risulta particolarmente importante per bilanciare i carichi amministrativi e per decentrallizare l'amministrazione di Active Directory. Per avere maggiori informazioni su come delegare il controllo di un oggetto di Active Directory si può consultare la Knowledge Base KB315676.

Operation Master Role

Non tutte le operazioni che si svolgono all'interno di Active Directory possono venire svolte sfruttando il Multi-Master Replication Model. Per queste particolari operazioni (come ad esempio l'aggiunta o la rimozione di un dominio da una foresta) si adotta il più consueto metodo del Single Master Operation Model ovvero le operazioni in questione vengono svolte solamente da un singolo Domain Controller. A quei Domain Controller che hanno il compito di amministrare queste particolari operazioni si assegna il nome di Operation Master Role. Quando un Domain Controller è un Operation Master Role, tutte le operazioni riconducibili ad un particolare ruolo, vengono svolte sempre ed esclusivamente dal Domain Controller che ricopre quel particolare Operation Master Role. Tutti i Domain Controller possono ospitare un Operation Master Role. Lo Operation Master Role può essere spostato da un Domain Controller ad un'altro in un qualunque momento, anche quando il titolare del Operation Master Role è indisponibile. Un Domain Controller può ospitare più di un Operation Master Role alla volta.

I possibili Operatione Master Role sono:

Per convenzione, il primo Domain Controller installato di una foresta svolge i seguenti Operation Master Role:

Per convenzione, il primo Domain Controller installato di un dominio svolge i seguenti Operation Master Role:

Per sapere come collocare gli Operation Master Server all'interno di una foresta di Active Directory si può consultare la Knowledge Base KB223346.

Come individuare gli Operation Master Server

Gli Operation Master Role si dividono in ruoli di Foresta e in ruoli di Dominio. Per individuare i ruoli di Dominio:

basta procedere come segue:

Per individuare i ruoli di Foresta:

basta procedere come segue:

La cartella SYSVOL

La cartella SYSVOL è una cartella di sistema condivisa presente all'interno di tutte le strutture gerarchiche delle cartelle ospitate all'interno di tutti i Domain Controller. Questa cartella condivisa contiene i file, come i logon, logoff, startup e shutdown scripts, le informazioni di Group Policy, che vengono poi replicati fra i vari domain controller. Il SYSVOL usa lo stesso metodo di Active Directory per replicarsi, ovvero una particolare caratteristica del file system NTFS 5.0 di Windows 2000, pertanto questa cartella, può essere e deve essere collocata solamente su partizioni NTFS. La caratteristiche citata è il File Replication Service (FRS). Per maggiori informazioni sul FRS si può consultare la Knowledge Base KB296944. Per avre invece maggiori informazioni sulla replicazione di Active Directory si può consultare il documento Active Directory Replication.

Global Catalog

Il primo domain controller che s'installa all'interno di una foresta, svolge sempre il ruolo di Global Catalog Server.

Gli oggetti del Global Catalog sono le varie risorse di rete come ad esempio le stampanti, gli utenti ... Gli attributi sono le possibili caratteristiche che possono avere le varie risorse di rete, come ad esempio il Nome o Cognome di un utente o il Modello o Location di una stampante. Le proprietà sono le istanze (valori) di ciascun attributo.

Il Global Catalog contiene una replica completa di tutti gli attributi degli oggetti di Active Directory definiti all'interno del dominio a cui il Global Catalog Server appartiene e una replica parziale di tutte gli attributi degli oggetti definiti negli altri domini.

All'interno del Global Catalog sono elencati tutti i nomi di tutti gli Universal Group, Global Group e Domain Local Group, non che tutti i membri degli Universal Group, ma non quelli dei gruppi Global Group e Domain Local Group. Il Global Catalog svolge principalmente un ruolo di consultazione. É sempre buona norma che per ogni sito esista almeno un Global Catalog Server. Il Global Catalog viene parzialmente replicato su tutti i domain controller di una foresta.

Per ogni Foresta esiste un solo Global Catalog, ovvero tutti i domini di una foresta condividono lo stesso Global Catalog.

Il Global Catalog svolge due ruoli chiave, all'interno della struttura di Active Directory:

Se durante la fase di logon, il Global Catalog Server non è raggiungibile, un utente può solamente collegarsi localmente al computer su cui opera; fanno eccezione i membri del gruppo Domain Admins, i quali, anche in assenza del Global Catalog Server, sono in grado di fare un logon in rete. Per ridondanza, possono esistere più di un Global Catalog Server all'interno di una Forest.

Il Global Catalog contiene e replica le seguenti informazioni:

Per aggiungere dei nuovi attributi al Global Catalog si può consultare la Knowledge Base KB313992. Si ricordi però che quando si aggiungono dei nuovi attributi al Global Catalog viene scatenata una sincronazzazione globale di tutti gli oggetti imagazzinati nel Global Catalog fra tutti i Domini di una Foresta. Il meccanismo di replica del Global Catalog verte sulla cossidetta Replicazione per Attributi, in quanto, solamente le Proprietà che, fra un ciclo di replicazione e il successivo, sono cambiate di valore vengono replicate. In questo modo viene ridotta la quantità di dati da trasferire fra un Global Catalog Server ed un'altro.

Per sapere come creare, spostare o rimuovere il Global Catalog da un Domain Controller si può consultare la Knowledge Base KB313994.

Restricted Group

I Restricted Group si rivelano particolarmente utili quando si vogliono popalare i Local Group di alcune o tutte le workstation presenti in un dato dominio di Active Directory, infatti, grazie a questo strumento ed ad una Group Policy Object si possono modificare tutti i Local Group delle workstation di dominio senza ricorrere ad alcun script o programma esterno. Per avere maggiori informazioni su come utilizzare i Restricted Group si può consultare il documento Restricted Group Tables.

Replicazioni di Active Directory

Per replicare le informazioni contenute in Active Directory, quest'ultime vengono suddivise in modo logico, in tre insiemi principali:

Pertanto:

Il sistema di replica di Active Directory, basandosi su un sistema Multi-Master, prende il nome di Replica a Perdita di Convergenza, in quanto, lo stato del sistema composto dai vari domain controller di una Foresta, cerca di raggiungere uno Stato di Equilibrio Coerente, che se continua a cambiare nel tempo, tende a diventare uno stato in divenire e mai in essere. Sebbene la replicazione ha l'effetto di sincronizzare tutti i domain controller di una Foresta, il processo di replica avviene solamente fra due domain controller alla volta. La replicazione di Active Directory fra un Domain Controller e l'altro, verte sul File Replication Services (FRS) che è una caratteristica della versione 5.0 del New Technology File System. Per maggiori informazioni sul FRS si possono consultare la Knowledge Base KB296944 e il documento How FRS Works. Per avre invece maggiori informazioni sulla replicazione di Active Directory si possono consultare i documenti Active Directory Replication e Active Directory Replication Model. Per conoscere il ruolo svolto dai DNS Server nel processo di replicazione di Active Directory si può consultare il documento How DNS Support Active Directory. Per sapere quali strumenti mette a disposizione Windows 2003 per gestire eventuali problemi di replicazione di Active Directory fra due o più Site, si può consultare il documento Troubleshooting Guidelines for Branch Office.

Terminologia

Di segutio vengono elencati alcuni dei termini utilizzati per descrivere la replicazione di Active Directory.

Sites

La struttura di una foresta di Active Directory è composta da Sites. Per ogni foresta di Active Directory esiste almeno un Site, il cui nome di default è Default-First-Site-Name. Il primo Domain Controller che viene installato crea il Default-First-Site-Name. Tutti i successivi Domain Controller vengono creati all'interno del Default-First-Site-Name se:

In tutti gli altri casi il Domain Controller creato viene inserito un Site diverso da quello del Default-First-Site-Name. Più in generale, un Domain Controller viene inserito all'interno del Site corrispondente alla sottorete di appartenenza del suo Indirizzo IP.

Per Site s'intende un insieme di server che sono ben connessi fra loro in termini di velocità e costo di banda. Tipicamente un collegamaneto basato su tecnologia LAN viene considerato un collegamento veloce e a basso costo, mentre un collegamento basato sulle tecnologie WAN viene considerato un collegamento lento e a costo elevato. Il costo di un collegamento di rete viene valutato in termini puramente economici, ovvero, se la linea utilizzata è flat, a consumo a canone mensile o annuale, oppure è semplicemente gratuita. In quest'ottica, infatti, le LAN sono di solito di proprietà dell'azienda e quindi non soggette ad alcun costo aggiuntivo rispetto a quelli di manutenzione e potenziamento, col risultato che le LAN sono da considerarsi delle reti a basso costo; tipicamente, invece, le reti WAN sono composte da linee di collegamento che appartengono a società di terze parti rispetto all'azienda a cui la WAN fa riferimento, col risultato che l'azienda per utilizzare queste lienee deve pagare una certa cifra di denaro, spesso assai superiore al costo di una normale linea LAN, proprio per questo motivo le WAN vengono considerate più care delle LAN.

Poichè la connessione fra i vari Domain Controller che compongono un Sites è buona, la replicazione di Active Directory avviene per Notification ogni qual volta si verificano delle modifiche in Active Directory.

Per gestire i Sites di una foresta di Active Directory bisogna utilizzare l'Active Directory Sites and Service console degli Administrative Tools di Windows 2000. Il nome Default-Fist-Site-Name può essere tranquillamente cambiato in base agli standard di un'azienda.

Ad ogni Sites restano associate una o più sottoreti. I computer di una rete, utilizzano le informazioni sulle sottoreti che compongono un Sites per individuare quali sono i Domain Controller che appartengono al proprio Sites di appartenenza. In tal modo, i computer della rete riducono i tempi di Logon e Logoff, in quanto si collegano a Domain Controller con i quali hanno una buona connessione. Le informazioni relative alle sottoreti che compongono un Sites vengono utilizzate anche dai Domain Controller per stabilire il miglior percoso di replicazione.

Affinchè la replicazione di Active Directory possa avvenire fra due Sites diversi, bisogna creare, fra i due Sites un Site Link. A differeza fra quanto avviene fra i Domain Controller che compongono un Sites, la replicazione di Active Directory fra Sites diversi avviene solamente in maniera schedulata. I Site Link vengono creati in base al numero di tecnologie WAN che sono utilizzate per collegare i vari Sites. Pertanto, se si utilizza una sola tecnologia WAN per collegare due o più Sites, basterà creare un solo Site Link per collegare i vari Sites fra loro. Quando s'installa il Primo Domain Controller di una foresta di Active Directory, l'Active Directory Installation Wizard provvede a creare un Site Link di default chiamato DEFAULTIPSITELINK. Una volta terminata l'installazione del primo Domain Controller della foresta, si può procedere a rinominare DEFAULTIPSITELINK. Accanto al DEFAULTIPSITELINK possono venire creati altri Site Link in base alle necessità aziendali.

Tecnologie di replicazione di Active Directory

I Site Link hanno a disposizione due tecnologie per replicare Active Directory:

Proprietà di un Site Link

I Site Link godono delle seguenti proprietà:

Come creare un Site Link

Per creare un Site Link basta procedere nel seguente modo:

Per aggiungere o togliere Sites ad un Sites Link, oppure per modificare le proprietà di un Site Link basta andare ad editare le Properties del Sites Link.

Site Link Bridges

Di default tutti i Site Link di una foresta di Active Directory formano un agglomerato in termini di Site Link Cost, nel senso che è come se fra tutti i Sites della foresta di Active Directory esistesse un Site Link, anche se fra alcuni Sites non esiste un vero e proprio Site Link. Per maggiori informazioni si può osservare il seguente schema. Ovviamente questa configurazione ha senso se la rete è completamente routable, ovvero a partire da un Sites qualunque posso raggiungere via IP tutti gli altri Sites. In questo modo, il meccanismo di replicazione di Active Directory può costruire, in autonomia ed in modo automatico, la sua topologia di replicazione. Se la rete non è completamente routable ci si deve preoccupare che tutti i Sites siano raggiungibili per la replicazione di Active Directory. Infatti, in questo caso, non è più possibile affidarsi al meccanismo di replica di Active Directory per far costruire la topologia di replicazione, ma bisogna provvedere manualmente. Per stabilire qual'è la topologia di replicazione si deve provvedere a creare dei Site Link Bridge. I Site Link che componogono il Site Link Bridge godono della proprietà transitiva, ovvero i pacchetti IP ad essi legati possono venire instradati all'interno di tutti i Sites che essi collegano. Ciò non è vero per i Site Links che non appartengono al Site Link Bridge. Il costo di ciascuno di questi Site Links viruali è dato dalla somma dei Site Link Costs dei Site Links che devono venire utilizzati per realizzarli. Per poter creare i Site Link Bridge bisogna disabilitare l'opzione Bridge All Site Links. Infine, i Site Links che compongono un Site Link Bridge devono avere almeno un Site in comune, altrimenti il Site Links Bridge perde di significato.

Come creare un Site Link Bridge

Per creare un Site Link Bridge basta procedere come segue:

Preferred Bridgehead Server

Nei suoi processi di replicazione fra Sites, Active Directory utilizza la seguente tecnica (tanto per fissare le idee, chiameremo i due Sites col nome di A e B):

Il Domain Controller del Site B in cui il Domain Controller del Site A replica il suo contenuto prende il nome di Bridgehead Server. Se non si è scelto diversamente, tutti i Domain Controller di un Site possono svolgere il ruolo di Bridgehead Server. Questa situazione può risultare limitante nelle seguenti condizioni:

Per tutte queste situazioni si può fissare uno o più Domain Controller come Preferred Bridgehead Server. In questo modo, solamente i Domain Controller che sono considerati Preferred Bridgehead Server vengono utilizzati come Bridgehead Server. Il Domain Controller che fra quelli che compongono i Preferred Bridgehead Server viene utilizzato come Bridgehead Server, prende il nome di Active Preferred Bridgehead Server. Si può impostare, fra i vari Preferred Bridgehead Server, quale di loro dovrà essere considerato l'Active Preferred Bridgehead Server predefinito. Se per qualche motivo, nessun Preferred Bridgehead Server dovesse essere disponibile, Active Directory sceglierà uno qualunque degli altri Domain Controller presenti all'interno del Sites, per replicare i contenuti di Active Directory fra i due Sites.

Come impostare i Preferred Bridgehead Server

Per impostare i Preferred Bridgehead Server si può procedere come segue:

Knowledge Consistency Checker

Il Knowledge Consistency Checker (KCC) è un servizio di Windows 2000 che gira solamente sui Domain Controller e si preoccupa di svolgere le seguenti operazioni:

Come controllare la replicazione di Active Directory

Per controllare se il meccanismo di replicazione di Active Directory funziona correttamente, si può utilizzare la tecnica seguente:

Relazioni di fiducia in Active Directory

All'interno di Active Directory esiste una implicita relazione biunivoca di fiducia tra i vari Domain di un Domain Tree e tutti i Top-Level Domain dei vari Domain Tree che compongono la Forest. Poiché all'interno di Active Directory viene utilizzato Kerberos come meccanismo di autenticazione, ovvero una Forest costituisce un Realm Kerberos, ed essendo l'autenticazione Kerberos transitiva, la relazione di fiducia all'interno di Active Directory gode della proprietà trasitiva. Ciò significa che se tre Domain, A, B e C appartengono al medesimo Domain Tree ed hanno le seguenti relazioni biunivoche di fiducia: A<->B e B<->C allora vale anche la relazione A<->C. Pertanto, un utente di A può accedere alle risorse sia di B sia di C e viceversa. In questo modo, un utente di un Domain può accedere a tutte le risorse di una Forest.

Active Directory prevede poi la presenza di una relazione unidirezionale, esplicità e non transitiva di fiducia nei seguenti casi:

Per poter creare le relazioni di fiducia sopra elencate, il server che svolge il ruolo di Primary Domain Controller Emulator deve essere disponibile.

Zone create da Active Directory

Quando s'installa Active Directory la procedura d'installazione provvedere a creare delle opportune zone DNS che servono al corretto funzionamento di Active Directory. Per poter creare queste zone, qualora il servizio DNS fosse già attivo, l'aggiornamento dinamico della zona DNS su cui opererà Active Directory deve essere abilitato. Le Forward Lookup Zone che vengono create sono:

All'interno della zona forest_root_domain_name devono risultare presenti le seguenti due zone DNS:

Non viene invece creata alcuna Reverse Lookup Zone.

Livelli di Dominio e di Foresta

Per avere un'idea di quelli che sono le novità sui Livelli di Dominio e di Foresta in Active Directory di Windows 2003 si può consultare il documento: How Active Directory Functional Levels Work. I possibili Livelli di Dominio di Windows 2003 sono:

I Livelli di Foresta di Windows 2003 sono:

Quando si alza il Livello di Foresta, tutti i successivi Domini erideteranno il livello di dominio corrispondete a quel particolare livello di foresta, pertanto se si passa al livello di foresta Windows Server 2003 allora tutti i successivi domini avranno come Livello di Dominio quello Windows Server 2003.

Per poter alzare il Livello di Dominio bisogna appartenere al gruppo dei Domain Admins. L'operazione d'innalzamento va eseguita sul Primary Domain Controller Emulator. L'operazione d'innalzamento del livello di dominio è irreversibile. Per alzare il livelo di dominio si deve utilizzare come strumento Active Directory Users and Computers.

Per poter alzare il Livello di Foresta a Windows Server 2003 bisogna che:

Per sapere come innalzare il Livello di Foresta o il Livello di Dominio si può consultare la Knowledge Base KB322692.

Una volta innalzato il livello di foresta a Windows Server 2003 tutti gli Active Directory Domain vengono portati a livello di dominio Windows Server 2003. Per alzare il Livello di Foresta si deve utilizzare l'Active Directory Domains and Trusts e bisogna far parte del gruppo Enterprise Admins. L'operazione d'innalzamento del livello di foresta è irreversibile. L'operazione d'innalzamento del Livello di Foresta va eseguita sul Domain Controller che ricopre il ruolo di Schema Operations Master.

Per sapere quali sono i livelli di dominio e foresta con cui un Domain Controler è compatibile, si possono consultare gli attributi msDSBehaviorVersion della classe nTDSDSA interrogoando le impostzioni dell'oggetto NTDS con la seguente query LDAP:

cn=NTDS Settings,cn=<ServerName>,cn=<servers>,cn=<sites>,cn=configuration,dc=<DomainName>,dc=<ForestRootDomainName>

L'assenza di questi attributi significa che la macchina sta eseguendo, come sistema operativo, Windows 2000, mentre l'assenza dell'oggetto NTDS sta a significare che sulla macchina è stato installato il sistema operativo Windows NT.

Per conoscere qual'è il Livello di Dominio si può consultare l'attriuto msDSBehaviorVersion della classe domainDNS eseguendo una query LDAP del tipo: 

dc=<DomainName>,dc=<ForestRootDomainName>

L'assenza dell'attributo va interpretata come livello 0 (ovvero Windows 2000 mixed o Native).

Per conoscere qual'è il Livello di Foresta si può consultare l'attriuto msDSBehaviorVersion della classe crossRefContainer eseguendo una query LDAP del tipo:

cn=partitions,cn=configuration,dc=<DomainName>,dc=<ForestRootDomainName>

L'assenza dell'attributo va interpretata come livello 0 (ovvero Windows 2000 mixed o Native).

Per eseguire queste query si può utilizzare il comando ldp.exe:

Active Directory Object

Esistono molti Active Directory Object. Alcuni dei più significativi Active Directory Object sono:

Struttura fisica di Active Directory

La struttura fisica di Active Directory è composta dai seguenti elementi:

Viene definito Site un insieme composto da Domain Controller collegati fra loro da un link ad alta velocità (almeno 512Kbps). Caratteristiche di un Site:

I Site vengono utilizzati per svolgere al meglio i seguenti compiti:

Fra due o più Site i dati vengono scambiati in modo leggermente diverso:

Restore Autoritativo di Active Directory

Quando si esegue un resotre di Active Directory, il contenuto del database di Active Directory appena ripristinato, viene sincronizzato con quello degli altri Domain Controller, col risultato che non si riesce, in questo modo, a recuperare un dato cancellato per errore. Per ovviare a questa strategia di restore, si utilizza un Restore Autoritativo di Active Directory. In questo modo, il dato che si desidera recuperare viene da prima ripristinato e poi replicato sugli altri Domain Controller. Per eseguire un Restore Autoritativo di Active Directory basta procedere come segue:

Per maggiori informazioni sul comando ntdsutil si possono consultare le Knowledge Base: KB315131 e KB241594.

Per valutare l'integrità del database di Active Directory, si può consultare la Knowledge Base: KB315136.

Configurazione di Active Directory per un sito Web

Supponento di fare riferimento all'architettura standard di un sito web, composta dagli strati denominati User Services, Business Logic e Data Services, dove col termine strato intendiamo un insieme di computer aventi compiti di funzionamento simili; la configurazione di Active Directory va così impostata.

Pubblicare un servizio in Active Directory

In generale in Active Directory si possono pubblicare le seguenti risorse:

Prima di pubblicare un Servizio di Rete bisogna controllare se la sua pubblicazione soddisfa alle seguenti condizioni:

Di solito vengono pubblicate due categorie di servizi:

Per pubblicare un servizio di rete in Active Direcotry si deve utilizzare l'Active Directory Sites and Services.

System Key (SYSKEY)

La System Key (o più brevemente SYSKEY) è una chiave a 128bit che consente di:

La SYSKEY viene attivata di default ogni qual volta si esegue l'installazione di un Domain Controller. In particolare la SYSKEY presenta tre modalità di funzionamento:

Per maggiori informazioni sulla SYSKEY e su come mettere in sicurezza un Domain Controller si può consultare il documento Deploying Secure Domain Controllers.

Sincronizzazione temporale all'interno di Active Directorty

Per avere maggiori informazioni sulla sincronizzazione fra i vari computer che appartengono ad Active Directory, si possono consultare le seguenti Knowledge Base: KB216724 e KB243574. Per sapere come sincronizzare fra di loro i vari Domain Controller di un Dominio e i vari computer di un Dominio di Active Directory, potete leggere la ricetta Come impostare l'ora in Active Directory.

Autenticazione via TLS ad Active Directory

Per avere maggiori informazioni sul processo di autenticazione via Transport Layer Security (o più brevemente TLS) ad Active Directory si possono consultare i documenti SSL/TLS in Windows Server 2003, How TLS/SSL Works.

Per abilitare il protocollo TLS/SSL in Active Directory bisogna seguire le indicazioni riportate nella Knowledge Base KB321051. In caso di problemi di autenticazione ad Active Directory si può abilitare il livello di logging del SChannel, per maggiori informazioni si può consultare la Knowledge Base KB260729.

Compatibilità fra Active Directory ed i software Antivirus

Per la natura stessa dei software Antivirus si possono verificare dei problemi di compatibilità fra Active Directory ed i software antivirus stessi. Questi problemi di compatibilità riguardano essenzialmente l'interferenza che si può verifica fra il software antivirus quando questi esegue una scansione virale ed Active Directory nell'accesso ad alcuni file vitali per il corretto funzionamento di Active Directory. Per ovviare a questo tipo di problemi basta escludere alcuni file e cartelle dalla scansione virale del programma antivirus. Per maggiori informazioni si possono consultare le seguenti Knowledge Base KB822158 e KB284947.

Togliere dalla scansione dell'Antivirus le seguenti cartelle:

Strumenti di Amministrazione di Active Directory

Esistono due classi di strumenti per gestire e mantenere Active Directory:

Accanto agli strumenti riportati, si può utilizzare anche l'ADSI Editor, questo strumento però si trova all'interno dei Support Tools di Windows 2003.

Strumenti di diagnostica di Active Directory

Esistono diversi comandi per valutare lo stato di salute di Active Directory (abbreviato AD). Tra questi vale la pena menzionare i seguenti:

Per ottenere maggiori informazioni dall'Event Viewer sullo stato di Active Directory si deve aumentare il livello di logging dei vari componenti di Active Directory. Per far questo basta procedere come segue:

Per avere un esatta desrizione di tutti gli eventi legati al File Replication Service si può consultare il documento FRS Event Log Error Codes.

Per ottenere maggiori informazioni su come svolgere alcune operazioni di diagniostica di Active Directory si può consultare i documenti Active Directory Diagnostics Troubleshooting and Recovery e How to Troubleshoot AD Replication Problem.

Per conoscere quali sono i nuovi comandi che sono stati messi a disposizione degli amministratori di Windows 2003 si può consultare il documento New Command-Line Tools for Active Directory.

Per gestire i servizi di Windows 2003 è stato messo a disposizione degli amministratori di sistema il comando sc.exe.

1.6 User e Computer Object

Esistono tre categorie di utenti in Windows 2000:

Per maggiori informazioni sulla gestione degli User e Computer Object si consulti il documento Users and Computers Objects.

Template

Se si creano molti utenti durante le normali attività quotidiane, conviene creare dei modelli d'utente da utilizzare nella procedura di creazione. Per creare un modello d'utente si può procedere come segue:

Caratteristiche di un utente

Quando si analizzano le Properties di un utente, le sezioni che di default si hanno a disposizione sono:

Se s'installano dei programmi che estendono lo schema di Active Directory, allora accanto alle sezioni di default, ci possono essere ulteriori sessioni legate all'estensione dello schema. Un tipico programma che estende lo schema di Active Directory è Microsoft Exchange.

User Profile

I User Profile sono una collezzione di di dati che contengono le configurazioni dell'ambiente Desktop attuale di un utente, le impostazioni delle applicazioni che utilizza, la configurazione del menu Start, i dischi di rete condivisi in modo permanente dall'utente e i suoi dati personali. In particolare, i dati personali di un utente vengono conservati in una cartella che prende il nome di Home Folder. Esistono diversi tipi di User Profile:

Gli User Profile vengono conservati di default nella cartella %SystemDrive%\Documents and Settings e contengono le seguenti cartelle (alcune delle quali sono, per costruzione del sistema operativo, nascoste):

Oltre alle cartelle riportate, la cartella %SystemDrive%\Documents and Settings contiene anche il file NTUser.dat in cui sono contenute le impostazioni del registry relative all'utente.

Quando si creano dei Roaming User Profile bisogna tenere presente che centralizzando il contenuto dei profili degli utenti si sta realizzando un single point of failure, ovvero si sta aumentando la criticità di una risorsa della rete, In quest'ottica conviene seguire alcune semplici regole:

Come creare un Roaming User Profile

Per creare un Roaming User Profile basta procedere come indicato:

Talvolta si può rivelare particolarmente utile, creare un profilo standard (Standard Roaming User Profile) per alcuni utenti, di modo che abbiano tutti a disposizone lo stesso ambiente di lavoro. Per creare questo profilo standard si può procedere nel seguente modo:

Se necessario si può ripetere la procedura indicata per tutti gli utenti a cui si vuole assegnare lo Standard Roaming User Profile.

Come creare un Mandatory User Profile

I Mandatory User Profile non sono altro che Roaming User Profile opportunamente modificati. Creare un Mandatory User Profile è estremamente semplice:

Home Folder

Sebbene la cartella My Documents sia la cartella di default in cui gli utenti possono archiviare i loro documenti, Windows 2000 mette a disposizione agli amministratori di sistema, la possibilità di dotare gli utenti di un'ulteriore cartella, alternativa alla My Documents, in cui salvare i propri documenti, chiamata Home Folder. In questo modo gli utenti possono decidere se archiviare i loro documenti all'interno della Home Folder o all'interno della My Documents. La Home Folder viene conservata in una cartella condivisa, di modo che sia accessibile su tutti i computer della rete a cui l'utente decide di collegarsi. Inoltre la Home Folder non fa parte della cartella Documents and Settings, col risultato che le sue dimensioni non alterano il tempo di accesso alla macchina da parte dell'utente dopo che questi ha inserito la sua account. L'uso delle Home Folders presenta i seguenti vantaggi:

Essendo le Home Folders immagazzinate in una cartella condivisa, la disponibilità di questa cartella diventa di primaria importanza per la buona efficienza della rete aziendale, ne consegue che bisogna mettere in atto tutte le precauzioni necessarie a garantrire il massimo livello di disponibilità di questa risorsa di rete. Conviene, pertanto, collocare questa cartella condivisa all'interno di un cluster ad alta affidabilità.

Come creare una Home Folder

Per creare una Home Folder basta seguire le indicazioni riportate di seguito:

Reset Computer Account

Ogni computer di un Active Directory Domain ha una canale segreto di comunicazione con i Domain Controller del Active Directory Domain. Questo canale di comunicazione prende il nome di Secure Channel. Per garantire la riservatezza della comunicazione il computer e il Domain Controller concordano una password (Secret Channel Password) che viene rinnovata, per i sistemi operativi Windows 2000 e superiori, ogni 30 giorni. La coppia formata dal Computer Account e la Secret Channel Password viene conservata sia in Active Directory e quindi in ogni Domain Controller, sia localmente all'interno del Local Security Authority (LSA) del computer a cui la Computer Account fa riferimento. Se per qualche motivo la sincronizzazione fra la coppia conservata in Active Directory e quella nel LSA dovesse venire meno, si deve procedere eseguendo un Reset Computer Account. Per maggiori informazioni sulla Reset Computer Account si può consultare la Knowledge Base: KB216393.

Per svolgere un Reset Computer Account si possono usare i seguenti strumenti:

Quando si utilizza il comando NetDom.exe per eseguire un Reset Computer Account, sia la copia della password del Local Security Authority sia la copia della password di Active Directory vengono modificati in: <ComputerName>$. Si ricordi, infine, che un Computer Account può appartenere solamente ad un Dominio (sia Active Directory sia Windows NT) per volta.

Comandi Utili

Uno dei comandi più utili nell'amministrazione di Active Directory è il comando NetDom.exe che si trova sia all'interno dei Support Tools sia all'interno del Resource Kit. Questo comando consente, fra le altre cose di aggiungere un computer all'interno di Active Directory. Per conoscere meglio la sintassi di questo comando si può consultare la Knowledge Base: KB266651. Se si desidera migrare un Computer Account da un Dominio Windows NT ad un Dominio di Active Directory, si può utilizzare, oltre che al già citato comando NetDom.exe, anche l'Active Directory Migration Tool.

Per spostare in modo rapido User Account, Group Account e Organizational Unit da un Dominio della foresta di Active Directory, ad un'altro dominio della stessa foresta di Active Directory, si può utilizzare il comando MoveTree.exe. Durante l'esecuzione del comando MoveTree.exe vengono generati due file; il primo, chiamato MoveTree.log, contiene tutte le operazioni che sono svolte dal comando MoveTree.exe, il secondo, chiamato MoveTree.err, contiene tutti gli errori segnalati dal comando MoveTree.exe. Per avere maggiori informazioni sull'utilizzo del comando MoveTree.exe si può consultare la Knowledge Base: KB238394.

Per eseguire delle modifiche massive su Active Directory, si può utilizzare il comando Ldifde.exe, questo comando è disponibile su tutti i server che svolgono il ruolo di Domain Controller. Grazie al comando Ldifde.exe si possono svolgere le seguenti attività:

Per maggiori informazioni si possono consultare la Knowledge Base KB237677 ed il documento Guide to Active Directory Bulk Import and Export

1.7 Group Policy Object

I Group Policy Object (GPO) si applicano solamente ai sistemi Windows 2000 o superiori. I Group Policy Object sono uno dei mezzi più potenti nelle mani degli amministratori di rete. Tramite i Group Policy Object risulta possibile personalizzare il desktop degli utenti, i permessi, privilegi e regole a cui un utente deve sottostare. I Gorup Policy Object sono una collezzione di Group Policy Settings e vengono immagazzinate in due luoghi differenti:

I Gorup Policy Object possono venire applicati o ai Computers (Group Policy Settings for Computers) a agli utenti (Group Policy Settings for Users). I Group Policy Settings for Computers vengono applicati quando il computer si avvia o si spegne. Esiste poi un ciclo di refresh periodico dei Group Policy Object che provvede ad aggiornarle qualora si verifichino delle modifiche. Le Group Policy Settings for Computers hanno la precedenza, in caso di conflitti, sulle Group Policy Settings for Users. Le modifiche introdotte dalle Group Policy Settings for Computers vengono inserite nella zona del registry sotto HKEY_LOCAL_MACHINE. Le Group Policy Settings for Users vengono applicate quando un utente fa logon o logoff e godono anch'esse di un ciclo di refresh. Le modifiche introdotte dalle Group Policy Settings for Users vengono inserite nella zona del registry sotto HKEY_CURRENT_USER.

Più in particolare, i template delle Group Policy che sono salvati nel SYSVOL vengono inseriti in due caretelle distinte a seconda della tipologia del templete, ovvero se il template si riferisce ai compueter o agli utenti. Abbiamo:

I Group Policy Object possono venire applicati ad un Site, Domain o Organizational Unit:

Si ricordi però che può esistere solamente una Domain Account Policy per ogni Active Directory Domain. I Group Policy Object non vengono applicati ai Security Group, ma solamente agli Utenti e Computer che fanno parte di un Site, Domain o Organizational Unit.

Per maggiori informazioni sulle Group Policy si possono consultare i documenti Group Policy e Step-by-Step Guide to Understanding the Group Policy.

Per sapere come si possono utilizzare i Group Policy Object per gestire i profili utente si può consultare il documento Managing User Data and Settings.

Per avere un'idea di come realizzare un'archietettura di rete basata sui Group Policy Object si può consultare il documento Group Policy Infrastructure.

Per verificare quali possono essere gli errori a cui un'errata implementazione dei Group Policy Object può dare vita si può consultare il documento Troubleshooting Group Policy.

Per sapere come spostare un Group Policy Object da un dominio ad un'altro si può consultare il documento Migrating GPOs Across Domains with GPMC.

Con Windows 2003 è stato introdotto un nuovo strumento, la Group Policy Management Console che consente di gestire ed amministrare in modo semplice ed efficace i vari Group Policy Object che si possono creare con Windows 2003. Per maggiori informazioni sulla Group Policy Management Console si può consultare il documento Administering Group Policy.

Default Group Policy Object

Quando s'installa il primo Domain Controller di una foresta di Active Directory, vengono creati i seguenti Group Policy Object di default:

Tipi di Gorup Policy Object

Esistono due tipi di Group Policy Object:

A seconda del tipo di Group Policy Object a cui ci si riferisce, risulta possibile impostare in parte o in tutto le segenti impostazioni:

Le impostazioni che caratterizzano una Group Policy vengono inserite all'interno di un Group Policy Object (GPO). I Group Policy Object possono poi essere associati ad un Site, Domain, Organizational Unit, Local Computer. Di default i Group Policy Object vengono applicati in modo sincrono: uno dopo l'altro. Per poter eseguire i Group Policy Object i seguenti servizi devono essere in esecuzione:

I servizi di Windows 2000 sopra citati vengono avviati di default in modo automatico, pertanto vengono avviati ad ogni avvio del sistema operativo.

Scripts

Risulta possibile, tramite i Group Policy Object far eseguire ad un computer, al momento dello startup o dello shutdown, o ad utente, al momento del log on o del log off, uno o più script. Gli script che possono essere eseguiti allo startup/shutdowm del computer sono eseguiti in modo sincrono, ovvero uno di seguito all'altro, in particolare uno script che viene eseguito al momento dello startup/shutdowm di un computer, possono partire solamente se gli script che li precedeno sono terminati o sono andati in Timeout. Il tempo di Timeout, per questa categoria di script è, di default, pari a 600sec (10min). Per modificare questo valore di default si possono utilizzare diverse Group Policy. Al contrario gli script che vengono eseguiti al momento del logon/logoff di un utente sono processati in modo asincrono: tutti insieme. In particolare gli User Object Script sono eseguiti per ultimi. Per creare uno script si può utilizzare un qualunque Linguaggio ActiveX come ad esempio:

Questo perchè gli scripts vengono eseguiti nell'ambiente Windows Scripting Host (WSH). All'interno di uno scripts è possibile eseguire qualunque Executable Files (.exe). Per avere un'idea di che cos'è il WSH si può consultare la KB232211.

Per poter far eseguire gli scripts a tutti gli utenti o computer di un dominio di Active Directory indipendentemente da quale Domain Controller utilizzano per fare log on o log off, startup o shutdown, bisogna copiare gli script all'interno della cartella SYSVOL, in particolare all'interno della cartella <NomeDominioAD>\Policies\<GPO-GUID>\USER\Scripts\Logon. Con la sigla <GPO-GUID> intendiamo il Globally Unique Identifier che viene assegnato ad ogni GPO.

Group Policy di Sicurezza

Per quanto riguarda l'utilizzo dei Group Policy come strumento per controllare la sicurezza degli account, è bene sottolineare che:

A seconda che ci si riferisca ai Computer Configuration o agli User Configuration, si hanno a disposizione le seguenti impostazioni di Group Policy:

Conviene impostare le Computer Configuration solamente per quelle Organization Unit in cui sono presenti dei Computers, poichè queste impostazioni non vengono prese dagli utenti. Analogamente le impostazioni relative all'Account Policies vengono applicate o al Security Account Manager (SAM) database locale di ciascun computer oppure ai Domain Controller della foresta di Active Directory. Pertanto, se non si desidera modificare il SAM di ciascun computer, conviene applicare queste impostazioni solamente alle Organizational Unit che contengono dei Computers. Diversamente, se si vogliono modificare le impostazioni delle Account Policices dei Domain Controller bisogna modificare la Default Domain Policy o più in generale un Group Policy Object applicato a livello di dominio di Active Directory.

Le possibili impostazioni da applicare alle password degli utenti sono le seguenti:

Le possibili impostazioni per il blocco di un'account sono:

I Group Policy Object che configurano le password degli utenti possono venire applicate a livello di Site, Domain e Organizational Unit ma influiscono solamente sui Domain Controller, pertanto le uniche Group Policy Object che definiscono il comportamento delle password degli utenti che sono realmente significative sono quelle che s'impostano sui Domain Controller. L'impostazione può essere fatta o direttamente sui Domain Controller o all'Organization Unit a cui i Domain Controller appartengono, oppure a livello di Site o di Domain. In questo caso la gerarchia Local Group Policy Object -> Site Group Policy Object -> Domain Group Policy Object -> Organizational Unit potrebbe non valere, poichè tutto dipende a quale livello appartengono i Domain Controller.

Per compatibilità verso il passato è stata inserita la voce LAN Manager Authentication Level per consentire di utilizzare i vecchi metodi di autenticazione: LAN Manager, NTLM ver. 1 e NTLM ver. 2. In questo modo, anche gli utenti che operano con sistemi operativi pre-Windows 2000 possono venire autenticati in Active Directory.

Permessi per creare ed associare un Group Policy Object

Per poter creare od associare un Group Policy Object ad un contenitore, ovvero un Dominio, una Organization Unit o un Sito, bisogna avere i permessi di Read e Write sulle opzioni gPlink e gPOptions. Le opzioni gPlink e gPOptions fanno parte dei permessi avanzati che può avere un contenitore. Di default, questi permessi sono garantiti ai seguenti gruppi, Domain Admins ed Enterprise Admins. Si ricordi, comunque, che per associare un Group Policy Object ad un sito bisogna far parte degli Enterprise Admins.

Affinché un Group Policy Object possa venire applicato ad un utente, un gruppo di utenti, un computer o ad un insieme di computer, è necessario e sufficiente che l'utente, i gruppi o i computer, abbiano i permessi di Read e di Allow Apply Group Policy sul Group Policy Object stesso.

I membri del Group Policy Creator Owners possono creare Gorup Policy Object, ma non possono collegarle.

Di default vengono assegnati i seguenti permessi:

Risultare possibile delegare il controllo di uno o più Group Policy Object a gruppi di dominio, diversi da quelli di default (Domain Admins e Enterprise Admins). Per far questo bisogna garantire a questi gruppi i permessi di Allow Read e Allow Write sulla Security dei Group Policy Object a cui si desidera delegare il controllo. Se si sta cercando di delegare il controllo di uno o più Group Policy Object tramite uno dei seguenti tool:

Allora non si può utilizzare il Delegation of Control Wizard per delegare il controllo dei Group Policy Object. Bisogna invece aprire le Properties di ciascun Group Policy Object e modificare manualmente le sue impostazioni di Security.

Per poter aprire un Group Policy Object all'interno del Group Policy Snap-In, si devono avere i permessi di Allow Read e Allow Write sul Group Policy Object.

Permessi per creare un Computer Account

Per poter creare una Computer Account all'interno di una Organizational Units bisogna godere dei seguenti privilegi:

Il primo privilegio viene assegnato quando si godono dei permessi di Full Control sulla Organization Unit, mentre il secondo privilegio è impostato di default quando si crea un nuovo utente. Il solo permesso Add workstation to Domain permette di aggiungere fino a 10 workstation ad un dominio Active Directory. Le due abilitazioni invece consentono di aggiungere un numero illimitato di workstation ad un dominio Active Directory o all'interno di una particolare Organization Unit. Più in generale il permesso Create Computer Object può essere assegnato ricorrendo agli Special Permission.

Come creare un Group Policy Object

Si possono creare due tipologie di Gorup Policy Object, quelli collegati (linked) o quelli non collegati (unlinked), a un Site, Domain o Organization Unit. Le Gorup Policy Collegate sono applicate e quinid operano, su di un Site, Domain o Organization Unit, col risultato che qualche computer o qualche utente riceve le impostazioni indicate dal Group Policy Object. Un Group Policy Non Collegato, invece, non fa riferimento a nessun Site, Domain o Organization Unit e pertanto le impostazioni specificate al suo interno non agiscono su nessun computer o utente. Per creare queste due tipologie di Group Policy Object si utilizzano i seguenti strumenti:

Per migliorare l'operatività conviene non creare mai Group Policy Object Non Collegati, conviene invece creare una Organization Unit dal nome Unlinked Group Policy e applicare tutte i Gorup Policy Object che non si desidera mettere in produzione a questa Organization Unit. In questo modo è più facile reperire i Group Policy Object che si sono creati. Ovviamente all'interno della Oragnization Unit Unlinked Group Policy non deve venire inserito nessun utente o computer.

Quando si crea o modifica un Group Policy Object tramite lo snap-in Group Policy della MMC, il comportamento predefninito di questa console, è quello di creare e modificare le Group Policy sul server che svolgere il ruole di Primary Domain Controller Emulator. Per cambiare il Domain Controller a cui fa riferimento lo snap-in, bisogna utilizzare l'opzione DC Options del menu View. Si osservi, poi, che maggiore è il numero di Group Policy Object applicate, maggiori sono i tempi di startup/shoutdown o logon/logoff.

Le impostazioni di un Group Policy Object possono riferirsi ad un Computer o ad un Utente, nel primo caso si parla di Computer Configuration Settings, nel secondo di User Configuration Settings. Sia le Computer Configuration Settings sia le User Configuration Settings possiedono la seguente struttura:

Più in particolare, ciascuna sezione riportata sopra, contiene:

Per meglio amministrare le Group Policy si può realizzare una Group Polic Object Console, dove le Group Policy Object (GPO) non sono altro che una collezzione d'impostazioni di Group Policy. Per costruire una Group Polic Object Console basta procedere come indicato:

  1. Aprire la Microsoft Management Console.
  2. Aprire il menu Console e selezionare la voce Add/Remove Snap-In.
  3. All'interno della finestra Add/Remove Snap-In cliccare sul pulsante Add.
  4. All'interno della finestra Add Standalone Snap-In selezionare la Group Policy snap-in e cliccare poi sul pulsante Add.
  5. All'interno della finestra Select Group Policy Object, cliccare sul pulsante Browse.
  6. Nella finestra Browse For A Group Policy Object selezionare la sezione All. Cliccare sulla GPO che s'intende aggiungere alla Group Polic Object Console. Confermare la scelta premendo il pulsante OK.
  7. Tornati alla finestra Select Group Policy Object cliccare sul pulsante Finish.
  8. Ripetere i punti precedenti per tutte le GPO che s'intende aggiungere alla Group Polic Object Console.
  9. Quando si sono aggiunte tutte le GPO desiderate, chiudere la finestra Add Standalone Snap-In premendo il pulsante Close.
  10. Confermare l'inserimento delle GPO chiudendo la finestra Add/Remove Snap-In premendo OK.
  11. Salvare la Group Polic Object Console così creata aprendo il menu Console e scegliendo la voce Save As. Si osservi che così facendo la Group Polic Object Console viene aggiunta agli Administrative Tools dell'utente che a svolto le operazioni. Per rendere la console disponibile a tutti gli utenti bisogna copiarla nella cartella %ALLUSERSPROFILE%\Start Menu\Programs\Administrative Tools.

Esecuzione dei Group Policy Object

All'interno di uno stesso oggetto di Active Directory, sia esso una Organizational Unit, un Domain o un Site, l'ordine con cui vengono eseguiti i Group Policy Object associati all'oggetto di Active Directory, dipende dall'ordine con cui i Group Policy Object vengono riportati all'interno della finestra Group Policy Object Links che fa parte della sezione Group Policy all'interno delle Properties dell'oggetto di Active Directory. I Group Policy Object che si trovano in alto, all'interno della finestra Group Policy Object Links, hanno priorità più alta rispetto ai Group Policy Object che si trovano in basso. Per modificare questo ordine si possono utilizzare i pulsanti Up e Down. Data questa conevenzione sulla priorità di un Group Policy Object, Windows 2000 eseguirà i Group Policy Object che si trovano all'interno della finestra Group Policy Object Links partendo dal basso verso l'alto, in questo modo i Group Policy Object che hanno priorità più alta verranno eseguiti per ultimi. In tal modo, infatti, le loro impostazioni possono alterare le impostazioni dei Group Policy Object che li precedono.

Ereditarietà dei Group Policy Object

Le Group Policy godono della proprietà dell'Ereditarietà, ovvero le impostazioni delle Group Policy passano da un contenitore padre ad un contenitore figlio. In particolare il flusso ereditario è il seguente:

Group Policy Object di Site -> Group Policy Object di Domain -> Group Policy Object di Organization Unit Padre -> Group Policy Object Organization Unit Figlio -> Group Policy Object Organization Unit Nipote

Un Group Policy Object di Site è valida anche per tutti i Domain che appartengono al Site, così come per tutte le Organization Unit definite nei vari Domain di cui è composto il Site e così via. Si osservi che vengono ereditate solamente le impostazioni che formano una Group Policy Object che sono state Abilitate o Disabilitate, le impostazioni Non Configurate non vengono ereditate.

L'ordine con cui i Group Policy Object vengono applicati ad un computer o ad un utente è il seguente:

Fanno eccezione al flusso indicato le macchine che sono member server e su cui gira un unico servizio, come ad esmpio Internet Information Services (IIS).

Esistono diversi metodi per arginare o impedire l'ereditarietà dei Group Policy Object, precismanete (le impostazioni riportate sono valide solamente per i Nonlocal Group Policy Object):

Si ricordi che il No Override ha la precedenza sul Block Inheritance, pertanto una Group Policy a cui è stato impostato il No Override, si applica anche quei contenitori in cui è stato specificato il Block Inheritance. Per filtare le Group Policy, bisogna modificare i permessi che hanno gli utenti o i computer nei confronti di una o più Gorup Policy. Più specificatamente, bisogna porre Deny in Apply Group Policy. Se si vogliono delegare le richieste di filtraggio delle Gorup Policy conviene seguire le seguenti regole:

Esistono poi dei particolari Group Policy Object, chiamati Loopback Group Policy Object, che hanno il compito di blindare la configurazione di una macchina. Quando si abilitano i Loopback Group Policy Object gli User Settings relativi alle Group Policy Settings for Computers hanno la precedenza sulle impostazioni analoghe delle Group Policy Settings for Users. Per impostare i Loopback Settings bisogna:

Le Group Policy di Loopback vengono create quando si vuole garantire la massima sicurezza di certe macchine, come ad esempio quelle che appartengono ad un Chiosco o ad una Classe di Studenti.

Replicazione dei Group Policy Object

Di default la replicazione dei Group Policy Object fra un Domain Controller e l'altro, parte dal Primary Domain Controller Emulator, in quanto, quando si crea o si edita un Group Policy Object tramite il Group Policy Editor, questi si connette, per default al Primary Domain Controller Emulator. Per replica dei Group Policy Object indendiamo la replicazione del contenuto dei due contenitori Group Policy Container e Group Policy Template. In particolare abbiamo:

Controllo periodico delle Group Policy

Esiste un meccanismo, all'interno delle macchine Windows 2000 o superiori, con cui vengono controllare pediodicamente le Group Policy per vedere se ci sono state modifiche all'interno di esse o se per caso esistono nuove Group Policy d'applicare. I tempi con cui questi controlli vengono eseguiti cambiano a seconda del ruolo della macchina, ovvero se la macchina è un Domain Controller o no. Abbiamo:

Lo scopo dell'offset è quello di evitare che molte macchine arrivino a controllare le Group Policy nello stesso periodo. L'offset anticipa o ritarda il controllo delle Group Policy da parte di una macchina in modo casuale, evitando in tal modo l'accavallarasi delle richieste.

Fanno eccezzione alle regole riportate sopra, le Group Policy Installations, le quali vengono controllate solamente all'avvio o allo spegnimento di una macchina o al logon e logoff di un'utente, ma non durante il normale funzionamento della macchine o il normale lavoro di un utente.

Si osservi infine, che si può cambiare l'intervallo di tempo di default con cui le Group Policy vengono controllate, ma che non si possono pianificare orari in cui le Group Policy vengono di sicuro controllate, cioè schedulare dei processi di controllo delle Group Policy. Per sapere come modificare l'intervallo di tempo di default con cui le Group Policy vengono controllate, si può consultare la Knowledge Base KB203607.

Group Policy e connessioni di rete lenta

Il meccanismo che sovraintende al controllo e all'applicazione delle Group Policy, riesce a determinare se la connessione di rete fra il Domain Controller in cui si trovano le Group Policy Object da applicare ed un client, è sufficientemente veloce oppure no. Se dovesse concludere che la connessione è lenta, il corrispondente client verrebbe etichettato di modo che l'applicazione di un particolare Group Policy sia a completa discrezione del client stesso. Di default, non tutte le Group Policy vengono applicate, quando si è difronte ad un caso di connessione lenta. In particolare si ha:

Per cambiare il comportamento di default per le tipologie di Group Policy a cui ciò è consentito, si deve utilizzare un opportuno Administrative Template.

Administrative Template

Gli Administrative Template sono modelli di Group Policy, applicabili sia agli utenti sia ai computer con sistema operativo Windows 2000 o superiore, con cui personalizzare la configurazione dei desktop degli utenti o il comportamento dei computer. Gli Administrative Template sono file di testo (in formato Unicode) con estensione .adm e si trovano nella cartella %SystemRoot%\Inf. Con l'arrivo di Windows XP la Microsoft ha introdotto degli Administrative Template aggiornati, in particolare:

Quando si applica un Administrative Template, questi va a modificare il Registry del computer a cui l'Administrative Template viene applicato. In particolare, a seconda che l'Administrative Template si riferisca ad un Computer o ad un Utente viene modificata una parte diversa del Registry. Più precisamente:

Security Template

I Security Template si trovano all'interno delle cartelle %WINDIR%\Inf e %WINDIR%\Tecurity\Templates. I Security Template non sono altro che una collezione d'impostazioni di sicurezza. Quando una macchina Windows 2003 Domain Controller viene installato potrà ricevere l'uno o l'altro dei seguenti Default Security Template:

Non applicare mai il Secuirty Template HiSecDC.inf su un Domain Controller in quanto ne compromette sensibilmente la funzionalità: i client potrebbero non autenticarsi più.

Folder Redirection

Con l'aiuto delle Group Policy risulta possibile redirezionare su una cartella condivisa una o più cartelle che compongono l'ambiente desktop di Windows 2000. In particolare si possono redirezionare le seguenti cartelle:

Group Policy Object e Quote disco

Le quote disco vengono gestite in base all'ownership dei file e delle cartelle, indipendentemente dalla cartella in cui i file e le cartelle si trovano. Risulta particolarmente comodo e allo stesso tempo elegante, gestire le Quote Disco all'interno dei Group Policy Object. In particolare risulta possibile abilitare le seguenti voci:

Per attivare queste voci basta andare all'interno della sezione Computer Configuration\Administrative Templates\System\Disk Quotas.

Strumenti per la gestione delle Group Policy

Esistono due tool del Windows 2000 Resource Kit che aiutano nella diagniostica delle Group Policy:

Per applicare e controllare la sintassi di una Gorup Policy, si può utilizzare il comando SecEdit.exe Le possibili opzioni del comando sono:

Le opzioni /Analyze, /Configure richiedono l'utilizzo o di un database che viene specificato ricorrendo allo switch /db, o di un template, che può essere specificato attraverso lo switch /cfg, per poter essere utilizzate.

Se si utilizza un PC in cui è installato Windows XP per aggiornare le Group Policy Object applicate localmente alla macchina si può utilizzare il comando GPUpdate. In particolare si può utilizzare il comando gpupdate /target:<NomeComputer> per aggiornare un computer remoto con Windows XP.

Per amministrare le Group Policy si può utilizzare la Group Policy Management Console lanciando il comando gpmc.exe che si può trovare sul sito www.microsoft.com/downloads (per installarla è necessario avere installato il Microsoft .NET Framework 1.1).

Oltre ai programmi indicati, vale la pena segnalare anche i seguenti strumenti:

Esempio di strutturazione di Active Directory per la gestione delle GPO

Esistono diversi modi di realizzare un'infrastruttura di rete basata sui Group Policy Object, il più funzionale di questi è quello di creare una struttura basata sulle esigenze aziendali e non sulla struttura organizzativa aziendale. Difatti, un utente dell'ufficio Marketing non è molto diverso da un utente dell'Amministrazione del Personale, entrambi devono svolgere compiti strettamente legati al loro lavoro e poco inerenti all'amministrazione delle loro macchine (compito di solito demandato agli amministratori di rete). Questo significa che è molto meglio suddividere gli utenti e le macchine in tipologie, assegnando a ciascuna tipologia un ben preciso obiettivo. Tipicamente all'interno di una qualunque realtà aziendale si possono incontrare una o più delle seguenti tipologie:

Maggiori informazioni sulla gestione degli account utente si possono trovare all'interno dei documenti User Data and Settings Management e Enterprise Logon Scripts.

Particolrmente interessanti sono gli articoli: Secure Configuration e Hardening Domain Controllers.

1.8 Dynamic Host Configuration Protocol

Il Dynamic Host Configuration Protocol (DHCP) consente di assegnare in modo dinamico un insieme coerente d'indirizzi IP ad una o più sottoreti. Per meglio comprendere il meccanismo di assegnazione degli indirizzi IP indicheremo il dispositivo che richiede un indirizzo IP col nome di DHCP Client e il dispositivo che offre un indirizzo IP col nome di DHCP Server. Per fissare le idee si può pensare al DHCP Client come ad una Workstation ed al DHCP Server come ad un server Windows 2000 in cui è stato installato il servizio Dynamic Host Configuration Protocol. Più in generale, una moderna stampante di rete può essere o un DHCP Client, quando richiede un indirizzo IP, o un DHCP Server, quando offre indirizzi IP; allo stesso modo un router del mercato SOHO può svolgere anche il ruolo di DHCP Server.

Per avere maggiori informazioni sul servizio DHCP si può consultare il sito web www.dhcp-handbook.com.

Affinchè un server possa diventare un DHCP Server bisogna che soddisfi alle seguenti condizioni:

Per maggiori informazioni sul Dynamic Host Configuration Protocol si può consultare il documento Dynamic Host Configuration Protocol. Per sapere come migrare il database di un DHCP Server da una macchina Windows 2000 ad una macchina con Windows 2003 si possono consultare le seguenti Knowledge Base: KB325473 e KB323360.

Processo di generazione delle DHCP Lease

Il processo d'assegnazione degli indirizzi IP avviene in quattro fasi:

  1. IP Lease Discovery (DHCPDiscover) dal DHCP Client ai DHCP Server.
  2. IP Lease Offer (DHCPOffer) dai DHCP Server al DHCP Client.
  3. IP Lease Request (DHCPRequest) dal DHCP Client ad un ben preciso DHCP Server.
  4. IP Lease Acknowledgement (DHCPAck) da un ben preciso DHCP Server al DHCP Client.

Tutte i passaggi di sopra sono richieste che vengono effettuate via Broadcast sia dal DHCP client sia dal DHCP server, in quanto, di solito, il DHCP client non ha ancora un indirizzo IP valido quando inzia a dialogare col DHCP server per avere un indirizzo IP.

Nelle loro comunicazioni il DHCP Client e il DHCP Server utilizzano lo User Datagram Protocol (UDP) sulle porte 67 (BOOTPS) e 68 (BOOTPC).

IP Lease Discovery

Questo processo ha inizio quando si verifica una delle seguenti condizioni:

Poichè il DHCP Client non ha ancora un indirizzo IP, nella fase di dialogo col DHCP Server, assume momentaneamente l'indirizzo 0.0.0.0 ed invia via Broadcast all'indirizzo 255.255.255.255 la sua richiesta d'indirizzo IP, DHCPDiscover. All'interno del pacchetto DHCPDiscover sono contenute le seguenti informazioni:

Se un DHCP ha più di una scheda di rete configurata per ricevere un Indirizzo IP via DHCP, vengono lanciate tante richieste DHCPDiscover quante sono le schede di rete.

Se il DHCP Client non riceve nessuna risposta dai DHCP Server, rinnova la sua richiesta di DHCPDiscover altre quattro volte, ad intervalli di 2sec, 4sec, 8 sec e 16sec dalla richiesta precedente, con un OffSet compreso fra 0sec e 1sec.

Se il DHCP Client è una macchina Windows 2000 o superiore e se dopo quattro tentativi di DHCPDiscover non ha ancora ricevuto alcuna risposta dai DHCP Server, allora il DHCP Client esegue una procedura di autoassegnazione di un indirizzo IP chiamata Automatic Private IP Address (APIPA). La Microsoft ha acquistato dal IETF la seguente classe B d'indirizzi IP: 169.254.0.0. Con indirizzi che vanno dal 169.254.0.1 al 169.254.255.254. Sebbene dopo l'APIPA le macchine Windows 2000 o superiori abbiano un indirizzo IP valido, continuano lo stesso a cercare la disponibilità di un DHCP Server, eseguendo un DHCPDiscover ogni 5min.

IP Lease Offer

Tutti i DHCP Server che hanno un indirizzo IP valido per il segmento di rete a cui il il DHCP Client ha inviato una richiesta di DHCPDiscover, rispondono con un offerta d'indirizzo IP, DHCPOffer. All'interno del pacchetto DHCPDiscover sono contenute le seguenti informazioni:

In questa fase il DHCP Server, sebbene non abbia ancora ricevuto una conferma da parte del DHCP Client, esclude momentaneamente l'indirizzo IP che ha offerto al DHCP Client, tra quelli disponibili per essere rilasciati.

IP Lease Request

Quando il DHCP Client inzia a ricevere le diverse offerte DHCPOffer dai vari DHCP Server che hanno ricevuto la sua richiesta DHCPDiscover, esegue una fase di selezione delle varie offerte. La selezione si basa sui seguenti criteri:

In risposta alla DHCPOffer il DHCP Client fornisce una DHCPRequest. All'interno del pacchetto DHCPRequest sono contenute le seguenti informazioni:

Quando un DHCP Server che aveva inviato un DHCPOffer che è stato scartato dal DHCP Client, si vede recapitare una DHCPRequest, toglie dagli indirizzi IP assegnati l'indirizzo IP che aveva offerto al DHCP Client e lo torna ad inserire fra quelli disponibili. Mentre il DHCP Server che si è visto accettare l'indirizzo IP che aveva offerto al DHCP Client, invia al DHCP Client una risposta di conferma, lo DHCPAck.

IP Lease Acknowledgement

Quando il DHCP Server che ha offerto l'indirizzo IP accettato dal DHCP Client, riceve il DHCPRequest, invia, per accettazione, un pacchetto chiamato DHCPAck. All'interno del pacchetto DHCPAck sono contenute le seguenti informazioni:

Quando il DHCP Client riceve il DHCPAck procede a configurare la scheda di rete a cui la DHCPOffer si riferiva secondo le impostazioni contenute nel DHCPAck. Al termine di questa fase il DHCP Client sarà in grado di dialogare con gli altri dispositivi di rete.

Automatic Lease Renewal

Al 50% della durata della Lease di un indirizzo IP, il DHCP Client tenta di rinnovare la Lease del proprio indirizzo IP inviando una richiesta DHCPRequest al DHCP Server che gli ha fornito l'indirizzo IP. Se il DHCP Server è attivo rinnova la Lease del DHCP Client inviandogli un DHCPack. Se il DHCP Server non è attivo o non è in grado di rinnovare la Lease, allora il DHCP Client ritenterà il rinnovo della Lease quando sarà trascorso lo 87.5% della durata della Lease. In questo caso però, la richiesta DHCPRequest verrà inviata a tutti i DHCP Server presenti nella rete. Il primo DHCP Server che gli risponderà con un DHCPack sarà il nuovo DHCP Server di riferimento del DHCP Client. Un DHCP Client continua ad utilizzare, se non riesce a rinnovare la Lease, l'indirizzo IP assegnatogli sino a quando la Lease non scade. Alla scadenza della Lease il DHCP Client rilascia l'indirizzo IP che gli era stato assegnato e inizia una nuova richiesta d'IP Lease Discover. Se si riavvia il servizio DHCP Client, una volta che questi aveva già ricevuto un indirizzo IP, il DHCP Client esegue i seguenti passi:

  1. Tenta di rinnovare la propria IP Lease
  2. Se non riesce a rinnovare la propria IP Lease tenta di raggiungere il Default Gateway. Se il tentativo va a buon fine continua ad utilizzare l'indirizzo IP che gli era stato assegnato. Se il tentativo non va a buon fine, il DHCP Client smette di utilizzare l'indirizzo IP che gli era stato assegnato e procede con una nuova richiesta d'IP Lease Discover.

Autorizzare un server DHCP

Affinchè un server DHCP possa rilasciare indirizzi IP, deve venire prima Autorizzato. Gli utenti che possono compiere questa operazione sono tutti quelli che:

Per Autorizzare un server DHCP si può seguire la seguente ricetta:

Una volta che un DHCP Server è stato autorizzato viene riavviato il servizio DHCP Server. Riavviando il servizio DHCP Server viene eseguita la seguente procedura:

  1. Invia una messaggio DHCPInform via Global Broadcast (255.255.255.255) a tutti i DHCP Server di una rete. I DHCP Server della rete attivi in quel momento rispondono con un messaggio DHCPack.
  2. Se i DHCP Server della rete appartengono ad un dominio Active Directory, all'interno della risposta DHCPack viene inserito anche l'elenco dei Domain Controller.
  3. Il DHCP Server contatta tutti i Domain Controller per ottenere la lista dei DHCP Server Autorizzati, se il DHCP Server vi appartiene allora il servizio DHCP Server si avvia regolarmente, altrimenti il servizio DHCP Server viene fermato ed inserito un messaggio d'errore all'interno dell'Event Viewer.

Il messaggio DHCPInform via Global Broadcast viene inviato da un DHCP Server Autorizzato ogni 5 minuti per controllare che non ci siano stati dei cambiamenti all'interno delle autorizzazioni dei DHCP Server in Active Directory.

L'autorizzazione di un DHCP Server è valida solamente all'interno di una singola foresta di Active Directory. Se in una infrastruttura di rete ci sono due o più foreste i DHCP Server delle varie foreste, anche se non autorizzati, potrebbero rilasciare indirizzi IP ad host che non appartengono alla foresta a cui sono stati autorizzati.

La stessa modalità utilizzata per autorizzare un DHCP Server può essere utilizzata per autorizzare un RIS Server. Analogamente ai DHCP Server anche i RIS Server devono poter venire autorizzati, prima in Active Directory, per poter erogare il loro servizio ai client.

Per sapere come Autorizzare, Deautorizzare o vedere l'elenco dei server DHCP autorizzati, tramite il comando NetSH.exe si può consultare la Knowledge Base KB303351.

Scope

Una volta che uno Scope è stato creato, bisogna attivare lo Scope affinchè il DHCP Server possa rilascaire gli indirizzi dello Scope creato.

Non è possibile cambiare la Subnet Mask di uno Scope. Se si vuole cambiare la Subnet Mask di uno scope bisogna prima Cancellare lo scope e poi tornarlo a creare, utilizzando ad esempio lo New Scope Wizard, con la nuova Subnet Mask.

DHCP Client Class

Per DHCP Client Class s'intendono tutti quei DHCP Client accomunati dall'avere una medesima caratteristica comune (come ad esempio la versione del Sistema Operativo). Le DHCP Client Class si dividono in due categorie:

I sistemi operativi di casa Microsoft presentano le seguenti classi:

Per impostare le DHCP Client User Classes si può utilizzare il comando: ipconfig /setclassid L'utilizzo delle classi si rivela particolarmente utile quando si voglio realizzare scope d'indirizzi IP caratteristici per certe tipologie di macchine, come ad esempio i Notebook.

DHCP Options

Esistono quattro tipi di DHCP Options, legate fra loro da un legame di precedenza. Le DHCP Options consentono di fornire gli indirizzi IP dei server che erogano i servizi (come ad esempio gli indirizzi IP dei DNS Server, i WINS Server ...) presenti all'interno di una LAN. Le possibili DHCP Options sono:

Per maggiori informazioni sulle DHCP Options si può consultare il documento RFC 2132.

DHCP e Dial-Up Client

Il servizio di Routing and Remote Access di Windows 2000 o superiore, consente di configurare, per i Remote Access Client, l'assegnazione dinamica dell'indirizzo IP tramite DHCP Server. Poichè conviene tenere separati gli indirizzi rilasciati dal DHCP ai client di rete da quelli rilasciati ai Remote Access Client, si può utilizzare, per tale scopo, la classe utente Default Routing and Remote Access Class. In questo modo si possono impostare delle Scope Option differenti da quelle degli Scope a cui puntano i client della LAN. Conviene infatti tenere basso il periodo di lease onde ridurre il numero di indirizzi IP utilizzati dai Remote Client Access (di solito s'imposta la lease a 2 ore).

DHCP Multicasting

Risulta possibile identificare più host con un medesimo indirizzo IP. Gli host in questo modo avranno due indirizzi IP, uno che l'identifica singolarmente all'interno della rete, un'altro che l'individua come membri di uno stesso gruppo. Questo secondo indirizzo IP prende il nome di IP Multicast. Risulta possibile assegnare dinamicamente oltre all'indirizzo IP di ciascun host, anche l'indirizzo IP Multicast. Affinchè un client possa ricevere un indirizzo IP Multicast bisogna che il suo servizio DHCP Client sia compatibile col Multicast Address Dynamic Client Allocation Protocol (MADCAP). Per poter assegnare indirizzi IP Multicast bisogna creare, sul DHCP Server, un Multicast Scope.

Per maggiori informazioni sul IP Multicasting e lo MDACAP si possono consultare i seguenti documenti RFC 1112, RFC 2236 e RFC 2730.

DHCP in Routed Network

Di solito i Router vengono configurati per non lasciar passare le richieste Broadcast da una rete all'altra, col risultato di bloccare anche le richieste DHCPDiscover. Pertanto, se una delle due reti risulta priva di un DHCP Server, ci si deve porre il problema di come assegnare dinamicamente gli indirizzi IP agli host di questa rete. Le soluzioni possibili sono:

I DHCP Relay Agent hanno il pregio di trasformare le richieste Broadcast, legate ai messaggi DHCPDiscover, in richieste Unicast dirette al DHCP Server che viene configurato nel DHCP Relay Agent. La comunicazione fra il DHCP Server e il DHCP Relay Agent è di tipo Unicast, mentre la comunicazione fra il DHCP Relay Agent e il DHCP Client è di tipo Broadcast.

Per installare un DHCP Relay Agent bisogna utilizzare il Routing and Remote Access. I parametri che bisogna inserire per configurare un DHCP Relay Agent sono:

DHCP Logging

Se si abilitano le capacità di logging di un DHCP Server, allora viene generato un file chiamato DHCPSrvLog.<xxx> dove la sigla <xxx> va sostituita con le prime tre lettere che identificano il giorno della settimana in cui sono state abilitate le capacità di logging. Questo file viene inserito, di default, all'interno della cartella %SystemRoot%\System32\Dhcp. Conviene abilitare le capacità di logging solamente se ci sono dei problemi, in quanto degradano le performance del DHCP Server. Per abilitare il DHCP Logging basta procedere come segue:

Comandi Utili

Non si può lanciare il comando DHCPLoc.exe del Resurce Kit di Windows 2000 da un DHCP server, in quanto questa utility cerca d'individuare i server DHCP, intercettando i pacchetti che questi server trasmettono, ne segue che venendo il comando lanciato da un server DHCP, il comando intercetterà le richieste DHCP che questo server invierà, col risultato che il server sembrerà inattivo.

Altri comandi utili sono:

1.9 Internet Information Server

I componenti dell'Internet Information Server (IIS) sono:

L'installazione minima dell'Internet Information Server prevede l'installazione dei componeneti Common File, Internet Information Services Snap-In e World Wide Web Server.

L'installazione di default di Internet Information Server prevede la creazione di:

Per modificare l'installazione di default di IIS bisogna utilizzare un'installazione unattended. Per eseguire un'instllazione unattended di IIS bisogna prima creare un file di testo contente le informazioni neccessarie per l'installazione dei componenti e dei servizi che compongono IIS. Un possibile esempio di file IISUnattendedSetup.txt si può trovare qui. Una volta creato il file IISUnattendedSetup.txt si può procedere con l'installazione di IIS eseguendo da command prompt il comando: sysocmgr /i:%WinDir%\Inf\Sysoc.inf /u:C:\IISUnattendedSetup.txt ammesso che il file IISUnattendedSetup.txt si trovi all'interno del disco C:. Il comando Sysocmgr.exe consente d'installare un numero limitato di componenti di Windows 2000. Per sapere come trasformare un server con Windows 2000 a bordo in un web server si può consultare la Knowledge Base KB308192. Pi� in generale, per installare l'Internet Information Server si può consultare il documento Installing IIS. Per maggiorni informazioni sulla sintassi del comando sysocmgr.exe si può consultare il documento Syntax of Sysocmgr.exe.

È buona norma seguire le seguenti abitudini quando si decide d'installare IIS:

Quando si disinstalla IIS le seguenti cartelle non vengono rimosse:

Durante il processo di disinstallazione di IIS tutte le chiavi di registry modificati in seguito all'applicazione di una HotFix non vengono rimosse, pertanto si deve aprire il registry e provvedere a rimuoverle manualmente, altrimenti lo HotFix Checking Tool (Hfnetchk.exe) non è più in grado di analizzare in modo corretto il sistema. Per elimanare le chiavi di registry bisogna andare all'interno della chiave HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\HotFix, individure le chiavi relative alle HotFix applicate e rimuoverle dal registry (le chiavi che corrispondono a delle HotFix. portano il nome della Knowledge Base a cui fanno riferimento). Per maggiori informazioni sul HotFix Checking Tool si può consultare la Knowledge Base KB303215.

Configurazione di IIS

La configurazione di IIS avviene impostando due tipi di proprietà:

Le Master Properties sono impostazioni globali applicate al server su cui è installato IIS. Le Master Properties vengono ereditate da tutti i siti che vengono aperti sul server in cui è installato IIS. Le Site Properties sono invece proprietà caratteristiche di ciascun sito e possono essere diverse da sito a sito (siano essi Web o FTP).

Per accedere alle Master Properties basta procedere come segue:

Per accedere alle Site Properties basta procedere come indicato:

E' buona norma specificare come Home Directory, ovvero la cartella che contiene tutti i file che compongono un sito Web o un sito FTP, una cartella diversa da quella di default: %SystemDrive%\InetPub\WWWRoot per i siti Web, %SystemDrive%\InetPub\FTPRoot per un sito FTP. In quanto le cartelle di default presentano le seguenti caratteristiche che depongono a loro sfavore:

Un'altra buona norma è quella di specificare, all'interno della sezione Documents delle proprietà di un sito, il nome della Home Page, cioè del primo documento che viene caricato quando si accede ad un sito. Poichè IIS ricerca questo documento all'interno della Home Directory, prendendo a modello i nomi dei file che sono elencati all'interno della sezione Documents, partendo dal primo in alto sino all'ultimo in basso, bisogna collocare questo documento all'interno della cartella Home Directory. Per accelerare il processo d'individuazione della Home Page conviene specificare il nome del file che contiene questa pagina come il primo nome della lista presente all'interno della sezione Documents.

Per sapere come integrare IIS e ISA Server si può consultare la Knowledge Base KB300435.

Virtual Directory

Le Virtual Directory sono cartelle, appartenenti alla struttura di un sito, che punto a uno share di rete. Facendo riferimento alla Virtual Directory si punta direttamente alla share di rete, in questo modo si riesce a dare alla struttura del sito una struttura coerente, senza che l'utente si accorga che sta passando da un server ad un'altro. Le Virtual Directory consentono di arricchire la struttura di un sito senza dover spostare i documenti da un server ad all'altro. Dalla console di amministrazione di Internet Service Manager, risulta possibile assegnare dei permessi globali alle Virtual Directory Questi permessi globali sono validi per tutti gli utenti che accedono alla Virtual Directory. I permessi che si possono impostare sono (i permessi che riportiano si applicano anche a tutte le Directory che compongono un Sito Web o un Sito FTP):

I permessi di un utente che accede alla Virtual Directory via browser, sono il frutto della combinazione dei permessi globali della Virtual Directory e delle ACL di NTFS. In particolare, i permessi delle Virtual Directory si comportano esattamente come i permessi delle share di rete: pertanto l'utente otterà la combinazione più restirttiva fra i permessi globali della Virtual Directory e le ACL su file system. La combinazione più restirttiva si ottiene intersecando le ACL del file system con i permessi globali della Virtual Directory, esattamente come per le share di rete. Per creare Virtual Directory all'interno di un sito si possono usare le seguenti tecniche:

Identificazione di un sito web

IIS conente di ospitare più di un sito all'interno dello stesso server web. Per poter accedere ai vari siti che ospita un server web si possono utilizzare tre metodologie diverse:

A prescindere da quale metodo si decida di utilizzare per gestire la presenza di più siti all'interno dello stesso server web, bisogna integrare la scelta fatta con il server DNS che si preoccuperà di risolvere i vari nomi dei siti.

L'utilizzo del metodo degli HTTP Header si rivela particolarmente utile, quando si vuole consentire all'utente d'inserire URL diverse per raggiungere il medesimo sito. Ad esempio, per raggiungere il sito www.MioSito.net, si può concedere all'utente d'inserire o il nome completo del sito: www.MioSito.net, oppure solamente il nome del dominio: MioSito.net o in alternativa il vecchio nome del sito: www.MioPrimoSito.net.

Quando si utilizzano gli HTTP Header si deve togliere l'opzione di default All Unsigned altrimenti il sito web a cui si stanno impostando gli HTTP Header, tenterà di rispondere a tutte le interrogazioni HTTP del server web.

Logging di un sito Web

Internet Information Service mette a disposizioni le seguenti tipologie di logging di un sito Web:

In particolare il W3C Extended Log File Format consente un controllo molto raffinato delle informazioni da registrare all'interno del file di log, ovvero risulta possibile decidere se registare o meno le seguenti informazioni:

Aggiornamento di un sito web

Ci sono due possibili metodi per aggiornare un sito web:

Il secondo metodo è preferibile al primo per i seguenti motivi:

La maggiore sicurezza del WebDAV rispetto al protocollo FTP deriva dal fatto che il primo si appoggia ai Web Services mentre il secondo no.

Poichè quando si abilita l'utilizzo di WebDAV i permessi di scrittura all'interno della Home Directory si applicano a tutti gli utenti, per poter filtrare l'autorizzazzione alla scrittura solamente a certe persone ben precise, si deve ricorrere alle ACL del file system NTFS. Per abilitrare la scrittura sulla Home Directory tramite WebDAv si devono abilitare i seguenti permessi:

Avere abilitato il permesso di Write non significa avere dato l'opportunità di modificare le pagine di script, come ad esempio le ASP Page. Per consentire ad un utente di modificare il contenuto di questi file, oltre al permesso di Write bisogna fornire anche il permesso di Script Source Access.

Autenticazione

IIS mette a disposizione diversi metodi per Autenticare un utente. Col termine Autenticazione intendiamo il processo con cui il server web identifica un utente che tenta di accedere uno o più siti che si trovano sul server web. I possibili metodi di Autenticazione sono:

L'Anonymous Authentication è l'autenticazione di default (quando questa viene scelta) adottata da IIS. Per tutti gli altri meccanismi di autenticazione, la scelta di quale adottare viene effettutata in concomitanza dal Browser del web client e da IIS, in base alle seguenti regole:

L'autenticazione Integrated Windows Authentication è l'autenticazione più sicura, mentre quella Digest Authentication è più sicura della Basic Authentication. Pertanto, se selzionata, l'autenticazione Integrated Windows Authentication è quella utilizzata di default se non si seleziona l'Anonymous Authentication.

Anonymous Authentication

Questo tipo di autenticazione è abilitata di default e di solito è quella più utilizzata, soprattutto per le areee pubbliche di un sito web. Quando si utilizza questo tipo di autenticazione, tutti gli utenti che accedono al sito vengono impersonati dall'utente IUSR_%ComputerName%. Pertanto, bisogna stare molto attenti ai permessi che vengono assegnati a questo utente a livello di ACL di NTFS. Salvo motivi particolare, conviene fornire all'utente IUSR_%ComputerName% solamente i permessi di Read, senza autorizzarlo a quelli di Write ed Execute. Se lo si desidera, si può cambiare l'utente anonymous, cambiando l'utente IUSR_%ComputerName% con uno scelto dall'amministratore di rete. Bisogna però sottolineare che l'utente anonymous deve avere il permesso di Log On Locally e Network Logon. La pratica di cambiare l'utente anonymous da quello di default di IIS è comunque vivamente sconsigliata!

Basic Authentication

Affinchè un utente o locale alla macchina o del dominio possa venire autenticato con Basic Authentication deve avere i permessi di Log On Locally. Di default un utente di dominio non ha i permessi di Log On Locally. I vantaggi della Basic Authentication sono:

Per gli utenti che appartengono ad un dominio, sia di Windows NT, sia di Windows 2000, risulta possibile specificare il campo Domain Name per indicare il dominio predefinito da utilizzare quando un utente di dominio, nel momento di autenticarsi, non dovesse specificare il dominio di appartenenza. Questa opzione torna utile per evitare che gli utenti di dominio debbano specificare, oltre allo username, anche il domain name.

Digest Authentication

La Digest Authentication è uguale alla Basic Authentication col l'unica eccezione che il principal (ovvero l'insieme composto dal Nome Utente e dalla Password) viene criptato e poi inviato al server web, il quale si preoccuperà poi di decriptarlo. Il processo di criptazione avviene tramite un processo di mascheramento noto col nome di Hashing. Per poter mettere in piedi questo tipo di autenticazione devono essere soddisfatte le seguenti condizioni:

Anche la Digest Authentication può essere utilizzata in presenza di Proxy Server o Firewall.

Integrated Windows Authentication

L'Integrated Windows Authentication non funziona se il client si collega al sito tramite un HTTP Proxy Server. Nell'Integrated Windows Authentication il Nome Utente e la Password vengono inviati al Web Server in modo criptato. L'Integrated Windows Authentication è la forma di autenticazione più sicura fra tutte quelle che si possono utilizzare per accedere ad un sito Web ospitato da un Internet Information Server.

Processo di Autorizzazione

Per Processo di Autorizzazione s'intende il meccanismo col quale vengono assegnati i permessi di cui un utente gode, quando questi accede ad un sito. In altri termini, ciò che un utente può fare o non può fare all'interno di un sito. Il Processo di Autorizzazione di una persona ad un sito si basa sull'applicazione di due tipi di permessi:

Viene applicata prima la Web-Based Permission e poi la NTFS Permission, in caso di conflitto viene applicato il permesso più restrittivo. La Web-Based Permission è composta da:

La Web-Based Permission si applica a tutte le persone che accedono al sito, a prescindere dalla loro natura: ovvero se sono amministratori o semplici utenti; dal loro gruppo di apprtenenza ecc... Con questa sola permission non è possibile implementare dei filtraggi selettivi basati sull'account di chi accede al sito. Per avere un processo di autorizzazione più granulare si deve ricorrere alla NTFS Permission sfruttando le ACL insite nel file system NTFS.

Secure Sockets Layer

Il Secure Sockets Layer (SSL) consente di criptare la comunicazione fra un Web Server e un Web Client. Per attivare il Secure Sockets Layer su di un Web Server bisogna ottenere un certificato digitale, fornito da una società riconosciuta a livello internazionale, come ad esempio VeriSign, nel quale si certifica l'identità del Web server e allo stesso tempo contiene le Public Keys con cui criptare la comunicazione con i Web Client. Per avre maggiori informazioni su come implementare il Secure Sockets Layer in Internet Information Server si possono consultare le Knowledge Base: KB299875 e KB298805.

Siti FTP

Su di un Sito FTP si possono impostare i seguenti permessi:

Un Sito FTP supporta solamente i seguenti meccanismi di autenticazione:

Per avere maggiori informazioni su come configurare l'accesso ad un sito FTP si può consultare la Knowledge Base KB318712.

Salvataggio della configurazione di IIS

Esitono diversi metodi per salvare la configurazione di IIS, tra i possibili citiamo:

Fatta eccezzione per il primo e l'ultimo metodo elencato per salvare la configurazione di IIS, di solito i file relativi al salvataggio della configurazione vengono messe all'interno della cartella: %SystemDrive%\WINNT\system32\inetsrv\MetaBack ed hanno estensione MD0, MD1, MD2 ... A seconda della versione di salvataggio (indicata dalla cifra che segue le lettere MD).

Se il sistema operativo del server web viene reinstallato o se si cerca di recuperare la configurazione di IIS da una file di salvataggio di un'altro server web, l'operazione di ripristino non va a buon fine. Per poter spostare un file di configurazione da un server web ad un'altro si deve utilizzare il Metabase Editor, esportando il file di configurazione di IIS di un server web in formato testo, utilizzando la funzione Export Text File del menu Metabase ed importandolo successivamente in un'altro server web, ricorrendo alla funzione Import Text File del menu Metabase. L'operazione d'importazione di file di configurazione è estremamente pericolosa e va pertanto eseguita con cautela.

Amministrazione remota di IIS

Esistono diversi metodi per amministrare remotamente IIS:

Per poter accedere da remoto al Administrative Web Site bisogna prima assicurarsi che la macchina da cui ci stiamo collegando sia autorizzata ad accedere al sito. Per autorizzare una macchina ad accedere al sito Administrative Web Site bisogna:

Se si desidera fermare o riavviare i servizi di IIS, conviene utilizzare l'apposita opzione che si trova all'interno della finestra Internet Information Services piuttosto che fermare o riavviare i servizi manualmente dalla finestra Services.

Per maggiori informazioni su come impostare l'Administrative Web Site per potervi accedere da remoto, si può consultare la Knowledge Base: KB308169. Si osservi, infine, che di default l'Administrative Web Site non supporta connessioni ti tipo SSL, pertanto, senza predisporre le opportune modifiche, non si può accedere all'Administrative Web Site attraverso il protocollo HTTPS.

Comandi utili

Tramite il comando iisreset è possibile compiere le seguenti operazioni:

Altri comandi utili possono essere:

1.10 Installazione del Software

A differenza delle versione precedenti di Windows, con la versione Windows 2000 o superiori, sono stati previsti tre nuove entità per installare ed amministrare il software, ovvero:

Il Software Installation and Maintenance Technology è un sistema d'integrazione dell'installazione del software tramite il servizio Windows Installer che viene gestito tramite le Group Policy.

I programmi che possono venire installati col servizio Windows Installer hanno estensione .msi e vanno a sostituire i vecchi file Setup.exe. I vantaggi offerti dal servizio Windows Installer sono:

Il servizio Windows Installer è composto dalle seguenti parti logiche:

Il servizio Windows Installer gode della proprietà di autoripararazione, ovvero se si accorge che alcuni file che facevano parte dell'applicazione installata col pacchetto msi non sono presenti, procedere in modo automatico a reinstallarli.

Per avere maggiori informazioni sulla capacità di gestione del software offerte da Windows 2000, si può consaultare il documento Improving Software Management. Il documento descrive in modo abbastanza dettagliato tutti gli strumenti che Windows 2000 mette a disposizione degli amministratori di rete per rilasciare, gestire ed eliminare il software all'interno di una rete aziendale. In particolare vengono descritti casi reali pratici e qual'è il modo migliore per affrontarli. Può tornare utile anche la lettura del documento Useful Tools for Package and Deployment Issues.

Assegnazione del Software

Ci sono due modi possibili di assegnare un pacchetto MSI:

Il pacchetto MSI può poi venire assegnato o ad un utente o ad un computer, più precisamente:

In alternativa ai pacchetti MSI si possono utilizzare i file Zero Administration for Windows (ZAW) down-level Application Package (sono normali file di testo ASCII con estensione ZAP), i quali consentono di continuare ad utilizzare i normali file Setup.exe per eseguire le installazioni. Compito dei file ZAP è quello di guidare l'installazione di un programma. All'interno dei file ZAP sono contenute le seguenti informazioni:

Per avere informazioni su come realizzare un file ZAP, si può consultare la Knowledge Base KB231747.

Come creare un pacchetto MSI

Esistono tre metodi possibili per creare un pacchetto msi:

Più in genrale, per creare un pacchetto MSI si deve ricorrere ad un tool appossito che partendo dal programma eseguibile ne ricavi il pacchetto MSI.

Contenuto di un pacchetto MSI

Di default un pacchetto MSI contiene le seguenti informazioni:

Pianificazione per la distribuzione del Software

Per distribuire uno o più programmi all'interno di una infrastruttura aziendale, sono necessari i seguenti passi:

Come rilasciare un pacchetto MSI

Prima di poter distribuire un pacchetto MSI, bisogna creare un Software Distribution Point, ovvero una cartella di rete condivisa avente diritti e proprietà particolari:

Quando si provvede a copiare il software da distribuire all'interno della cartella che costituisce il Software Distribution Point, conviene tenere presente che molti programmi prevedono oppurtuni switch da riga di comando in grado di realizzare la cartella dalla quale venire poi distribuiti all'interno della rete.

Di seguito esponiamo i passi da compiere per rilasciare un pacchetto MSI ad un utente, Organization Unit o ad un computer:

Se si desidera modificare il comportamento di default di un pacchetto MSI, bisogna creare tanti file MST quante sono le modifiche d'apportare. I file MST prendono anche il nome di trasform. Le modifiche vanno applicate al pacchetto MSI che si desidera rilasciare, prima che questi venga messo in distribuzione tramite Group Policy Object. Per applicare le modifiche contenute nei file MST basta procedere come segue:

  1. Aprire la Group Policy Snap-In.
  2. O nella sezione Computer Configuration o nella sezione User Configuration aprire la voce Software Settings.
  3. Cliccare col pulsante destro del mouse sopra Software Installation, selezionare poi New ed infine Package.
  4. Nel campo File Name nella finestra Open, inserire il nome del pacchetto MSI che si desidera pubblicare. Premere il pulsante Open per confermare la selezione del file.
  5. Nella finestra Deploy Software selezionare la voce Advanced Published Or Assigned. Premere OK per confermare.
  6. Nella finestra contenente le Properties del pacchetto, andare nella sezione Modifications.
  7. Tramite il pulsante Add si possono aggiungere i file MST contenenti le modifiche d'apportare al pacchetto MSI. I file MST vengono eseguiti dall'alto verso il basso, nell'ordine con cui compaiono nella finestra Modifications.
  8. Per cancellare un file MST dalla lista si può utilizzare il comando Remove.
  9. Per modificare l'ordine con cui i file MST sono elencati all'interno della finestra Modifications, si possono utilizzare i pulsanti Move Up e Move Down.

Come abbiamo visto, quando si distribuisce un pacchetto MSI, risulta possibile specificare:

Per poter specificare queste informazioni bisogna prima arricchire le informazioni contenute nella sezione Software Installation. Per aggiungere queste informazioni basta procedere come indicato di seguito:

  1. Aprire il Group Policy Snap-In.
  2. O nella sezione Computer Configuration o nella sezione User Configuration aprire la voce Software Settings.
  3. Cliccare col pulsante destro del mouse sopra Software Installation, selezionare poi Properties.
  4. Nella sezione File Extensions si possono specificare a quali estensioni di file devono corrispondere gli applicativi contenuti nei pacchetto MSI.
  5. Nella sezione Categories si possono specificare le categorie a cui le applicazioni contenute nel pacchetto MSI devono rimanere associate. Si ricordi che le categorie qui definiti varranno per l'intero dominio di Active Directory: non risulta possibile definire categorie per Oraganizational Unit.
  6. Quando terminato d'inserire tutti i dati, premere il pulsante OK per confermare e uscire.

Come applicare una patch ad un pacchetto MSI

Talvolta, all'interno del ciclo di vita di un pacchetto MSI, si rende necessario applicarvi delle patch, ovvero degli aggiornamenti in grado di mettere a posto delle lacune del programma presente all'interno del pacchetto MSI. Le patch di un pacchetto MSI sono contenute all'interno di un file avente estensione MSP. Per applicare questi pacchetti patch ad un pacchetto MSI si deve utilizzare un apposito programma chiamato MSIExec.exe. La sintassi con cui eseguire il programma è la seguente:

msiexec /a <NomePacchetto.msi> /p <NomePacchetto.msp>

Una volta aggiornato il pacchetto MSI bisogna provvedere a ridistribuirlo utilizzando la sua Group Policy Object originaria, se questa è attiva, altrimenti si dovrà provvedere a metterne in piedi un'altra. Per maggiori informazioni si può consultare la Knowledge Base: KB226936. Per maggiori informazioni sul comando MSIExec.exe si può consultare la Knowledge Base: KB227091.

Come distribuire una nuova versione di un pacchetto MSI

Nel corso della vita di un applicativo, si può presentare il momento dell'uscita di una sua nuova versione. Per poter aggiornare un'applicativo, precedentemente distribuito tramite Group Policy Object, con un altro pacchetto MSI contenente la nuova versione del pacchetto, bisogna procedere come riportato di seguito:

Rimozione del Software

Si possono rimuove, tramite Group Policy Object, solamente quelle applicazioni che sono state installate utilizzando il servizio Windows Installer. Esistono due metodi per rimuovere le applicazioni installate:

Per mettere in pratica uno o l'altro dei due scenari sopra citati, si deve procedere nel seguente modo:

  1. Aprire la Group Policy Snap-In. Entrare o nella sezione Computer Configuration o in quella User Configuration.
  2. Aprire la voce Software Settings ed entrare nella sezione Software Installation.
  3. Cliccare col pulsante destro del mouse sul pacchetto MSI che si desidera rimuovere. Dal menu selezionare la voce All Tasks e poi cliccare su Remove.
  4. All'interno della finestra Remove Software selezionare una delle seguenti voci:
    • Immediately Uninstall the Software from Users and Computers. Selezionare questa opzione per indicare che l'applicazione venga rimossa la prossima volta che un utente fa log on o riavvia la macchina.
    • Allow Users to Continue to use the Software, but Prevent New Installation. Selezionare questa opzione per consentire agli utenti di continuare ad usare l'applicazione. Se gli utenti non hanno mai installato l'applicazione oppure la hanno rimossa, allora non avranno più l'opportunità di tornarla ad installare.
  5. Premere il pulsante Ok per confermare le scelte effettuate.

Comandi Utili

Il comando più utile nella gestione dei pacchetti MSI è il comando MSIExec.exe. Per maggiori informazioni sulle opzioni disponibili per questo comando si può consultare la Knowledge Base: KB227091.

1.11 Remote Installation Services

Il servizio Remote Installation Services, o più brevemente RIS, permette la distribuzione all'interno di una rete ben organizzata (chiariremo meglio il concetto di rete ben organizzata nei paragrafi successivi), d'immaggini o d'installazioni automatiche di Windwos 2000 Professional. Il RIS permette di automatizzare e distribuire solamente immagini o installazioni automatiche di Windows 2000. A differenza delle installazioni remote che si basano sul lancio del comando WinNT.exe, le installazioni via RIS non richiedono la conoscenza dell'ubicazione dei file d'installazione o la conoscenza dei parametri d'installazione. L'installazione avviene in modo del tutto automatico.

Requisiti per Attivare RIS

Il RIS può venire instalalto solamente sui Server che appartengono ad un dominio Active Directory. In particolare può venire installato sui server che svolgono il ruolo di Domain Controler. Il servizio RIS può venire tranquillamente installato ricorrendo alla sezione del Control Panel chiamata Add/Remove Programs, cliccando sul pulsante Add/Remove Windows Components e selezionando infine Remote Installation Services. Una volta installato, per poter funzionare, il RIS ha bisogno dei seguenti servizi di rete:

Dal punto di vista logico l'architettura su cui si basa il RIS prevede la presenza di:

Caratteristiche di un RIS Server

Un server di un dominio di Active Directory può aspirare a diventare un RIS Server solamente se sono soddisfatti alcuni vincoli hardware. In particolare il server deve garatire uno spazio disco adeguato alle immagini che utilizza il servizio RIS durante le sue installazioni automatiche. Ovvero:

La partizione che non svolge il ruolo di Boot Partition e di System Partition, è quella che ospiterà le immagini che utilizzerà il servizio RIS durante le sue installazioni automatiche. Questa partizione, che per brevità chiameremo Images Partition, dovrà ospitare tante immagini quante sono le tipologie d'installazione che dovrà svolgere il RIS Server. La restante partizione ospiterà il sistema operativo del server, che potrà essere Windows 2000 Server, Windows 2000 Advanced Server o Windows 2000 Data Center.

La Cartella in cui verrano inserite le immagini utilizzate dal RIS dovrà presentare le seguenti caratteristiche:

Attivazione di un RIS Server

Una volta installato il servizio RIS, questi non è ancora attivo, ovvero non è in grado di erogare alcun servizio. Per attivare il servizio RIS bisogna:

Configurazione del Servizio RIS

Per configurare il servizio RIS, Windows 2000 mette a disposizione un como wizard chiamato Remote Installation Service Setup Wizard. Per lanciare questo wizard è sufficiente eseguire il comando RISetup.exe. Per configurare il servizio RIS bisogna impostare le seguenti sezioni del wizard:

Una volta che il servizio RIS è stato configurato si può procedere con l'autorizzazione del RIS Server.

Autorizzazione di RIS Server

Affinchè un RIS Server possa erogare il suo servizio ai RIS Client, questi deve venire preventivamente autorizzato in Active Directory. Per autorizzare un RIS Server ci vuole un utente che appartenga al gruppo degli Enterprise Admins. La procedura da seguire è identica a quelle che s'impiega per autorizzare un DHCP Server (per maggiori informazioni si veda il paragrafo Autorizzare un server DHCP).

1.12 Service Pack

Le Service Pack sono una collezzione di hotfix che eliminano delle vulnerabilità intrinseche nel codice del sistema operativo. A differenza delle Service Pack di Windows NT quelle di Windows 2000 installano tutti i file aggiornati di modo che, se si decide d'installare un componente di Windows aggiuntivo, come ad esempio Internet Information Server, questi viene installato utilizzando tutti i file aggiornati dalla Service Pack relativi ad IIS.

Come funziona una Service Pack

Le Service Pack possono venire installate ricorrendo al comando Update.exe. Il compito di questo comando è quello di:

Per applicare una Service pack è necessario avere a disposizione una certa quantità di spazio disco:

Pertanto, aseconda che si decida di archiviare o meno i file che verranno rimpiazzati dalla Service Pack, lo spazio richiesto per installare la Service Pack va da un minimo di 280MB ad un massimo di 835MB circa.

Il comando Update.exe

Per installare una Service Pack si deve utilizzare il comando Update.exe. Questo comando consente le seguenti opzioni:

Se si utilizzano contemporaneamente gli switch -u e -q, il comportamento del file Update.exe è quello di non aggiornare i file OEM, se si desidera pertanto aggiornare anche questi file, bisogna utilizzare anche lo switch -o.

Per installazione integrata s'intende un'installazione del Sistema Operativo in cui la cartella i386 è stata aggiornata con la Service Pack.

Come integrare una Service Pack all'interno della cartella i386

Se non si dispone di una cartella i386 integrata con l'ultima Service Pack di Windows 2000, se ne può creare una a patto di possedere una cartella i386 originale o già integrata con service pack precedenti. L'operazione d'integrazione di una cartella i386 con l'ultima Service Pack, prende il nome di Slipstreaming. Per realizzare questa cartella i386 basta procedere come indicato di seguito (nel corso della spiegazione che segue supporremo che la cartella i386 da integrare sia all'interno del seguente percorso C:\Install\i386):

La cartella i386 appena creata contiene tutte gli aggiornamenti riguardanti la service pack. È possibile avere ulteriori informazioni andando a leggere il documento Windows 2000 Service Pack X Installation and Deployment Guide (dove X indica la versione della service pack).

Come eseguire l'installazione di una Service Pack via GPO

La Microsoft, nel rilasciare le varie Service Pack di Windows 2000 (o superiori) mette a disposizione degli amministratori del sistema anche un pacchetto MSI che consente la distribuzione delle Service Pack via Group Policy Object. Per distribuire una Service Pack tramite Group Policy Object si può procedere come segue:

A questo punto non resta che testare l'efficacia della distribuzione della Service Pack via GPO eseguendo alcune installazioni di prova. Una volta concluso che non ci sono problemi si può procedere con la distribuzione su tutte le macchine del dominio di Active Direcotry della nuova Service Pack.

Disinstallare una Service Pack

Per disinstallare una Service Pack si può utilizare uno degli strumenti seguenti:

Una Service Pack non può venire disinstallata quando:

Se si tenta di disinstallare la Service Pack dopo che si è deciso d'installare ulteriori componenti di Windows o programmi successivamente all'applicazione della Service Pack, si rischia di compromettere il corretto funzionamento di questi componenti e programmi.

1.13 Auditing e Sicurezza

Per avere informazioni sulle più recenti vulnerabilità e virus, consultare il sito del CERT. Per avere informazioni su come analizzare le impostazioni locali sulla sicurezza di un computer si può consultare la Knowledge Base: KB313203. Per sapere quali fix applicare per mettere a posto i bug di Windows 2000, si può utilizzare il tool Microsoft Baseline Security Analyzer (MBSA), per avere maggiori informazioni su questo tool si può consultare la Knowledge Base KB303215.

Event Viewer

All'interno dell'Event Viewer si possono avere le seguenti sezioni:

Le sezioni Application log, Security log e System log costituiscono le sezione di default che si ottengono quando s'installa Windows 2000. Le sezioni Directory Service log e File Replication Services log vengono create quando si promuove un server Windows 2000 a Domain Server. La sezione DNS server log viene creata un server Windows 2000 diventa un Name Server.

Gli eventi registrati nelle sezioni Application e System possono essere visti da tutti gli utenti. Un evento è composto da tre sezioni:

Windows File Protection

Nativamente Windows 2000 server e Professional, insieme a Windows XP Professional, hanno un sistema di protezione dei file di sistema (ad esempio i file con estensione *.exe, *.ocx, *.sys e *.dll) che li mette al riparo da eventuali manipolazioni, alterazioni, modifiche o sostituzioni. Questo sistema di protezione, denominato Windows File Protection (WFP) viene gestito in automatico dal sistemo operativo ed è attivo di default. Dal punto di vista amministrativo, il WFP mette a disposizione due tool che si prefiggono i seguenti obiettivi:

Il primo obbietto viene raggiunto facendo uso del comando Sfc.exe, dove l'acronimo SFC sta per System File Checker. In seguito ad un bug in Windows 2000, il comando Sfc.exe può venire lanciato in modo estemporaneo solamente se si provveduto in precedenza ad installare la Service Pack 4, altrimenti tutti gli aggiornamenti introdotti dalle HotFix applicate vengono persi all'atto dell'esecuzione del comando Sfc.exe /scannow; per maggiori informazioni si può consultare la Knowledge Base KB814510. Per un corretto funzionamento il comando Sfc.exe va lanciato direttamente sulla macchina di cui si desidera aggironare la cache di sistema. La cache dei file di sistema viene conservata, di default, all'interno della cartella %systemroot%\system32\dllcache. L'utilizzo del comando Sfc.exe prevede la presenza di una fonte dati sicura per aggiornare la cache dei file di sistema (ovvero la cartella %systemroot%\system32\dllcache), come ad esempio il cdrom originale del sistema operativo oppure quello dell'ultima Service Pack installata. Il comando Sfc.exe presenta le seguenti opzioni:

Il secondo obiettivo può essere raggiunto utilizzando il comando SigVerif.exe. Se si seleziona l'opzione Look For Other Files That Are Not Digitally Signed allora si possono controllare anche file che non fanno parte dei file di sistema.

Per aggiornare i file di sistema sono possibili solamente i seguenti metodi:

Questi metodi provvedono ad aggiornare in modo automatico la cartella DLLCache con la versioni aggiornata dei file di sistema installati. Se si utilizzano metodi diversi da quelli indicati, il WFP provvede a mantenere inalterati i file di sistema, cioè se per qualche motivo uno o più file di sistema vengono sostituiti o cancellati, il WFP provvede a ripristinare la versione di tali file indicata all'interno della cartella DLLCache.

Il comando SecEdit.exe permette invece d'impostare, configurare ed analizzare i templete di sicurezza (Security Template) dalla riga di comando.

Auditing

Sebbene non impostati di default, i sistemi Windows 2000 e superiori mettono a disposizione degli amministratori di rete, tutta una serie di opzioni per monitorare le varie attività che possono essere svolte su di un server. In particolare conviene monitorare i seguenti eventi:

Più in generale, i Group Policy Object consentono di monitorare i seguenti eventi:

Gli eventi di auditing vengono registrati nel Security Log della macchina in cui gli eventi sono stati generati. I Group Policy Object che gesticono gli eventi di auditing devono venire applicate direttamente ai server in cui si trovano gli oggetti che s'intende monitorare. Le policy di auditing, infatti, non si applicano agli utenti bensì ai computer. Conviene, quindi, creare delle Organizational Unit in cui raggruppare tutti i server da monitorare e applicare i Group Policy Object a queste Organizational Unit.

In generale, quando si decide di attivare una auditing policy, conviene tenere sempre ben presente le seguenti regole:

Per avere informazioni sulle impostazioni relative alla sicurezza che sono state realizzate su una macchina, si può consultare la Knowledge Base: KB318711.

Per maggiori informazioni sugli eventi riguardanti la sicurezza che vengono registrati nel Security Log del Event Viewer, si possono consultare i seguenti documenti: Windows 2000 Security Event Descriptions (Part 1 of 2) e Windows 2000 Security Event Descriptions (Part 2 of 2)

Permessi per creare un Audit Policy

Per poter creare una Audit Policy bisogna godere dei seguenti privilegi:

Come creare un Audit Policy

Per creare un Audit Policy bisogna:

Se il computer non è un Domain Controller:

In alternativa a questo metodo, si può creare un Group Policy Object da applicare alla Organizational Unit a cui appartiene il computer. In questo modo tutti i computer che appartengono alla stessa Organizational Unit riceveranno le medesime impostazioni di auditing.

Per abilitare il monitoraggio di file e cartelle:

Per monitorare un oggetto di Active Directory:

Parametri per il controllo dei Logon

La lettura dei log di logon e logoff consente di ottenere un gran numero di informazioni quando si utilizza IIS, SQL Server e COM+. La categoria degli eventi elencati è la stessa sia per Windows NT sia per Windows 2000. Gli eventi principali da monitorare sono:

Gli eventi 529, 528, 539 possono venire registrati o sul computer locale in cui si è tentato in logon, oppure su di un qualunque network resource server di cui si è tantato di condividere una risorsa, oppure su un Domain Controller. Gli eventi 675, 676, 677, in quanto sono legati al processi di failed authentication vengono registrati solamente in un Domain Controller.

Per poter registrare l'evento 513 bisogna abilitare l'auditing dei System Events.

Agli eventi 578 possono essere legati al Change of Ownership se all'interno dei dettagli degli eventi compare:

All'interno dei log relativi agli event viwer legati ai processi di Logon e Logoff, sono presenti alcune parole chiave che consentono d'inquadrare meglio la natura del Logon e del Logoff. In particolare:

Per maggiori informazioni sugli eventi riguardanti la sicurezza che vengono registrati nel Security Log del Event Viewer, si possono consultare i seguenti documenti: Windows 2000 Security Event Descriptions (Part 1 of 2) e Windows 2000 Security Event Descriptions (Part 2 of 2)

System Monitor

Sebbene il System Monitor sia uno strumento per tracciare l'utilizzo delle risorse di sistema, può venire anche utilizzato per monitorare alcuni aspetti legati alla sicurezza. In particolare tornano utili le seguenti informazioni:

Strumenti di gestione delle ACL

Il Windows 2000 Server Resource Kit mette a disposizone alcuni utili tool dalla linea di comando in grado di manipolare le ACL presenti sul file system. In particolare:

1.14 Kerberos

Sino a Windows NT l'unico protocollo supportato dalla Microsoft per gestire l'autenticazione degli utenti era NTLM. Questo protocollo, però presenta alcune limitazioni che col tempo si sono rivelate assai fastidiose:

Per tutte queste ragioni, a partire da Windows 2000 la Microsoft ha deciso di adottare Kerberos come protocollo di autenticazione. Kerberos è un protocollo standard (RFC 1510) ampiamente supportato. Kerberos è composto, dal punto di vista logico, da tre componenti indipendenti:

Nell'impletazione Microsoft di Kerberos tutti i Domain Controller sono anche Key Distribution Center. Il processo di autenticazione di Kerberos è stato pensato per essere snello, sicuro, semplice ed efficace, il suo modo di lavorare è il seguente:

  1. L'utente inserisce il proprio UserName e la propria Password all'interno dei rispettivi campi della schermata di logon. Il Kerberos Client che risiede sulla macchina converte la Password in una chiave di criptatazione creando un one-way hash value.
  2. L'ora locale del client viene criptata con la chiave generata al punto precedente. Viene poi creata una Kerberos Authentication Service Request (KRB_AS_REQ) conetente:
    • Lo Username dell'utente.
    • La richiesta di una Ticket-Granting Ticket.
    • Lo Hash Value della Password.
    • L'ora locale criptata.
    Questo pacchetto d'informazioni viene inviato all'Authentication Service del Key Distribution Center (KDC).
  3. Il KDC utilizza lo Username e lo Hash Value della Password per individuare l'utente all'interno di Active Directory (o più in generale di un directory service). Grazie allo Hash Value della Password viene decritata l'ora locale del client e conforntata con l'ora corrente del KDC. Se la differenza temporale è entro i 5 minuti (questo valore può essere modificato a piacimento), il KDC ne conclude che la KRB_AS_REQ non è una ripetizione, accertato che le credenziali dell'utente sono presenti in Active Directory, il KDC procede a:
    • Generare una Session Key per eventuali future comunicazioni con l'utente.
    • Criptare la Session Key utilizzando lo Hash Value della Password dell'utente.
    • Criptare ulteriormente la Session Key sfruttando la propria chiave di criptazione.
    La Session Key così criptata prende il nome di Ticket-Granting Ticket (TGT). Il TGT viene quindi inviato al client. Questa procedura prende il nome di Kerberos Authentication Service Replay (KRB_AS_REP).

Una volta ottenuto un Ticket-Granting Ticket, il client può iniziare a dialogare con gli altri server della rete. Il processo con cui il client si autentica ad un server di rete è il seguente:

  1. Il client invia un pacchetto al Ticket-Granting Service del KDC contenente:
    • Il TGT che aveva ottenuto in precedenza.
    • Il nome del server con cui vorrebbe dialogare.
    Questa richiesta del client prende il nome di Kerberos Ticket-Granting Service Request (KRB_TGS_REQ). Il pacchetto viene poi criptato con lo Hash Value della Password dell'utente.
  2. Il KDC decripta il pacchetto KRB_TGS_REQ utilizzando il TGT dell'utente (il quale contiene lo Hash Value della Password dell'utente) che era stato precedentemente criptato con la chiave di criptazione del KDC. Se la Session Key risulta corretta allora il KDC proceda a:
    • Generare una Session Key con cui l'utente può comunicare col server indicato nella KRB_TGS_REQ.
    • Criptare la Session Key utilizzando lo Hash Value della Password dell'utente.
    • Criptare ulteriormente la Session Key sfruttando la propria chiave di criptazione.
    Questo nuovo pacchetto costituisce un nuovo Ticket-Granting Ticket che il KDC invia al client, Kerberos Ticket-Granting Service Replay (KRB_TGS_REP).
  3. Ottenuto il nuovo TGT il client procede ad eseguire una Kerberos Application Request al server con cui voleva comunicare. La Kerberos Application Request (KRB_AP_REQ) consiste in un pacchetto contenete:
    • Lo Username dell'utente.
    • L'ora locale del client criptata con la Session Key generata dal KDC per l'occasione.
    • Il TGT fornito dal KDC per comunicare col server.
  4. Il server una volta ricevuta la Kerberos Application Request procede a decripare il pacchetto appena ricevuto ottenendo:
    • La Session Key con cui comunicare con l'utente.
    • Lo UserName dell'utente.
    • L'ora locale del client.
    Se l'ora locale del client differesce per meno di 5 minuti (è il tempo di default ma può essere cambiato) dall'ora locale del server, allora il server ritiene affidabile l'identità del client. Se il client ha chiesto al server la mutua autenticazione allora il server provvede a criptare la prorpia ora locale con la Session Key fornita dal client e a spedire il tutto al client. Questa operazione prende il nome di Kerbers Application Replay (KRB_AP_REP).
  5. Il client ricevuto il KRB_AP_REP provvede a decriptare il pacchetto utilizzando la Session Key che gli ha fornito il KDC per comunicare col server e se l'ora locale del server differisce per meno di 5 minuti dall'ora del client, vuol dire che il server è veramente colui con cui il client vuole dialogare. A questo punto la comunicazione fra il server ed il client può avere luogo.

Si osservi che in tutto questo meccanismo sia il client, sia il server non devono ricordarsi nulla l'uno dell'altro, inoltre il server non deve mai contattare il KDC per autenticare il client. I vari TGT che il client tende ad accumulare vengono conservati dal client per un certo periodo di tempo e poi vengono distrutti. Il KDC non si preoccupa minimamente di gestire questo tipo di procedure e lascia al client completa autonomia sulla gestione dei sui TGT. Per comodità l'Hash Value della Password dell'utente viene conservato in memoria, ma se per qualche motivo dovesse venire perso, il server provvederà a richiedere di nuovo al client di autenticarsi utilizzando la sequenza:

  1. KRB_TGS_REQ
  2. KRB_TGS_REP
  3. KRB_AP_REQ
  4. KRB_AP_REP

© 2020 Home Works - all rights reserved
Questo sito ha superato il test W3C Validator HTML e CSS