Ricerche IT

Leggendo questo post di Andrea Beggi, e proseguendo la lettura dei relativi commenti, viene descritta una situazione in cui si ha una rete che esce verso Internet tramite un router, e contestualmente si ha una VPN con un’altra sede che esce tramite un router separato, per cui bisogna lavorare bene con l’instradamento del traffico, facendo in modo che il traffico verso la VPN non esca tramite il router Internet, ma tramite il router VPN. Andrea Beggi propone una soluzione che consiste nel creare una route statica sul default gateway della rete locale, che sia in grado di reinstradare il traffico verso la VPN in modo trasparente all’utente; il problema potrebbe porsi nel traffico dalla sede remota ad un host della rete locale e ritorno, se infatti l’host non ha una valida configurazione di routing, la sede remota potrebbe comunque non comunicare con gli host della rete locale. In realtà normalmente ciò non accade, poiché il router, una volta configurato, utilizza il meccanismo chiamato ICMP Redirect Message per mandare messaggi ICMP ai vari host con le informazioni necessarie ad aggiornare la tabella di routing degli host, informandoli sul percorso più corretto da seguire per raggiungere la sottorete corrispondente alla sede remota connessa in VPN.

Nei commenti al post di Andrea Beggi, c’è chi ha proposto soluzioni alternative per raggiungere lo stesso fine, tra cui mi ha colpito la tecnica di distribuire una (o più) route statiche ai client della rete locale tramite server DHCP; il motivo principale per cui mi ha colpito è che ignoravo quest’opzione di DHCP. Al momento ho testato la soluzione solamente su un server Windows Server 2003 R2 SP1 e su un client Windows XP Professional SP2, e devo dire funziona senza problemi. In sostanza, l’obiettivo che vogliamo ottenere è fare in modo che i client della rete 172.16.1.0/24 possano raggiungere la rete 192.168.1.0/24 tramite il router 172.16.1.253; per raggiungere lo scopo, è necessario configurare nelle opzioni dell’ambito DHCP precedentemente configurato l’opzione “249 Classless Static Routes”, in cui indicare (tramite il tasto Add Route) la rete di destinazione, la subnet mask e il router tramite il quale raggiungere la sottorete in questione, come visibile dalla figura 1:

Fatto questo, dare conferma, riavviare il servizio DHCP e infine verificare che la distribuzione delle route statiche avvenga correttamente. Tenere presente che esiste un’altra opzione di DHCP che si occupa di distribuire route statiche ai client, la “033 Static Route Option”, che però non è applicabile nella nostra situazione, in quanto con questa route è possibile specificare solamente un host come destinazione e non un’intera sottorete.

Quando si gestisce un sistema informativo, bisogna fare in modo che questo sia protetto da attacchi più o meno subdoli. Una delle precauzioni principali da prendere riguarda la gestione delle credenziali d’accesso al sistema, che devono rispondere a specifici criteri di sicurezza che prevengano accessi non autorizzati, in ottemperanza alle elementari regole di sicurezza informatica ed al D. Lgs. 196 del 2003 conosciuto anche come "Testo Unico sulla Privacy". Pur esistendo dispositivi che permettono di fornire le proprie credenziali in modo sicuro, come ad esempio smart card e dispositivi biometrici, in realtà il metodo più usato consiste ancora nel fornire un’accoppiata Nome Utente - Password come credenziali d’accesso al sistema informativo. In particolare, è centrale il problema di come gestire le password associate ad ogni account, che rappresentano il punto debole e maggiormente attaccabile da parte di un malintenzionato, per cui è necessario prendere alcuni accorgimenti nella scelta e gestione delle password:

• segretezza della password: la password deve essere segreta, e nota solamente al legittimo utilizzatore di quelle determinate credenziali d’accesso ed al responsabile delle password, inoltre, l’utente non deve lasciare in giro appunti o post-it con in bella mostra la propria password, come troppo spesso succede;
• lunghezza della password: se un ipotetico "attaccante" cerca di scoprire la password di un utente tramite "tentativi" automatizzati (il cosidetto attacco a forza bruta), l’attacco avrà maggior successo se la password attaccata è breve, a differenza di una password lunga che, ovviamente, per essere indovinata necessita di un maggior numero di tentativi;
• complessità della password: l’utente, scegliendo una password, dovrà fare in modo che questa non contenga riferimenti a sé stesso o all’ambito familiare, infatti un malintenzionato, utilizzando eventualmente tecniche di ingegneria sociale, potrà scoprire riferimenti della vita privata dell’utente che riutilizzerà immediatamente come tentativo di accesso non autorizzato, se poi l’attaccante è un nostro collega di lavoro (cosa possibile anche se non frequente) non dovrà sforzarsi molto per conoscere particolari che ci riguardano; altro accorgimento in questo senso può essere quello di utilizzare caratteri non standard (come segni di interpunzione o spazi) nella composizione della password, misura utile anche nei casi di attacchi "brute force";
• durata della password: una password, per essere considerata sicura, dev’essere cambiata entro un periodo di tempo ragionevole, ciò rende la vita più difficile ad un malintenzionato che intende "rubare" la password, inoltre consente di "richiudere fuori" un attaccante venuto in possesso delle nostre credenziali, anche se in questo caso probabilmente il danno è già stato fatto

