Come fare: Autenticazione a livello di rete (NLA) per Connessione a Desktop Remoto su Windows XP

Una delle novità del protocollo RDP su Windows 2008 Server è il supporto per l'autenticazione a livello di rete (Network Level Authentication); che fondamentalmente sposta la fase di autenticazione dal server al client, proteggendo lo stesso da attacchi di tipo DOS, soprattutto se l'RDP è esposto direttamente su Internet.

I requisiti lato Client sono i seguenti:

1. che il client supporti  RDC 6.0 omaggiore
2. che sul client sia installato Windows XP SP3 o superiore

Per verificare se il nostro client RDP supporta la NLA, apriamo il client "Connessione a Desktop remoto" e cliccando sull'iconcina in alto a sinistra selezioniamo "Informazioni su"

 
Comunque per abilitare l'autenticazione a livello di rete su Windows XP dopo aver installato il Service Pack 3 dobbiamo seguire i seguenti passi:

1. andate su Start->Esegui e poi scrivete "regedit"*
2. Andate su HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa e modificate la chiave Security Packages aggiungendo ai valori esistenti "tspkg"* e premete Ok
3.  andate su HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders e modificate la chiave SecurityProviders aggiungendo alla fine ", credssp.dll"* e premete OK
4. Uscite da Regedit e Riavviate il Computer 

 * Senza Virgolette

 

Come fare: Windows 2008 Server Wifi

Di default il supporto WIFI su Windows Server 2008 è disabilitato;  per attivarlo bisogna aggiungere la funzionalità Wifi da Server Manager.

Trucco: Deposito dei driver Windows 7 e Windows 2008 Server

Nella cartella C:\Windows\System32\DriverStore\FileRepository ci sono i file:
dei driver (.sys)
di installazione (.inf)
INF precompilati(.pnf)
manifesti XML che contiene le informaziozi di tutti i file all'interno del pacchetto del driver.

Ma quello che ci interessa è che il contenuto di questa cartella è tutto quello che ci serve per l'installazione dei driver di una nuova device, quindi possiamo utilizzarla per rendere disponibili driver ad altri computer.

Utilizzare i VHD

Cosa sono (utilizzi e scenari)

Una delle nuove funzionalità di Windows 7 e di Windows Sever 2008 R2 è quella di consentire la gestione diretta dei Dischi Virtuali (VHD) senza la necessità di utilizzare ulteriori tool.

Parallelamente la Microsoft sta distribuendo in formato VHD diversi Software in versione dimostrativa, incluse le nuove versioni dei suoi sistemi operativi, con il grande vantaggio di avere un HD completamente preconfigurato che può essere montato tramite l'Hyper-V o utilizzato in fase di boot.
Tale semplicità e flessibilità di utilizzo sta conducendo ad un vero e proprio boom di utilizzo e quindi e bene non farci trovare impreparati; in particolare si richiede un certo approfondimento l'utilizzo dei VHD a scopi di boot.   

Innanzitutto capiamo che vantaggi ci da poter avviare un Sistema Operativo direttamente da un VHD:

1. Non è necessario ripartizionare l'HD
2. Semplifica la gestione delle immagini dei sistemi operativi fra versioni fisiche e virtuali, infatti lo stesso VHD può essere utilizzato in ambedue gli scenari.
3. Facilita lo spostamento del VHD su un server Hyper-V o su altre piattaforme di virtualizzazione che supportano i VHD, inclusa VMWare ESX.
4. Conferisce grande efficienza nella gestione degli spazi disco, infatti è possibile impostare la dimensione massima del VHD; il sistema Guest lo vedrà nella sua interezza, ma sull'Host occuperà solo lo spazio effettivamente richiesto. Il disco virtuale successivamente crescerà fino al limite massimo man mano che i dati verrano effettivamente scritti (allocazione in scrittura).
5. Le dimensioni inizialmente impostate possono essere modificate in qualsiasi momento senza alcuna perdita di dati.
6. E' possibile rimuovere un intero sistema operativo semplicemente eliminando il file VHD ed aggiornando i dati di boot.
7. Ci consente di bootare da un supporto esterno, tipo un'unità USB (Questo non è ufficialmente supportato ma si può tranquillamente fare) .
8. Possiamo fare il backup di un intero SO facendolo di un singolo file.
9. E' possibile gestire le versioni del Sistema operativo utilizzando i dischi differenziali per creare una relazione padre-figlio fra i VHD.

Come crearli e dove scaricarli


Per creare un VHD ex novo abbiamo le seguenti strade:

1. Dalla MMC tramite lo snap-in della gestione disco
2. Da riga di comando tramite DISKPART
3. Tramite  l'utility Disk2vhd che consente di creare versioni VHD  di dischi fisici.
4. Oppure possiamo scaricarne uno preinstallato

