Archivi categoria: Windows Server

Gestione backup GLPI v9.1.4 in ambiente Windows

GLPI (Gestion Libre de Parc Informatique) è un progetto Open Source gratuito distribuito sotto licenza GPL che consente l’IT Asset Management, l’issue tracking system, fornisce una soluzione di service desk solution e consente la gestione di tasks amministrativi e finanziari. Dal momento che il servizio di l’IT Asset Management e/o di issue tracking system, quando implementate all’interno di un’infrastruttura informatica, assumono un’importanza rilevate ai fini della gestione occorre pianificare un’adeguata politica di backup.

Di seguito verrà analizzato come gestire il backup di GLPI 9.1.4 installato in IIS con PHP 7.1.1 su MariaDB 10.2.7 in ambiente Windows Server 2012 R2, inoltre si ipotizzerà che i file di GLPI siano memorizzati in S:\GLPI e che il database sia stato creato col nome glpi.

Funzionalità di backup in GLPI

GLPI offre nativamente la possibilità di eseguire il backup del database tramite il menu Amministrazione – Manutenzione

Tale backup permette di creare un dump sql o XML del contenuto del database, ma come riportato nella pagina WIKI Data/Backup del progetto GLPI al momento non è possibile automatizzare tale operazione, che può quinti tornare utile per backup estemporanei da eseguire prima di operazioni per cui è consigliabile avere una copia di sicurezza del database.

I backup eseguiti tramite l’interfaccia web di GLPI vengono conservati nella subdirectory files\_dumps della cartella d’installazione, è possibile copiarli e incollarli per esempio per gestire il restore su un server differente ad esempio per creare ambienti di test.

Backup del database di GLPI tramite script

Dal momento che come visto precedentemente il backup nativo di GLPI non offre la possibilità di essere eseguito in base ad una schedulazione, per una gestione automatizzata del processo di backup occorrerà creare degli appositi script da eseguire in base ad un’opportuna pianificazione. Di seguito si analizzerà come creare uno script per il backup del database di GLPI ipotizzando che, come detto precedentemente, quest’ultimo sia esposto dal DBMS MariaDB 10.2.7.

In MariaDB 10.2.7 è stato introdotto il tool di backup mariabackup in versione Beta basato su Percona XtraBackup 2.3.8, a riguardo si vedano About MariaDB Backup e MariaDB Backup released with MariaDB Server 10.1.23. Tramite mariabackup è possibile gestire tramite script le operazioni di backup del DBMS MariaDB, di seguito uno script Powershell per il backup gestito dell’intero DBMS MariaDB con possibilità di gestione del numero minimo di backup da mantenere, lo script prevede l’utilizzo dei parametri per poter essere gestito nell’ambito di un’automazione del backup del server GLPI che prevede più step.

Param(
[string]$MariaBackupFile,
[string]$BackupRoot,
[string]$MariaDBHost,
[string]$User,
[string]$Password,
[uint32]$BackupsRetained
)

Set-strictmode -version latest

# Impostazioni di Test
#$MariaBackupFile= $env:ProgramFiles + “\MariaDB 10.2\bin\mariabackup.exe”
#$BackupRoot=”Z:\Backup-MariaDB”
#$MariaDBHost=”.”
#$User=”root”
#$Password=”P@assW0rd!”
#$BackupsRetained = 10

# Inizializzazione Backup
$BackupPath=$BackupRoot + “\” + (Get-Date -format yyyy-MM-dd)
If (Test-Path $BackupPath) {Remove-Item $BackupPath -Force -Recurse}
New-Item -ItemType Directory -Force -Path $BackupPath

# Avvio backup MariaDB
$TargetArg = “–target-dir=” + $BackupPath
$MariaDBHostArg = “–host=” + $MariaDBHost
$UserArg = “–user=” + $User
$PasswordArg = “–password=” + $password

Start-Process -NoNewWindow -Wait -FilePath $MariaBackupFile -ArgumentList “–backup”, $TargetArg, $MariaDBHostArg, $UserArg, $PasswordArg

# Eliminazione backup obsoleti
$BackupDirectories = (Get-ChildItem -Directory $BackupRoot | Sort FullName)
$BackupsCount = ($BackupDirectories | Measure-Object).Count

If ($BackupsCount -gt $BackupsRetained){
For ($i = 1; $i -le $BackupsCount – $BackupsRetained; $i++) {
Remove-Item $BackupDirectories[$i-1].FullName -Force –Recurse
}
}

Lo script è disponibile nel repository GitHub ermannog/PowerShell/Backup-GLPI col nome Backup-MariaDB.ps1.

In alternativa è anche possibile ovviamente eseguire solo il backup del database di GLPI, di seguito uno script Powershell per il backup gestito del singolo database di GLPI con possibilità di gestione del numero minimo di backup da mantenere, lo script prevede l’utilizzo dei parametri per poter essere gestito nell’ambito di un’automazione del backup del server GLPI che prevede più step.

Param(
[string]$MariaBackupFile,
[string]$BackupRoot,
[string]$MariaDBHost,
[string]$GLPIDatabaseName,
[string]$User,
[string]$Password,
[uint32]$BackupsRetained
)

Set-strictmode -version latest

# Impostazioni di Test
#$MariaBackupFile= $env:ProgramFiles + “\MariaDB 10.2\bin\mariabackup.exe”
#$BackupRoot=”Z:\Backup-MariaDB”
#$GLPIDatabaseName=”glpi”
#$User=”root”
#$Password=”P@assW0rd!”
#$BackupsRetained = 10

# Inizializzazione Backup
$BackupPath=$BackupRoot + “\” + (Get-Date -format yyyy-MM-dd)
If (Test-Path $BackupPath) {Remove-Item $BackupPath -Force -Recurse}
New-Item -ItemType Directory -Force -Path $BackupPath

# Avvio backup Database GLPI
$TargetArg = “–target-dir=” + $BackupPath
$MariaDBHostArg = “–host=” + $MariaDBHost
$GLPIDatabaseNameArg = “–databases=” + $GLPIDatabaseName
$UserArg = “–user=” + $User
$PasswordArg = “–password=” + $password

Start-Process -NoNewWindow -Wait -FilePath $MariaBackupFile -ArgumentList “–backup”, $TargetArg, $MariaDBHostArg, $GLPIDatabaseNameArg, $UserArg, $PasswordArg

# Eliminazione backup obsoleti
$BackupDirectories = (Get-ChildItem -Directory $BackupRoot | Sort FullName)
$BackupsCount = ($BackupDirectories | Measure-Object).Count

If ($BackupsCount -gt $BackupsRetained){
For ($i = 1; $i -le $BackupsCount – $BackupsRetained; $i++) {
Remove-Item $BackupDirectories[$i-1].FullName -Force –Recurse
}
}

Lo script è disponibile nel repository GitHub ermannog/PowerShell/Backup-GLPI col nome Backup-DB-GLPI.ps1.

Backup dell’applicazione web GLPI tramite script

Dopo aver eseguito il backup del database di GLPI occorre anche eseguire il backup dell’applicazione web, di seguito uno script Powershell per il backup gestito dell’applicazione GLPI con possibilità di gestione del numero minimo di backup da mantenere, lo script prevede l’utilizzo dei parametri per poter essere gestito nell’ambito di un’automazione del backup del server GLPI che prevede più step.

Param(
[string]$BackupRoot,
[string]$WebApplicationPath,
[string]$WebSiteName,
[uint32]$BackupsRetained
)

Set-strictmode -version latest

# Impostazioni di Test
#$BackupRoot=”Z:\Backup-WebApplication-GLPI”
#$GLPIWebApplicationPath=”C:\inetpub\wwwroot\glpi”