Considerata l’importanza di queste politiche di protezione, non si può delegarne l’osservanza alla buona volontà dell’utente finale, dev’essere l’amministratore di sistema ad imporre queste policy a livello centralizzato, in modo tale che l’utente possa solamente trovarsi a scegliere se autenticarsi sul sistema informativo secondo le regole impostate dal sysadmin o se mollare tutto e passare la giornata al bar.
Per quanto concerne una piattaforma Windows Server, in un dominio Active Directory è possibile definire e imporre una policy delle password valida a livello dell’intero dominio. Per definire i criteri relativi alle password, aprire la console "Active Directory Users and Computers", portarsi alla radice del dominio e quindi cliccare col tasto destro e scegliere la voce Properties, quindi andare sulla scheda "Group Policy", comparirà una finestra simile a quella mostrata nella figura sottostante (i passaggi saranno diversi se si utilizza lo snap-in di Group Policy Management, ma il punto d’arrivo è il medesimo):

Si può vedere che esiste già un criterio di gruppo per il dominio (Default Domain Policy), che però non sarà quello che andremo a modificare, poiché Microsoft consiglia di non utilizzare il criterio predifinito per queste operazioni, ma di creare un nuovo criterio di gruppo e modificare quello, per cui, tramite il pulsante New, creare un nuovo criterio di gruppo a cui assegnare il nome "Password Policy", quindi modificare il criterio appena creato cliccando il tasto Edit, che farà comparire l’editor del criterio di gruppo prescelto; i parametri che ci interessano sono quelli definiti in "Computer Configuration" - "Windows Settings", come mostrato nella seguente immagine:

In particolare, dovremo far riferimento, inizialmente, alla sezione "Security Settings" - "Account Policies", e lì scegliere la voce "Password Policy", in cui andranno impostate le seguenti opzioni:

• Enforce password history: serve per definire il numero di password "ricordate" dal server, ciò significa che prima di poter riutilizzare una password bisogna cambiare password (la quale ovviamente sarà sempre diversa) almeno x volte, dove per x si intende il valore impostato per questo parametro, che nella maggior parte dei casi secondo me può essere uguale a 10
• Maximum password age: indica il numero di giorni di validità della password, passato questo periodo, verrà imposto il cambio di password, pena l’impedimento all’accesso sul client da parte dell’utente finale; il valore consigliato non deve superare i 90 giorni, che è il limite massimo consentito dal Testo unico sulla privacy in caso di trattamento di dati sensibili, mentre Microsoft consiglia di non superare i 42 giorni di validità della password, che è anche l’impostazione predefinita in caso di attivazione di questa password policy
• Minimum password age: questa policy viene automaticamente attivata quando si attiva l’impostazione "Maximum password age" mettendo come impostazione predefinita 30 giorni; in realtà, questo settaggio consente di specificare la validità minima della password, cioé il numero minimo di giorni in cui non è consentito un cambio della password a partire dalla data di creazione della stessa, quindi è bene specificare un valore più basso per consentire un più tempestivo cambio della password che si può rendere necessario per diversi motivi, infatti Microsoft consiglia di impostare questo valore a 2
• Minimum password length: definisce la lunghezza minima della password intesa come numero di caratteri; secondo il Testo Unico sulla Privacy la lunghezza minima della password deve essere di otto caratteri, per cui ci possiamo attenere a questa prescrizione, in modo tale che l’utente non possa utilizzare password più corte di otto caratteri, ovviamente nessuno vieta di utilizzare password composte da più di 8 caratteri
• Password must meet complexity requirements: impostazione che obbliga l’utente ad immettere password utilizzando criteri di complessità in grado di rendere una password "sicura": in particolare, la password deve essere lunga almeno sei caratteri (precauzione superata dagli 8 caratteri specificati nel parametro "Minimum password length"), non deve contenere tre o più caratteri che fanno parte del nome utente, e deve includere almeno tre di cinque categorie di caratteri:
  • lettere dalla A alla Z maiuscole
  • lettere dalla a alla z minuscole
  • cifre comprese tra 0 e 9
  • segni di interpunzione e caratteri non alfanumerici (virgola, punto e virgola, $, %, ecc…)
  • caratteri unicode (simboli)