Come avviare direttamente da VHD

1. Installando un nuovo SO su un VHD
2. Utilizzando di un VHD esistente
3. Importando un VHD in Hyper-V

Strumenti di gestione

MMC snap-in Gestione disco:
Ci consente di creare, montare e gestire VHD.

Creazione o montaggio di un VHD:

Il VHD montato:

Esplora risorse:
Una volta montato possiamo gestire il contenuto del nostro VHD come quello di un qualsiasi disco

Nell'esempio sto accedendo ad un VHD contente un'installazione completa Windows 2008 R2 da Windows 7

DISKPART
Consente da riga di comando la gestione di tutti gli aspetti relativi ai dischi fisici e virtuali


WinPE
Windows Preinstallation Environment (Windows PE) 3.0 è una versione minima del sistema operativo Win32 con servizi limitati, costruito sul kernel di Windows 7. Viene utilizzato per preparare i conmputer all'installazione, nel nostro caso per creare o montare i VHD su cui installare il sistema operativo.

BCDEdit

BCDEdit è uno strumento da riga di comando per la gestione degli archivi dei dati di configurazione di avvio che può essere utilizzato per diversi scopi, tra cui la creazione di nuovi archivi, la modifica di archivi esistenti, l'aggiunta di opzioni al menu di avvio e così via. BCDEdit svolge praticamente le stesse funzioni di Bootcfg.exe nelle precedenti versioni di Windows, ma offre due sostanziali miglioramenti:
BCDEdit espone una gamma di opzioni di avvio più ampia di Bootcfg.exe.

VHDTool
Un stumento che davvero fornisce grandi funzionalità per la creazione e la gestione dei VHD.

Microsoft Hyper-V Server 2008 R2 Failover Cluster

Premessa

Microsoft ha ha reso disponibile gratuitamente (senza alcun bisogno di licenza) il Sistema Operativo: Microsoft Hyper-V Server 2008 R2.
Si tratta di una versione di Windows server 2008 R2 in modalità Server Core (quindi senza GUI) comprensiva del solo ruolo di Hyper-V, ma che mette comunque a disposizione la funzionalità di Failover Cluster, normalmente inclusa solo nelle versioni Enterprise e Datacenter di Windows Server.
Detta in altri termini è possibile creare un’infrastruttura per la gestione di macchine virtuali ad alta disponibilità e con funzionalità di migrazione in tempo reale senza alcun costo di licenze software per i server host.

Il Progetto

L'esigenza è di mettere in alta disponibilità i server aziendali con ruoli di AD ds, Dns, Dhcp, File server, Application Server, SQL server ed Exchange server.

HW (certificato W2k8 R2) :
n°2 Server (DELL PowerEdge) con le seguenti caratteristiche:
4 schede di rete GB: 2 saranno dedicate alla connettività con l’unità ISCSI ed 1 alle macchine virtuali
2 HD 15k rpm messi in RAID 1
24 GB RAM
4 CPU
Alimentazione ridondata

n°1 Unità disco ISCSI (DELL PowerVault ) (date un occhio alle caretteristiche necessarie per il cluster):
6 dischi SCSI 15k rpm messi in RAID 10
controller ridondato
alimentazione ridondata

n°2 Switch (Dell PowerConnect) Ethernet GB da dedicare alla connettività fra server ed ISCSI

SW:

Microsoft Hyper-V Server 2008 R2 (gratuito)

Reti:

LAN aziendale: 10.10.0.0/24 (collegata allo switch GB generale)
LAN ISCSI 1: 192.168.130.0/24 (switch GB 1)
LAN ISCSI 2: 192.168.131.0/24 (switch GB 2)







Configurazione ISCSI

Per prima cosa configuriamo l'unità ISCSI. Io l'ho fatto installando il SW di gestione fornito dalla DELL.

Nell'ordine ho proceduto nel seguente modo:

Configurato i 6 dischi in un solo array RAID 10. Questo tipo di RAID fornisce fault tolerance, grazie al mirroring, unitamente a ottime performance di I/O per via del parallelismo garantito dal sistema stripe.

Creato due volumi uno di 1 GB per il Quorum del Cluster ed uno con tutto lo spazio restante per i Dati

Configurato la rete
Controller 1
Porta di gestione: 10.10.0.10
ISCSI 0: 192.168.130.10
ISCSI 1: 192.168.131.101
Controller 2
Porta di gestione: 10.10.0.102
ISCSI 0: 192.168.130.102
ISCSI 1: 192.168.131.102

Indicato che i due volumi sarebbero stati acceduti da un cluster (accessi concomitanti)