#$WebSiteName=”Default Web Site”
#$BackupsRetained = 10

# Inizializzazione Backup
$BackupPath=$BackupRoot + “\” + (Get-Date -format yyyy-MM-dd)
If (Test-Path $BackupPath) {Remove-Item $BackupPath -Force -Recurse}
New-Item -ItemType Directory -Force -Path $BackupPath

# Arresto Web Site
Stop-WebSite $WebSiteName

# Avvio Backup Web Application GLPI
Copy-Item -Path $WebApplicationPath -Destination $BackupPath –Recurse

# Avvio Web Site
Start-WebSite $WebSiteName

# Eliminazione backup obsoleti
$BackupDirectories = (Get-ChildItem -Directory $BackupRoot | Sort FullName)
$BackupsCount = ($BackupDirectories | Measure-Object).Count

If ($BackupsCount -gt $BackupsRetained){
For ($i = 1; $i -le $BackupsCount – $BackupsRetained; $i++) {
Remove-Item $BackupDirectories[$i-1].FullName -Force –Recurse
}
}

Lo script è disponibile nel repository GitHub ermannog/PowerShell/Backup-GLPI col nome Backup-WebApplication-GLPI.ps1.

Backup del sistema del server GLPI

Oltre al backup del database e dell’applicazione web di GLPI è consigliabile eseguire un backup dell’intero sistema per gestire anche eventuali disaster recovery. Per gestire tali scenari di ripristino è ovviamente consigliabile che il server GLPI sia una macchina virtuale in modo da poter gestire il backup del sistema con vari approcci.

Un primo modo di eseguire il backup dell’intero sistema è quello di utilizzare Windows Backup dedicandogli ad esempio un disco virtuale. Nel la macchina virtuale del server GLPI sia in esecuzione in Hyper-V conviene connettere il disco virtuale su un controller virtuale SCSI in quanto permette di gestire tramite script la connessione e la disconnessione del VHD a caldo per copiare lo stesso su un server di backup.

In alternativa è possibile eseguire il backup dall’Hypervisor e nel caso che quest’ultimo sia Hyper-V tramite Windows Backup o altri software di backup come ad esempio System Center 2016 Data Protection Manager, Veeam Backup & Replication.

Conclusioni

La gestione del backup di GLPI in ambiente Windows non risulta eccessivamente complessa e può essere automatizzata tramite scripts PowerShell, per un recupero dei dati più semplice conviene eseguire il backup con vari livelli di granularità per consentire il ripristino di dati in tabelle, database, applicazione o intero sistema.

Configurazione autenticazione Windows in GLPI v9.1.4

GLPI (Gestion Libre de Parc Informatique) è un progetto Open Source gratuito distribuito sotto licenza GPL che consente l’IT Asset Management, l’issue tracking system, fornisce una soluzione di service desk solution e consente la gestione di tasks amministrativi e finanziari. Tali attività normalmente vengono assegnate a persone differenti e nel caso in cui in cui GLPI venga utilizzato in un’infrastruttura basata su Active Directory diventa comodo integrare l’autenticazione Windows con l’autenticazione GLPI sfruttando LDAP (Lightweight Directory Access Protocol).

Di seguito verranno descritti i passi per configurare l’autenticazione basata su LDAP in GLPI 9.1.4 installato in IIS con PHP 7.1.1 in ambiente Windows Server 2012 R2.

Configurazione di IIS e PHP per il supporto dell’autenticazione Windows

Perché IIS possa gestire l’autenticazione Windows utilizzando gli utenti Active Directory il server che ospita IIS dovrà essere membro del dominio come indicato nella KB258063 Internet Explorer May Prompt You for a Password:

Windows Integrated authentication, also known as Windows NT Challenge/Response, must be enabled in the Web site properties in IIS. Anonymous authentication is attempted first, followed by Windows Integrated authentication, Digest authentication (if applicable), and finally Basic (clear text) authentication.

Both the client and the Web server must be either in the same Microsoft Windows NT-based or Microsoft Windows 2000-based domain or in trusted Windows NT-based or Windows 2000-based domains in which the user’s account can be granted permissions to resources on the IIS-based computer.

Inoltre sul server che ospita IIS dovrà essere installata la componete Windows Authentication di IIS:

Per abilitare in PHP l’autenticazione integrata di Windows abilitare l’estensione LDAP modificando il file %ProgramFiles%\PHP\v7.1\php.ini aggiungendo nella sezione [ExtensionList] la seguente impostazione:

extension=php_ldap.dll

Terminata l’editazione del file %ProgramFiles%\PHP\v7.1\php.ini riavviare IIS tramite lnternet Information Services (IIS) Manager (InetMgr.exe) o mediante il seguente comando:

iisreset /restart

Per ulteriori informazioni si veda IIS Configuration Reference – Windows Authentication.

Configurazione di GLPI per l’utilizzo di LDAP

Per default GLPI ha già delle configurazioni per la gestione degli utenti provenienti da una fonte esterna come LDAP, in particolare le opzioni Aggiunge automaticamente utenti da fonte esterna di autenticazione e Aggiungi un utente senza diritti da LDAP consentono di aggiungere automaticamente gli utenti al primo accesso con profilo di sicurezza Self-Service, se si preferisce gestire l’accesso manualmente impostare a No tali opzioni.

La prima operazione da eseguire è configurare GLPI per l’utilizzo di LDAP sul proprio dominio per la ricerca di utenti e gruppi nella Organizational Unit che conterrà gli utenti che dovranno accedere a GLPI, configurando come segue:

Nel campo Server è possibile specificare il dominio che verrà così risolto con gli indirizzi IP dei vari Domain Controller, mentre nel campo Filtro Connessione specificare la query LDAP che consente di ricercare gli utenti non disabilitati:

(&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

Nel campo BaseDN specificare il path LDAP della Organizational Unit che conterrà gli utenti che dovranno accedere a GLPI, mentre nei campi RootDN e Password specificare le credenziali di un utente a minimi privilegi che verrà utilizzato per eseguire le query LDAP su Active Direcory. Infine nel campo Nome utente specificare l’attributo utente che idendifica il logon name ovvero samaccountname (per default GLPI propone uid).

Inoltre configurare la ricerca dei gruppi come segue

Nel campo Tipo ricerca specificare che la ricerca verrà eseguita nei gruppi, mentre nel campo Filtro di ricerca nei gruppi specificare la seguente query LDAP:

(&(objectCategory=group))

Terminata la configurazione delle impostazioni relative alla Directory LDAP eseguire un test di connessione verso Active Directory con l’opzione Test. Per ulteriori informazioni si veda GLPI, LDAP and Active Directory.

Configurare gli utenti Active Directory in GLPI

Per accedere a GLPI tramite gli utenti Active Directory specificando le autorizzazioni necessari occorre prima aggiungerli tramite il Menù Amministrazione – Utenti selezionando l’opzione Collegamento a directory LDAP e quindi l’opzione Importa nuovi utenti:

In alternativa è possibile far sì che GLPI aggiunga automaticamente gli utenti al primo accesso con profilo di sicurezza Self-Service, come visto precedente.

Abilitazione autenticazione Windows in IIS

Di seguito si ipotizzerà che GLPI è stato installato in una Virtual Directory denominata glpi su cui occorrerà disabilitare l’autenticazione anonima e abitare l’autenticazione Windows tramite lnternet Information Services (IIS) Manager (InetMgr.exe)

Per testare che l’autenticazione Windows funziona correttamente e che l’utente viene trasmesso dal browser al server è possibile creare nella Virtual Directory un file php denominato ad esempio TestAuth.php con seguente contenuto:

<?php

echo “REMOTE_USER = ” . $_SERVER [“REMOTE_USER”] . “<BR />”;

echo “HTTP_AUTH_USER = ” . $_SERVER [“HTTP_AUTH_USER”] . “<BR />”;

echo “PHP_AUTH_USER = ” . $_SERVER [“PHP_AUTH_USER”] . “<BR />”;

echo “USERNAME = ” . $_SERVER [“USERNAME”] . “<BR />”;

echo “REDIRECT_REMOTE_USER” . $_SERVER [“REDIRECT_REMOTE_USER”];

?>

Configurazione GLPI per l’autenticazione automatica

Per far sì che l’utente con cui ci si è autenticati sul client venga passato al server su cui è installato GLPI è necessario configurare come segue l’invio dell’autenticazione nella richiesta http mediante il menù Configurazione – Altri metodi di autenticazione:

In Campo per la registrazione dell’accesso nella richiesta HTTP impostare REMOTE_USER. Dopo aver eseguito tali impostazioni gli utenti a cui è stato consenti l’accesso a GLPI in modo manuale o automatico avranno accesso senza più dover inserire le credenziali, in ogni caso sarà ancora possibile accedere alla pagina di login mediante il seguente url:

http://hostname.domain.ext/glpi/index.php?noAUTO=1

Per maggiori informazioni si veda Automatic authentication

Conclusioni

La gestione dell’autenticazione integrata di Windows in GLPI prevede la configurazione della stessa nei vari componenti quindi in IIS, PHP e GLPI, ma consente un’interessante integrazione con l’infrastruttura Active Directory. Nel caso in cui si riscontrino malfunzionamenti nell’accesso a GLPI mediante l’autenticazione integrata di Windows si provi a chiudere tutte le sessioni dei browser e quindi a tentare nuovamente l’accesso, inoltre per identificare eventuali problemi si provi ad esaminare il file \files\_log\php-errors.log.

Configurare un site-aware failover cluster e la node fairness in Windows Server 2016

Il Site-Aware failover è una novità relativa alla funzionalità di Failover Clustering che è stata introdotta in Windows Server 2016. Anche se in realtà già in Windows Server 2012 R2 era possibile realizzare un cluster i cui nodi erano funzionanti in due regioni geografiche diverse, non c’era modo per indicare in quale di queste regioni si trovassero i diversi nodi, in modo tale da poterli gestire in maniera diversa e poter indicare ai diversi servizi di poter fare “failover” nella stessa area geografica.

Con Windows Server 2016 è stata invece introdotta la possibilità di raggruppare i nodi in base alla loro posizione fisica in modo tale da poter, ad esempio, permettere alle risorse del cluster di poter essere trasferite su un nodo nello stesso sito in caso di manutenzione o draining di un altro nodo.

Per poter implementare la site awareness è possibile procedere in due modi, uno automatico ed uno manuale.

Se si utilizza il modo automatico è possibile utilizzare i Site di Active Directory. Quindi se avete già definito dei Site dentro i quali avete messo i vostri Domain Controller e a cui avete associato delle subnet, vi basterà digitare il comando PowerShell (lanciato con privilegi elevati):

(Get-Cluster).AutoAssignNodeSite 1

Se volete utilizzare la modalità manuale sarà invece prima necessario definire quali sono i Site e successivamente aggiungervi i nodi, utilizzando i comandi PowerShell (lanciati con privilegi elevati):

#Creazione dei Site

New-ClusterFaultDomain –Name Roma –Type Site –Description “Datacenter Primario” –Location “Datacenter Roma”

New-ClusterFaultDomain –Name Milano –Type Site –Description “Datacenter Secondario” –Location “Datacenter Milano”

#Assegnazione dei nodi ai Site

Set-ClusterFaultDomain –Name Nodo1 –Parent Roma

Set-ClusterFaultDomain –Name Nodo2 –Parent Roma

Set-ClusterFaultDomain –Name Nodo3 –Parent Milano

Set-ClusterFaultDomain –Name Nodo4 –Parent Milano

Questo tipo di configurazione permette di migliorare notevolmente il failover, il placement delle macchine virtuali, gli heartbeat tra i nodi e il quorum.

Ad esempio la Failover Affinity permette che le risorse vengano spostate su un nodo dello stesso sito, prima di tentare di spostarle in un sito differente. Inoltre durante la Node Drain le macchine virtuali vengano spostate localmente, su un nodo vicino.

Il Cross-Site Heartbeat da’ la possibilità di configurare in maniera accurata alcuni parametri come ad esempio il CrossSiteDelay (il tempo tra due heartbeat inviati tra nodi in siti diversi) e il CrossSiteThreshold (il numero di heartbeat persi tra due nodi in site diversi). Entrambi i valori sono configurabili con i comandi PowerShell (lanciati con privilegi elevati)

(Get-Cluster).CrossSiteDelay 1000    #valore di default

(Get-Cluster).CrossSiteThreshold 20  #valore di default

Un’altra interessante novità di Windows Server 2016 riguarda la Virtual Machine Node Fairness, che è già abilitata di default ma che viene disabilitata se utilizzate la funzionalità Dynamic Optimization di System Center Virtual Machine Manager. La VM Node Fairness permette di bilanciare le macchine virtuali tra i diversi nodi del cluster: dopo aver valutato l’utilizzo del processore e della memoria, le macchine vengono automaticamente migrate (utilizzando la Live Migration) da un nodo più carico ad un nodo scarico. Il bilanciamento può essere configurato per ottenere le migliori performance nel cluster, utilizzando il comando PowerShell (eseguito con privilegi elevati) per configurare la percentuale di utilizzo del nodo:

(Get-Cluster).AutoBalancerLevel 2

riprendendo i valori dalla seguente tabella:

AutoBalancerLevel

Aggressiveness

Host load percentage

1 (default)

Low

80%

2

Medium

70%

3

High

60%

Oppure è possibile configurare ogni quanto tempo deve essere utilizzata la node fairness, utilizzando il comando PowerShell (eseguito con privilegi elevati):

(Get-Cluster).AutoBalancerMode 2

riprendendo i valori dalla seguente tabella:

AutoBalancerMode

Behavior

0

Disabled

1

Balance on node join only

2 (default)

Balance on node join and every 30 minutes

Conclusioni

Queste due importanti novità relativa al cluster di Windows Server 2016 sono pensate sia per la gestione del Disaster Recovery geografico tra diversi siti della nostra infrastruttura, sia per l’ottimizzazione delle performance dei nodi, senza dover ricorrere a prodotti a pagamento come SCVMM. Sicuramente un grosso passo in avanti per rendere i nostri datacenter più performanti ed avere lo stesso livello di funzionalità offerte dal Cloud pubblico.

Windows Server, novità sul rilascio e prima build Insider 16237

Il 15 giugno 2017 Microsoft ha annunciato un nuovo modello di rilascio di Window Server, allineandolo quindi a Windows 10 e Office 365. Viene infatti introdotto il Windows Server Semi-annual Channel, ovvero saranno rilasciate nuove funzionalità per Windows Server a coloro che si stanno muovendo verso una “cadenza Cloud” – ad esempio con cicli di sviluppo molto rapidi – e vogliono essere sempre al passo con i tempi. Saranno disponibili nuove versioni di Windows Server 2 volte all’anno, in primavera e in autunno. Ogni versione rilasciata in questo nuovo ramo sarà supportata per 18 mesi a partire dal rilascio iniziale, mentre il modello classico/familiare (ora chiamato LTS – Long-term Servicing Branch) resta invariato con i relativi aggiornamenti di sicurezza e non.

La maggior parte delle funzionalità rilasciate nel Semi-annual Channel saranno introdotte nella successiva edizione LTS (generalmente ogni 2-3 anni) di Windows Server. Le edizioni, le funzionalità e il supporto dei contenuti potrebbero variare in base ai feedback degli utenti

Il nuovo ramo di manutenzione sarà disponibile a tutti coloro con un contratto di licenza a volume tramite Software Assurance, nonché tramite il Marketplace di Azure o altri provider di servizi Cloud/Hosting e programmi speciali quali MSDN.

In questo nuovo modello, le nuove versioni di Windows Server vengono identificate dall’anno e dal mese. Per esempio, nel 2017, il rilascio autunnale (settembre 2017) sarà identificato dalla versione 1709, mentre quello primaverile (marzo 2018) dalla 1803.

Rami di manutenzione e opzioni d’installazione

I rami di manutenzione disponibili variano in base all’edizione di Windows Server installata. Come mostra la tabella sottostante, il nuovo Semi-annual Channel sarà disponibile soltanto per le opzioni Nano Server e Server Core di Windows Server:

Opzione Semi-annual Channel (Windows Server) Long-term Servicing Channel (Windows Server 2016)
Nano Server Si No
Server Core Si Si
Server con la Desktop Experience No Si

Prima build Insider di Windows Server

Dopo l’introduzione sulla nuova strategia di rilascio per Windows Server ritorniamo a qualche mese fa, quando vi abbiamo parlato dell’annuncio del programma Windows Insider dedicato ai professionisti IT (WIP4Biz). Finalmente è arrivata la prima build di Windows Server dedicata agli Insider, nello specifico la 16237. Per poterla scaricare è richiesta la registrazione al programma Windows Insiders for Business o al classico dei Windows Insider.

Microsoft sottolinea che le edizioni Windows Server Datacenter Core e Standard Core sono “senza testa” e, quindi, vengono gestite meglio in remoto. Per maggiori informazioni trovate la guida sul come Configurare un’installazione Server Core di Windows Server 2016 con Sconfig.cmd. I dettagli aggiornati sull’amministrazione in remoto saranno rilasciati con le future release Insider.

Novità di Windows Server build 16237

Il changelog è molto corposo e lo trovate per intero a questo link. Di seguito i punti salienti:

  • Memoria Persistente. La memoria persistente (PMEM) può essere esposta alle macchine virtuali create con Hyper-V
  • Passthrough della batteria. Una VM potrà visualizzare lo stesso stato della batteria del sistema host
  • Miglioramenti alla rete di Containers.
  • RDMA (Remote Direct Memory Access) per macchine guest attendibili.
  • Miglioramenti per l’architettura di rete SDN (Software Defined Networking).
  • Miglioramenti alla rete di trasporto.
  • Miglioramenti per HTTP(s).
  • Miglioramenti per la misurazione accurata del tempo.
  • Nano Server ottimizzato per i Containers.
  • Ottimizzazioni all’immagine base di Server Core.

Come scaricare la build 16237

La prima build Insider di Windows Server è disponibile per il download a questo link. Le immagini corrispondenti per i Containers saranno disponibili attraverso l’Hub di Docker. Maggiori informazioni qui.

Le seguenti chiavi sono disponibili per un numero illimitato di attivazioni di Windows Server. Esse possono essere utilizzate per tutto il ciclo di pre-rilascio.

  • Server Datacenter Core: B69WH-PRNHK-BXVK3-P9XF7-XD84W
  • Server Standard Core: V6N4W-86M3X-J77X3-JF6XW-D9PRV

Come sempre vi consigliamo d’installare queste build Insider in ambienti di test. Trovate uno spazio dedicato agli Insider di Windows Server nella Microsoft Tech Community.

Installazione GLPI v9.1.4 in ambiente Windows

Quando le infrastrutture informatiche assumo dimensioni consistenti o la cui complessità richiede più persone per la gestione comincia a farsi sentire l’esigenza di adottare un software per la gestione del parco informatico e del servizio di helpdesk. Un altro scenario in cui tali tipi di software sono particolarmente utili è quello in cui un fornitore di servizi informatici si trovi a dove gestire più piccole aziende con la necessità di offrire un servizio di helpdesk e anche la gestione del parco macchine e apparecchiature dei propri clienti.

Vari sono i software che propongono soluzioni in tal senso, ma molti di essi affrontano il problema tramite scansione della rete per rilevare in modo automatizzato gli asset informatici presenti, sebbene questo tipo di approccio sia in determinati scenari molto pratico in altri può non essere applicabile o comodo. Infatti in scenari in cui non tutti gli asset possono essere gestiti tramite rilevazione automatica in rete in quanto non raggiungibili o privi di interfaccia di rete o ancora perché è necessario poterli gestire prima che vengano inseriti in rete (si pensi ad esempio ad asset mantenuti in magazzino come ricambi).

Inoltre molto spesso la necessità della gestione del parco informatico parte da specifiche necessità di carattere più amministrativo che tecnico, come la gestione dei rinnovi delle garanzie, la gestione del mazzino, la gestione della posizione fisica degli asset o il computo dell’impatto dell’helpdesk declinato in base alle richieste o per tipologia di asset su cui sono avvenuti gli interventi.

Un prodotto che risponde a queste esigenze è GLPI (Gestion Libre de Parc Informatique), un progetto Open Source gratuito distribuito sotto licenza GPL che consente l’IT Asset Management, l’issue tracking system, fornisce una soluzione di service desk solution e consente la gestione di tasks amministrativi e finanziari, di seguito alcune interessanti caratteristiche:

  • Gestione di Multi-entities (multi-park, multi-structure)
  • Gestione Multiutenza
  • Sistema di autenticazione multipla (locale, LDAP, AD, Pop/Imap, CAS, x509…) e multi servers
  • Multilingual (al momento sono disponibili 45 localizzazioni)
  • Gestione di Permissions e profili

Per l’elenco completo delle caratteristiche si veda FEATURES LIST OF GLPI.

GLPI è un applicazione web-based nata nel 2003 come progetto Community based a cui chiunque può contribuire tramite lo lo sviluppo di moduli su GitHub – GLPI o mediante lo sviluppo di GLPi plugins, il progetto ha subito negli anni varie evoluzioni sino ad arrivare all’attuale versione 9.1.4, di seguito la time line dell’evoluzione del progetto tratto dalla pagina Wikipedia dedicata al progetto.

Prerequisiti d’installazione di GPLI

Come riportato nel seguente Prerequisites for installing GLPI l’applicazione web ha i seguenti prerequisiti software:

  • Un Web Server con supporto PHP (Apache 2 o superiore oppure Microsoft IIS)
  • PHP 5.3 o superiore (si veda il seguente Web Server Prerequisites per le estensioni PHP richieste
  • Database MySQL 4.23, ma è raccomando utilizzare per ragioni di performance la versione 5.5.x, in alternativa è possibile utilizzare il DBMS MariaDB (a riguardo si veda Database server Prerequisites)

Dal momento che come viene riportato in Database server Prerequisites, GLPI utilizza l’engine MyISAM non è possibile al momento utilizzare SQL Server come DBMS in quanto quest’ultimo utilizza un engine derivato da quello di Sybase SQL Server frutto di una partnership tra Microsoft e Sybase del 1987 (per maggiori dettagli sulla storia dell’evoluzione dell’engine di SQL Server si veda SQL MythBusters – “SQL Server is really a Sybase product not a Microsoft one.”).

Scenario d’installazione

Nel seguente articolo GPLI sarà installato su IIS 8.5 in Windows Server 2012 R2 utilizzando Microsoft Web Platform Installer 5.0 per installare la versione PHP 7.1.1 a 64 Bit, mentre per quanto riguarda il DBMS sarà installato MariaDB 10.2.6 a 64 Bit.

La scelta di non utilizzare MySQL ma MariaDB che è uno dei fork del primo, nato il 29 ottobre 2009, e scritto dagli sviluppatori originali di MySQL dipende dal fatto di utilizzare un DBMS totalmente OpenSource dal momento che andrà a supporto di un applicativo Open Source qual è GLPI. MySQL infatti dalla versione 5.5 include estensioni non Open Source disponibili solo nella versione Enterprise, tale evoluzione di MySQL è frutto dell’acquisizione di Sun Microsystems da parte di Oracle avvenuta il 27 gennaio 2010 (per quanto riguarda l’evoluzione di MySQL e la nascita MariaDBa riguardo si vedano le relative pagine su Wikipedia). In conseguenza al fatto che MySQL non è più un DBMS solo Open Source (esistono infatti due versioni quella Open Source denominata MySQL Community Server e quella proprietaria denominata Enterprise Server) ha portato vari progetti Open Source a sostituire MySQL con MariaDB, come ad esempio Wikipedia (a riguardo si veda Wikipedia Adopts MariaDB) e alcune distribuzioni Linux quali ad esempio Fedora e RedHat (a riguardo si veda Oracle who? Fedora & openSUSE will replace MySQL with MariaDB).

Per quanto riguarda i prerequisiti hardware dovranno essere rispettati almeno quelli consigliati per il sistema operativo (a riguardo si veda System Requirements and Installation Information for Windows Server 2012 R2):

  • Processore almeno 1.4 GHz a 64-bit
  • 1024 MB di Ram e nel caso una macchina virtuale in Hyper-V è preferibile utilizzare la memoria statica
  • 32 GB per il volume dedicato al sistema operativo, è preferibile installare GLPI e il relativo database su un volume dedicato

Dal momento che i vari pacchetti d’installazione di PHP e MariaDB sono disponibili solo in lingua Inglese è consigliabile installare anche il sistema operativo in lingua Inglese configurando le impostazioni del formato data e ora per la nazionalità italiana. Al termine dell’installazione aggiornare il sistema installando gli aggiornamenti necessari.

Per la documentazione relativa a GLPI si faccia riferimento al Wiki del progetto, mentre per ulteriori informazioni sui prerequisiti si veda https://github.com/glpi-project/glpi mentre per informazioni sui changelog delle varie versioni si veda https://github.com/glpi-project/glpi/releases

Installazione del ruolo Web Server (IIS)

Installare il ruolo Web Server (IIS) con le impostazioni di default, al termine dell’installazione aggiornare il sistema installando gli eventuali aggiornamenti necessari.

Come indicato nei seguenti non è possibile (fatta esclusione per alcune cartelle) spostare IIS su un volume dedicato in quanto IIS è un componente di sistema:

Installazione PHP

Il modo più pratico per installare PHP è quello di utilizzare il Microsoft Web Platform Installer, attualmente è disponibile la versione 5.0 che va installata prima di poter avviare l’installazione del PHP. Per avviare l’installazione del Microsoft Web Platform Installer occorre prima disabilitare la funzionalità IE Enhanced security Configuration per il gruppo Administrators (terminata l’installazione sarà possibile riabilitare tale funzionalità).

Una volta installato il Microsoft Web Platform Installer sarà possibile installare PHP selezionando PHP 7.1.1 a 64 Bit tra i prodotti del gruppo Frameworks

L’installazione comporterà l’installazione di ulteriori package e features:

Per verificare la funzionalità di PHP è possibile creare un file phpinfo.php in %SystemDrive%\inetpub\wwwroot col seguente contenuto:

<?php phpinfo(); ?>

Aprire poi la pagina http://localhost/phpinfo.php che mostrerà le informazioni di configurazione tra cui il percorso del file ini di configurazione per default in (%ProgramFiles%\PHP\v7.1\php.ini)

Abilitazione dell’estensione PHP FileInfo e verifica delle configurazioni nel php.ini

Modificare il file %ProgramFiles%\PHP\v7.1\php.ini aggiungendo nella sezione [ExtensionList] le seguenti impostazioni:

extension=php_fileinfo.dll

zend_extension=php_opcache.dll

Come indicato nel seguente Web Server Prerequisites verificare che le seguenti variabili nel file %ProgramFiles%\PHP\v7.1\php.ini rispettino le seguenti indicazioni (le impostazioni predefinite dovrebbero essere coerenti a tali indicazioni):

memory_limit = 64M ; // Minimum Value
file_uploads = on ;
max_execution_time = 600 ; // Optional but not mandatory
register_globals = off ; // Optional but not mandatory
magic_quotes_sybase = off ;
session.auto_start = off ;
session.use_trans_sid = 0 ; // Optional but not mandatory

La versione 9.14 di GLPI richiede l’estensione apcu-bc che richiede a sua volta l’estensione APCu che può essere scaricata al seguente https://pecl.php.net/package/APCu, al momento l’ultima versione è la 5.1.8 ed occorre scaricare la release per PHP 7.1 Non Thread Safe (NTS) x64 dal momento che il PHP in IIS è configurato con l’opzione Thread Safety a disabled come suggerito in http://windows.php.net/:

“If you are using PHP as FastCGI with IIS you should use the Non-Thread Safe (NTS) versions of PHP.”

Dopo aver scaricato l’estensione apcu, scompattarla e copiare la libreria php_apcu.dll in %ProgramFiles%\PHP\v7.1\ext e quindi modificare il file %ProgramFiles%\PHP\v7.1\php.ini aggiungendo nella sezione [ExtensionList] la seguente impostazione:

extension=php_apcu.dll

Dopo aver attivato l’estensione APCu è possibile scaricare l’estensione apcu-bc al seguente https://pecl.php.net/package/apcu_bc, al momento l’ultima versione è la 1.0.3 ed occorre scaricare la release per PHP 7.1 Non Thread Safe (NTS) x64 perché come visto precedentemente IIS è configurato con l’opzione Thread Safety a disabled.

Dopo aver scaricato l’estensione apcu-bc scompattarla e copiare la libreria php_apc.dll in %ProgramFiles%\PHP\v7.1\ext e quindi modificare il file %ProgramFiles%\PHP\v7.1\php.ini aggiungendo nella sezione [ExtensionList] la seguente impostazione:

extension=php_apc.dll

Nel caso dopo l’installazione di GLPI si notino malfunzionamenti nella visualizzazione delle pagine è possibile disabilitare le estensioni APCu e apcu-bc commentando l’attivazione delle estensioni nel file php.ini dal momento che è un requisito opzionale

Per ulteriori informazioni sulle estensoni PHP in Windows si veda Installation of extensions on Windows.

Terminata l’editazione del file %ProgramFiles%\PHP\v7.1\php.ini riavviare IIS tramite lnternet Information Services (IIS) Manager (InetMgr.exe) o mediante il seguente comando:

iisreset /restart

Installazione del DBMS MariaDB

Scaricare dal sito http://mariadb.org (la pagina di download è disponibile al seguente https://downloads.mariadb.org/) il package per piattaforma Windows a 64 Bit dell’ultima versione di MariaDB, al momento l’ultima versione stabile è la 10.2.6 (mariadb-10.2.6-winx64.msi), come riportato la versione 10.2 ha oltre alla features di MySQL 5.6 & 5.7 anche nuove funzionalità. Sebbene esista anche un package ZIP (mariadb-10.2.6-winx64.zip) questo è indicato solo per semplici scenari di test, ma è meno preformante dell’installazione come servizio e meno sicuro, a riguardo si veda Installing MariaDB Windows ZIP Packages.

Avviare l’installazione di MariaDB 10.2.26 64 Bit eseguendo il package msi con le seguenti impostazioni (per la documentazione sulla procedura d’installazione si veda Installing MariaDB MSI Packages on Windows).

Accettare l’installazione delle funzionalità di default.

Selezionare Database instance per impostare il path dei file di dati tramite il pulsante Browse, nello scenario di esempio saranno memorizzati in S:\MariaDB 10.2\data.

Impostare la password dell’utente root che dovrà essere utilizzato solo motivi amministrativi

Impostare le proprietà dell’istanza configurandola come servizio come raccomandato e se non è necessario connettersi remotamente al DBMS disabilitare l’opzione di networking (come nel caso dello scenario di esempio in quanto GLPI sarà installato sullo stesso server), in questo caso per la connessione al database sarà utilizzato named pipes. GLPI per ora non utilizza InnoDB a riguardo si vedano Closing ticket time issue #1150 e Change storage engine to innodb #644.

Per informazioni sulle impostazioni si vedano le seguenti note riportate in Installing MariaDB MSI Packages on Windows:

Per modificare successivamente le impostazioni è possibili intervenire successivamente editando il file my.ini memorizzato nella directory d’installazione (nello scenario di esempio S:\MariaDB 10.2\data), per informazioni sulla configurazione tramite file d’impostazioni si vedano:

Per connettersi all’istanza di MariaDB è possibile utilizzare HeidiSQL, installato per default insieme a MariaDB, configurando una connessione localmente tramite named pipe, come nello scenario d’esempio.

Installazione dell’applicazione GLPI

Scaricare l’ultima versione di GLPI dal sito http://glpi-project.org (la pagina di download è disponibile al seguente http://glpi-project.org/spip.php?article41), al momento l’ultima versione è la 9.1.4 (glpi-9.1.4.tgz). Estrarre il package tgz, ad esempio tramite 7Zip, e copiare la cartella glpi in locale, nello scenario di esempio verrà copiata in S:\glpi-9.1.4\glpi. Quindi creare in IIS all’interno del Default Web Site una Virtual Directory che punta alla cartella gpli in modo da mantenere l’applicazione su un volume diverso da quello del sistema operativo.

Aprire il sito http://localhost/glpi per eseguire la prima parte dell’installazione di GLPI che creerà il database.

Selezionare la localizzazione italiana.

Accettare la licenza (GNU General Public License Versione 2).

Selezionare Installa.

Controllare che tutte le verifiche siano eseguite con successo.

Inserire le credenziali per accedere all’istanza locale (.)del DBMS MariaDB tramite named pipe con l’account root per creare il database.

Creare un nuovo database, nello scenario di esempio sarà denominato glpi.

Attendere la creazione del database.

Attendere il termine dell’istallazione.

Terminata l’installazione sarà possibile accedere a GLPI tramite la pagina http://localhost/glpi autenticandosi con l’account di amministrazione di default (username=glpi e password=glpi) per iniziare a configurare l’applicazione.

Per ragioni di sicurezza cancellare il seguente file: install/install.php (nello scenario di esempio S:\glpi\install\install.php) e modificare le password degli utenti predefiniti glpi, post-only, tech e normal.

Creazione di un utente per l’accesso al database di GLPI da parte dell’applicazione

Creare tramite HeidiSQL un utente che verrà poi utilizzato dall’applicazione GLPI per accesso locale con soli i privilegi sul database di GLPI, nello scenario di esempio il database è denominato glpi mentre l’utente sarà denominato UsrGLPI.

Impostare le credenziali dell’utente per l’accesso al database GLPI tramite la seguente procedura:

  • Arrestare IIS tramite Internet Information Services (IIS) Manager o mediante il comando: iisreset /stop
  • Impostare le credenziali dell’utente nel file config\config_db.php (nello scenario di esempio S:\glpi-9.1.4\glpi\config\config_db.php)
  • Avviare IIS tramite Internet Information Services (IIS) Manager o mediante il comando: iisreset /start

Gestione dei Plugin

Come anticipato all’inizio dell’articolo le funzionalità di GLPI possono essere estese tramite plugins sviluppati da volontari che contribuiscono al progetto, per il catalogo dei plugins disponibili si veda la Plugin directory, mentre se si intende cimentarsi nello sviluppo di un plugin è possibile trovare informazioni utili ai seguenti:

Per quanto riguarda l’installazione di un plugin l’operazione è descritta al seguente Plugin installation Procedure in GLPI e consiste nelle seguenti operazioni:

  1. Eseguire un backup del database (tramite il menù Amministrazione\Manutenzione)
  2. Scaricare il plugin dalla directory GLPI plugins verificando che sia compatibili con la versione di GLPI installata
  3. Estrarre il file .tar.gz in una sottocartella col nome del plugin nella directory glpi/plugins dell’applicazione, per estrarre i file .tar.gz è possibile utilizzare ad esempio 7Zip (il nome della cartella del plugin deve rispettare quello presente all’interno del file .tar.gz altrimenti il plugin potrebbe non funzionare correttamente)
  4. Eseguire il Log off ed un successivo Log in
  5. Installare il plugin tramite il menu Configurazione\Plugins selezinando Installa in corrispondenza del plugin
  6. Attivare il plugin selezinando Attiva in corrispondenza del plugin

Alcuni plugin necessitano di modifiche al database, che verranno eseguite al primo avvio dello stesso, oppure possono essere necessarie configurazion, in questo caso vi saranno avvisi nella pagina dell’installazione/attivazione del plugin.

L’aggiornamento di un plugin è sostanzialmente simile all’installazione, ma con le precauzioni necessarie per consentire un eventuale ripristino alla versione precedente, di seguito le operazioni da eseguire:

  1. Eseguire un backup del database (tramite il menù Amministrazione\Manutenzione) o delle tabelle create dal plugin che dovrebbero essere specificate nel file readme nella directori del plugin syessto (glpi/plugins/<pluginName>)
  2. Rinominare la directory del plugin per esempio da glpi/plugins/<pluginName> a glpi/plugins/<pluginName-Versione>
  3. Procedere nuovamente all’installazione del plugin come visto precedentemente

Se si intende invece rimuovere un plugin è possibile procedere come segue:

  1. Eseguire un backup del database (tramite il menù Amministrazione\Manutenzione)
  2. Accedere all’elenco dei plugin installati tramite il menu Configurazione\PluginsS
  3. Selezionare Disinstalla in corrispondenza del plugin da rimuovere

Si noti che ovviamente l’utilizzo dei plugin comporterà il controllo che questi siano supportati anche nelle future release di GLPI quanto verranno rilasciate e si deciderà di installarle.

Conclusioni

Grazie al Microsoft Web Platform Installer 5.0 che permette di installare velocemente applicazioni PHP in Windows l’installazione di GLPI si risolve velocemente. Con Windows Server 2016 e la sua integrazione nativa con i container Docker tale installazione potrà ulteriormente essere semplificata. Su GitHub sono infatti presenti vari progetti con la finalità di realizzare container Docker per GLPI, si veda ad esempio driket/docker-glpi – Deploy GLPI (any version) with Docker.

Implementare Workgroup Cluster e Multi-Domain Cluster in Windows Server 2016

Mentre nelle precedenti versioni di Windows Server era necessario che tutti i nodi di un cluster fossero joinati ad un dominio di Active Directory, in Windows Server 2016 è stata introdotta la possibilità di creare cluster usando dei nodi in workgroup, permettendo quindi di non dover utilizzare un dominio ed implementare dei domain controller.

Nota: Con Windows Server 2016 è inoltre possibile creare cluster i cui nodi appartengono a domini diversi.

Per implementare un workgroup cluster o un multi-domain cluster è necessario però che vengano rispettati determinati prerequisiti:

  • Creare un account utente con lo stesso nome e la stessa password su tutti i nodi
  • Aggiungere l’account creato al gruppo Administrators locale
  • Se non si utilizza l’account predefinito Administrator è necessario creare la chiave di registro LocalAccountTokenFilterPolicy in HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System e metterla con valore 1
  • Il cluster deve essere creato nella modalità Active Directory-Detached Cluster, senza creare nessun oggetto in AD
  • È necessari creare il Cluster Network Name (chiamato anche Administrative Access Point) di tipo DNS
  • Ogni nodo deve avere un suffisso DNS
  • Nel caso di un multi-domain cluster, i suffissi DNS per tutti i domini del cluster devono essere presenti su tutti i nodi
  • Il Witness consigliato è un Cloud Witness oppure un Disk Witness. Non è supportato in entrambi i casi l’utilizzo del File Share Witness.

In questo articolo creeremo un workgroup cluster a due nodi (chiamati NODO1 e NODO2) utilizzando Windows Server 2016. Dopo aver preparato i nodi del cluster ed aver installato il sistema operativo ho provveduto a configurare il suffisso DNS su entrambi i nodi, come mostrato in figura:

Figura 1: Modifica del suffisso DNS

Dopo aver riavviato entrambi i nodi, ho provveduto a modificare il file HOSTS sulle macchine in modo tale che potessero risolvere i nomi dei nodi e il nome del cluster (che ho deciso di chiamare WRKGCLUSTER). Questa operazione è necessaria solo se non volete configurare un DNS. Nel caso abbiate un DNS in rete potete popolare la zona scelta (il suffisso DNS) per il vostro cluster (nel mio caso demo.lab).

Figura 2: Modifica del file HOSTS per la risoluzione del nomi

Ho provveduto quindi a creare su entrambi i nodi l’account di servizio ClusterSVC, ho impostato la stessa password e l’ho aggiunto al gruppo Administrators locale, come mostrato in figura:

Figura 3: Creazione dell’account per l’autenticazione NTLM

L’account è necessario affinché i nodi utilizzino l’autenticazione NTLM. Poiché non sto usando l’account Administrator è necessario inserire sui nodi la chiave di registro indicata nei prerequisiti. In maniera rapida ho eseguito sui due nodi, da un prompt PowerShell con privilegi elevati, il comando:

New-ItemProperty -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1

Figura 4: Inserimento della chiave di registro necessaria all’utilizzo degli account

Successivamente ho provveduto ad installare la feature del Failover Cluster sui due nodi. È possibile usare il Server Manager oppure il comando PowerShell
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Figura 5: Installazione della funzionalità di Failover Cluster tramite PowerShell

Terminata l’installazione ho avviato il Failover Cluster Manager e ho lanciato il wizard per la creazione del Cluster. Ho aggiunto i due nodi e ho cliccato su Next, come mostrato in figura:

Figura 6: Aggiunta dei due nodi

Nella schermata successiva ho deciso di lanciare il Validate Configuration Wizard che ovviamente mi ha riportato dei Warning, come mostrato in figura:

Figura 7: Validate Configuration Wizard

Figura 8: Warning relativo alla non appartenenza dei nodi del cluster al dominio

Nella schermata successiva del wizard ho indicato il nome del cluster e l’indirizzo IP scelto, come mostrato in figura:

Figura 9: Scelta del nome del cluster e dell’indirizzo

Terminata la verifica che non ci sia un server con lo stesso nome NETBOIS e non ci siano indirizzi IP duplicati nella stessa rete, appare la schermata riepilogativa mostrata in figura, che indica che il cluster utilizzerà per la registrazione solo il DNS:

Figura 10: Schermata riepilogativa relativa alla creazione del cluster

La stessa operazione poteva essere effettuata utilizzando il comando PowerShell

New-Cluster –Name WRKGCLUSTER.demo.lab -Node NODO1.demo.lab,NODO2.demo.lab -AdministrativeAccessPoint DNS -StaticAddress 10.10.0.5


Al termine della procedura ho ottenuto la schermata finale dell’avvenuta creazione del cluster

Figura 11: Creazione del cluster completata

Figura 12: Nodi del cluster attivi

Conclusioni

I Workgroup Cluster e i Multi-Domain Cluster sono decisamente un’importante novità introdotta in Windows Server 2016. I workload supportati sono SQL Server, File Server e Hyper-V. Per quanto riguarda Hyper-V la mancanza dell’autenticazione Kerberos in realtà complica le cose in quanto la Live Migration non è supportata, mentre è supportata la Quick Migration.

Privileged Access Management e Temporary Group Membership in Windows Server 2016 AD

Privileged Access Management (PAM) è una funzionalità introdotta in Windows Server 2016 che si basa sul principio dell’amministrazione Just In Time (JIT) e che permette di gestire quella che viene chiamata Just Enough Administration (JEA), che ha come scopo quello di aumentare la sicurezza nella gestione e nella delega dei privilegi in Windows Server.

JEA è un toolkit di Windows PowerShell che definisce un set di comandi per l’esecuzione di attività con privilegi. Limitando nel tempo i privilegi amministrativi è possibile anche aumentare il livello di sicurezza perché molto spesso si assegnano privilegi elevati e successivamente questi privilegi non vengono rimossi, o per dimenticanza o banalmente perché si sottovaluta il pericolo derivante dalla non adozione della modalità amministrativa del Least Administrative Privilege.

Se dobbiamo concedere ad esempio al gruppo di Help Desk o al consulente esterno di effettuare operazioni privilegiate adesso possiamo fare in modo che ci sia un limite di tempo all’appartenenza ad un gruppo amministrativo. Stesso discorso vale se dobbiamo eseguire degli script con un utente particolare.

Privileged Access Management (PAM) contribuisce quindi a risolvere il problema dell’accesso alle risorse di Active Directory ed evitare che gli autori di un attacco informatico possano ottenere le credenziali degli account amministrativi.

Prerequisiti

Per poter utilizzare PAM è necessario prima di tutto che il livello funzionale dalla Foresta di Active Directory sia Windows Server 2016. Inoltre PAM è una funzione che va abilitata, perché non è attiva di default.

Per verificare il livello funzionale della foresta e del dominio potete utilizzare la console Active Directory Administrative Center, come mostrato in figura:

Figura 1: Innalzamento del livello funzionale del Dominio e della Foresta

In alternativa potete anche usare i seguenti comandi PowerShell:

#Get the Active Directory Forest functional level

(Get-ADForest).ForestMode

#Get the Active Directory Domain functional level

(Get-ADDomain).DomainMode

Figura 2: Uso di PowerShell per la verifica dei livelli funzionali di dominio e di foresta

Per innalzare il livello funzionale del dominio e della foresta potete anche usare i comandi PowerShell:

#Raise livello funzionale del dominio a Windows 2016

Set-ADDomainMode -Identity demo.lab -DomainMode Windows2016

#Raise livello funzionale della foresta a Windows 2016

Set-ADForestMode -Identity demo.lab -ForestMode Windows2016

Abilitazione della funzionalità Privileged Access Management (PAM)

Una volta che vi siete accertati che la Foresta abbia il livello funzionale Windows Server 2016, potete installare la funzionalità PAM solo utilizzando PowerShell:

#Abilitazione della funzionalità Privileged Access Management (PAM)

Enable-ADOptionalFeature “Privileged Access Management Feature” -Scope ForestorconfigurationSet -Target demo.lab

Figura 3: Abilitazione della funzionalità Privileged Access Management (PAM)

Nota: Una volta abilitata la funzionalità non è possibile disabilitarla.

Per verificare se la funzionalità sia stata già installata è possibile usare la cmdlet

#Verifica dell’installazione della funzionalità Privileged Access Management (PAM)

Get-ADOptionalFeature “Privileged Access Management Feature”

Figura 4: Verifica dell’installazione della funzionalità Privileged Access Management (PAM) tramite PowerShell

Assegnazione temporanea dell’appartenenza di un utente ad un gruppo di Active Directory

Per poter assegnare temporaneamente uno o più utenti ad un gruppo di AD è necessario effettuare i seguenti comandi PowerShell:

#Definisco la durata di appartenenza al gruppo

$durata New-TimeSpan -Minutes 20

#Aggiungo al gruppo Domain Admind due utenti (attualmente Domain Users)

Add-ADGroupMember -Identity “Domain Admins” -Members nicferr,hector -MemberTimeToLive $durata

Figura 5: Aggiunta di due utenti al gruppo Domain Admins

Per verificare che i due utenti appartengano al gruppo Domain Admin vi basta poi lanciare la cmdlet

Get-ADGroup “Domain Admins” -Property Member -ShowMemberTimeToLive


Figura 6: Verifica dell’appartenenza al gruppo Domain Admins

Come si può notare dalla figura sopra, il risultato riporta:

Member : {<TTL=1068>,CN=Ettore Ferrini,CN=Users,DC=demo,DC=lab, <TTL=1068>,CN=Nicola Ferrini,CN=Users,DC=demo,DC=lab, CN=Administrator,CN=Users,DC=demo,DC=lab}

Accanto ai nomi dei due utenti aggiunti al gruppo Domain Admins c’è un campo TTL (espresso in secondi), che indica la durata rimanente dell’appartenenza al gruppo stesso.

Conclusioni

Privileged Access Management (PAM) è una funzionalità concepita appositamente per gli account amministrativi. Gli amministratori (o gli script) che necessitano solo occasionalmente dell’accesso per gruppi con privilegi, possono richiedere questo accesso e mantenerlo per un periodo limitato di tempo, garantendo la modalità amministrativa del Least Administrative Privilege ed aumentando di fatto la sicurezza della nostra infrastruttura di Active Directory.

Per maggiori informazioni vi rimando all’articolo https://docs.microsoft.com/it-it/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services

Configurare diversi indirizzi IP per la stessa scheda di rete nelle VM in Microsoft Azure

Una delle novità più interessanti in ambito Networking riguardo Microsoft Azure è stata presentata pochi giorni fa nell’annuncio General availability: Multiple IP addresses per network interface

Trovo questa funzionalità particolarmente interessante perché risolve diversi problemi che mi avevano posto alcuni clienti. Ad esempio una web agency che ha creato diversi web server in Microsoft Azure ha bisogno di far girare diversi siti web e servizi con differenti indirizzi IP e certificati digitali sulla stessa scheda di rete della VM.

Questo tipo di funzionalità è utilizzabile per poter creare dei bilanciatori di carico o dei firewall utilizzando macchine virtuali gestite da noi.

È anche disponibile da pochissimi giorni la possibilità di avere almeno due schede di rete in tutte le macchine virtuali (Windows e Linux) create in Azure, come annunciato in General availability: Dual network interfaces for all Azure VMs

Per poter assegnare alla stessa scheda di rete due indirizzi IP diversi è sufficiente collegarsi al portale di Azure, selezionare la VM da modificare e cliccare sulla scheda di rete utilizzata dalla VM, come mostrato in figura:

Figura 1: Selezione dell’interfaccia di rete da modificare per la VM

Dopo aver cliccato sull’interfaccia di rete interessata, nel nuovo blade che vi si aprirà selezionate IP Configurations e cliccate sul pulsante Add per aggiungere un nuovo indirizzo, come mostrato in figura:

Figura 2: Blade IP Configurations per la scheda da modificare

Nel Blade Add IP configuration scegliete un nome simbolico per l’indirizzo IP da aggiungere, scegliete se volete mantenere statico o dinamico l’indirizzo IP privato (vi consiglio di mantenerlo statico) e successivamente scegliete se volete abilitare l’indirizzo IP Pubblico, come mostrato in figura:

Figura 3: Aggiunta del secondo indirizzo IP pubblico

Una volta completata la procedura ed assegnato il nome al secondo indirizzo IP pubblico vi verrà mostrata la schermata con gli indirizzamenti per la vostra scheda di rete, come mostrato in figura:

Figura 4: Indirizzamenti IP privati e pubblici per la scheda di rete della VM

Avete un numero limitato di indirizzi IP privati e pubblici da assegnare, come documentato dall’articolo https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits?toc=%2fazure%2fvirtual-network%2ftoc.json#azure-resource-manager-virtual-networking-limits

Per completare l’operazione è necessario collegarsi in desktop remoto alla macchina virtuale ed assegnare gli indirizzi privati manualmente. Se infatti eseguite il comando ipconfig /all all’interno della VM vedrete che verrà visualizzato solo l’indirizzo primario, come mostrato in figura:

Figura 5: Presenza solo dell’indirizzo Primario assegnato alla scheda di rete della VM

Modificate le proprietà della scheda di rete aggiungendo manualmente gli indirizzi IP interni che avete assegnato staticamente nel portale di Azure, come mostrato in figura:

Figura 6: Assegnazione statica degli indirizzi privati scelti

Dopo aver assegnato gli indirizzi (attenti a non sbagliare perché altrimenti non vi riconnetterete più alla VM) la connessione in desktop remoto potrebbe disconnettersi per un secondo, ma poi sarete nuovamente collegati.

Rilanciando il comando ipconfig /all potrete verificare che adesso la scheda di rete ha i due IP interni che avete assegnato, come mostrato in figura:

Figura 7: Scheda di rete con doppio indirizzo IP interno

La macchina virtuale sarà raggiungibile in Desktop remoto su tutti gli indirizzi pubblici che avete assegnato, in quanto le regole di firewall sono definite dallo stesso Network Security Group.

Volendo è possibile dare un’occhiata alle proprie configurazioni di rete utilizzando lo strumento Network Watcher, che è possibile abilitare per ogni regione. Cliccate su Monitor nella Dashboard e abilitate il Network Watcher per le regioni disponibili per la vostra sottoscrizione.

Figura 8: Abilitazione del Network Watcher

Tra le funzionalità messe a disposizione del Network Watcher c’è la visualizzazione della Topologia del proprio scenario di rete, che mostra le varie interconnessioni e le associazioni tra le risorse di rete in un gruppo di risorse. Dal menù a tendina in alto scegliete la vostra sottoscrizione, il resource group e la scheda di rete da monitorare e vi verrà creata automaticamente la topologia di rete, con le diverse connessioni, come mostrato in figura:

Figura 9: Topologia di rete creata col Network Watcher

Conclusioni

La possibilità di avere due schede di rete su tutte le macchine virtuali in Azure e assegnare alla stessa scheda di rete diversi indirizzi IP, sia pubblici che privati, ci permette di implementare degli scenari di networking anche complesso che finora non era possibile realizzare. Creare bilanciatori di carico e firewall con le macchine virtuali su Azure non è mai stato così facile!

Blog italiani (e in italiano) nel mondo IT/ICT