L’impostazione di queste opzioni consente di definire dei criteri di protezione validi per tutto il dominio, per cui, ogni utente che si autentica sul dominio, sarà "costretto" a seguire queste regole, ciò fa sì che, almeno da questo punto di vista, non ci siano utenti che mettono a rischio la sicurezza del sistema informativo semplicemente facendosi da sé le regole di accesso al sistema. Di importanza fondamentale rimane però la sensibilizzazione degli utenti riguardo queste tematiche, troppo spesso accade che l’utente finale comunichi le proprie credenziali ai colleghi con motivazioni del tipo "non ho nulla da nascondere", così come altrettanto spesso si vedono post-it appiccicati al monitor con in bella evidenza la propria password; ciò accade perché gli utenti non hanno ben chiaro che vanno protette non (solo) le informazioni personali, ma i dati personali o sensibili di terzi che si trattano col lavoro di tutti i giorni.

Link di riferimento: applicazione dell’utilizzo di password complesse nell’organizzazione

Quando si fa un backup su Windows Server 2003 utilizzando l’utilità integrata (ntbackup), può capitare che per qualche motivo non venga eseguito il backup; le cause possono essere varie, ed a questo proposito è bene controllare il log di ntbackup, che di solito descrive, seppur in modo striminzito, le ragioni del mancato salvataggio. Se il log dà un responso simile a questo:

Backup Status
The requested media failed to mount. The operation was aborted.

e nel log degli eventi compare un evento con Id 168 e l’origine Removable Storage Service, ciò significa che per qualche ragione il servizio Removable Storage non riesce a comunicare con l’unità di backup. In questo caso, una possibile soluzione consiste nel disinstallare da Gestione periferiche (Device manager) l’unità di backup e nel successivo riavvio del server, in modo tale che Windows reinstalli l’unità di backup appena disinstallata; fatto questo, se tutto va bene avremo di nuovo il nostro backup funzionante.

SQL Server 2005 Express è il database gratuito di Microsoft appartenente alla serie SQL Server 2005, e si pone quindi come successore di MSDE, il database rilasciato gratuitamente da Microsoft fino alla serie SQL Server 2000. Questa versione di SQL è liberamente scaricabile dal sito Microsoft e richiede il framework .NET 2.0, altrimenti non si installa.

Il grosso limite di SQL Express è che non ha un’interfaccia visuale di gestione, per cui andrà gestito da linea di comando (a meno di non avere un’altra installazione di SQL Server attiva sulla rete o di altri tool che al momento non conosco), ma soprattutto, in modo predefinito, SQL Express non accetta connessioni da altri host.

Per permettere a SQL Express di accettare connessioni da altri host, è necessario per prima cosa aprire il tool di configurazione di SQL Express che prende il nome di SQL Configuration Manager, quindi da lì andare in "SQL Server 2005 Network Configuration", poi su "Protocols for SQLEXPRESS", quindi abilitare il protocollo TCP/IP. Fatto questo, andare nel registro di configurazione e impostare il valore HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90\SQL Browser\Ssrplistener a 1, dopodiché bisogna abilitare l’avvio automatico del servizio "SQL Server Browser", poi bisogna avviarlo ed infine riavviare il servizio "SQL Server (SQLEXPRESS). Ora, oltre a rendere possibile l’accesso ad altri host, è possibile anche amministrare la nostra installazione di SQL col tool da riga di comando SQLCMD, tramite il comando:

sqlcmd -E -S nomeserverSQL\nomeistanzaSQL,1434

dove per nomeserverSQL si intende il nome host del PC su cui è installato SQL Express, per nomeistanzaSQL si intende il nome che si è dato all’istanza in fase d’installazione (il nome dell’istanza predefinita è MSSQL$EXPRESS) e per 1434 si intende la porta TCP su cui risponde SQL Express.

A questo punto, è abbastanza probabile che si vogliano riutilizzare database utilizzati in precedenza con SQL Server 2000 o con MSDE; se abbiamo i file del database (.mdf e .ldf), è possibile metterli nella cartella predefinita in cui sono contenuti i database di sistema di SQL Express e quindi, tramite T-SQL, creare un nuovo database facendo un attach dei file già esistenti:

> CREATE DATABASE nuovoDB ON
> (FILENAME = ‘c:\program files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\nomefileDB.mdf’) FOR ATTACH;

in questo modo SQL Express crea il nuovo database agganciando i vecchi dati in nostro possesso, facendo una conversione nel nuovo formato se stiamo facendo l’attach di un database SQL Server 2000

E’ inoltre possibile che esistano applicazioni distribuite sulla rete locale che devono accedere al database SQL Express presente su un server, per cui in questo caso possono servire i driver nativi per accedere al database via ODBC o via OLE DB. Questi driver sono installati con un pacchetto messo a disposizione di Microsoft e chiamato "Microsoft SQL Server Native Client", scaricabile ovviamente dal sito Microsoft.