N.B per semplicità ho omesso la configurazione dell’autenticazione CHAP



Installazione e configurazione iniziale dei server

Sono partito con il disco di installazione della DELL, ho configurato i due dischi in mirror (RAID1), ho selezionato il SO da installare (Windows 2008 R2) ed ho proseguito con il DVD Microsoft Hyper-V Server 2008 R2 creato dal file ISO scaricato dal sito Microsoft; la fase di installazione mi ha solo chiesto su che unità installare, le impostazioni internazionali e la password di amministrazione al primo logon.
P.S. Ricordatevi di abilitare da Bios il supporto per la virtualizzazione
Alla fine dopo l’accesso mi sono ritrovato con la consolle di gestione sconfig.cmd

Tramite questa consolle:

Diamo un Nome alla macchina: nel mio caso, e con molta fantasia, le ho chiamate Virtual01 e Virtual02

Metterle in Dominio: xxxx.local

Abilitare la Gestione Remota: essendo in modalità core è molto più comodo gestirla da remoto, anziché da riga di comando, ho quindi abilitato tutte le voci disponibili che aprono le apposite porte sul firewall e abilitano il supporto per la PowerShell

Abilitato il Desktop Remoto per scopi amministrativi

Eseguito un download ed installazione degli aggiornamenti

Configurato le Schede di Rete (solo 3 delle 4 disponibili riservandomene una per dedicarla alle macchine virtuali ):
Virtual01:
10.10.0.1
192.168.130.1
192.168.131.1
Virtual02:
10.10.0.2
192.168.130.2
192.168.131.2

DNS: 10.10.0.10
Gateway:10.10.0.5

N.B. E' possibile configurare queste impostazioni anche con il comado netsh interface ipv4...

Abilitato il Multipath I/O (da ora in vanti MPIO): tramite il comando start /w ocsetup MultipathIo




Installato il DSM (Device Specific Module) dell’unità ISCSI (fornita dal produttore) per il MPIO: fondamentale per la corretta comunicazione del server verso l’ISCSI in presenza di connessioni di rete multiple. Questa installazione può avvenire tramite un programma automatico di installazione (nel caso della DELL) o aggiungendoli manualmente tramite la consolle mpiocpl (lanciata da riga di comando)








Connettersi e configurare l’unità ISCSI tramite la consolle iscsicpl

Tab Individuazione: ho messo l’IP address 192.168.130.101 (ne basta uno qualasiasi di quelli configurati)

Tab Destinazioni: Connetti poi andare su Proprietà





Configurare manualmente le sessioni: Aggiungi sessione

Abilitare MPIO, Avanzate e selezionare:

Scheda locale: Iniziatore ISCSI Microsoft
IP iniziatore: 192.168.130.1 (questo su Virtual01, su Virtual02 ho sostituito l’1 finale con il 2 es. 192.168.130.2)
IP portale destinazione:192.168.130.101

ripetere per le coppie 192.168.130.1-192.168.130.102
192.168.131.1-192.168.131.101
192.168.131.1-192.168.131.102





Quindi alla fine ci troviamo con 4 sessioni di cui 2 attive e due in standby, ma il tutto è gestito in automatico dal MPIO tramite il DSM









Tramite il comando diskpart > List disk verificare la corretta connessione ai volumi ISCSI (lo stato riservato è successivo alla creazione del cluster, all’inizio sono OFFLINE).
In effetti i dischi 1 e 2 sono esattamente i due dischi creati sull’ISCSI



Per finire abilitiamo la funzionalità di Failover Cluster tramite il pannello Sconfig.cmd




Gestione remota e configurazione del Cluster

Essendo i server im modalità server core e quindi privi di interfaccia grafica per procedere con l'installazione a questo punto ho utilizzato RSAT (Remote Server Administration Tools) anche disponibili come funzionalità nella versione Windows server 2008 R2 (attenzione gli RSAT di Windows Server 2008 Standard non riescono a gestire i cluster basati su host R2), su un PC Windows 7 messo in dominio.



Scaricare ed installare il pacchetto e dopo andare in Pannello di controllo-> Programmi e funzionalità -> Funzionalità di Windows-> Strumenti di amministrazione remota del server: abilitare l’amministrazione del ruolo Hyper-V e della funzionalità Cluster di failover.









Ho quindi creato una nuova Management console (comando: MMC) ed aggiunto gli snap-in per la Gestione del computer sia per Virtual01 che per Virtual02 al cui interno c’è la Gestione disco in cui ho assegnato le lettere alle unità Q al quorum ed S al disco che ospiterà le macchine virtuali

N.B.: La gestione volumi remota deve essere aggiunta come eccezione sul Firewall sia della macchina da cui utilizziamo la MMC che dei server