Per amministrare la nostra installazione di SQL Express 2005, è possibile anche scaricare ed installare SQL Server Management Studio Express, che altro non è che l’erede di Enterprise Manager, ovvero la console MMC di gestione visuale di SQL Server, in questo modo non siamo legati per forza all’amministrazione di SQL Express da riga di comando.

In una rete con un server di dominio Windows Server 2003 è indispensabile un corretto funzionamento del servizio DNS, onde evitare problemi nell’utilizzo dei servizi di autenticazione e dei normali servizi di rete erogati su una LAN, poiché Active Directory (da ora in poi AD) si basa su DNS per il proprio funzionamento, senza contare che la risoluzione dei nomi host dei PC in rete viene realizzata sempre tramite DNS. Per evitare di dover gestire a mano tutte le corrispondenze nome host -> indirizzo IP, il servizio DNS integrato in Windows Server 2003 supporta gli aggiornamenti dinamici dei record di risorse dell’host (A) - cioè dei record memorizzati nelle zone di ricerca diretta - e dei record di risorse del puntatore (PTR) - i record memorizzati nelle zone di ricerca inversa - da parte dei client della rete a partire da Windows 2000. In questo modo, quando avvengono dei cambi di nomi host o dei cambi di PC sulla rete locale, non è necessario cambiare a mano i record presenti sul server DNS, poiché gli aggiornamenti sono automatici.

Se nella rete abbiamo un server DHCP (come accade nella stragrande maggioranza delle reti, pratica comunque sempre condivisibile a mio parere), dobbiamo accertarci che questo supporti gli aggiornamenti dinamici dei record DNS, ovviamente, se usiamo il server DHCP integrato in Windows Server, non avremo problemi, visto che per impostazione predefinita, quando rilascia un lease ad un client, si occupa di aggiornare le zone diretta ed inversa del dominio AD coi corrispondenti record (A) e (PTR); a tal riguardo, bisogna fare attenzione a non avere attivo un server DHCP su altri dispositivi presenti in rete (come un router) che potrebbe creare conflitti con il server DHCP installato sul server, infatti in questi casi la cosa migliore è utilizzare l’accoppiata server DNS - server DHCP già presenti sul Windows Server 2003.

Quando un client cambia il proprio nome oppure quando viene registrato nel dominio, il servizio DHCP Client fa una query di tipo SOA al proprio server DNS primario, e se riceve una risposta affermativa, tenta di contattare il server DNS restituito come risultato dell’interrogazione per fornirgli un aggiornamento dinamico che includa il nuovo valore dell’accoppiata nome host -> indirizzo IP come record (A) e (PTR), ed inoltre, contestualmente e se necessario, rimuova la vecchia accoppiata nome host -> indirizzo IP dalla "forward zone" e dalla "reverse lookup zone" di AD.

Se in una rete è attivo un server DHCP su un controller di dominio, allora può essere lo stesso server DHCP a farsi carico di aggiornare dinamicamente il server DNS per conto dei client; ciò è indispensabile in quanto può succedere in qualsiasi momento che un server DHCP cambi l’assegnazione dell’indirizzo IP ad un client, ed è quindi di fondamentale importanza che vengano aggiornati i record (A) e (PTR) relativi al client sul server DNS, altrimenti la macchina non sarà contattabile in rete locale. Per forza di cose quindi il server DHCP di Windows Server 2003 è configurato per aggiornare dinamicamente il server DNS in modo predefinito, ma solamente per quei client che richiedono in modo predefinito l’aggiornamento dinamico, cioé che hanno come sistema operativo Windows 2000, Windows XP o Windows Server 2003 (e presumo anche Windows Vista). Come comportamento predefinito, quando un client riceve un lease dal server DHCP, il client cercherà di aggiornare il record di risorse dell’host (A), mentre il server DHCP tenterà di aggiornare il record di risorse del puntatore (PTR). Per controllare le impostazioni concernenti gli aggiornamenti dinamici da parte di client e server DHCP, cliccare col tasto destro sul server DHCP in MMC e andare su Properties, quindi cliccare sulla scheda DNS, comparirà una schermata come quella di figura 1.

Sempre parlando della configurazione predefinita dei server DNS e DHCP in Windows Server 2003, bisogna considerare che gli aggiornamenti dinamici del server DNS avvengono per default in modalità protetta per le zone integrate in AD, ciò significa che solamente i client ed i server facenti parte del dominio AD possono effettuare aggiornamenti dinamici sul server DNS. In questa situazione, è necessario creare un account utente di AD che verrà utilizzato dal servizio DHCP server per aggiornare dinamicamente il server DNS, ed impostarlo effettivamente per questo compito, andando sempre in console MMC di DHCP, quindi cliccando col tasto destro sul server, Properties, Advanced, cliccare sul pulsante Credentials, e comparirà la maschera mostrata in figura 2 dove inserire il nome utente dell’account di cui sopra, il dominio di appartenenza e la relativa password. Tenere presente inoltre che l’account dedicato va creato anche quando il servizio DHCP è attivo su un controller di dominio (situazione tipica presente su piccole reti) e quando è il servizio DHCP che registra gli aggiornamenti dinamici per conto dei client, in parole povere, questo account va impostato nelle situazioni più comuni di funzionamento di Windows Server 2003.

Se si utilizza Exchange come server di posta elettronica, la configurazione predefinita prevede un invio diretto dei messaggi di posta utilizzando il server DNS predefinito configurato sul server stesso per la risoluzione dei nomi di dominio e per l’interrogazione sul record MX del dominio del destinatario, quindi si connette direttamente ai server SMTP dei destinatari delle mail per il recapito dei messaggi. Ciò però non sempre è possibile, ad esempio perché un range di indirizzi è finito in una blacklist, quindi, per evitare questi problemi, ci si può appoggiare ad un server SMTP esterno alla nostra organizzazione per l’invio delle mail, che prende il nome di "smart host".

Per impostare uno smart host, su Exchange come su qualsiasi altro server di posta, dobbiamo considerare che in genere i provider consentono l’accesso al proprio server SMTP solo a quegli host che si connettono sulla loro rete, quindi è bene utilizzare il server SMTP del proprio provider, anche se alcuni provider richiedono anche informazioni di autenticazione sul server SMTP per poter inviare messaggi; Exchange prevede due metodi di configurazione di un server SMTP esterno: l’impostazione dello smart host sul server virtuale SMTP e la creazione di un connettore SMTP.

Per impostare uno smart host sul server SMTP virtuale andare su System Manager e fare il percorso Servers -> NomeServer -> Protocols -> SMTP -> tasto destro su Default SMTP Virtual Server, quindi cliccare su Properties, da lì andare sul tab Delivery e quindi andare sul pulsante Advanced e lì impostare l’indirizzo del server SMTP esterno nella casella "Smart host"; l’indirizzo da impostare può essere un normale indirizzo FQDN oppure un indirizzo IP compreso tra parentesi quadre (es. [1.1.1.1]), quindi una volta impostato cliccare su Ok per tornare alla schermata precedente. A questo punto, si può cliccare di nuovo su Ok se la configurazione è completata, oppure si deve cliccare sul pulsante "Outbound security" se bisogna inserire anche informazioni di autenticazione per poter inviare messaggi tramite il server SMTP esterno; in quest’ultimo caso, cliccare su "Basic autentication" ed inserire nome utente e password, quindi mettere un segno di spunta sulla voce "TLS encryption" se è necessario stabilire una connessione criptata con lo smart host. Ora non rimane che cliccare due volte su Ok, quindi basta riavviare il servizio SMTP per attivare le nuove impostazioni.

L’altro modo per configurare uno smart host consiste nella creazione di un connettore SMTP. Un connettore SMTP permette di stabilire la connessione tra il nostro server Exchange (o tra i diversi server Exchange della nostra organizzazione) e il mondo esterno, inoltre, un connettore SMTP ci dà anche la possibilità di utilizzarlo per inviare posta solamente verso certi domini, oltre a permettere di bilanciare il carico tra i diversi server Exchange presenti sulla nostra rete. Quando si crea un connettore SMTP bisogna, tra le altre cose, impostare la modalità di recapito della posta in uscita, cioè bisogna dire se spedire la posta direttamente utilizzando DNS per la risoluzione dei nomi oppure se utilizzare uno smart host, che è la situazione che interessa a noi. Per impostare lo smarthost, basta selezionare la voce "Forward all mail through this connector to the following smart hosts" e digitare il nome del server SMTP a cui inoltreremo la mail provenienti dalla nostra organizzazione; anche in questo caso, valgono le considerazione fatte in precedenza in merito all’eventuale autenticazione sul server SMTP smart host. Ora bisogna impostare almeno un server Exchange "bridgehead" (testa di ponte) responsabile dell’invio della posta tramite il connettore che si sta creando; se abbiamo un unico server Exchange nella nostra organizzazione, questo andrà impostato obbligatoriamente come server bridgehead. Ora rimane da impostare lo spazio degli indirizzi del connettore, cioè bisogna specificare se il connettore è responsabile dell’invio di messaggi per ogni dominio esistente o solamente per alcuni domini, quindi, andare sul tab "Address space", cliccare su Add e digitare * se si vogliono comprendere tutti i domini come indirizzi validi per il connettore (impostazione predefinita), dopodiché, poco più in basso, è possibile specificare l’ambito di validità del connettore (Connector scope), se non si ha un’organizzazione complessa lasciare l’impostazione di default "Entire organization".

Seguendo uno dei due metodi sopra esposti, è possibile utilizzare un server esterno alla nostra organizzazione per inviare messaggi di posta elettronica.