Tramite lo snap-in Hyper-V ho creato sulle due macchine una rete virtuale denominata MacchineVirtuali (attenzione il nome deve essere identico su tutti e due gli host del cluster!) facendola puntare alla scheda di rete che avevo lasciato appositamente libera














Siamo finalmente pronti a tirare su il cluster. Quindi tramite lo snap-in Gestione cluster di failover ho avviato la Convalida del Cluster selezionando le due macchine Virtual01 e Virtual02.

Vi consiglio di non procedere se la convalida non è completamente esente da errori ed avvisi, pena la probabilissima futura cancellazione e ricreazione del cluster.


Possiamo quindi procedre con la Creazione del cluster: qui viene chiesto di selezionare i nodi afferenti al cluster Virtual01 e Virtual02, il nome xxx_cluster_vitual e l’IP address condiviso dal cluster, io ho scelto il 10.10.0.3. Il Wizard fa tutto in automatico (davvero complimenti alla Microsft!) ed alla fine ci troviamo il cluster attivo.



Appena finito per prima cosa diamo un'occhiata ai dischi.
Il Wizard in automatico seleziona i dischi condivisi sui nodi selezionati e li configura nel cluster, quindi andando su Archiviazione ci troviamo con i due dischi definiti sull’unità ISCSI montati rispettivamente come disco di Quorum (Q) e come Storage (S) su cui andremo a mettere le macchine virtuali.


Una delle nuove opzioni del cluster R2 sono i Volumi condivisi del Cluster (CSV) che ottimizzano l’accesso contemporaneo, e quindi concorrente, dei nodi del cluster alla SAN in particolare per il ruolo Hyper-V, per attivarli ho cancellato da Archiviazione il volume S e l’ho rimesso nei Volumi condivisi cluster




I volumi condivisi del cluster vengono mappati sulle singole macchine con la directory (virtuale): c:\ClusterStorage\volumeX (con X che indica il volume condiviso, nel nostro caso solo 1).
Siccome questa directory rappresenta la nostra SAN, condivisa da ambedue i nodi, andiamo nelle proprietà dell' Hyper-V dei due host e impostiamo come default questa directory per memorizzare i Dischi rigidi (VHD) e le Macchine Virtuali in maniera da avere i dati disponibili su ambedue i nodi e potere quindi garantire l’alta disponibilità nonché migrarle a nostro piacimento.




Le impostazioni delle Reti all'interno del Cluster servono per poter consentire ai nodi di comunicare e scambiarsi dati tra loro, nel nostro caso il wizard ha identificato 3 reti disponibili:
10.10.0.0/24
192.168.130.0/24 (ISCSI)
192.168.131.0/24 (ISCSI)

Ma noi non vogliamo che le reti dedicate all’ISCSI vengano utilizzate in alcun altro modo, quindi le disattiviamo.

Il nostro Cluster è finalmente pronto, non ci resta che aggiungere una macchina virtuale per fare tutti i Test prima di metterci le macchine di esercizio. Nel mio caso ho scaricato ed importato una versione trial di una macchina virtuale Windows Server 2008 R2 x64. Una volta aggiunta ai Servizi e applicazione del Cluster nal menù azioni o semplicemente nel menù contestuale chiamato con il mouse destro abbiamo l’opzione per eseguire la migrazione della Virtual machine sull’altro nodo (Live Migration).
 
Test e conclusioni



Ed ecco il risultato di un ping –t durante la Live Migration









Ho eseguito anche positivamente dei test di Fail del server che ospitava la macchina virtuale, ovviamente in questo caso la macchina viene riavviata (la RAM non è condivisa dalle due macchine, quindi una chiusura “sporca” non ne consente il recupero).

Ultima nota è possibile distribuire le macchine virtuali a piacimento sui nodi del cluster facendole lavorare in modalità attivo/attivo e spostandole all’occorrenza fra i vari nodi, in questa modo è possibile eseguire una distribuzione dei carichi facendo attenzione a ricordare sempre che l’ I/O sulla SAN, che è comune, può essere un collo di bottiglia.

Spero che questa guida possa esservi utile. Vi chiederei cortesemente di segnalarmi qualsiasi errore o inesattezza possiate riscontrarvi.

Auguro un buon cluster e buona virtualizzazione a tutti ;-)

Ruggiero Lauria

Benvenuti nel mio Blog Tecnico

L'obiettivo è di condividere con la rete soluzioni, progetti e trucchi che possano essere di interesse comune.

Sentitevi liberi di utilizzare questo blog in maniera bidirezionale, ogni commento e precisazione è il benvenuto.

Buon proseguimento

Ruggiero Lauria