Dopo un’installazione di Exchange Server 2003, vanno create le relative cassette di posta, e qui la situazione dipende da cosa si è fatto prima di installare Exchange: se erano presenti già in precedenza utenti di Active Directory (AD), dopo aver installato Exchange bisogna creare una cassetta di posta per gli utenti già esistenti, mentre per tutti gli utenti AD creati successivamente all’installazione di Exchange, è necessario indicare in fase di creazione se associare o meno una nuova cassetta di posta all’utente.

In entrambi i casi, gli indirizzi di posta elettronica vengono assegnati automaticamente alla cassetta di posta seguendo un determinato criterio, definito nella "default policy" visualizzabile andando su System Manager -> Recipients -> Recipient Policies; il criterio predefinito corrisponde al dominio di Active Directory, per cui se ho un utente con alias "utente" ed ho un dominio AD con nome DNS "dominio.lan", l’indirizzo di posta creato in modo predefinito è "utente@dominio.lan". Questo tipo di indirizzamento ha solamente validità locale, e siccome di certo non installiamo Exchange solo per la comunicazione interna, è necessario cambiare la policy predefinita, aggiungendo una policy con una priorità più alta (cioé col numero più basso) oppure modificando direttamente la policy predefinita, in modo da avere indirizzi di posta con un dominio identico al dominio registrato dalla nostra società; inoltre, è possibile personalizzare la parte a sinistra dell’indirizzo e-mail utilizzando le variabili messe a disposizione da Exchange.

Per creare una nuova policy, andare su System Manager -> Recipients -> Recipient Policies e quindi cliccare sul menu Action -> New e quindi scegliere "Recipient policy", si aprirà una finestra di dialogo in cui dobbiamo indicare se la nuova policy riguarda gli indirizzi di posta elettronica (E-mail Addresses) o se riguarda la gestione delle cassette postali (Mailbox Manager Settings), in questo caso scegliamo la prima voce, E-mail Addresses, clicchiamo su Ok e comparirà la finestra in cui, per prima cosa, va inserito un nome per definire il criterio (in questo caso, chiameremo la policy "Dominio Aziendale"), quindi, cliccheremo sul pulsante "Modify" per creare un filtro che applichi la policy solo a determinati elementi presenti in Active Directory; la lista degli elementi a cui è possibile applicare è mostrata in figura 1:

Figura 1

Nella maggior parte dei casi, sarà sufficiente selezionare solamente "Users with Exchange mailbox", poiché difficilmente useremo la stessa policy per gli utenti e per i gruppi, più probabilmente gli utenti seguiranno un criterio ed i gruppi un altro criterio, quanto ai Contatti, è improbabile definire per essi una policy comune; da notare che, cliccando sulla scheda Advanced, è possibile creare dei filtri con criteri più stringenti per selezionare solamente, ad esempio, parte degli utenti con cassette di posta rispondenti a determinati criteri. Fatto questo, cliccare su Ok ed ancora su Ok al messaggio successivo, quindi andare sulla scheda "E-mail Addresses (Policy), cliccare sulla voce SMTP presente (corrispondente alla policy di default di Exchange) e cliccare sul pulsante "Edit" per modificare il criterio; a questo punto, è opportuno conoscere le variabili necessarie per comporre la nostra policy, che si baserà su nome e cognome dell’utente:

%g -> Given name -> Nome
%s -> Surname -> Cognome

Se ad esempio abbiamo il dominio dell’azienda che prende il nome di "nomeazienda.com" e vogliamo che gli indirizzi aziendali siano tutti del tipo "mario.rossi[at]nomeazienda.com", dovremo specificare la seguente policy:

%g.%s@nomeazienda.com

In realtà, molto spesso le aziende usano spesso indirizzi del tipo "m.rossi@nomeazienda.com", ed in questo caso, per avere il risultato voluto, nella policy bisogna scrivere questa stringa:

%1g.%s@nomeazienda.com

dove 1 indica che andrà preso per la variabile %g solamente il primo carattere, in questo caso l’iniziale del nome appunto (per ulteriori informazioni sulle variabili utilizzabili in questo contesto consultare la relativa pagina della Knowledge Base Microsoft). Una volta scritto il criterio, cliccare su Ok e quindi su Yes, e la policy è attiva. Gli indirizzi di posta verranno quindi modificati a seconda dell’intervallo di aggiornamento specificato in "Recipient Update Services" presente nella voce "Recipients" nella struttura generale di System Manager. E’ possibile specificare in seguito una ulteriore policy per i gruppi di distribuzione, ad esempio utilizzando le variabili %d (Display name) o %m (Alias Exchange dell’utente AD), così da avere due policy distinte per gruppi ed utenti.

Netshell è un utilità a riga di comando (richiamata dal file netsh.exe) che permette la visualizzazione e la modifica di diversi parametri relativi alla configurazione di rete del PC. Quest’utilità è presente da Windows 2000 in poi, ma i comandi seguenti sono testati esclusivamente su Windows XP.

Netshell può essere molto utile per eseguire dei batch che cambino la configurazione di rete, oppure che siano in grado di ripristinare la configurazione di rete perduta per un qualsiasi motivo. Ad esempio, se col nostro portatile dobbiamo spostarci su diverse reti, è possibile avere una serie di batch che configurano automaticamente la rete; ciò si rende necessario se il servizio DHCP non è presente su tutte le reti in cui ci muoviamo, altrimenti questo accorgimento sarebbe inutile. Prima di vedere come utilizzare Netshell, è bene compiere un passaggio, e cioé rinominare la connessione di rete locale, che generalmente prende il nome di "Connessione alla rete locale (LAN)", trasformandola in qualcosa di più semplice, tipo "Rete Locale" (senza virgolette).

Fatto ciò, vediamo come impostare la configurazione di rete (cioè il settaggio di indirizzo IP, subnet mask, default gateway, server DNS senza usufruire di un server DHCP) su un client Windows XP:

> netsh interface ip set address name="Rete Locale" source=static addr=192.168.0.11 mask=255.255.255.0 gateway=192.168.0.254 gwmetric=1
> netsh interface ip set dns name="Rete Locale" source=static addr=192.168.0.1

Come si può facilmente intuire, bisogna utilizzare due comandi distinti: il primo per impostare la configurazione di indirizzo IP, subnet mask, default gateway, ed il secondo per impostare la configurazione del server DNS. Analizzando più nel dettaglio i due comandi, abbiamo come prima cosa l’ambito su cui va ad agire il comando netsh, ovvero "interface ip", quindi, abbiamo l’istruzione "set", che indica la riconfigurazione dell’interfaccia di rete, ciò significa che le vecchie impostazioni vengono sostituite da quelle indicate nel comando netsh. Di seguito, andiamo ad indicare cosa andiamo a riconfigurare, nel primo comando "address" e nel secondo "dns", poi si specifica il nome della connessione della rete locale (name="Rete Locale") e quindi si indica se i parametri sono statici o dinamici (se sono dinamici, i dati riguardanti la configurazione di rete verranno assegnati al client da un server DHCP), infine si specificano i parametri veri e propri, ma solo nel caso in cui questi vengano assegnati staticamente.

Nel caso in cui si voglia aggiungere un secondo server DNS, è possibile utilizzare il comando:

> netsh interface ip add dns name="Rete Locale" addr=192.168.0.2 index=2

Le differenze col comando precedente sono minime, e si limitano all’istruzione "add" che sostituisce "set", in quanto il server DNS impostato precedentemente viene mantenuto, ed all’istruzione "index=2", che indica che il server DNS impostato è il secondo nell’ordine di ricerca e viene chiamato in causa solamente quando il primo server DNS non risponde.

Il comando netsh è molto utile anche per effettuare il salvataggio delle impostazioni TCP/IP della propria scheda di rete, impostazioni che possono quindi essere ripristinate in caso di bisogno. Per effettuare il salvataggio eseguire il seguente comando:

> netsh interface ip dump > c:\rete.txt

In questo modo le impostazioni di rete vengono salvate nel file "c:\rete.txt", e possono essere richiamate per un ripristino tramite il comando:

> netsh -c "interface ip" -f c:\rete.txt

L’opzione -c "interface ip" serve per indicare a netsh che deve accettare i comandi contenuti nel file "c:\rete.txt" nel contesto "interface ip", mentre con l’opzione -f indichiamo il percorso del file in cui abbiamo salvato le impostazioni di rete. Dopo aver lanciato questo comando, le impostazioni del protocollo TCP/IP verranno riportate alla loro condizione originaria, cosa utile, come detto, in caso di problemi con la configurazione di rete.

Netshell è presente anche su Windows Vista, e da quel poco che ho potuto vedere ha alcune opzioni in più che non ho ancora provato.

Se si vuole sincronizzare l’ora del nostro domain controller (DC) con un time server esterno per avere sempre l’ora corretta impostata su tutto il dominio, i passi da compiere sono pochi e semplici. La sincronizzazione avviene per mezzo del protocollo NTP, che serve proprio a questo scopo.

Per sincronizzare l’ora del server, basta digitare questi due semplici comandi:

w32tm /config /syncfromflags:manual /manualpeerlist:time.ien.it,www.clock.org
w32tm /config /update

Da notare l’ultimo parametro del primo comando, /manualpeerlist, dove di seguito sono indicati due time server (time.ien.it e www.clock.org) tramite i quali sincronizzare la nostra rete locale, o meglio, si sincronizza l’ora del server, il quale a sua volta funge da time server per i client della rete.

Exchange Server in edizione Standard ha il problema di non poter scaricare mail da server POP3 per poi recapitarle alle caselle di posta locali, poiché questa versione non ha un connettore POP3, presente invece nella versione Small Business di Exchange. Per ovviare a questo problema, esistono diversi connettori POP3 per Exchange, ma, per quel che ho visto io, sono tutti a pagamento. Se non si vogliono spendere altri soldi per acquistare un connettore POP3 (per quanto diversi connettori non hanno certo importi proibitivi) e si ha un’altro PC a disposizione, è possibile installare hMailServer, un mail server open source per Windows dall’interfaccia semplice e funzionale, e che permette di scaricare la posta elettronica da un server POP3 e di inoltrarla all’indirizzo desiderato sul server Exchange. Detto così è semplice, e in effetti non è una soluzione molto complicata da utilizzare, ma bisogna prestare un po’ di attenzione a ciò che si fa.

Dando per scontato di avere Exchange Standard 2003 funzionante e correttamente configurato, dovremo installare hMailServer sull’altra macchina Windows (meglio un Windows Server, ovviamente se dobbiamo installare una macchina "solo" per quello scopo, conviene acquistare un connettore POP3), la cui installazione non è complicata ed è spiegata piuttosto bene nella documentazione presente sul sito di hMailServer. Tenere presente che hMailServer ha bisogno di un database di appoggio, che può essere MySQL o SQL Server (la stessa installazione di hMailServer può installare una propria versione minimale di MySQL, personalmente preferisco installarmi autonomamente MySQL).

Dopo aver installato hMailServer, va creato il dominio della posta; è consigliabile scegliere un nome di dominio differente sia dal dominio "ufficiale" di posta elettronica sia dal dominio Active Directory, e quindi, sotto il cappello di questo dominio, vanno create le caselle di posta elettronica, una per ogni casella accessibile sul server POP3 da cui dobbiamo scaricare la posta.

Per ogni casella di posta creata in hMailServer, dovremo andare nella scheda "Account esterni", cliccare sul pulsante "Aggiungi" ed inserire le informazioni relative a server POP3, nome utente e password - parametri che vengono forniti dal fornitore del servizio - inoltre, bisogna indicare ogni quanti minuti si scaricheranno i messaggi dal server e se si vogliono cancellare o meno i messaggi sul server POP3; inserite queste impostazioni, bisogna indicare a quale indirizzo vanno inoltrati tutti i messaggi ricevuti sulla casella di posta definita su hMailServer andando sulla scheda "Inoltro", in cui bisogna indicare l’indirizzo al quale inviare i messaggi. Qui bisogna prestare particolare attenzione alla situazione un po’ particolare: su Exchange sono definite le caselle con indirizzo di posta primario quello "ufficiale" corrispondente al dominio aziendale - ad esempio azienda.it - quindi, la policy predefinita per gli indirizzi di posta sarà "@azienda.it"; in tal caso, se su hMailServer inoltriamo le mail verso gli indirizzi di posta "@azienda.it", queste verranno di nuovo ricevute sul server di posta del nostro fornitore di servizio, ed hMailServer le riscaricherà, creando un circolo vizioso che porterà in un tempo più o meno breve alla saturazione del servizio. A questo punto abbiamo due soluzioni:

1. creare per ogni utente di Active Directory un indirizzo di posta secondario (e non predefinito) che termina con il dominio definito in AD stessa (ad esempio, @azienda.lan) ed inoltrare le mail verso quest’indirizzo;
2. creare una zona azienda.it sul DNS del domain controller e definire come record MX del dominio il server Exchange.

Se seguiamo la soluzione numero 1), dovremo definire nella scheda "Inoltro" di ogni casella di hMailServer l’indirizzo di posta corrispondente all’utente e che termina con "@azienda.lan", se invece seguiamo la soluzione numero 2), utilizzeremo come indirizzo di inoltro gli indirizzi di posta "ufficiali" (@azienda.it), avendo cura di impostare come server DNS del server hMailServer l’indirizzo IP del domain controller, cosa che si deve fare in ogni caso. Personalmente preferisco la soluzione numero 1), poiché in questo modo si evita di far confusione con gli indirizzi, identici in tutte le situazioni, mentre utilizzando indirizzi "@azienda.lan", la parte amministrativa è più impegnativa ma le due situazioni sono ben distinte, senza contare che così facendo non si va ad impiastricciare il DNS di Active Directory, particolare non trascurabile. L’utilizzo di hMailServer come connettore POP3 presenta un vantaggio da prendere in considerazione, cioé il fatto che è possibile mantenere il messaggio nella cartella di hMailServer, in questo modo si ha una copia di tutti i messaggi ricevuti, cosa utile in caso di disastri con il server Exchange, anche se ovviamente la cosa migliore è avere una buona strategia di backup.